I am testing a project on my Surface Pro 4 and I am using the Touch interface in javascript. According to MDN, the rotationAngle and force properties should return [0 - 90] and [0.0 - 1.0] respectively.
But no matter how I touch the display, I get fixed values for either of them. In Chrome (81) it is always 0 and 0.5. In Firefox (76), 0 and 0 are returned.
The code is simple:
element.addEventListener('touchstart', function(evt) {
// Prevent the mouse click
evt.preventDefault();
//-- Log the touch information
var touch = evt.changedTouches.item(0);
console.log(touch.radiusX);
console.log(touch.radiusY);
console.log(touch.rotationAngle);
console.log(touch.force);
});
Now, about the force property, MDN specifies that if the value is unknown for some reason (e.g. the device doesn't support it), 0.0 is returned. But nothing is mentioned about a constant 0.5 for this property or 0 for the rotationAngle.
Am I missing something? Or does the Surface Pro 4 indeed not support these values and I can not do anything about it?
I'm building a React app where the user is shown 2 numbers on the screen on the left and right side of the screen respectively. The user is then prompted to press a button on the left or right side of the keyboard with which he/she indicates which of the 2 shown numbers is larger.
My issue is that is there a smarter way of determining the side of the key input other than literally just making an if(); statement listing all the key values that you want to be marked as the "left side" and vice versa?
If it helps to narrow down an answer in this case I'd consider anything left from the vertical line "7, U, J, N" to be a left side input and everything right (including said keys) to be the right side inputs.
And I am not allowed to change the way the user can answer in this particular case or I'd have done it by now.
The only input a computer can get from a keyboard is the the key code - which has no indication of the physical position of the key in the keyboard. Although the alphabet is located almost in the same places across all major keyboard layouts, I have seen exceptions.
So, for your program to do the task approximately, one of the ways I can think of is putting the key codes to an array where the left key codes will be placed below the half of the length and right key codes are placed above the half of the array length.
//Mock key codes
var keyPos = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
function isLeft(keyCode) {
return keyPos.indexOf(keyCode) + 1 > keyPos.length / 2
}
You are going to have to get the concept and adjust the code. You may have odd number of keys.
Also, there are many other ways you can do this with arrays. The key is finding the element index and correlate it to the key position.
Today I've discovered some very bizarre behavior in Microsoft's Edge browser, where the deltaX values for wheel events is apparently inverted! This was particularly surprising because this is not consistent with every other browser I've ever tested, including Internet Explorer 11 which returns the expected values.
Seeing this issue in action is rather simple, just run the following code, and use your mouse wheel or trackpad.
window.addEventListener('wheel', function(e) {
console.log(e.deltaX, e.deltaY);
});
For your convenience, I've created a full-page example (snippets are tricky for this):
Fullpage Working Example
Wheeling down gives a positive value and wheeling up gives a negative value as expected in Edge, IE, and other browsers. However, in Edge wheeling left gives a positive value, and right a negative value, the exact opposite of every other browser (IE11 and below included).
I made some GIF videos to show off the issue too, linked for file sizes.
IE11
Edge
The question:
Why is it like this, and is there a solution for handling the browser compatibility issues? Is there a way to feature-detect this? Is this behavior a bug, or is it documented somewhere?
The spec strongly suggests this is in-fact incorrect behavior:
If a user agent scrolls as the default action of the wheel event then the sign of the delta SHOULD be given by a right-hand coordinate system where positive X, Y, and Z axes are directed towards the right-most edge, bottom-most edge, and farthest depth (away from the user) of the document, respectively.
Notes:
I've tested this in both a Windows 10 VM and a native laptop, behavior was the same for both.
I'm reasonably sure this is not related to "natural"/inverted scrolling (off on all systems and VM hosts tested, and only happening on one axis).
On a side note, I don't know if deltaZ is inverted or even supported to begin with, I lack such an input device.
Bug Report:
I've reported the bug to Microsoft here. It has been assigned to someone, so hopefully it will be fixed.
While we await an official response from Microsoft, hopefully in the form of an update that resolves the issue, I have found a way to check if the browser is reporting an incorrectly inverted deltaX.
Edge also added support for the non-standard wheelDeltaX, wheelDeltaY, and wheelDelta properties also found in Chrome. Unlike deltaX, these values are correct, but instead refer to the actual wheel change and not the computed result. While their actual values are of little interest, we can infer the correct sign value from them.
In Chrome, deltaX and wheelDeltaX correctly have different sign values, so when one is negative, the other is positive. This means that if both values are negative or both are positive, the deltaX is incorrectly signed as it is presently in Edge. Therefore we can use this property to detect the incorrectly inverted value and un-invert it.
Here is a wrapper function I created to resolve the issue.
function wheelDeltaX(e) {
// Get the reported deltaX.
var r = e.deltaX;
// In Edge, the deltaX incorrectly matches wheelDeltaX sign.
// If both value signs match then uninvert it.
var wheelDeltaX;
if (
r &&
(wheelDeltaX = e.wheelDeltaX) &&
(
(r < 0 && wheelDeltaX < 0) ||
(r > 0 && wheelDeltaX > 0)
)
) {
r = -r;
}
return r;
}
So long as Edge retains the correct signing for wheelDeltaX when they hopefully fix the issue, this should be future-proof.
I'm trying to determine the proper key/char code in javascript when a key is pressed.
It seems that when the CapsLock key is on, lowercase letters are not detectable.
Try the combinations:
1. a = a (97) shift:false
2. Shift+A = A (65) shift:true
3. Capslock,A = A (65) shift:false
4. Capslock, Shift+A = A (65) shift:true -- this should be 'a'
Cases 2 & 4 are indistinguishable.
A simple fiddle to illustrate the problem.
http://jsfiddle.net/sramam/pet5G/3/
OUTPUT:
keypress 'a' shift:false charCode97 keyCode:97 which:97
keypress 'A' shift:true charCode65 keyCode:65 which:65
(CAPSLOCK ON)
keypress 'A' shift:false charCode65 keyCode:65 which:65
keypress 'A' shift:true charCode65 keyCode:65 which:65
I only have a MacPro(Lion) to try this on.
Is it even possible to detect character to be rendered correctly?
The keypress detection is in fact "correct." The issue you're running into is that on OS X Lion, if you enable caps lock and press shift, it IGNORES caps lock. On Windows, shift + caps lock will return lower case letters. On your Mac, it will return upper case letters. This is not a matter of how the browser interprets a keypress, it's what the operating system registers.
Try typing in ANY application, i.e. Terminal, and you should see what I mean.
This may be the case for other Mac OS versions, I tested this on my MacBook Air w/ OS X Lion.
The keypress code is correct on windows, returning the correct key codes for the letter as it would be printed on keypress.
CAPS LOCK ON:
PRINTED
CHARACTER keyup/down keypress Modifiers
z 90 122 +Shift
a 65 97 +Shift
Z 90 90
A 65 65
caps lock off:
Z 90 90 +Shift
A 65 65 +Shift
z 90 122
a 65 97
The keydown, keyup, and keypress events are supported by all browsers, but there are some interoperability problems because the values of the keyCode property of the event object have never been standardized.
// The legacy keyCode property of the keydown event object is not standardized
// But the following values seem to work for most browsers and OSes.
Keymap.keyCodeToKeyName = {
// Keys with words or arrows on them
8:"Backspace", 9:"Tab", 13:"Enter", 16:"Shift", 17:"Control", 18:"Alt",
19:"Pause", 20:"CapsLock", 27:"Esc", 32:"Spacebar", 33:"PageUp",
34:"PageDown", 35:"End", 36:"Home", 37:"Left", 38:"Up", 39:"Right", 40:"Down", 45:"Insert", 46:"Del",
// Number keys on main keyboard (not keypad)
48:"0",49:"1",50:"2",51:"3",52:"4",53:"5",54:"6",55:"7",56:"8",57:"9",
// Letter keys. Note that we don't distinguish upper and lower case
65:"A", 66:"B", 67:"C", 68:"D", 69:"E", 70:"F", 71:"G", 72:"H", 73:"I", 74:"J", 75:"K", 76:"L", ` 77:"M", 78:"N", 79:"O", 80:"P", 81:"Q", 82:"R", 83:"S", 84:"T", 85:"U", 86:"V", 87:"W", 88:"X", 89:"Y", 90:"Z",`
// Keypad numbers and punctuation keys. (Opera does not support these.)
96:"0",97:"1",98:"2",99:"3",100:"4",101:"5",102:"6",103:"7",104:"8",105:"9", 106:"Multiply", 107:"Add", 109:"Subtract", 110:"Decimal", 111:"Divide",
// Function keys
112:"F1", 113:"F2", 114:"F3", 115:"F4", 116:"F5", 117:"F6", 118:"F7", 119:"F8", 120:"F9", 121:"F10", 122:"F11", 123:"F12", 124:"F13", 125:"F14", 126:"F15", 127:"F16", 128:"F17", 129:"F18", 130:"F19", 131:"F20", 132:"F21", 133:"F22", 134:"F23", 135:"F24",
// Punctuation keys that don't require holding down Shift
// Hyphen is nonportable: FF returns same code as Subtract
59:";", 61:"=", 186:";", 187:"=", // Firefox and Opera return 59,61 188:",", 190:".", 191:"/", 192:"`", 219:"[", 220:"\\", 221:"]", 222:"'"
};
I enjoy working with Google Analytics and the ways that I am able to slice information about our visitors. We use Customer Variables to track information about who and how are users interact with our site. Staying true to the goal of Analytics, we are always looking for ways to improve and optimize our website.
Currently we are in a phase of development where we can make choices about how we want to store and present product information. One of the questions that came up was whether or not to show product information in all caps or not. Working with our users for the last few years, it seems that much of our traffic comes from visitors who do have caps lock on. So it got us thinking, could we track our caps lock users with a customer variable to that we can make a more informed determination about how to present the information?
Check out this sample I slapped together: http://jsfiddle.net/shanabus/Za4kL/
Our site basically represents a standard e-commerce site. There are a few different text boxes and that allow you to search for part numbers and throughout the order process there are a few places where users can type text. Would you bind the caps lock test to all text boxes or just the common ones? Is there a performance hit if I bind the keypress listener to all text boxes on the site or is it negligible? Is there a better way to implement this?
I imagine instead of showing/hiding a div I would instead set the custom var:
_gaq.push('_setCustomVar', 5, 'capslock', 'true', 3);
Thanks for any thoughts and consideration on this seemingly trivial topic.
I'd bind the event globally, and use the following code:
var CAPS_ON = null;
$(window).keypress(function(ev) {
var charCode = ev.which; //jQuery normalizes ev.charCode to ev.which
// Lowercase chars
if (charCode >= 97 && charCode <= 122) {
CAPS_ON = ev.shiftKey; // Caps are off if SHIFT is not pressed
} else if (charCode >= 65 && charCode <= 90) {
CAPS_ON = !ev.shiftKey;
}
});
This creates a variable CAPS_ON, which can be used throughout the page.
Further explanation on the code:
The event has to be bound to the keypress event, because it's the only key event which discerns lowercase/uppercase characters.
The shiftKey property has to be checked, because it inverts the CAPS LOCK feature.