Re: [whatwg] Proposal: Allow block content inside label element
Of course, a Windows check box label corresponds to nothing in HTML! I have extrapolated Windows GUI where a check box has a TITLE. This Windows TITLE property has no counterpart in HTML. Sorry for the confusion. I should have added Please answer yes or no because I would like to have a definitive statement of your advice to Microsoft Internet Explorer. Do you think the Internet Explorer should abandon support for LABEL behavior as defined in HTML 4? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, October 29, 2008 6:06 AM To: Křištof Želechovski Cc: 'WHAT-WG' Subject: 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.
Re: [whatwg] Proposal: Allow block content inside label element
On Wed, 29 Oct 2008, Křištof Želechovski wrote: Of course, a Windows check box label corresponds to nothing in HTML! This is incorrect. A Windows checkbox label corresponds to the contents of a label element associated with an input type=checkbox element. Do you think the Internet Explorer should abandon support for LABEL behavior as defined in HTML 4? Insofar as I think they should do whatever the platform does, I believe that they should abandon a strict reading of HTML4, yes. However, at the end of the day, this is up to them. -- 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
We have a different opinion on what corresponds means. A label in HTML is detached, both logically and graphically, while a TITLE in Windows GUI is attached. You can translate from Windows GUI to HTML - but this direction is not interesting; you cannot translate from HTML to Windows GUI, at least not in all cases, without reorganizing content. So you cannot implement support for HTML label in terms of Windows TITLE. Chris -Original Message- From: Ian Hickson [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 29, 2008 9:20 PM To: Křištof Želechovski Cc: 'WHAT-WG' Subject: RE: [whatwg] Proposal: Allow block content inside label element On Wed, 29 Oct 2008, Křištof Želechovski wrote: Of course, a Windows check box label corresponds to nothing in HTML! This is incorrect. A Windows checkbox label corresponds to the contents of a label element associated with an input type=checkbox element.
Re: [whatwg] Proposal: Allow block content inside label element
On Wed, 29 Oct 2008, Křištof Želechovski wrote: We have a different opinion on what corresponds means. A label in HTML is detached, both logically and graphically, while a TITLE in Windows GUI is attached. You can translate from Windows GUI to HTML - but this direction is not interesting; you cannot translate from HTML to Windows GUI, at least not in all cases, without reorganizing content. So you cannot implement support for HTML label in terms of Windows TITLE. Sure, nobody said there was a 1:1 mapping from HTML to Win32. We're just talking about UI concepts, the actual implementation details at the API level are completely irrelevant to the discussion. -- 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] 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] 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] 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] 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] 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] 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] 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] 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] Proposal: Allow block content inside label element
On May 9, 2007, at 2:27 AM, Matthew Paul Thomas wrote: On May 8, 2007, at 9:06 PM, Kristof Zelechovski wrote: ... 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. ... If a browser redirects focus to a *text field* when you click its label, on a platform where that doesn't happen in native GUIs (e.g. Windows, Mac OS, Gnome, or KDE), that's a bug in the browser. Web Forms 2 clarifies this. http://www.whatwg.org/specs/web-forms/current-work/#label ... As an update on this: In KDE 4, released in January this year, clicking a text field's label focuses the field. This was not the case in KDE 3. So, it would be appropriate for Konqueror (or, when running in KDE 4, Firefox or Opera) to focus text fields when their label is clicked, but not for browsers on other platforms. Web Forms 2 allows this platform-specific behavior. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Proposal: Allow block content inside label element
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 Label class described at http://msdn2.microsoft.com/en-us/library/system.windows.controls.label.aspx belongs to the WinFX environment; it is a portable open environment. I would not call it a platform control except for a managed browser, which is a hypothetical entity for the time being. That means, by the way, that a managed browser is forbidden to redirect focus from labels while a native one can do it if it pleases. I never said the wiki is normative. I only wanted to suggest that since this change was overlooked, it may not have been thoroughly considered. Cheers Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Paul Thomas Sent: Friday, May 11, 2007 4:17 PM To: 'WHAT-WG' List' Subject: Re: [whatwg] Proposal: Allow block content inside label element On May 9, 2007, at 10:28 PM, Křištof Želechovski wrote: The restriction on LABEL behavior is not a clarification, it is a change. Sorry, that was a poor word choice on my part. By clarifies this I meant makes this more accurate, not makes this more precise. If you know of any non-contrived Web applications that are broken by this change, I'd be fascinated to see them. 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. It seems to be a bug in the HTML 4 specification. The relevant paragraph says: When a LABEL element receives focus, it passes the focus on to its associated control. See the section below on access keys for examples. Obviously they were thinking about access keys, and maybe they were thinking about voice interfaces too, but not mentioning them specifically so as to convey an aura of media-independence. I would be very surprised if they were thinking about clicking on the label, since no native GUI worked that way (and ten years later, still none do). 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. No openly-editable wiki page can be normative. It seems it has strong support http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2004-July/ thread.html#1366 - 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.* ... That's not true. For example: http://urlx.org/microsoft.com/7354a Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Proposal: Allow block content inside label element
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. Cheers Chris -- *The GUI allows to associate text with a control. The result of associating text with a control that is not allowed to contain text is making the text into a label; otherwise, the text goes into the control as its content. I imagine that the user agent can transform a labeled checkbox into a checkbox with caption set to the text of the label (ignoring markup and style) and get the desired functional behavior. But this procedure does not work for text controls, therefore you cannot infer anything about the behavior of such a label. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Paul Thomas Sent: Wednesday, May 09, 2007 3:28 AM To: 'WHAT-WG' Subject: Re: [whatwg] Proposal: Allow block content inside label element On May 8, 2007, at 9:06 PM, Kristof Zelechovski wrote: ... 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. ... If a browser redirects focus to a *text field* when you click its label, on a platform where that doesn't happen in native GUIs (e.g. Windows, Mac OS, Gnome, or KDE), that's a bug in the browser. Web Forms 2 clarifies this. http://www.whatwg.org/specs/web-forms/current-work/#label Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Proposal: Allow block content inside label element
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.) Best regards, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brad Fults Sent: Tuesday, May 08, 2007 5:47 AM To: WHAT-WG Subject: [whatwg] Proposal: Allow block content inside label element Currently, as far as I can tell, in HTML 4 [1] and HTML 5 [2], 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? Thanks. [1] - http://www.w3.org/TR/html401/interact/forms.html#edef-LABEL [2] - http://www.whatwg.org/specs/web-apps/current-work/multipage/section-forms.ht ml#the-label -- Brad Fults
Re: [whatwg] Proposal: Allow block content inside label element
On Tue, 08 May 2007 05:46:57 +0200, Brad Fults [EMAIL PROTECTED] wrote: Currently, as far as I can tell, in HTML 4 [1] and HTML 5 [2], 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. Hmm. textarea is not a block-level element. It's also willing to be a child of label for me: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Clabel%20style%3D%22background%3Alime%22%3Ex%3Ctextarea%3Ey%3C/textarea%3Ez%3C/label%3E -- Simon Pieters
Re: [whatwg] Proposal: Allow block content inside label element
Brad Fults wrote: Currently, as far as I can tell, in HTML 4 [1] and HTML 5 [2], 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. 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. For this reason, I certainly wouldn't mind label allowing block-level children. Both Opera 9 and IE6 (the only browsers I have handy to test right now) already support DIV as a child of LABEL correctly, per Hixie's DOM viewer.[2] [1] A part of the CSS spec that Microsoft pioneered, but still... [2] http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Clabel%3E%3Cdiv%3Edsfgdsfgsdfgsdf%3C/div%3E%3C/label%3E
Re: [whatwg] Proposal: Allow block content inside label element
Kristof Zelechovski wrote: 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. That is not /the/ purpose of a LABEL element, but merely one way in which user agents can use LABEL. Another use is for a screen reader to label particular fields accurately, especially important when hopping between fields. 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.) Some uses of TEXTAREA are straightforward, some are complex. All benefit from the addition of a LABEL. 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/ -- Benjamin Hawkes-Lewis
Re: [whatwg] Proposal: Allow block content inside label element
On May 8, 2007, at 9:06 PM, Kristof Zelechovski wrote: ... 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. ... If a browser redirects focus to a *text field* when you click its label, on a platform where that doesn't happen in native GUIs (e.g. Windows, Mac OS, Gnome, or KDE), that's a bug in the browser. Web Forms 2 clarifies this. http://www.whatwg.org/specs/web-forms/current-work/#label Cheers -- Matthew Paul Thomas http://mpt.net.nz/
[whatwg] Proposal: Allow block content inside label element
Currently, as far as I can tell, in HTML 4 [1] and HTML 5 [2], 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? Thanks. [1] - http://www.w3.org/TR/html401/interact/forms.html#edef-LABEL [2] - http://www.whatwg.org/specs/web-apps/current-work/multipage/section-forms.html#the-label -- Brad Fults
