Windows 8 Touch Support

[tjvantoll]

No description provided.

[tjvantoll]

For draggable and sortable this isn't ideal as it applies touch-action: none to the entire element, when it's possible that only part of the element can initiate a drag because of the handle option.

Currently the handle logic for both widgets happens after mouse events occur - which is too late to apply touch-action. We could introduce a class name that is applied on initialization - e.g. ui-draggable-handle and ui-sortable-handle - then apply touch-action: none to that instead of the whole element. Thoughts?

[scottgonzalez]

Missing newline at EOF.

[scottgonzalez]

Oh boy. Our CSS linter don't know about touch-action.

[scottgonzalez]

Ping @georgestephanis who pinged me about this earlier.

[tjvantoll]

Oh boy. Our CSS linter don't know about touch-action.

Even the most recent version (0.2.0) of the linter has this issue. touch-action is specced so this is a bug. I'll create an issue for the task. Not sure how we'll work around the issue though.

[georgestephanis]

Yup. I'd maybe rather see this set in JS rather than CSS, as that way it won't necessarily clutter up non-IE browsers.

WordPress Core had initially dealt with this here:

http://core.trac.wordpress.org/ticket/22583
http://core.trac.wordpress.org/changeset/22866

and then refined it to the handles here:

http://core.trac.wordpress.org/ticket/26297
http://core.trac.wordpress.org/changeset/26715

It's easy to hit in JS, though --

if ( typeof el.style.msTouchAction != 'undefined' ) el.style.msTouchAction = "none";

-- and that would just need to be on the elements that the dragging should activate on -- either the full element or just the handle. If there's not a good class applied, this is probably easier than adding a new class just for IE 10/11 Touch?

[georgestephanis]

The JS above may need to switch and also do

if ( typeof el.style.touchAction != 'undefined' ) el.style.touchAction = "none";

to handle the unprefixed version.

[scottgonzalez]

Well, it's not just going to be IE 10/11 touch, it's presumably going to be all browsers (potentially sans Safari) at some point.

[scottgonzalez]

I suppose if it's only affecting touch devices right now that might mean that this will continue to only be touch devices in the future, but it should certainly apply to more browsers in the future. Blink is actively working on this, so that would include Chrome and Opera. I think Firefox is working on this already, but at a minimum it's planned. Apple hasn't expressed any interest in Pointer Events, but members of the Blink team are trying to get touch action into Touch Events for WebKit, so this could affect Safari too at some point.

[georgestephanis]

True. I'd be fine with either resolution -- if it's adding new stylesheets, though, we'd definitely need to add some classes to target specifically, like...

.ui-draggable .ui-item,
.ui-sortable .ui-item {
    -ms-touch-action: none;
    touch-action: none;
}
.ui-with-handles .ui-item {
    -ms-touch-action: auto;
    touch-action: auto;
}
.ui-with-handles .ui-handle {
    -ms-touch-action: none;
    touch-action: none;
}

as if we set it on the entire containing element, then it can nerf the user's ability to drag the page on the touch device if they're touching anywhere in the containing element -- even if not on an item in it.

[tjvantoll]

The reason I prefer a class name is it makes it far easier to clean up in destroy(). The problem is, if the handle option isn't used, you'd have to apply a class name like ui-draggable-handle to the main element, which seems odd. Sortable is further complicated by its items option.

Maybe we can use something generic like ui-touch-target for draggable and sortable?

[georgestephanis]

Not really. As long as there's a .ui-with-handles class (or the like) on the parent, you can negate the none by resetting it to auto in a subsequent rule, as I did above ^^

[tjvantoll]

Ah ok. I don't think I'll get a good sense for which of these approaches is going to work best without trying them out. I'll play around this weekend and see what I can come up with.

[tjvantoll]

I just pushed the best I could come up with. I also started the process to get our linter to recognize touch-action with CSSLint/parser-lib#98.

[tjvantoll]

https://github.com/nzakas/parser-lib/ was updated so grunt runs error free now. This is ready for review.

[scottgonzalez]

this.options.handle || this.element

[scottgonzalez]

It looks like sortable still needs to handle new items being introduced via .refresh().

[tjvantoll]

All changes have been made. Good catch on refresh().

[scottgonzalez]

Just some minor changes and we're good to go.

@georgestephanis Does this look good to you?

[georgestephanis]

Looks reasonable from a quick skim, I've explicitly loaded/tested it yet though.

I'm going to try spinning it up over the weekend to confirm everything's running well.

[tjvantoll]

I didn't mean to close the pull request; I hit the wrong button. o_O

@scottgonzalez The final few changes have been made.

@georgestephanis Thanks for trying this out. You'll have to let us know how it goes. Assuming all is well I'll land this.

[scottgonzalez]

@georgestephanis Did you get a chance to test this over the weekend?

[georgestephanis]

Just verified, and everything seems to be operating correctly from what I can tell. 👍

[georgestephanis]

Made a ticket in WordPress trac to drop our polyfill for this once it gets merged in.

https://core.trac.wordpress.org/ticket/26843

[tjvantoll]

Thanks for your help @georgestephanis. This is now merged into master and will go out with 1.11.