Re: [whatwg] Do we really need a device element?
On Sun, Jun 13, 2010 at 6:36 PM, James Salsman jsals...@gmail.com wrote: ... I [was] persuaded that the device element is unnecessary, given recent announcements for the accept=...;source=... type specification proposed by Android and Firefox developers. Does anyone have any reasons to the contrary? A device element with a type parameter would be useful when the HTML author is unaware of the target browsers' choice of specific elements such as embed, object, video, microphone, camera, camcorder etc. to control placement of, for example, audio volume and recording level controls, microphone visual feedback, video display viewports, camera and camcorder viewfinders, etc. for real-time device access, which does seem to be very reasonable to do in HTML instead of Flash. Use cases include teleconferencing, screen grabs (device type=image;source=desktop?), maybe shared whiteboards (device type=pointer;source=canvas-id producing coordinate streams and up/down codes?) Real-time camcorder upload has as compelling use case as buffered form-based input type=file accept=video;source=webcam does under lower bandwidth situations. People will want both, so I am not ready to write off the device element yet.
Re: [whatwg] Form validation against invisible controls
On Sun, Jun 13, 2010 at 10:41 PM, Peter Kasting pkast...@google.com wrote: On Sun, Jun 13, 2010 at 10:16 PM, TAMURA, Kent tk...@chromium.org 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 !DOCTYPE html. 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
Re: [whatwg] Form validation against invisible controls
On Mon, 14 Jun 2010 07:41:40 +0200, Peter Kasting pkast...@google.com wrote: On Sun, Jun 13, 2010 at 10:16 PM, TAMURA, Kent tk...@chromium.org 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 !DOCTYPE html. I think this is a mistake. PK -- Ola P. Kleiven, Core Compatibility, Opera Software
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
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] Installable web apps
On Thu, 27 May 2010 18:22:03 +0200, Aaron Boodman a...@google.com wrote: On Thu, May 27, 2010 at 5:09 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: meta name=application-name content=... 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 meta and link 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 html manifest rather than creating some new kind of JSON-based format that needs to be separately fetched. -- Anne van Kesteren http://annevankesteren.nl/
[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] 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
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 canvas, and it has no problem stealing the keyboard focus (with JavaScript) for most keypresses. Gordon 2010/6/14 Ashley Sheridan a...@ashleysheridan.co.uk 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 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 canvas, and it has no problem stealing the keyboard focus (with JavaScript) for most keypresses. Gordon 2010/6/14 Ashley Sheridan a...@ashleysheridan.co.uk 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?
On Mon, 14 Jun 2010 20:38:07 +0100, Carlos Andrés Solís
csol...@gmail.com 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] 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] Form validation against invisible controls
On Mon, 14 Jun 2010 08:44:09 +0100, Jonas Sicking jo...@sicking.cc 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] Is there a way to stop scrolling when pressing directional arrows?
On Tue, 15 Jun 2010 00:16:13 +0200, Kornel Lesinski kor...@geekhood.net
wrote:
On Mon, 14 Jun 2010 20:38:07 +0100, Carlos Andrés Solís
csol...@gmail.com 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
canvas (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.
script
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();
}
}
/script
canvas tabindex=0 onkeypress=press(event)/canvas
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] Is there a way to stop scrolling when pressing directional arrows?
On Mon, Jun 14, 2010 at 3:56 PM, Simon Pieters sim...@opera.com wrote:
On Tue, 15 Jun 2010 00:16:13 +0200, Kornel Lesinski kor...@geekhood.net
wrote:
On Mon, 14 Jun 2010 20:38:07 +0100, Carlos Andrés Solís
csol...@gmail.com 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
canvas (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.
script
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();
}
}
/script
canvas tabindex=0 onkeypress=press(event)/canvas
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] 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 input type=speech. 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
