Re: [whatwg] focusability of visibility:hidden and display:none elements WAS: Autofocus readonly Input Elements
On Mon, 26 Sep 2011, Ojan Vafai wrote:
>
> *"8.3.2 Focus management*
>
> An element is *focusable* if the user agent's default behavior allows it to
> be focusable or if the element is specially focusable, but only if the
> element is either being rendered or is a descendant of a canvas element that
> represents embedded content."
> As the test below shows, non-rendered divs with a tabindex are still
> focusable in all browsers.
>
> "input elements whose type attribute are not in the Hidden state and that
> are not disabled"
>
> It seems that all browsers also don't make visibility:hidden and
> display:none input elements focusable.
The spec agrees:
"An element is focusable if the user agent's default behavior allows it to
be focusable or if the element is specially focusable, but only if the
element is either being rendered or is a descendant of a canvas element
that represents embedded content."
I've tried to make this clearer.
> DETAILS:
> http://plexode.com/eval3/#ht=%3Cinput%20id%3Dtext%20type%3D%22%22%3E%3C%2Finput%3E%0A%3Cinput%20id%3Dhidden%20type%3D%22hidden%22%3E%3C%2Finput%3E%0A%3Cinput%20id%3Ddisabled%20disabled%3E%3C%2Finput%3E%0A%3Cinput%20id%3Dreadonly%20readonly%3E%3C%2Finput%3E%0A%3Cinput%20id%3Dvisiblity-hidden%20style%3D%22visibility%3Ahidden%22%3E%3C%2Finput%3E%0A%3Cinput%20id%3Ddisplay-none%20style%3D%22display%3Anone%22%3E%3C%2Finput%3E%0A%3Cdiv%20id%3Ddiv-hidden%20sytle%3D%22visibility%3Ahidden%22%20tabindex%3D1%3E%3C%2Finput%3E%0A%0A%3Cdiv%20id%3Dlogger%3E%3C%2Fdiv%3E&ohh=1&ohj=1&jt=var%20result%20%3D%20''%3B%0A%0Afunction%20isFocusable(type)%20%7B%0A%20%20%20%20var%20element%20%3D%20document.getElementById(type)%3B%0A%20%20%20%20result%20%2B%3D%20type%20%2B%20'%20is'%3B%0A%20%20%20%20try%20%7B%0A%20%20%20%20%20%20%20%20element.focus()%3B%0A%20%20%20%20%20%20%20%20if%20(element%20!%3D%20document.activeElement)%0A%20%20%20%20%20%20%20%20%20%20%20%20result%20%2B%3D%20'%20not'%3B%0A%20%20%20%20%7D%20catch%20(e)%20%7B%0A%20%20%20%20%20%20result%20%2B%3D%20'%20not%20(error%20thrown)'%3B%0A%20%20%20%20%7D%0A%20%20%20%20result%20%2B%3D%20'%20focusable%3Cbr%3E'%3B%0A%7D%0A%0AisFocusable('text')%3B%0AisFocusable('hidden')%3B%0AisFocusable('disabled')%3B%0AisFocusable('readonly')%3B%0AisFocusable('visiblity-hidden')%3B%0AisFocusable('display-none')%3B%0AisFocusable('div-hidden')%3B%0A%0Adocument.getElementById('logger').innerHTML%20%2B%3D%20result%3B&ojh=1&ojj=1&ms=100&oth=0&otj=0&cex=1
>
> Firefox 6, Chrome 16, IE9:
> text is focusable
> hidden is not focusable
> disabled is not focusable
> readonly is focusable
> visiblity-hidden is not focusable
> display-none is not focusable
> div-hidden is focusable
> div-display-none is focusable
The test above had a bug which made the s not be properly hidden.
With that bug fixed, a visibility:hidden div and a display:none div also
come out as not focusable, as in the spec.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Focus remains on Hidden Element
On Sat, 8 Oct 2011, Kaustubh Atrawalkar wrote: > > In a form element, If a form input element has a focus and its then made > hidden using style property display:none the focus still remains on the > hidden element. According to specs ( > http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#focus-management- > > 4th point) hidden input elements can not be focused. But there is still > inconstancy in the browsers. The spec requires that focus be dropped in this case: "When an element that is focused stops being a focusable element, or stops being focused without another element being explicitly focused in its stead, the user agent should synchronously run the focusing steps for the body element, if there is one; if there is not, then the user agent should synchronously run the unfocusing steps for the affected element only." -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On 2/21/12 10:47 PM, Dimitri Glazkov wrote: I made WebKit match this behavior a couple of years ago: https://bugs.webkit.org/show_bug.cgi?id=9756 Ah, interesting. Some of the links in that bug indicate that people are in fact depending on this behavior -Boris
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Tue, Feb 21, 2012 at 5:36 PM, Boris Zbarsky wrote: > On 2/21/12 7:35 PM, Ian Hickson wrote: >> >> On Sun, 25 Sep 2011, Boris Zbarsky wrote: >>> >>> >>> Not doing that last is actually a requirement for web compat, last I >>> looked at this. >> >> >> Do you have any links to pages that break if a form with more than one >> text field supports implicit submission? > > > Not offhand. Again, it's been a while since I looked into this, but at the > time this was being implemented in Gecko we carefully made the > two-input-no-submit case not submit. I thought that was for good reason, > but reskimming the bugs now I can't find the reason. It's been over 10 > years, so the details are a bit hazy in my mind. :( I made WebKit match this behavior a couple of years ago: https://bugs.webkit.org/show_bug.cgi?id=9756 :DG< > > >>> For those who want to mess with the spec for this behavior, >>> https://bugzilla.mozilla.org/show_bug.cgi?id=99920 and >>> https://bugzilla.mozilla.org/show_bug.cgi?id=109463 and >>> https://bugzilla.mozilla.org/show_bug.cgi?id=147850 are necessary (but >>> probably not sufficient) reading. >> >> >> I read those bugs, but can't see the reason why submitting a form with two >> text fields and no buttons would break the Web. Can you elaborate? > > > https://bugzilla.mozilla.org/show_bug.cgi?id=22526 is the other bug that > needs reading, but it doesn't help either. I didn't look at the various > (and somewhat numerous) duplicates of the various bugs involved... > > I suppose we could try submitting the "more than one text input, no submit > button" case and see what happens... > > -Boris
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Tue, Feb 21, 2012 at 6:35 PM, Ian Hickson wrote: > > (It also explicitly says that if implicit submit is supported but > there's no submit button in the form, the implicit submit must still > > happen. That doesn't sound like it could be followed, since lots of > > pages are probably depending on the absence of a submit button > > suppressing implicit submit. That's just backwards-compatibility, not > > platform conventions, though.) > > Do you have any such pages to point to? > Nope, only the assumption that the weird browser behavior related to this could only be for that reason. I'll be happy if this proves unnecessary; this ugliness has caused me headaches in the past. On Sun, 25 Sep 2011, Ryosuke Niwa wrote: > > Why is this authoring question? As an user, I'd like to know whether > > pressing enter in my text field triggers implicit submission or not. > > Whether it does or not should be based on the conventions of the platform. > I don't think the existence of implicit submit should depend on platform conventions, though, for interop on forms without visible submit buttons. The form implicit submit takes is a platform convention, but it should be required to exist in some form or another. -- Glenn Maynard
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On 2/21/12 7:35 PM, Ian Hickson wrote: On Sun, 25 Sep 2011, Boris Zbarsky wrote: Not doing that last is actually a requirement for web compat, last I looked at this. Do you have any links to pages that break if a form with more than one text field supports implicit submission? Not offhand. Again, it's been a while since I looked into this, but at the time this was being implemented in Gecko we carefully made the two-input-no-submit case not submit. I thought that was for good reason, but reskimming the bugs now I can't find the reason. It's been over 10 years, so the details are a bit hazy in my mind. :( For those who want to mess with the spec for this behavior, https://bugzilla.mozilla.org/show_bug.cgi?id=99920 and https://bugzilla.mozilla.org/show_bug.cgi?id=109463 and https://bugzilla.mozilla.org/show_bug.cgi?id=147850 are necessary (but probably not sufficient) reading. I read those bugs, but can't see the reason why submitting a form with two text fields and no buttons would break the Web. Can you elaborate? https://bugzilla.mozilla.org/show_bug.cgi?id=22526 is the other bug that needs reading, but it doesn't help either. I didn't look at the various (and somewhat numerous) duplicates of the various bugs involved... I suppose we could try submitting the "more than one text input, no submit button" case and see what happens... -Boris
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Sat, 24 Sep 2011, Kaustubh Atrawalkar wrote: > On 24-Sep-2011, at 12:24 AM, Ian Hickson wrote: >> On Fri, 23 Sep 2011, Kaustubh Atrawalkar wrote: >>> >>> If the form has submit button with display property as none, will that >>> form should be implicitly submitted on pressing enter key? This works >>> in Opera & Firefox but does not work in IE & Safari as of now. What is >>> the expected behavior for this? > >> The strict answer is that it's up to the browsers; the spec allows >> browsers to do whatever they think is appropriate per their platform's >> conventions. So both behaviours are compliant. > > But then this might result in website compliance issue. A website having > username, password field with hidden submit button expecting to login on > enter key using forms implicit submission will work on FF & Opera but > may not work on IE & Safari. Yes. Similarly, some browsers might provide spelling checking, and others might not. Some might support tabbing from field to field, others might not. The thing is, if a platform does not have the concept of implicit submission, presumably the user wouldn't try to implicitly submit anything in the first place, so it doesn't matter if the browser does it or not. >> The guidelines in the spec do not say anything about the behaviour >> being different for elements that are display:none or otherwise hidden, >> though, so I don't see any reason to consider the visibility of a >> button in making the decision as to which button is the default. > > Second to your opinion, on the last line of the specs paragraph it says > - "If the form has no submit button, then the implicit submission > mechanism must just submit the form element from the form element > itself." > http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#implicit-submission This does not contradict what I wrote. It just says what to do if there IS an implicit submission mechanism, but there's no button at all. On Sat, 24 Sep 2011, Ryosuke Niwa wrote: > > WebKit's behavior is very confusing here. It does implicit submission in the > following conditions: > >- One text fields >- One text field with one visible submit button >- Two text fields with one visible submit button >- Two text fields with one visibility:hidden submit button >- One text field with one display:none submit button > > However, it doesn't submit when we have: > >- Two text fields That's non-conforming currently. >- Two text fields with one display:none submit button That's not really sensible, but it was technically within the spec's language. (You were allowed to not pick a default button if there was one to pick from but you didn't like it for some reason.) I've changed the spec to make this no longer allowed. The first button will now always be the default. > Given that WebKit implicitly submits form even in the presence of a > visible submit button or an invisible submit button (visibility: hidden, > or display: none with exactly one text field), I don't see why we should > avoid implicit submission only when there are multiple form controls and > a display:none submit button. Agreed. On Sat, 24 Sep 2011, Ryosuke Niwa wrote: > > IE9 does implicit submission in the following conditions: > >- One text field >- One text field with one visible submit button >- One text field with one display:none submit button >- Two text fields with one visible submit button > > It does not do implicit submissio in the following conditions: > >- Two text fields >- Two text fields with one visibility:hidden submit button >- Two text fields with one display:none submit button > > Basically, IE9 only does implicit submission when there is exactly one > text field (you can have checkbox, hidden, etc...) or there is a visible > button (i.e. not diplay: none nor visibility: hidden). If you submit with one text field and no button, then you are required to also submit with two text fields and no button. So this is non-conforming. > Firefox 5 does implicit submission in the following conditions: > >- One text field >- One text field with one visible submit button >- One text field with one display:none submit button >- Two text fields with one visible submit button >- Two text fields with one visibility:hidden submit button >- Two text fields with one display:none submit button > > It does not do implicit submissio in the following conditions: > >- Two text fields > > In summary, Firefox special cases one text field (can have checkbox, > hidden, etc...) like MSIE and requires a submit button with more than > two text fields regardless of presence of visibility: hidden or display: > none. On Sun, 25 Sep 2011, Kaustubh Atrawalkar wrote: > > Opera - Does Implicit submission in following cases - > * One text field > * One text field with one visible submit button >
[whatwg] s in by quality as well as codec
I propose that add a quality, bitrate, or filesize attribute to allow the UA to decide between multiple streams by choosing the maximum quality file that it can download within a reasonable amount of time (e.g. it will download faster than it will play) or based on a user preference (e.g. prefer SD quality, or always use HD when provided). It should also be possible to retrieve a list of the s the UA can play in JS, and switch between them by user action (either a JS call for a custom UI or a dropdown in the builtin UI), loading the new file and switching to it with minimal skipping. This way, a site like YouTube, which presents several files in various bitrates and codecs, can allow the user to choose to use a higher quality without having to force an src attribute on the video, and a mobile UA that roams from 3G to WiFi or moves close to a base station can increase the quality of its stream. I think it fits in well with the purpose of the source element. This is certainly open for modification, but I think it's a good concept in essence.
[whatwg] Encrypted Media support for HTMLMediaElement
Hi, We just published a joint proposal for adding Encrypted Media to HTMLMediaElement on the W3C website: http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html; announcement: http://lists.w3.org/Archives/Public/public-html/2012Feb/0273.html. To avoid forking the discussion, please provide feedback and comments in the thread above or on one of the lists mentioned at the top of the proposal. Regards, David
Re: [whatwg] including in form submissions
On Tue, 13 Sep 2011, Michael Gratton wrote: > > HTML5 does not provide a means of submitting form content that is > otherwise rendered as normal text, i.e. not as a form control. The use > cases for this are the same as for the element, but when it is > also desirable for the result of a calculation to be sent to the server > when the form is submitted. > > Currently, the only way to implement this is to maintain two copies of > the value, one the child text of an element (or something > similar, for example a or ) and once in the value of an > element, using appropriate scripting to keep the > two in sync. This is error prone and places an additional burden on the > web page author. > > This can be remedied by allowing the value of elements to be > submitted. That is, include the element in the submittable > form-associated element category. > > I initially thought that this was precisely what the element > existed for - it was rather surprising when I tried using them but none > of the values were appearing in the submission. You can work around this by just assigning the value to a hidden input when you assign it to the output control. But in general, I recommend against this. Anything that can be computed should be computed on the server to obtain the canonical value, otherwise you open yourself up to attackers sending you inconsistent data. On Wed, 14 Sep 2011, Michael Gratton wrote: > > [As an aside, it just occured to me that it would also be helpful if > supported the "type" attribute, for most of the same values as > now does in HTML5, for much the same reason as it makes sense > for .] It makes sense for because it lets the browser know what interface to give to the user to let the user change the value... How does that make sense for ? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Deprecate registerProtocolHandler/registerContentHandler via Web Intents
Þann þri 21.feb 2012 19:41, skrifaði James Hawkins: Is this use case not fully handled by the UA specifying the appropriate action when building the intent, e.g., the user right-clicks on an image in a page and the UA constructs context menu items for edit/share/etc. action? Not if the image is both fetched and drawn by a single plugin. By plugin I mean an extra-UA piece of software that is allocated a window to draw to. I hope you meant that an Intent API could be used to pass URIs to fetchers to pass back retrieved resources, without converting them to HTML or bitmaps, rather than to pass URIs of resources to be drawn to users' screens or speakers.
Re: [whatwg] Proposal: Deprecate registerProtocolHandler/registerContentHandler via Web Intents
On Tue, Feb 21, 2012 at 11:31 AM, Bjartur Thorlacius wrote: > Þann þri 21.feb 2012 18:44, skrifaði James Hawkins: > >> I'm not sure if the proposal was explicit enough, but for the RPH-esque >> functionality in Web Intents, we activate WI in the same circumstances >> RPH is activated, which is when links are activated in a page. Can you >> elucidate how the scenarios you listed could be handled? Note these >> scenarios are above and beyond RPH, but we're not trying to make the API >> self-limiting. > > Windows Explorer (the file manager) does for example offer users to edit > images upon right-click. I worry that if URI scheme handlers need not only > take care of fetching but also of presentation, other actions than view will > be unnecessarily hard to implement. Thus I figure retrieval and presentation > must be separated. > > (view (fetch uniform:resource/locator)) > or > (edit (fetch uniform:resource/locator)) > > instead of > (fetch-and-view uniform:resource/locator) Is this use case not fully handled by the UA specifying the appropriate action when building the intent, e.g., the user right-clicks on an image in a page and the UA constructs context menu items for edit/share/etc. action?
Re: [whatwg] Proposal: Deprecate registerProtocolHandler/registerContentHandler via Web Intents
Þann þri 21.feb 2012 18:44, skrifaði James Hawkins: I'm not sure if the proposal was explicit enough, but for the RPH-esque functionality in Web Intents, we activate WI in the same circumstances RPH is activated, which is when links are activated in a page. Can you elucidate how the scenarios you listed could be handled? Note these scenarios are above and beyond RPH, but we're not trying to make the API self-limiting. Windows Explorer (the file manager) does for example offer users to edit images upon right-click. I worry that if URI scheme handlers need not only take care of fetching but also of presentation, other actions than view will be unnecessarily hard to implement. Thus I figure retrieval and presentation must be separated. (view (fetch uniform:resource/locator)) or (edit (fetch uniform:resource/locator)) instead of (fetch-and-view uniform:resource/locator)
Re: [whatwg] Proposal: Deprecate registerProtocolHandler/registerContentHandler via Web Intents
Thanks for your feedback, Bjartur. On Tue, Feb 21, 2012 at 9:30 AM, Bjartur Thorlacius wrote: > Þann mið 15.feb 2012 23:39, skrifaði James Hawkins: > > * If |scheme| is specified, |action| *should* (must?) be ignored. >> > Why would you forbid distinguishing between actions on URIs? Postal and > retrieval of mail, for example, are quite distinct actions. As are > modification and retrieval of documents. > I'm not sure if the proposal was explicit enough, but for the RPH-esque functionality in Web Intents, we activate WI in the same circumstances RPH is activated, which is when links are activated in a page. Can you elucidate how the scenarios you listed could be handled? Note these scenarios are above and beyond RPH, but we're not trying to make the API self-limiting. Thanks, James
Re: [whatwg] Proposal: Deprecate registerProtocolHandler/registerContentHandler via Web Intents
Þann mið 15.feb 2012 23:39, skrifaði James Hawkins: * If |scheme| is specified, |action| *should* (must?) be ignored. Why would you forbid distinguishing between actions on URIs? Postal and retrieval of mail, for example, are quite distinct actions. As are modification and retrieval of documents.
Re: [whatwg] crypto.getRandomValues feedback
Awesome, thanks! / Jonas On Tue, Feb 21, 2012 at 5:18 AM, Adam Barth wrote: > I've updated http://wiki.whatwg.org/wiki/Crypto to have > getRandomValues return the array. > > Adam > > > On Mon, Feb 20, 2012 at 2:51 PM, Jonas Sicking wrote: >> Hi All, >> >> For reference, much of this feedback has been given in the Firefox >> Bugzilla bug. See [1] and forward. >> >> Basically the in/out nature of the getRandomValues function looks very >> bad to me. This is inconsistent with almost every other JS API which >> uses return values rather than in/out arguments. The main exception >> that I can find is Array.splice, but this appears to be so that it can >> return the removed items. >> >> But the main thing that I dislike about in/out arguments over return >> values is that it makes coding with them very cumbersome. This is a >> common pattern in perl: >> >> $tempString = getSomeValue(); >> $tempString =~ s/expression/; >> doStuff($tempString); >> >> This because the =~ operator doesn't return the result of the >> search'n'replace expression which is generally the value that you want >> to use. The same thing is the case with the getRandomValues API as it >> currently exists. The web JS will have to look something like this: >> >> var tempBuffer = new UInt8Array(65536); >> crypto.getRandomValues(tempBuffer); >> doStuff(tempBuffer); >> >> This can be greatly improved if we make getRandomValues return the >> buffer passed to it. That way the following code would work: >> >> doStuff(crypto.getRandomValues(new UInt8Array(65536))); >> >> This will also make it possible to nicely expand the API to take an >> integer which the API would use to create a buffer of the passed in >> size and fill that with random values. Not something we have to do >> right now, but would be easy to add later if we feel the need. >> >> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=440046#c205 >> >> / Jonas
