Re: [whatwg] Speech input element
Based on the feedback in this thread we've worked out a new speech input proposal that adds a @speech attribute to most input elements, instead of a new . Please see http://docs.google.com/View?id=dcfg79pz_5dhnp23f5 for the new proposal. /Bjorn Bringert & Satish Sampath -- Google UK Limited, Registered Office: Belgrave House, 76 Buckingham Palace Road, London, SW1W 9TQ Registered in England Number: 3977902
Re: [whatwg] Is there a way to stop scrolling when pressing directional arrows?
On Mon, Jun 14, 2010 at 3:56 PM, Simon Pieters wrote:
> On Tue, 15 Jun 2010 00:16:13 +0200, Kornel Lesinski
> wrote:
>
>> On Mon, 14 Jun 2010 20:38:07 +0100, Carlos Andrés Solís
>> wrote:
>>
>>> Hello! I've been noticing a problem in many HTML5 test apps, very
>>> especially games. When the directional arrow buttons are pressed, the screen
>>> scrolls.
>>> This is a problem that, as far as I know, Flash had solved by changing
>>> the focus of the application to the app. Is this doable in HTML5?
>>
>> Yes. It's possible already — page just has to return false from keypress
>> handler:
>>
>> window.onkeypress = function(){return false}
>>
>> That's just one line that, unfortunately, many web-based games forget to
>> include.
>
> If a game is embedded in a page with other content, it could make the
> (or whatever) focusable with tabindex='0' and only disable keys
> when the game has focus. It could also be nice and only disable the keys it
> chooses to use.
>
>
> var mapping = {37: 'left', 38: 'up', 39: 'right', 40:'down'}
> function press(e) {
> if (!e.shiftKey && !e.ctrlKey && !e.metaKey && e.keyCode > 36 && e.keyCode
> < 41) {
> var ctx = e.target.getContext('2d');
> ctx.clearRect(0, 0, e.target.width, e.target.height);
> ctx.fillText(mapping[e.keyCode], 20, 20);
> e.preventDefault();
> }
> }
>
>
>
> In Opera, I can scroll using the arrow keys, navigate to the game, interact
> with it using the arrow keys without it scrolling the page, and navigate
> away from it using spatnav (shift+arrow keys).
Random note: the keypress event isn't interoperably supported in this
area - in IE and webkit-based browsers, keys that don't generate a
character won't generate a keypress event. You can use keydown to
capture the press instead.
~TJ
Re: [whatwg] Form validation against invisible controls
On Mon, Jun 14, 2010 at 3:24 PM, Maciej Stachowiak wrote: > > On Jun 14, 2010, at 3:40 AM, Ian Hickson wrote: > >> On Mon, 14 Jun 2010, Ola P. Kleiven wrote: >>> >>> The following sites have workarounds in Opera's browser.js to allow form >>> submit: >>> >>> airgreenland.com (using required on hidden elements) >>> barnesandnoble.com (using required on visible elements that are supposed to >>> be >>> empty on submit...) >>> bookryanair.com (using required=false - this usage has also been found in JS >>> libraries) >>> ingdirect.com.au (using required on a visible field, but then emptying the >>> field with JS before submit) >>> usairways.com (using required on hidden elements) >>> >>> Most of these have been using it for several years and have not responded to >>> change requests from our side. >>> >>> We have also seen a couple of instances of wrong input types (number >>> where text expected etc.), but the usage of "required" is the biggest >>> problem in my experience. >> >> Incorrect use of "required" in HTML4-era documents also seems to be the >> common problem Chrome ran into -- at the risk of starting a bikeshed >> discussion, does anyone have any good suggestions for alternative names? > > > A few suggestions: > > required-field > value-required This is a pretty short list of sites. I'd really like to avoid renaming the attribute at this point as I strongly suspect that we can get these sites fixed within a few months. It might have been very hard to get these sites to listen when only one browser broke. However in a very short order 4 out of the top 5 browsers will implement the "required" attribute, which should be very strong incentive. I've contacted our evangelism team which in the passed have been pretty successful at getting sites to change, so I'm pretty hopeful we can do that here too. / Jonas
Re: [whatwg] Is there a way to stop scrolling when pressing directional arrows?
On Tue, 15 Jun 2010 00:16:13 +0200, Kornel Lesinski wrote: On Mon, 14 Jun 2010 20:38:07 +0100, Carlos Andrés Solís wrote: Hello! I've been noticing a problem in many HTML5 test apps, very especially games. When the directional arrow buttons are pressed, the screen scrolls. This is a problem that, as far as I know, Flash had solved by changing the focus of the application to the app. Is this doable in HTML5? Yes. It's possible already — page just has to return false from keypress handler: window.onkeypress = function(){return false} That's just one line that, unfortunately, many web-based games forget to include. If a game is embedded in a page with other content, it could make the (or whatever) focusable with tabindex='0' and only disable keys when the game has focus. It could also be nice and only disable the keys it chooses to use. var mapping = {37: 'left', 38: 'up', 39: 'right', 40:'down'} function press(e) {if (!e.shiftKey && !e.ctrlKey && !e.metaKey && e.keyCode > 36 && e.keyCode < 41) {var ctx = e.target.getContext('2d'); ctx.clearRect(0, 0, e.target.width, e.target.height); ctx.fillText(mapping[e.keyCode], 20, 20); e.preventDefault(); } } In Opera, I can scroll using the arrow keys, navigate to the game, interact with it using the arrow keys without it scrolling the page, and navigate away from it using spatnav (shift+arrow keys). -- Simon Pieters Opera Software
Re: [whatwg] Form validation against invisible controls
On Mon, 14 Jun 2010 08:44:09 +0100, Jonas Sicking wrote: Agreed on both accounts. Both these suggestions add a lot of complexity to the platform and we should avoid it if at all possible. To the extent that if there is lots of broken sites out there because they happen to use attribute names that collide with HTML5, but only partially match the HTML5 behavior, then we should consider renaming those attributes in HTML5. I don't agree that there are "lots" of broken sites. My main browser is Opera and I haven't noticed that problem yet. The fact that there are some sites using 'required' attribute proves that it's a good, intuitive name. HTML5 is likely to outlive those broken sites. I think it would be shame to change to worse name for HTML's lifetime just to avoid temporary problem with some sites. -- regards, Kornel Lesiński
Re: [whatwg] Form validation against invisible controls
On Jun 14, 2010, at 3:40 AM, Ian Hickson wrote: > On Mon, 14 Jun 2010, Ola P. Kleiven wrote: >> >> The following sites have workarounds in Opera's browser.js to allow form >> submit: >> >> airgreenland.com (using required on hidden elements) >> barnesandnoble.com (using required on visible elements that are supposed to >> be >> empty on submit...) >> bookryanair.com (using required=false - this usage has also been found in JS >> libraries) >> ingdirect.com.au (using required on a visible field, but then emptying the >> field with JS before submit) >> usairways.com (using required on hidden elements) >> >> Most of these have been using it for several years and have not responded to >> change requests from our side. >> >> We have also seen a couple of instances of wrong input types (number >> where text expected etc.), but the usage of "required" is the biggest >> problem in my experience. > > Incorrect use of "required" in HTML4-era documents also seems to be the > common problem Chrome ran into -- at the risk of starting a bikeshed > discussion, does anyone have any good suggestions for alternative names? A few suggestions: required-field value-required Regards, Maciej
Re: [whatwg] Is there a way to stop scrolling when pressing directional arrows?
On Mon, 14 Jun 2010 20:38:07 +0100, Carlos Andrés Solís
wrote:
Hello! I've been noticing a problem in many HTML5 test apps, very
especially games. When the directional arrow buttons are pressed, the
screen scrolls.
This is a problem that, as far as I know, Flash had solved by changing
the focus of the application to the app. Is this doable in HTML5?
Yes. It's possible already — page just has to return false from keypress
handler:
window.onkeypress = function(){return false}
That's just one line that, unfortunately, many web-based games forget to
include.
--
regards, Kornel Lesiński
Re: [whatwg] Is there a way to stop scrolling when pressing directional arrows?
On Mon, 2010-06-14 at 15:58 -0400, Gordon P. Hemsley wrote: > For what it's worth, I am actually of the opposite opinion, Ash. > > I like it when Flash steals the focus of the keyboard, and here's why: > Besides the arrow keys, which are available to everyone, I also use > the "Find As You Type" feature in Firefox. However, that usually means > that I can't play any HTML5 games that use letters as play keys. > Because the HTML5 game usually doesn't steal the focus of the > keyboard, typing a letter key activates the FAYT feature and distracts > me from the game. > > With that being said, Bespin (from Mozilla Labs) uses , and it > has no problem stealing the keyboard focus (with JavaScript) for most > keypresses. > > Gordon > > > 2010/6/14 Ashley Sheridan > > On Mon, 2010-06-14 at 13:38 -0600, Carlos Andrés Solís wrote: > > > Hello! I've been noticing a problem in many HTML5 test apps, > > very especially games. When the directional arrow buttons > > are pressed, the screen scrolls. This is a problem that, as > > far as I know, Flash had solved by changing the focus of the > > application to the app. Is this doable in HTML5? > > - Carlos Solís > > > > > I don't think it's something that was 'solved' by Flash. To > be honest, I'm often annoyed at the way Flash steals the focus > of all my key presses making it almost impossible to navigate > using only the keyboard. > > You could use Javascript to put the focus onto an object, > capture all the key presses on that and return false for them > all maybe. > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > > > > > > > -- > Gordon P. Hemsley > m...@gphemsley.org > http://gphemsley.org/ • http://gphemsley.org/blog/ > http://sasha.sourceforge.net/ • http://www.yoursasha.com/ It's not that I have it in for Flash, but I feel it's not the most accessibility friendly of things you find on the web. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Is there a way to stop scrolling when pressing directional arrows?
For what it's worth, I am actually of the opposite opinion, Ash. I like it when Flash steals the focus of the keyboard, and here's why: Besides the arrow keys, which are available to everyone, I also use the "Find As You Type" feature in Firefox. However, that usually means that I can't play any HTML5 games that use letters as play keys. Because the HTML5 game usually doesn't steal the focus of the keyboard, typing a letter key activates the FAYT feature and distracts me from the game. With that being said, Bespin (from Mozilla Labs) uses , and it has no problem stealing the keyboard focus (with JavaScript) for most keypresses. Gordon 2010/6/14 Ashley Sheridan > On Mon, 2010-06-14 at 13:38 -0600, Carlos Andrés Solís wrote: > > Hello! I've been noticing a problem in many HTML5 test apps, very > especially games. When the directional arrow buttons are pressed, the screen > scrolls. This is a problem that, as far as I know, Flash had solved by > changing the focus of the application to the app. Is this doable in HTML5? > - Carlos Solís > > > I don't think it's something that was 'solved' by Flash. To be honest, I'm > often annoyed at the way Flash steals the focus of all my key presses making > it almost impossible to navigate using only the keyboard. > > You could use Javascript to put the focus onto an object, capture all the > key presses on that and return false for them all maybe. > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > > -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/ http://sasha.sourceforge.net/ • http://www.yoursasha.com/
Re: [whatwg] Is there a way to stop scrolling when pressing directional arrows?
On Mon, 2010-06-14 at 13:38 -0600, Carlos Andrés Solís wrote: > Hello! I've been noticing a problem in many HTML5 test apps, very > especially games. When the directional arrow buttons are pressed, the > screen scrolls. This is a problem that, as far as I know, Flash had > solved by changing the focus of the application to the app. Is this > doable in HTML5? > - Carlos Solís I don't think it's something that was 'solved' by Flash. To be honest, I'm often annoyed at the way Flash steals the focus of all my key presses making it almost impossible to navigate using only the keyboard. You could use Javascript to put the focus onto an object, capture all the key presses on that and return false for them all maybe. Thanks, Ash http://www.ashleysheridan.co.uk
[whatwg] Is there a way to stop scrolling when pressing directional arrows?
Hello! I've been noticing a problem in many HTML5 test apps, very especially games. When the directional arrow buttons are pressed, the screen scrolls. This is a problem that, as far as I know, Flash had solved by changing the focus of the application to the app. Is this doable in HTML5? - Carlos Solís
Re: [whatwg] Installable web apps
On Thu, 27 May 2010 18:22:03 +0200, Aaron Boodman wrote: On Thu, May 27, 2010 at 5:09 AM, Lachlan Hunt wrote: You're right -- that one does exist already within the page. And it is a shame to waste these existing features. The more I think about it, the more I start to agree that just using the and tags we already have (with perhaps one addition for permissions), could work. Let me think about it some more. I think if we do more things it would make more sense to build them on top of rather than creating some new kind of JSON-based format that needs to be separately fetched. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Form validation against invisible controls
Il giorno 14/giu/2010, alle ore 12.40, Ian Hickson ha scritto: > Incorrect use of "required" in HTML4-era documents also seems to be the > common problem Chrome ran into -- at the risk of starting a bikeshed > discussion, does anyone have any good suggestions for alternative names? I believe "mandatory" would keep the same semantic and clarity "required" does. -- Bye, Michelangelo
Re: [whatwg] Form validation against invisible controls
On Mon, 14 Jun 2010, Ola P. Kleiven wrote: > > The following sites have workarounds in Opera's browser.js to allow form > submit: > > airgreenland.com (using required on hidden elements) > barnesandnoble.com (using required on visible elements that are supposed to be > empty on submit...) > bookryanair.com (using required=false - this usage has also been found in JS > libraries) > ingdirect.com.au (using required on a visible field, but then emptying the > field with JS before submit) > usairways.com (using required on hidden elements) > > Most of these have been using it for several years and have not responded to > change requests from our side. > > We have also seen a couple of instances of wrong input types (number > where text expected etc.), but the usage of "required" is the biggest > problem in my experience. Incorrect use of "required" in HTML4-era documents also seems to be the common problem Chrome ran into -- at the risk of starting a bikeshed discussion, does anyone have any good suggestions for alternative names? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Form validation against invisible controls
On Mon, 14 Jun 2010 07:41:40 +0200, Peter Kasting wrote: On Sun, Jun 13, 2010 at 10:16 PM, TAMURA, Kent wrote: There are some objections against omitting invisible controls from form validation. However, it is a real issue with existing sites and users can't submit such forms at all though they can submit it with non-HTML5 browsers. How many existing sites? What sites are asking for form validation but then not actually working with it? If this isn't a large number, I would prefer to stay as-is and let the sites fix themselves. The following sites have workarounds in Opera's browser.js to allow form submit: airgreenland.com (using required on hidden elements) barnesandnoble.com (using required on visible elements that are supposed to be empty on submit...) bookryanair.com (using required=false - this usage has also been found in JS libraries) ingdirect.com.au (using required on a visible field, but then emptying the field with JS before submit) usairways.com (using required on hidden elements) Most of these have been using it for several years and have not responded to change requests from our side. We have also seen a couple of instances of wrong input types (number where text expected etc.), but the usage of "required" is the biggest problem in my experience. My conclusion is it's better to disable interactive form validation for existing sites as possible. e.g. disabling interactive form validation for documents without "". I think this is a mistake. PK -- Ola P. Kleiven, Core Compatibility, Opera Software
Re: [whatwg] Form validation against invisible controls
On Sun, Jun 13, 2010 at 10:41 PM, Peter Kasting wrote: > On Sun, Jun 13, 2010 at 10:16 PM, TAMURA, Kent wrote: >> >> There are some objections against omitting invisible controls from form >> validation. However, it is a real issue with existing sites and users can't >> submit such forms at all though they can submit it with non-HTML5 browsers. > > How many existing sites? What sites are asking for form validation but then > not actually working with it? If this isn't a large number, I would prefer > to stay as-is and let the sites fix themselves. >> >> My conclusion is it's better to disable interactive form validation for >> existing sites as possible. e.g. disabling interactive form validation for >> documents without "". > > I think this is a mistake. Agreed on both accounts. Both these suggestions add a lot of complexity to the platform and we should avoid it if at all possible. To the extent that if there is lots of broken sites out there because they happen to use attribute names that collide with HTML5, but only partially match the HTML5 behavior, then we should consider renaming those attributes in HTML5. / Jonas
