Re: [whatwg] IRIs and javascript: scheme
On Wed, 18 Oct 2006, Christian Schmidt wrote: Most modern browsers support the following: a href=javascript:alert(123)foo/a AFAICS javascript:alert(123) is not a valid IRI according to RFC 3987 (it should be javascript:alert%28123%29 instead) and is thus not allowed in an input type=url field. This is somewhat surprising to me, and I think it will confuse users that they now have to manually escape their javascript: URLs when entering them in url input fields. Would it cause any problems to somehow allow the unescaped form in url input fields? Or is that a dangerous road to go down? I've allowed the user agent to escape user input. I don't think we should ever submit an invalid URI or IRI. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [wf2] Comments in textarea
On Fri, 20 Oct 2006, Simon Pieters wrote: There is a parsing requirement in WF2[1] I believe is incorrect: For textarea elements containing tags in HTML The tags should be parsed as character data, but entities and comments should be recognised and handled correctly. AFAICT browsers parse comments as character data too (ignoring the weird pseudo-comment parsing). Handled this in the parser section. Let me know if I screwed it up. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Constrains of the value propety of Controls
On Fri, 20 Oct 2006, Joao Eiras wrote: Value isn't readonly, and you might not have an index but a string. I'm not asking help how to code. I'd like to know what happenns in case 'VALUE' is set . Master Br [EMAIL PROTECTED] escreveu: I think that the correct approach is to define the SELECTED INDEX of the list, never to try setting the list value directly. Indeed, I think that the value property is READ-ONLY in this case... so you can NOT set Right approach: objectSelect.selectedIndex = DESIRED_INDEX; Joao Eiras escreveu: Currently, no DOM specification explicitly defines behaviour and restrictions when setting the value of the value property for elements part of forms, like select, option, and input. That's however, work that's being done at WHATWG. Yet, one single case persists: - the value property of a HMTLSelectElement is a limited domain, formed by the value of the select's child option elements value property. Is this a valid assertion ? What is expected to happen when a script tries to set the value of the value property of a select element, value which doesn't exist among it's children ? Should the value remain unchanged ? An error thrown ? I have attempted to answer this question in the HTML5 specification. Please let me know if the resulting text is inadequate. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Form Control Group Labels
On Tue, 31 Oct 2006, Lachlan Hunt wrote: [...] The problem is that each radio button or checkbox has it's own label, but the whole group is often associated with a single question and there is no way mark that up. e.g. pGender: label for=minput type=radio id=m name=gender value=m Male/label label for=finput type=radio id=f name=gender value=f Female/label /p In this case, when screen readers are in forms mode and the user is tabbing between form controls, it will only read out Male and Female, it won't read out Gender:. There are workarounds using fieldset and legend for the question, like this. fieldset legendGender:/legend label for=minput type=radio id=m name=gender value=m Male/label label for=finput type=radio id=f name=gender value=f Female/label /fieldset That's not a workaround. It's exactly what you're supposed to do. fieldset lets you group a set of controls with a common legend, which is exactly the problem you described. The problem with that technique is that, because of the way legends are rendered in browsers, styling is somewhat restricted. That's a CSS issue. It probably isn't a reason to invent a new syntax whose exclusive purpose is accessibility, especially since such syntax has a track record of very low uptake. On Tue, 31 Oct 2006, Matthew Raymond wrote: | p | grouplabel for=genderGender:/grouplabel |labelinput type=radio name=gender value=mMale/label |labelinput type=radio name=gender value=fFemale/label | /p The element grouplabel gives the label for the group. The |for| attribute in this case takes a name rather than and ID, therefore it labels as a group control elements that have |name=gender| as an attribute. It introduces only one element and one attribute for an unlimited amount of control elements. Drop the for, rename grouplabel to legend, and rename p to fieldset, and you're done. :-) On Thu, 2 Nov 2006, Lachlan Hunt wrote: 1. Seperate fields for a date (day, month, year) Note: I'm aware that type=date solves this specific use case, but this is still a very commonly used structure today and illustrates my point nicely. I'm not sure that this is really a good use case, because from an accessibility point of view, if you jump to the second or third field in a compound field, it doesn't help you much to know that you are in a field related to a date, you need to know if it's the first, second, or third such field. 2. Another use case is, which can't be solved using fieldset and legend, is a table of input elements, like this: The inputs could be checkboxes, text fields or whatever. table thead tr thlabel group= ? Apples/label thlabel group= ? Oranges/label thlabel group= ? Bananas/label tbody tr th scope=rowlabel group= ? Foo/label tdinput name=foo-apple tdinput name=foo-orange tdinput name=foo-banana tr th scope=rowlabel group= ? Bar/label tdinput name=bar-apple tdinput name=bar-orange tdinput name=bar-banana tr th scope=rowlabel group= ? Baz/label tdinput name=baz-apple tdinput name=baz-orange tdinput name=baz-banana /table Why isn't th enough for this? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] WindowHTML Option() constructor
On Sun, 5 Nov 2006, Anne van Kesteren wrote: The Option() constructor takes four arguments: 'Option(in DOMString name, in DOMString value, in boolean defaultSelected, in boolean selected)' is the complete version of it. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Tri-state checkboxes
Hi, There's been some previous discussion about providing a way to support tri-state checkboxes, and I recently came across a feature that's supported in IE and WebKit for this purpose. The DOM property HTMLInputElement.indeterminate is supported for input type=checkbox http://msdn.microsoft.com/en-us/library/ms533894(VS.85).aspx There doesn't seem to be any corresponding content attribute supported by either. This was apparently also considered and rejected by the DOM2 WG several years ago. http://lists.w3.org/Archives/Public/www-dom/2002AprJun/0106.html http://www.w3.org/2001/12/DOM-Level-2-issues#i24 -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Form Control Group Labels
Ian Hickson schrieb: On Tue, 31 Oct 2006, Lachlan Hunt wrote: There are workarounds using fieldset and legend for the question, like this. fieldset legendGender:/legend label for=minput type=radio id=m name=gender value=m Male/label label for=finput type=radio id=f name=gender value=f Female/label /fieldset That's not a workaround. It's exactly what you're supposed to do. fieldset lets you group a set of controls with a common legend, which is exactly the problem you described. IMO Lachlans opinion about the fieldset solution being a workaround reflects a basic problem with those form elements: they are highly presentational. Your example: fieldset legendGender:/legend label for=minput type=radio id=m name=gender value=m Male/label label for=finput type=radio id=f name=gender value=f Female/label /fieldset serves the same purpose as this one: label for=genderGender:/label select id=gender name=gender option value= /option option value=mMale/option option value=fFemale/option /select Both provide a list of values, of which zero or one can be selected. The only real difference is in the presentation, but structurally they are totally different. Now consider this: fieldset legendSender:/legend label for=ninput type=text id=n name=n value= Name/label label for=minput type=text id=m name=m value= E-mail/label /fieldset This is structurally the same as the radio button example, except some attribute values, but serves a totally different purpose. If you look at it this way, calling the fieldset solution for grouping a group of radio buttons (which are actually grouped by their common name attribute value) a workaround does not seem totally wrong to me. I consider a total re-thinking of select, input type=checkbox and input type=radio elements as highly desirable, though I see that this might cause more serious backwards compatiblity problems than for example removing the font tag. One possible solution could be using the select tag with a type attribute: label for=genderGender:/label select id=gender name=gender type=boxgroup option value= /option option value=mMale/option option value=fFemale/option /select Like this, the appearance would be controlled by the type and multiple attributes; type=boxgroup in combination with multiple would create a group of checkboxes, without multiple a group of radio buttons. And older UAs would render it as a selectbox in all cases, thus preserving usability of the form. And the label question would be consistently solved.
Re: [whatwg] Form Control Group Labels
On Tue, Oct 28, 2008 at 10:32 AM, Ian Hickson wrote: On Tue, 31 Oct 2006, Lachlan Hunt wrote: [...] The problem is that each radio button or checkbox has it's own label, but the whole group is often associated with a single question and there is no way mark that up. e.g. pGender: label for=minput type=radio id=m name=gender value=m Male/label label for=finput type=radio id=f name=gender value=f Female/label /p In this case, when screen readers are in forms mode and the user is tabbing between form controls, it will only read out Male and Female, it won't read out Gender:. There are workarounds using fieldset and legend for the question, like this. fieldset legendGender:/legend label for=minput type=radio id=m name=gender value=m Male/label label for=finput type=radio id=f name=gender value=f Female/label /fieldset That's not a workaround. It's exactly what you're supposed to do. fieldset lets you group a set of controls with a common legend, which is exactly the problem you described. Wouldn't aria-labelledby [1] be better-suited? (if and once ARIA is added to HTML5) span id=genderGender:/span input type=radio name=gender id=gender-male value=m aria-labelledby=gender male label id=male for=gender-maleMale/label input type=radio name=gender id=gender-female value=f aria-labelledby=gender female label id=female for=gender-femaleFemale/label According to [2] it works in most AT (and note the use of label for= to both degrade gracefully and gain the click to check behavior in visual browsers). [1] http://www.w3.org/TR/wai-aria/#labelledby [2] http://www.marcozehe.de/2008/03/23/easy-aria-tip-2-aria-labelledby-and-aria-describedby/ -- Thomas Broyer
Re: [whatwg] Form Control Group Labels
On Tue, Oct 28, 2008 at 11:39 AM, Markus Ernst [EMAIL PROTECTED] wrote: Ian Hickson schrieb: On Tue, 31 Oct 2006, Lachlan Hunt wrote: There are workarounds using fieldset and legend for the question, like this. fieldset legendGender:/legend label for=minput type=radio id=m name=gender value=m Male/label label for=finput type=radio id=f name=gender value=f Female/label /fieldset That's not a workaround. It's exactly what you're supposed to do. fieldset lets you group a set of controls with a common legend, which is exactly the problem you described. IMO Lachlans opinion about the fieldset solution being a workaround reflects a basic problem with those form elements: they are highly presentational. Your example: fieldset legendGender:/legend label for=minput type=radio id=m name=gender value=m Male/label label for=finput type=radio id=f name=gender value=f Female/label /fieldset serves the same purpose as this one: label for=genderGender:/label select id=gender name=gender option value= /option option value=mMale/option option value=fFemale/option /select Both provide a list of values, of which zero or one can be selected. The only real difference is in the presentation, but structurally they are totally different. Now consider this: fieldset legendSender:/legend label for=ninput type=text id=n name=n value= Name/label label for=minput type=text id=m name=m value= E-mail/label /fieldset This is structurally the same as the radio button example, except some attribute values, but serves a totally different purpose. If you look at it this way, calling the fieldset solution for grouping a group of radio buttons (which are actually grouped by their common name attribute value) a workaround does not seem totally wrong to me. I consider a total re-thinking of select, input type=checkbox and input type=radio elements as highly desirable, though I see that this might cause more serious backwards compatiblity problems than for example removing the font tag. One possible solution could be using the select tag with a type attribute: label for=genderGender:/label select id=gender name=gender type=boxgroup option value= /option option value=mMale/option option value=fFemale/option /select Like this, the appearance would be controlled by the type and multiple attributes; type=boxgroup in combination with multiple would create a group of checkboxes, without multiple a group of radio buttons. And older UAs would render it as a selectbox in all cases, thus preserving usability of the form. And the label question would be consistently solved. FWIW, I completely agree with Markus re: the semantic similarity between select input radio and input checkbox. In my own programming utilities I have a function which does exactly what Markus talks about; it takes an array of value/text pairs, a display specifier (collapsed/expanded), and a multiplicity specifier (single/multiple) (also some arguments to specify @name and #id prefixes and such, but that's not relevant here). It uses this to transform the array into a select, select multiple, input radio group, or input checkbox group as necessary. This is very easy precisely because of the clear semantic mappings between the four types of input. I haven't given it serious thought, but as far as I can tell his proposed solution (piling all four display types onto the select tag) would work wonderfully as a semantic consolidation/simplification, and be nicely backwards-compatible. There are still good reasons to support keeping the input types of radio and checkboxes, of course (frex, wrapping a form around a list, and putting an input within each li), but this proposal would simplify the most common case.
[whatwg] Form and select seeding
I have not integrated the form and select seeding features that were defined in WF2 into HTML5. In the case of forms, my motivation was driven mostly by the desire to drop the XML submission feature, which has not been popular, and which, once removed, left the seeding being based on a somewhat dubious format. I am also not convinced that the use cases that this feature solved are all that common. Furthermore, they could easily be implemented in script or by server-side prefilling, so the arguments in favour of it are pretty weak. In the case of select seeding, the feature was based on another dubious format (an XHTML file with a select root element) and the use cases didn't seem especially compelling (the file could just be merged in on the server side in static cases, and doing dynamic cases with half a dozen lines of code instead of 1 isn't a big deal). Basically both cases lacked compelling arguments in favour and had a number of minor problems that added up. Anyway, since these features are now gone, the feedback below is moot at this point, so I haven't done anything with it. On Sun, 19 Nov 2006, Sean Hogan wrote: 1. What happens when the data attribute is cleared? Are all OPTIONs removed? Or no change? 2. What happens when the data attribute is set to the value it already contains? Is that a refresh or no change? 3. Is there a way to start out with a SELECT that has hard-coded OPTIONs but no @data, set @data to load some OPTIONs (incrementally or otherwise) and then reset to the initial hard-coded options. On Fri, 15 Dec 2006, Sean Hogan wrote: The way in which a FORM element with @data is seeded seems internally inconsistent: CLEAR REPEAT directives apply to RepetitionBlocks in the whole document. but FIELD directives only apply to elements within the form. I would prefer FIELD directives to apply to the whole document - that seems consistent with current forms which retrieve a whole new page. Although it does allow conflict between @data on different forms. The first step in the initialization algorithm (resetting the form) sounds wrong in the context of form submission. I assume the intention is that the reset() method is called, but the documentation says reset to its initial values as specified in the markup. These two are the same when the document is initially loaded, but the form could easily be changed by the time of form submission. On Thu, 29 Mar 2007, Brad Fults wrote: The reset() method resets the form, then fires a a formchange event on all the form controls of the form. In the case of a form seeded with initial values, it is not clear to me whether the intention is for the form's reset() method to reset the form to some sort of blank state or to the state immediately following the seeding of initial values. On Mon, 27 Aug 2007, Garrett Smith wrote: how about seeding a FORM's data with a JSON object? Is this a reasonable consideration? Will it work with File type elements? Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Radio controls shared with multiple forms
On Tue, 19 Dec 2006, Anne van Kesteren wrote: The draft should probably be more explicit about: input type=radio name=A form=form1 input type=radio name=A form=form1 form2 checked input type=radio name=A form=form2 Assuming form1 and form2 both exist selecting the first control will unset the controls associated with form2 in Opera's current implementation. Our preferred solution is that in case of radio controls only the first entry in the form= attribute counts. If that happens we'll update our implementation in due course. On Thu, 27 Sep 2007, Anne van Kesteren wrote: This problem is also present for required checkboxes: input type=checkbox name=a form=b c required input type=checkbox name=a form=c This is moot now that form= only takes one ID and controls can only be in one form. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Form Control Group Labels
Thomas Broyer wrote: Wouldn't aria-labelledby [1] be better-suited? (if and once ARIA is added to HTML5) Better how? According to [2] it works in most AT (and note the use of label for= to both degrade gracefully and gain the click to check behavior in visual browsers). Note Marco is only talking about Firefox 3 and a significant selection of recent screen readers for GNOME and Windows, his test case is about individual field labels not group labels, and even there he mentions that it doesn't work with the most popular screen reader amongst those tested. LEGEND works in more user agents and AT combinations and is therefore more backwards compatible. -- Benjamin Hawkes-Lewis
Re: [whatwg] whatwg Digest, Vol 33, Issue 90
On Fri, 29 Dec 2006, Benjamin Hawkes-Lewis wrote: FROIDURE Nicolas wrote: - 2 attributes for textarea : max (like other fields) and type (to specify a text mime type for the content edition bbcode, html, xhtml, xbbcode etc...). It will be a good way to improve the quality of the web by improving the quality of user interventions. Already done, see maxlength and type at: http://www.w3.org/TR/web-forms-2/#extensions1 Although as I've pointed out before, MIME types are not a sufficiently specific tool: they don't differentiate between different versions of HTML, can't suggest microformats, can't differentiate between full documents and fragments, and so forth. Also BBCode, XBBCode, and the various Wiki dialects don't even have MIME type. (Mind you, WHATWG could actually submit some MIME type registrations to make type work a bit better for the real web.) So this area still desperately needs more work. I've dropped type= (actually accept=), as discussed in the past few weeks, because there was no interest from user agents, it didn't seem to solve a problem that wasn't solved by class=, and it has a series of difficulties (such as those described above). - 1 attribute for code : type. Not done really. One option would be to add microformats to the Wiki for different languages, I suppose. If you were to do so, I suggest including version numbers. PHP4 should not necessarily be highlighted the same as PHP5. Otherwise one might as well use type and MIME types, just as for script/, although I suspect many languages lack MIME types. I enourage people to use the class attribute for this (or data-something= if they want to us this for input to a script). - maybe an attribute for em and strong. Something like degree and a numeric value to notice the emphase degree of the sentences. Whenever this semantic problem is raised, two alternatives are proposed: either add an attribute to em/ and strong/ or specify the semantic meaning of nesting em/ and strong/. Web Applications 1.0 currently goes for the second option: http://www.whatwg.org/specs/web-apps/current-work/#the-em http://www.whatwg.org/specs/web-apps/current-work/#the-strong Question for the editor: how many em/ equal one strong/? They are orthogonal as defined now. On Fri, 29 Dec 2006, FROIDURE Nicolas wrote: Maybe that the DTD syntax could be use. The official DTD for W3C standards and a personal DTD for other languages. In all cases, i think that bbcode, wiki and other 'easy' web languages with disappear when browsers will include real WYSIWYG editors. That's an interesting but somewhat expensive idea. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Form Control Group Labels
On Tue, Oct 28, 2008 at 7:12 PM, Tab Atkins Jr. wrote: FWIW, I completely agree with Markus re: the semantic similarity between select input radio and input checkbox. In my own programming utilities I have a function which does exactly what Markus talks about; it takes an array of value/text pairs, a display specifier (collapsed/expanded), and a multiplicity specifier (single/multiple) (also some arguments to specify @name and #id prefixes and such, but that's not relevant here). It uses this to transform the array into a select, select multiple, input radio group, or input checkbox group as necessary. This is very easy precisely because of the clear semantic mappings between the four types of input. I haven't given it serious thought, but as far as I can tell his proposed solution (piling all four display types onto the select tag) would work wonderfully as a semantic consolidation/simplification, and be nicely backwards-compatible. There are still good reasons to support keeping the input types of radio and checkboxes, of course (frex, wrapping a form around a list, and putting an input within each li), but this proposal would simplify the most common case. That's what XForms more or less defines (it has select and select1 elements), and I'd say that you can use XForms within XHTML to generate an HTML form (Web Forms 2.0). I suspect XForms might more limited wrt complex layouts, but I guess the new CSS3 modules will help (when shipped and implemented). -- Thomas Broyer
Re: [whatwg] Proposing URI Templates for WebForms 2.0
On Fri, 12 Jan 2007, Jerome Louvel wrote: Even though the URI template RFC is not finalized yet, we already have a complete support for it, on the server-side, in the Restlet framework. We happily use them for our URI-based routing and I think they add a lot of expressiveness while keeping a simple syntax. Usage example: http://www.restlet.org/tutorial#part11 They are also supported in WADL, the RESTful description language, and in the OpenSearch specification. Extending their usage to HTML forms sounds like a logical and useful step. It seems to me like URI templates can be trivially done from script and from the server side already; given the poor backwards-compatibility story of URI templates, what do we gain from adding it to the language? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] usemap on input
On Wed, 17 Jan 2007, Henri Sivonen wrote: The WF 2.0 spec neither specifies the usemap attribute for the input element nor documents the lack of it as a change from WF 1.0. HTML5 documents lack of it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Constrains of the value propety of Controls
On , Ian Hickson [EMAIL PROTECTED] wrote: I have attempted to answer this question in the HTML5 specification. Please let me know if the resulting text is inadequate. Cheers, It's much better. Thanks
Re: [whatwg] onchange events for input type=radio
On Thu, 18 Jan 2007, Boris Zbarsky wrote: There has recently been an interesting Mozilla bug report about onchange for radio inputs. It seems that UAs interoperably implement something non-obvious; it may be a good idea to specify it: https://bugzilla.mozilla.org/show_bug.cgi?id=363693 Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [WF2] action=mailto: - encoding spaces
On Tue, 30 Jan 2007, Shadow2531 wrote: http://www.whatwg.org/specs/web-forms/current-work/#for-mailto http://www.whatwg.org/specs/web-forms/current-work/#x-www-form-urlencoded (#4) In mailto URIs, %20 represents a space. form action=mailto:; input name=subject value=1 2 input type=submit /form If you submit that form, mailto:?subject=1+2; will be passed to the mail client instead of mailto:?subject=1%202;. This results in 1+2 in the subject field instead of 1 2. Are UAs allowed to use %20 instead so things come out right, or must mail clients decode + to a space? Thunderbird, M2, and Outlook express don't decode +s. RFC2368 is referenced, but it and application/x-www-form-urlencoded that the mailto: form methods are referenced under conflict with each other on whether a space should be encoded to %20 or +. Fixed in the HTML5 spec. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 2.9 spelling error
On Sat, 3 Feb 2007, Elliotte Harold wrote: In section 2.9. The autocomplete attribute The off value means that the control's input data is either particularily sensitive (for example the activation code for a nuclear weapon) or that it is a value that will never be reused (for example a one-time-key for a bank login) and indicates that the user should therefore explicitly enter the data each time, instead of being able to rely on the UA to prefill the value for him. The on value indicates that the value is not particularily sensitive and the user should expect to be able to rely on his UA to remember values he has entered for that control particularily -- particularly (twice) (unless that's yet another Britishism, but I don't think so) Wow, a typo that actually made it all the way to the HTML5 spec. I barely copied any text from WF2, so that's quite surprising! :-) Thanks, fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] WebForms2 validity
On Fri, 9 Feb 2007, Sean Hogan wrote: I might be missing something obvious, but... When are ValidityState properties updated? And when are CSS pseudo-classes (:valid, :invalid, :in-range, :out-of-range) updated? Continually (in particular whenever the constraints or the values change -- the validity states are defined in terms of those values). Many textual input form-controls would begin in one or another invalid state (valueMissing, patternMismatch) however authors would typically want CSS validity styles to apply only after checkValidity() - either a manual one or the automatic one performed by form-submission. Why? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input name=isindex
On Tue, 20 Feb 2007, Martijn wrote: Submission of an isindex element is different compared to normal form submission with a text input element, only the value part is submitted. This parsing definition: http://www.whatwg.org/specs/web-apps/current-work/#isindex means that forminput name=isindex/form also should only submit the value part. And indeed, that is what IE7 seems to be doing. Mozilla even has a bug filed for this: https://bugzilla.mozilla.org/show_bug.cgi?id=93795 So I guess this needs to be mentioned somewhere in the web forms spec or something? Done, thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Placeholder option for text input boxes
Tab Atkins Jr. wrote: I'd suspect that *all* examples where placeholder text is used (definitely all the examples I know of personally) are most semantically served by a label with the text. Iirc, I once saw a nice javascript solution that mutated the DOM to remove the label and use its text as a placeholder. Thus, I think this is best served by a CSS directive that does exactly that. External vs placeholder text is a display issue - semantically, both are labels for the field. I found real example that uses both a label and placeholder text. In the iPhone, the dialog for setting up a new e-mail account, contains four fields, each with a label and an example provided as placeholder text. These are: [Label] [Placeholder] Name:John Appleseed Address: [EMAIL PROTECTED] Password:Required Description: My Email Account -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] [WF3] Web Forms 3.0 Feature List
On Thu, 22 Feb 2007, Matthew Raymond wrote: I'll start: * XForms Tiny's |calculate| attribute * |required| attribute with expression values (formerly XForms Tiny's |needed| attribute) * |valid| (formerly XForms Tiny's |constraint| attribute) * |disabled| attribute with expression values (formerly XForms Tiny's |relevant| attribute, without the hidden presentation) These all seem to be possible from script; it's not clear to me what defining a simple expression language gains us here. * |placeholder| attribute * input type=color (color picker) Will reply to these in separate threads. * input type=move (drag control for moving items in a repetition block) Dropped the repetition block structure altogether, so this is not longer really relevant. * altinput Responded to this recently. Basically I think that we shouldn't introduce features specifically for the transition period. On Thu, 22 Feb 2007, carmen wrote: don't you see cc1_exp_year as a bit of a problem? i hope webforms3 addresses the name hacking that has become standard in web frameworks to flatten multiple db tables, columns, keys, usernames, records, etc into a single name field. requiring regex is not so cool.. WF2 referenced RFC3106, but nobody seemed interested in this, so I've dropped that in HTML5. On Fri, 23 Feb 2007, Mihai Sucan wrote: I'm not sure if this is appropriate thread to make a wish, but the subject is WF3 feature list. Please don't forget about extending input type=email to allow a list of multiple emails, comma separated. Will cover that separately. On Sun, 25 Feb 2007, Keryx Web wrote: More food for thought can be found at http://friendlybit.com/js/improving-interactivity-with-javascript/ At least three of them seem to not be in WF 2: Drag and drop, Image handling and Sortable Items. Auto validation seems like a usable feature as well, but is perhaps left to JS as server-side validation often is necessary. We've done many of those now. Rich tooltips, and declaratively saying which controls affect each other, aren't possible in HTML5, but I'm not sure what to do about those. Better looking form fields are a CSS issue. I'm not really sure what we can do about autosaving, image handling, and search-based or structured navigation. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] _charset_ and conformance
On Sun, 25 Feb 2007, Henri Sivonen wrote: Is it conforming to specify a value for the _charset_ control? Is it conforming to have a form control that is not of type='hidden' and that is named _charset_. No, yes. HTML5 covers this now. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] WebForms2 validity
On Tue, Oct 28, 2008 at 8:09 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Fri, 9 Feb 2007, Sean Hogan wrote:
I might be missing something obvious, but...
When are ValidityState properties updated? And when are CSS pseudo-classes
(:valid, :invalid, :in-range, :out-of-range) updated?
Continually (in particular whenever the constraints or the values change
-- the validity states are defined in terms of those values).
Many textual input form-controls would begin in one or another invalid
state (valueMissing, patternMismatch) however authors would typically
want CSS validity styles to apply only after checkValidity() - either a
manual one or the automatic one performed by form-submission.
Why?
I agree with Sean's idea: at least on the initial state, controls
showing up with invalid styling can be quite confusing to many
users. It may depend a lot on the context, and even more on the user:
although the initial for a required text field would be invalid,
and even would make sense to visually convey that fact, many users may
wonder What did I wrong if I didn't do anything yet?. The best
solution I can think of this would be an additional pseudo-class, such
as :default, :initial-value, :non-modified, or anything like
that (I'm really bad at naming stuff, so please take those only as
*examples*, because that's what they are), which could be used
together depending on the needs of each site or application, like
this:
:valid {
// code for green higlighting
}
:invalid {
// code for red highlighting
}
:default {
// overriding code to remove highlighting (or to apply white highlighting)
}
:default:invalid {
// code for yellow highlighting
}
That's just an example. The idea is that an application may need to
convey (through styling the validity pseudo-classes) the meanings you
have put something wrong here and you have to provide something
here as different concepts.
Just my thoughts.
Re: [whatwg] onchange events for input type=radio
Ian Hickson wrote: On Thu, 18 Jan 2007, Boris Zbarsky wrote: There has recently been an interesting Mozilla bug report about onchange for radio inputs. It seems that UAs interoperably implement something non-obvious; it may be a good idea to specify it: https://bugzilla.mozilla.org/show_bug.cgi?id=363693 Done. Is http://www.w3.org/html/wg/html5/#event-input-change the relevant spec text? -Boris
Re: [whatwg] onchange events for input type=radio
On Tue, 28 Oct 2008, Boris Zbarsky wrote: Ian Hickson wrote: On Thu, 18 Jan 2007, Boris Zbarsky wrote: There has recently been an interesting Mozilla bug report about onchange for radio inputs. It seems that UAs interoperably implement something non-obvious; it may be a good idea to specify it: https://bugzilla.mozilla.org/show_bug.cgi?id=363693 Done. Is http://www.w3.org/html/wg/html5/#event-input-change the relevant spec text? The relevant spec text is in several places. For radio buttons in particular: http://www.whatwg.org/specs/web-apps/current-work/#radio-button-state # If the element is mutable, then: The pre-click activation steps consist # of setting the element's checkedness to true. The canceled activation # steps consist of setting the element's checkedness to false. The # activation behavior is to fire a simple event called change at the # element. Most of the terms in that paragraph are to do with (and are hyperlinked to) the algorithms defined in: http://www.whatwg.org/specs/web-apps/current-work/#interactive-content Please let me know if that doesn't make sense, and I'll try to clarify it. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] onchange events for input type=radio
Ian Hickson wrote: The relevant spec text is in several places. For radio buttons in particular: http://www.whatwg.org/specs/web-apps/current-work/#radio-button-state Most of the terms in that paragraph are to do with (and are hyperlinked to) the algorithms defined in: http://www.whatwg.org/specs/web-apps/current-work/#interactive-content Please let me know if that doesn't make sense, and I'll try to clarify it. Ah, ok. It makes sense; the phrasing and general formatting could probably be clearer, but I'm not going to worry about that at this stage, I think... -Boris
Re: [whatwg] WebForms2 validity
On Tue, Oct 28, 2008 at 9:27 PM, Eduard Pascual [EMAIL PROTECTED] wrote:
[The best] solution I can think of this would be an additional pseudo-class,
such
as :default, :initial-value, :non-modified, or anything like
that (I'm really bad at naming stuff, so please take those only as
*examples*, because that's what they are), which could be used
together depending on the needs of each site or application, like
this:
:valid {
// code for green higlighting
}
:invalid {
// code for red highlighting
}
:default {
// overriding code to remove highlighting (or to apply white highlighting)
}
:default:invalid {
// code for yellow highlighting
}
That's just an example. The idea is that an application may need to
convey (through styling the validity pseudo-classes) the meanings you
have put something wrong here and you have to provide something
here as different concepts.
Just my thoughts.
This seems to overlap with the @placeholder proposal. Maybe both
proposals could be merged somehow?
Ideas:
a) Don't include :default but instead define :invalid so that it won't
be set as long as the placeholder is visible;
b) get rid of the placeholder attribute and use :default instead;
Re: [whatwg] WebForms2 validity
Am Dienstag, den 28.10.2008, 23:03 +0100 schrieb Philipp Serafin: This seems to overlap with the @placeholder proposal. Maybe both proposals could be merged somehow? Ideas: a) Don't include :default but instead define :invalid so that it won't be set as long as the placeholder is visible; make an easy rule into a complicated one to cater to an unknown use case. yeah. way to go. /sarcasm fact: invalid content is invalid. i'd use javascript to change the element class from never given focus to had focus using onclick in your case. b) get rid of the placeholder attribute and use :default instead; :default (or :unchanged, or whatever you want to call it) in itself sounds good. however, as i understand it the proposed placeholder is to confer semantic content, thus some pseudocontent-trickery (with label ?) will probably be needed to properly separate semantic and presentational content.
Re: [whatwg] Form Control Group Labels
On Tue, 13 Mar 2007, Elliotte Harold wrote: Currently in HTML 4, and apparently in Web Forms 2, there is a rule that each label element applies to exactly one input field. 10 inputs, at least 10 labels. However looking at a number of tabular but not exactly repeating forms, both on the Web and on paper, I notice that it common for the column headers to essentially serve as label for the input fields. For example Homework 1 Homework 2 Homework 3 John Smith87 86 98 Jane Jones 100 78 98 Fred Wilde89 65 69 What strikes me about examples like this is that the labels for the input fields naturally apply to more than one input field. For example, in the above each label covers three fields. I wonder if there's a common use case to say something like label for=A1 A2 A3Homework 1/label label for=B1 B2 B3Homework 2/label label for=C1 C2 C3Homework 3/label Currently this is not possible. The label's for attribute can only point to one input element. This seems to be a case where the th should be enough, no? On Tue, 13 Mar 2007, Simon Pieters wrote: We could just say that if a form control is in a table data cell, and doesn't have a label associated with it, then the cell's header cells are labels for the form control. Do we need to explicitly say that, even? On Tue, 13 Mar 2007, Robert Brodrecht wrote: I think the main problem with multiple IDs for labels is the usability. How would it work and still make sense? Indeed. On Tue, 13 Mar 2007, Elliotte Harold wrote: Pretty much like it does now I suspect. When presenting the form control to a user, the software would assign it the label. It would just use the same label more than once. The for attribute is not new. What's being proposed is simply allowing it to identify multiple controls rather than just one. The problem is when you select the label, which control does it apply to? On some systems, we have to focus a control when that happens. On Tue, 13 Mar 2007, Jeff Cutsinger wrote: I'll second this. Given that the table is marked up correctly (that is, using th and |scope| or equivalents), it should be usable for a blind person without the labels. And the question is: what's the benefit of having labels with multiple controls? When a label is associated with a control it currently allows you to click the label to focus the control- this is obviously absurd with multiple controls per label. I'd probably just mark them up as labels without any |for|. Agreed. On Tue, 28 Oct 2008, Markus Ernst wrote: Ian Hickson schrieb: On Tue, 31 Oct 2006, Lachlan Hunt wrote: There are workarounds using fieldset and legend for the question, like this. fieldset legendGender:/legend label for=minput type=radio id=m name=gender value=m Male/label label for=finput type=radio id=f name=gender value=f Female/label /fieldset That's not a workaround. It's exactly what you're supposed to do. fieldset lets you group a set of controls with a common legend, which is exactly the problem you described. IMO Lachlans opinion about the fieldset solution being a workaround reflects a basic problem with those form elements: they are highly presentational. Your example: fieldset legendGender:/legend label for=minput type=radio id=m name=gender value=m Male/label label for=finput type=radio id=f name=gender value=f Female/label /fieldset serves the same purpose as this one: label for=genderGender:/label select id=gender name=gender option value= /option option value=mMale/option option value=fFemale/option /select Both provide a list of values, of which zero or one can be selected. The only real difference is in the presentation, but structurally they are totally different. Right; indeed Web Forms 2 actually called this out explicitly. Now consider this: fieldset legendSender:/legend label for=ninput type=text id=n name=n value= Name/label label for=minput type=text id=m name=m value= E-mail/label /fieldset This is structurally the same as the radio button example, except some attribute values, but serves a totally different purpose. If you look at it this way, calling the fieldset solution for grouping a group of radio buttons (which are actually grouped by their common name attribute value) a workaround does not seem totally wrong to me. Why not? This seems like the exact same thing to me. It's a compound control for a Sender consisting of a name and e-mail address. The AT behavior seems correct in both cases. I consider a total re-thinking of select, input type=checkbox and input type=radio elements as highly desirable, though I see that this might cause more serious backwards compatiblity problems than for example removing the font tag. One possible solution could be using
Re: [whatwg] WindowHTML Option() constructor
On Tue, 28 Oct 2008 02:52:36 -0700, Ian Hickson [EMAIL PROTECTED] wrote: On Sun, 5 Nov 2006, Anne van Kesteren wrote: The Option() constructor takes four arguments: 'Option(in DOMString name, in DOMString value, in boolean defaultSelected, in boolean selected)' is the complete version of it. Fixed. The IDL uses Constructor() but should use NamedConstructor=Option() instead. (See e.g. HTMLImageElement for how it should be done.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Web Forsm 2.0 possible omissions
On Wed, 21 Mar 2007, [EMAIL PROTECTED] wrote: I've noticed two possible ommissions that seem to me to be essential to a useful Web Forms spec: 1) Input filtering (i.e. allow only numbers to be typed) suggested implementation (like pattern takes a regexp but behaves as if inside: ^ [ ]$ input type=text filter=\d input type=text pattern=\D* 2) Auto tabbing for a 4 digit code: input type=text filter=\d autotab=4/ This appears to be a presentation concern, for which I think we should allow CSS and XBL to provide the solution. On Wed, 21 Mar 2007, Martin Atkins wrote: A more general request would be an ability to display one value but have a different one behind the scenes. Obviously when the user edits it they would expose the internal value, much like in an spreadsheet when you switch a field containing a formula from view mode to edit mode. Again, this seems like something for XBL. On Wed, 21 Mar 2007, [EMAIL PROTECTED] wrote: Re: This can be easily achieved with a simple script but I wonder if it's desirable. but the point of webforsm is to avoid scripts where possible (so it works for high security peeps as well as accessibility peeps...), isn't it? No, the goal is only to make the common things possible without script, not make anything possible without script possible. as for desireable - well if WEb forms is part of the WEB API initiative and both legacy applications (unix/dos based), contemporary applications (key code fields in installation dialogs) and future apps (my next project!! ;-)) I suspect it is both useful and desireable (if you've ever been a data inputter you'll know what i mean. If you are uncomfortable with 'autotabbing' then a trimmed down version might be making a field with readonly elements e.g. 01/02/1945 as __/__/___ Still autotabbing is a feature I have been asked to deliver about once ever six months for the last 10 years (and using script have done so) I just want to make it work for my banking friends who have scripts turned off and who are ALWAYS using legacy style apps so get frustrated when clunk web apps don't provide the facility (especially when hitting the right arrow on a form element doesn' jump you to the next element. I agree that it would be useful, the question is whether it's useful enough to warrant the expense of implementing it in browsers and testing it and speccing it and so forth. I'm guessing it probably isn't at the moment. Maybe in a future version? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Requests to change button to match IE7.
On Sat, 14 Apr 2007, Simon Pieters wrote: For compatibility with IE, button should default to type=button instead of type=submit. On Sat, 14 Apr 2007, Lachlan Hunt wrote: button without type should default to button. button type=unknown should default to submit. That way, we could still introduce new button types in the future and have them fall back to submit, while retaining compat with IE. On Sat, 14 Apr 2007, Simon Pieters wrote: We currently don't have interop with IE and other browsers with regards to what to send to the server as the value of button. IE always sends .innerText as value. Other browsers always send the contents of value= as value, or the empty string if it's missing (as per HTML4). There may be content on the Web relying on IE's behavior, e.g. missing value= attribute. Still, the other browsers agree on using value= and using value= is useful (in order to send one value to the server but show different text to the user as button text), and is the way other form controls work. A middle ground could be to use value= if the attribute is present, or .innerText otherwise (pretty much like option). On Sat, 14 Apr 2007, Kornel Lesinski wrote: IIRC it's innerHTML, but I can't verify it at the moment. Is there really a noticable number of sites that rely on IE's broken behaviour? I doubt, because: * By sending contents of button instead of value, it doesn't provide much more functionality than input type=submit. * Styling of button is not an easy task, so it's unlikely to be used for its HTML contents - authors rather use input type=image or a href=javascript:sendform() * And worst of all - IE always sends all undisabled buttons. This makes value irrelevant, because you can't check which button was clicked anyway. On Sat, 14 Apr 2007, Simon Pieters wrote: Apparently, enough for the IE team to not change it for IE7, despite me sending a bug report about it. (The bug was closed as by design IIRC.) IE8b2, WebKit trunk, Firefox trunk, and Opera 9.6 are now all consistent and do what the spec says: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A...%3Cform%20action%3D%22..%2F..%2Fcgi%2Ftest-tools%2Fecho%22%3E%3Cbutton%20name%3Da%3Ex%3Cbr%3Ey%3C%2Fbutton%3E%3Cbutton%20name%3Db%20type%3Db%3Ex%3Cbr%3Ey%3C%2Fbutton%3E%3C%2Fform%3E Thus, I have not changed the spec to match the above requests. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [wf2] form submission algorithm questions
On Sun, 15 Apr 2007, Benjamin West wrote: At http://bewest.wordpress.com/2007/04/10/webforms-2-submissionvalidation-model/ , I discuss the submission/validation algorithm specified in http://www.whatwg.org/specs/web-forms/current-work/#form-submission . Applications won't be able to trust any incoming input, without some mechanism that ensures that the validation steps have been followed. Even if such a mechanism existed, I suspect (but lack evidence) that most applications require additional validation beyond type and format. I also am a bit confused about the usability issues surrounding exposing errors in the input type and format to end users. This creates a maintenance problem: two implementations performing some set of similar capabilities. When I do validation in my web applications, I implement all the validation on the server, and expose the validation through some protocol. Many times, I use some combination of XHR + submission + json formatted responses. This ensures one implementation that allows the application to communicate its expectations of valid input beyond format and type. Would it be feasible to modify the algorithm to specify some kind of protocol to iteratively validate content until it's correct? The type/format validation is ok as a baseline for communication an application's expectations of input. Part of the desire here is to dramatically simplify the code and make the UI much faster. We can't really rely on a server round-trip here, that would defeat the point. And the code to do this kind of validation would probably end up non-trivial in comparison to having the validation UI all client-side and the server just having a generic error message when the validation fails server-side. Authors are welcome to implement what you describe themselves, though, using setCustomValidity(). I suggest something like: 1.) Step One: a new event onvalidate is dispatched 2.) Step Two: Identify form controls. 3.) Step Three: build form data set. 4.) Step Four:encode data set. 5.) Step Five:submit data set to validation URI. 6.) Step Six: dispatch recieved 7.) Step Seven: process validation results if response indicates validity- Submit using steps 2 - 8 of original algorithm. if response indicates invalid input- rinse and repeat There's a lot of stuff missing from this proposal, I suppose, and I'm not even sure how feasible it is to introduce events like onvalidate (or some analog). The protocol for the messages exchanged and the format of the response would need to be specified. The data set submitted for validation should probably include either the type information specified in the markup, or an identifier unique within the application. I suspect some profile technology, perhaps combined with XBL, could provide mechanisms for facilitating useful error handling interfaces for the end user. I'm also unfamiliar with any security concerns. I think I'd rather see people experimenting with doing this before we specify a formal way to do it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Allow block content inside label element
On Mon, 7 May 2007, Brad Fults wrote: Currently, as far as I can tell, in HTML 4 and HTML 5, the label element is defined as having inline content. When using the implicit form control association pattern described in the HTML 4 spec (e.g. a form control inside of the label element instead of or in addition to using the |for| attribute), this becomes a problem. Specifically, if one tries to place a textarea element inside of a label element, modern browsers will insert the textarea as a later sibling to the label in the DOM instead of as a child. This seems to be due to the fact that the textarea is a block element and that label can't contain it according to the spec. Could we remedy this by allowing block content inside of a label element? textarea is allowed in label in HTML5. (And HTML4, too, actually.) On Tue, 8 May 2007, Kristof Zelechovski wrote: I have a weak feeling against this proposition. Not that I think it would harm very much, it just seems not very appropriate. From the behavioral point of view: The purpose of a LABEL control is to redirect focus on click. It does not make much sense with a TEXTAREA control that is usually big enough to click upon. From a semantic point of view: the TEXTAREA control is special because it does not make sense to ask whether the content of the TEXTAREA is or even contains some fixed text because the user may express the same meaning with different words; its content may be stored but you have to use advanced text analysis tools (such as a human reader) to process it if you need to. You can use a label to define what you expect the user to enter into the control; the TEXTAREA control is so special that it seems obvious that it needs a caption or some introductory explanation, not a label (except for the labels Your message and Your text, which are possible but not very informative indeed.) I disagree, it seems quite reasonable to me. It's common in OS UIs, why not on the Web? On Tue, 8 May 2007, Benjamin Hawkes-Lewis wrote: It would probably help if we could associate short labels and longer descriptions with form fields. It would certainly help if we could do so with fieldsets: http://www.rnib.org.uk/wacblog/general-accessibility/too-much-accessibility-fieldset-legends/ I don't really follow. The blog post has good advice, but doesn't seem to point to a problem in the spec. On Wed, 9 May 2007, K�i�tof �elechovski wrote: The restriction on LABEL behavior is not a clarification, it is a change. The browser vendor has to choose whether it is compliant with version 4 or 5. Therefore the current behavior can hardly be called a bug. Note that this change is not reported on the Wiki http://wiki.whatwg.org/wiki/Changes_from_HTML4#Changed_Elements; I did not update the content because I strongly oppose this idea. It seems it has strong support http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2004-July/thread.html#1 366 - where Mr.�Raymond's opinion unfortunately sank - but there is a possibility to overthrow it by making it void on a legal basis: The Microsoft Windows environment does not provide a native LABEL control.* It there was one, the restriction of version 5 would perhaps apply. But you cannot tell how the native control behaves when it does not exist. You can assume it would redirect the focus to the input control if it existed, and introduce the feature to the browser upon that assumption. [...] Windows clearly does have the equivalent of a label control, even if it doesn't expose it as such. The behavior in HTML5, whether you call it a change or a clarification, is the right thing for us to require. On Fri, 11 May 2007, K�i�tof �elechovski wrote: The speculative wording of HTML5 is actually less accurate because it refers to a platform control which need not exist at all. The imperative wording of HTML4 is both clearer and more accurate. The text in HTML5 now says The label element's exact default presentation and behavior, in particular what its activation behavior might be, if anything, should match the platform's label behavior. which seems fine to me. On Tue, 8 May 2007, Martin Atkins wrote: Some software that I'm responsible for frequently wraps label elements around div elements, purely because current versions of IE will not apply display:inline-block to inline elements. While I guess that is using a deviation from the HTML spec in order to compensate for a deviation from the CSS spec[1], it's still something I'm not going to be able to stop doing without a large amount of work. Have you tried just display:block on the textarea instead? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Changes from HTML4 wiki page
On Thu, 10 May 2007, Kristof Zelechovski wrote: Note that the presentation reflects platform rule is unacceptable either since that essentially means that markup is not allowed in the label, except for the control that is being labeled. The presentation reflects platform rule is the whole point of media and device independent markup. It's the whole point of HTML. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Allow block content inside label element
What is the equivalent of the LABEL control under Microsoft Windows? Chris -Original Message- From: Ian Hickson [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 29, 2008 1:08 AM To: Brad Fults; Kristof Zelechovski; Benjamin Hawkes-Lewis; Matthew Paul Thomas; Simon Pieters; Martin Atkins Cc: WHAT-WG Subject: Re: [whatwg] Proposal: Allow block content inside label element On Wed, 9 May 2007, Kitof elechovski wrote: The restriction on LABEL behavior is not a clarification, it is a change. The browser vendor has to choose whether it is compliant with version 4 or 5. Therefore the current behavior can hardly be called a bug. Note that this change is not reported on the Wiki http://wiki.whatwg.org/wiki/Changes_from_HTML4#Changed_Elements; I did not update the content because I strongly oppose this idea. It seems it has strong support http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2004-July/thread.html#1 366 - where Mr.Raymond's opinion unfortunately sank - but there is a possibility to overthrow it by making it void on a legal basis: The Microsoft Windows environment does not provide a native LABEL control.* It there was one, the restriction of version 5 would perhaps apply. But you cannot tell how the native control behaves when it does not exist. You can assume it would redirect the focus to the input control if it existed, and introduce the feature to the browser upon that assumption. [...] Windows clearly does have the equivalent of a label control, even if it doesn't expose it as such. The behavior in HTML5, whether you call it a change or a clarification, is the right thing for us to require. On Fri, 11 May 2007, Kitof elechovski wrote: The speculative wording of HTML5 is actually less accurate because it refers to a platform control which need not exist at all. The imperative wording of HTML4 is both clearer and more accurate. The text in HTML5 now says The label element's exact default presentation and behavior, in particular what its activation behavior might be, if anything, should match the platform's label behavior. which seems fine to me.
Re: [whatwg] Changes from HTML4 wiki page
What should the browser do with a label containing markup, assuming the operating systems allows plain text labels only? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, October 29, 2008 1:09 AM To: Kristof Zelechovski Cc: 'WHATWG' Subject: Re: [whatwg] Changes from HTML4 wiki page On Thu, 10 May 2007, Kristof Zelechovski wrote: Note that the presentation reflects platform rule is unacceptable either since that essentially means that markup is not allowed in the label, except for the control that is being labeled. The presentation reflects platform rule is the whole point of media and device independent markup. It's the whole point of HTML.
Re: [whatwg] Proposal: Allow block content inside label element
Am Mittwoch, den 29.10.2008, 01:27 +0100 schrieb Kristof Zelechovski: What is the equivalent of the LABEL control under Microsoft Windows? http://msdn.microsoft.com/en-us/library/ms743463.aspx (Under 9000 seconds in your favorite search engine.) Harr harr, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Web Forms attributes: minlength / autocomplete
On Wed, 6 Jun 2007, Sander wrote: I'd like to see a minlength attribute that can be used on the same elements as the maxlength attribute. The default value can be 0 unless the required atribute is set (in that case it should be 1). The value of the element should be trimmed of spaces at the beginning or the end before validating/submitting (perhaps this could be made optional in which case negative values could be used for the minlength attribute to indicate whether the trimming has to take place or not). I haven't added this, because I'm not convinced the use cases are as compelling as those for maxlength. Maybe we should add this in a future version, though, if the feature is found to be needed often enough. (For now I'd rather keep things to a minimum to give browser vendors a chance to catch up.) The autocomplete attribute acts as a boolean, but its values are not consistent to other booleans, being either attributes or variables. Why not use autocomplete=autocomplete or its minimised form? Is it because it's not the on state that is important, but the off state. If so, I'd suggest to use true or false instead or rename the attribute to noautocomplete. If it's a backward compatibilty issue then I suggest both on/off and true/false should be allowed. I'd love to change that, but we're constrained by legacy implementations. On Wed, 6 Jun 2007, Sander wrote: I see. But we can add true/false as possible (and prefered) values and keep on/off for backward compatibility. I don't think we want to make things even more complex, especially since these new values add nothing and don't work in older browsers. Following your argument a of of its specs may not be changed anymore, even though the HTML5 specs are still in working draft. Yup. On Wed, 6 Jun 2007, Sander wrote: For instance some reference codes, zip codes or telephone numbers have a certain length, but maybe not alway the same notation. As you know telephone numbers in the Netherlands have 10 digits, but some people prefer to write them all together, and others seperate them, using spacers and/or hyphens. If you want to allow people to write their number in their own fashion (which is a good thing from a usability point of view) then you know the number must be at least 10 characters long. Same for Dutch zip codes that are sometimes written with a space in them and sometimes not, but they're at least 6 characters long. US ZIP codes are of the form 12345-6789 or 12345 but minlength wouldn't help you as much as pattern= here, since 123456 would be past the minimum length but totally bogus. Perhaps you want users to come up with a password that's at least 6 characters long Passwords are the only real use case I've seen so far, and while that is important, it's not really enough to justify the cost given that there are plenty of alternatives for doing this. [...] On Thu, 7 Jun 2007, Sander wrote: Well, you might wonder whether input type=range adds something to type=number that is really needed. It's a different control. That's a major difference. :-) On Thu, 7 Jun 2007, Kristof Zelechovski wrote: A pattern with exponential matching time can be used to lock the viewer's browser, potentially making her lose her input in other controls and other windows; that means the pattern attribute must be disabled for restricted sites. Not at all, the user agent can just detect that a pattern is taking a long time to match, just like a browser could detect that a document is creating too many img elements or whatever. On Thu, 7 Jun 2007, Anne van Kesteren wrote: FWIW: you're wrong. maxlength= was made to truncate (again) because not doing so broke existing content. (Implementation experience coming from Opera implementing the Web Forms 2 specification.) Could you clarify this? I didn't think we'd decided to truncate, just not raise an error on initial values that are too long. On Thu, 7 Jun 2007, Kristof Zelechovski wrote: These negative values are a misleading hack in that the input value it should be trimmed in the DOM as well to be consistent. If you need autotrim, introduce an explicit attribute to this end. This would make the side effect more explicit. I have no idea what you're talking about here, sorry. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Web Forms: change event
On Wed, 6 Jun 2007, Sander wrote: The specs say that for select ...the change event shall be fired when the selection is completed Does this mean that, when using a keyboard for navigation, the change event is fired when the user hits 'enter' or when she navigates from one option to another? I assume it's the former, but I just to be sure as selectboxes with change event handlers are often (ab)used for navigation purposes. So, can anyone confirm my assumption? Thanks. Depends on the platform. I've used different wording in HTML5, let me know if it's confusing still (it probably is), and what it should say instead. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [WF2] Why does list= work with select?
On Wed, 13 Jun 2007, Anne van Kesteren wrote: On Wed, 13 Jun 2007 08:17:50 +0200, Simon Pieters [EMAIL PROTECTED] wrote: Why does it work together with select? What are the use-cases for having a combo box where the select is also visible? It doesn't make any sense to me. The reason to remove this feature is that authors may start using select in combination with display:none which is not what is desired. (This was mentioned on IRC, but it's probably worth mentioning here as well.) This is an interesting point. Ok, fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms: input type=radio form=x y
On Thu, 21 Jun 2007, Anne van Kesteren wrote: It would be good if radio controls can not be shared accross multiple forms as that makes them a huge mess. Opera's proposal would be that if there's a form attribute specified and it's non-empty the first value determines the form it is associated with. (With all the usual error handling.) I removed all multiple-form support. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Allow block content inside label element
I am aware of that; however, that is not about Windows, it is about WPF. You could quote MFC, Delphi, Flash or even HTML (as HTA) with the same level of relevance. Harr harr, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nils Dagsson Moskopp Sent: Wednesday, October 29, 2008 1:34 AM To: whatwg Subject: Re: [whatwg] Proposal: Allow block content inside label element Am Mittwoch, den 29.10.2008, 01:27 +0100 schrieb Kristof Zelechovski: What is the equivalent of the LABEL control under Microsoft Windows? http://msdn.microsoft.com/en-us/library/ms743463.aspx (Under 9000 seconds in your favorite search engine.) Harr harr, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] WF2 - form action=
On Sat, 30 Jun 2007, Philip Taylor wrote: WF2 says: When the [form element's action] attribute is absent, UAs must act as if the action attribute was the empty string, which is a relative URI reference, and would thus point to the current document (or the specified base URI, if any). But: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Cbase%20href%3D%22http%3A//google.com%22%3E%3Cform%3E%3Cinput%20type%3Dsubmit%3E In IE7, FF2, FF3, Opera 9.2, it ignores the base URI and always submits to the current page. In Safari 3, it does take account of the base URI. In all, form action= does the same as form. In all, form action=. does take account of the base URI. Perhaps it would be sensible to follow the majority. Done. On Sun, 1 Jul 2007, Thomas Broyer wrote: Wouldn't that be a violation of RFC3986? http://tools.ietf.org/html/rfc3986#section-4.4 I guess so. Noted. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Allow block content inside label element
On Wed, 29 Oct 2008, Kristof Zelechovski wrote: What is the equivalent of the LABEL control under Microsoft Windows? There are various controls that have equivalents. But basically any text that is displayed next to an interactive control in a way that labels the interactive control. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Changes from HTML4 wiki page
On Wed, 29 Oct 2008, Kristof Zelechovski wrote: What should the browser do with a label containing markup, assuming the operating systems allows plain text labels only? That's a CSS issue, not a behavior issue. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Allow block content inside label element
Does that mean that Internet Explorer should NOT redirect focus from a LABEL to the control because the operating system GUI does not do that either? Chris -Original Message- From: Ian Hickson [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 29, 2008 2:00 AM To: Kristof Zelechovski Cc: 'WHAT-WG' Subject: RE: [whatwg] Proposal: Allow block content inside label element On Wed, 29 Oct 2008, Kristof Zelechovski wrote: What is the equivalent of the LABEL control under Microsoft Windows? There are various controls that have equivalents. But basically any text that is displayed next to an interactive control in a way that labels the interactive control.
Re: [whatwg] Changes from HTML4 wiki page
What should the browser do with a label containing a hyperlink, assuming the operating system allows plain text labels only? Chris -Original Message- From: Ian Hickson [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 29, 2008 2:00 AM To: Kristof Zelechovski Cc: 'WHATWG' Subject: RE: [whatwg] Changes from HTML4 wiki page On Wed, 29 Oct 2008, Kristof Zelechovski wrote: What should the browser do with a label containing markup, assuming the operating systems allows plain text labels only? That's a CSS issue, not a behavior issue.
Re: [whatwg] Proposal: Allow block content inside label element
On Wed, 29 Oct 2008, Kristof Zelechovski wrote: Does that mean that Internet Explorer should NOT redirect focus from a LABEL to the control because the operating system GUI does not do that either? For checkboxes and radio buttons, the text that Windows places near the interactive widget both focuses and activates the control; in the case of text fields, the text is static and has no behavior. On Wed, 29 Oct 2008, Kristof Zelechovski wrote: What should the browser do with a label containing a hyperlink, assuming the operating system allows plain text labels only? I'm not aware of any modern GUI that doesn't allow text to be interactive (like a link) or styled, so this is probably academic. However, the spec already defines how to handle elements within label that have their own activation behavior, so this is moot. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input name=isindex
On Wed, 29 Oct 2008, Martijn wrote: 2008/10/28 Ian Hickson [EMAIL PROTECTED]: On Tue, 20 Feb 2007, Martijn wrote: Submission of an isindex element is different compared to normal form submission with a text input element, only the value part is submitted. This parsing definition: http://www.whatwg.org/specs/web-apps/current-work/#isindex means that forminput name=isindex/form also should only submit the value part. And indeed, that is what IE7 seems to be doing. Mozilla even has a bug filed for this: https://bugzilla.mozilla.org/show_bug.cgi?id=93795 So I guess this needs to be mentioned somewhere in the web forms spec or something? Done, thanks. In hindsight, perhaps just remove the isindex element, all together. It's not allowed for authors, but it is required of UAs since there are still pages that use it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Allow block content inside label element
The text that Windows places near check boxes and radio buttons corresponds to INPUT[value], not to LABEL. Internet Explorer redirects focus from labels to obey HTML 4; according to HTML 5, it should stop. Should it really? And what should happen with labels on HTML 4 pages? The user experience will be inconsistent. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, October 29, 2008 2:10 AM To: Kristof Zelechovski Cc: 'WHAT-WG' Subject: Re: [whatwg] Proposal: Allow block content inside label element On Wed, 29 Oct 2008, Kristof Zelechovski wrote: Does that mean that Internet Explorer should NOT redirect focus from a LABEL to the control because the operating system GUI does not do that either? For checkboxes and radio buttons, the text that Windows places near the interactive widget both focuses and activates the control; in the case of text fields, the text is static and has no behavior.
Re: [whatwg] WebForms2 validity
Ian Hickson wrote:
On Fri, 9 Feb 2007, Sean Hogan wrote:
I might be missing something obvious, but...
When are ValidityState properties updated? And when are CSS pseudo-classes
(:valid, :invalid, :in-range, :out-of-range) updated?
Continually (in particular whenever the constraints or the values change
-- the validity states are defined in terms of those values).
Ok. But what's the use of checkValidity() on form-control-elements?
Isn't it just:
function() {
if (!this.validity.valid) this.dispatchEvent(invalid);
return this.validity.valid;
}
Many textual input form-controls would begin in one or another invalid
state (valueMissing, patternMismatch) however authors would typically
want CSS validity styles to apply only after checkValidity() - either a
manual one or the automatic one performed by form-submission.
Why?
I would probably now agree that the default should be immediate
application of :valid / :invalid styling which can worked-around with
script. The opposing view (what I would have said a year ago) is...
I think that's the way it usually is now. More specifically:
1. It could be confusing to have :invalid styling on form-controls when
the page first loads.
2. It could be distracting for the styling of a form-control to switch
between :valid and :invalid while the user is typing into it.
3. It could be distracting for the :valid and :invalid styles to apply
before the user tries to submit or explicitly requests the data to be
checked.
#2 can be worked around using :focus. I can't see how #1 and #3 can be
worked around without script.
A :validated pseudo-class that applied after checkValidity() is called
or form-submission has been attempted would give some extra flexibility
in the noscript scenario.
[whatwg] Video Element Events? - Use Case: Custom Progress Bar
Hello,
(Sorry if this has come up before and I missed it.)
I was looking over the spec and looking to see how I'd go about creating a
custom progress bar. (Like you see as part of scrub bars.)
To do this I'd imagine that a playing video would have to send out events
fast enough so that the progress bar could be updated enough.
Perhaps I didn't read the spec carefully enough, but I don't see any such
event.
I'd expect to be able to do something like...
videoElem = document.getElementById(aVideoElement);
videoElem.addEventListener( moment,
function()
{
// Handle the event.
// I.e., update the progress bar or something.
//
// I'll need a way to know a what point in time the video is at now.
}
,false);
Note I used the fictitious moment event. (I doesn't have to be called
moment. I just made up something.)
*Is there anything like this already?*
Or do you just set up a timer and poll the currentTime attribute.
I.e., something like...
function updateProgressBar(id)
{
videoElem = document.getElementById(id);
// Update the progress bar using: videoElem.currentTime
}
setTimeout(updateProgressBar(\aVideoElement\), 100);
I suppose the advantage of the polling method is that you can specify how
often you do the update. But it doesn't seems to make for poorer developer
usability.
--
Charles Iliya Krempeaux, B.Sc.
http://ChangeLog.ca/
Re: [whatwg] Proposal: Allow block content inside label element
On Wed, 29 Oct 2008, Křištof Želechovski wrote: The text that Windows places near check boxes and radio buttons corresponds to INPUT[value], not to LABEL. No, the value= attribute is the internal value for submission purposes and is not UI text. Internet Explorer redirects focus from labels to obey HTML 4; according to HTML 5, it should stop. Should it really? And what should happen with labels on HTML 4 pages? The user experience will be inconsistent. The whole point is to make the user experience within a single OS be consistent. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Video Element Events? - Use Case: Custom Progress Bar
On Wed, Oct 29, 2008 at 5:22 PM, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Perhaps I didn't read the spec carefully enough, but I don't see any such event. You're looking for the 'timeupdate' event. This gets raised whenever the current playback position changes. From the spec section 4.8.10.8: If the time was reached through the usual monotonic increase of the current playback position during normal playback, the user agent must then queue a task to fire a simple event called timeupdate at the element. (In the other cases, such as explicit seeks, relevant events get fired as part of the overall process of changing the current playback position.) Although this is hidden away in the cue ranges section, it happens on normal playback without cue ranges. Chris. -- http://www.bluishcoder.co.nz
