today without breaking backwards
compatibility and cover features that have been discussed as
possible additions previously. Hopefully we can figure out a way to
incorporate them that works for everyone.
--Brandon
--
Patrick H. Lauke
www.splintered.co.uk | ht
style with thinly veiled ad-hominems.
https://twitter.com/JoeSondow/status/692170578023862273
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
resorting to
your sarcastic tone which, frankly, is quite grating and is doing you no
favors in getting at least some of the readership on this list to even
want to engage in your argument.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos
On 28/01/2016 15:45, Chaals McCathie Nevile wrote:
Thanks Art for everything you've done for the group for so long.
Good luck, and I hope to see you around.
+1
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http
web components for fancy styling
(for instance having a material design button that essentially still
works just like a button) - in which case, it makes more sense to work
on stylability of standard elements.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http
primitives we'll be in a much better place.
Isn't that, in a way, what we currently have already?
- default focusable: add tabindex=0
- activatable with certain key commands: define key command handlers
yourself in JS
- announced by AT as a button: role=button
P
--
Patrick H. Lauke
wouldn't work there anyway, so AT attempt to understand
widgets based on their roles a bit more and provide built-in swipe/tap
gestures for certain constructs.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http
/WCAG10/#gl-device-independence
So I think this phrase/naming - which continues the same thinking and
expands it to include further input modalities - is more than
appropriate, as it builds on already established concepts.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com
on the Responsive
buzzword bandwagon is, if nothing else, too late now.
I still favor some form of naming that conveys this is about abstracted
intent.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter
On 12/12/2014 13:40, Simon Pieters wrote:
How about device-independent events?
I always liked input agnostic, but that's probably too religiously
loaded a term for some...
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
, signalling to the browser/OS that it will handle gamepad
input directly, and that default browser/OS mappings should be ignored.
Hope that makes it a tad clearer?
P
On Fri, Mar 14, 2014 at 1:35 AM, Patrick H. Lauke
re...@splintered.co.uk mailto:re...@splintered.co.uk wrote:
No takers on the idea
or navigate somewhere else.
And potentially once the user breaks out, fire a gamepaddisconnected
event?
Thoughts? This is certainly something that the spec should talk about,
since it will impact usage on consoles which is a pretty important use case.
P
--
Patrick H. Lauke
www.splintered.co.uk
#Browser_Modes
There's an argument that this should be left completely up to the UA,
and that users should switch the UA into different modes. However, at
the very least it would be nice then to have a way for a site/app to
*signal* that it can handle direct gamepad input.
Thoughts?
P
--
Patrick H
14 matches
Mail list logo
