This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13531 - use of implicit labels in examples
Summary: use of implicit labels in examples
Status: RESOLVED WORKSFORME
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11ytf
Depends on:
Blocks:
 
Reported: 2011-08-02 21:21 UTC by Cynthia Shelly
Modified: 2012-01-13 10:08 UTC (History)
12 users (show)

See Also:


Attachments

Description Cynthia Shelly 2011-08-02 21:21:55 UTC
the implicit label syntax <label>foo<input></label> is used in many form examples, and there are no examples using <label for>.  Because <label for> can be used in many places where implicit labels cannot, it is considered best practice for accessibility to use that syntax rather than implicit labels.  Examples should use <label for>.
Comment 1 Tab Atkins Jr. 2011-08-02 21:32:14 UTC
I don't understand.  Yes, <label for> is useful for some structures that implicit-<label> is not.  It doesn't follow that <label for> should thus be preferred in all situations.  Implicit-<label> is useful and less verbose than <label for> in the common cases that it's possible in.
Comment 2 Anne 2011-08-03 06:03:57 UTC
Implicit-<label> is also less prone to error (e.g. writing the ID name incorrectly).
Comment 3 Michael[tm] Smith 2011-08-04 05:14:15 UTC
mass-move component to LC1
Comment 4 Anne 2011-08-15 16:05:04 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: <http://dev.w3.org/html5/decision-policy/decision-policy.html>.

Status: Rejected
Change Description: no spec change
Rationale: Using the implicit construct is fine (if not better).
Comment 5 Cynthia Shelly 2012-01-05 16:53:55 UTC
More info on this issue
http://www.html5accessibility.com/tests/form-labels.html
Comment 6 Anne 2012-01-05 16:57:10 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: <http://dev.w3.org/html5/decision-policy/decision-policy.html>.

Status: Rejected
Change Description: no spec change
Rationale: Examples that do not work everywhere yet is not a reason to change the examples. It's an incentive to get the software fixed.
Comment 7 steve faulkner 2012-01-06 10:36:23 UTC
(In reply to comment #6)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, please change the state of this bug to CLOSED. If
> you have additional information and would like the editor to reconsider, please
> reopen this bug. If you would like to escalate the issue to the full HTML
> Working Group, please add the TrackerRequest keyword to this bug, and suggest
> title and text for the tracker issue; or you may create a tracker issue
> yourself, if you are able to do so. For more details, see this document:
> <http://dev.w3.org/html5/decision-policy/decision-policy.html>.
> 
> Status: Rejected
> Change Description: no spec change
> Rationale: Examples that do not work everywhere yet is not a reason to change
> the examples. It's an incentive to get the software fixed.

These examples are not for a new feature they are for a feature that has been around for a long time (10+ years):

http://www.w3.org/TR/html401/interact/forms.html#h-17.9

In this example, we implicitly associate two labels with two text input controls:

<FORM action="..." method="post">
<P>
<LABEL>
   First Name
   <INPUT type="text" name="firstname">
</LABEL>
<LABEL>
   <INPUT type="text" name="lastname">
   Last Name
</LABEL>
</P>
</FORM>

Continuing to promote a method that does not work across browsers without at least providing a warning does a disservice to users and developers. Why promote coding practices that don't work cross browser?
Comment 8 Anne 2012-01-06 13:55:29 UTC
A standard sets a goal. It's not cross-browser coding tutorial.
Comment 9 steve faulkner 2012-01-06 14:00:39 UTC
(In reply to comment #8)
> A standard sets a goal. It's not cross-browser coding tutorial.

Then examples that are not fully implemented should be clearly marked so developers are not fooled into thinking that they are real world examples they can actually use with confidence, especially where the 'goal' is for a trivial implementation of a feature that has not been implemented fully after 12 years.
Comment 10 Benjamin Hawkes-Lewis 2012-01-06 14:21:49 UTC
N(In reply to comment #9)
> (In reply to comment #8)
> Then examples that are not fully implemented should be clearly marked so
> developers are not fooled into thinking that they are real world examples they
> can actually use with confidence, especially where the 'goal' is for a trivial
> implementation of a feature that has not been implemented fully after 12 years.

The WHATWG spec, at least, doesn't highlight implementation status based on the HTML test suite.

I think this should be highlighted in the specification that mandates the behaviors in question, which would seem to be the accessibility API mapping document. This highlighting should be backed by a test suite.

Note that according to the (unofficial) test results liked by Cynthia, the main offender here is now WebKit, and there is an open bug in the WebKit bugtracker on which progress is being made:

https://bugs.webkit.org/show_bug.cgi?id=69736
Comment 11 Benjamin Hawkes-Lewis 2012-01-06 14:33:33 UTC
(In reply to comment #10)
> The WHATWG spec, at least, doesn't highlight implementation status based on the
> HTML test suite.

"does" I meant to say.
Comment 12 John Foliot 2012-01-06 16:24:13 UTC
(In reply to comment #8)
> A standard sets a goal. It's not cross-browser coding tutorial.

Interesting comment Anne. 
Does this mean we could apply the same 
philosophy to  @longdesc?
Comment 13 Tab Atkins Jr. 2012-01-06 16:33:57 UTC
(In reply to comment #12)
> (In reply to comment #8)
> > A standard sets a goal. It's not cross-browser coding tutorial.
> 
> Interesting comment Anne. 
> Does this mean we could apply the same 
> philosophy to  @longdesc?

John, let's not bring irrelevant things into the discussion.
Comment 14 John Foliot 2012-01-06 21:20:06 UTC
(In reply to comment #13)
> 
> John, let's not bring irrelevant things into the discussion.

With due respect, the relevance here is found in the word philosophy. 

As Steve noted in his post to the html-public mailing list (http://lists.w3.org/Archives/Public/public-html/2012Jan/0009.html) there is a design philosophy disconnect going on here.

We have been told, repeatedly, that HTML5 is documenting what works, and not what we wish would work. Ian has on more than one occasion suggested that "specing" something that browsers will not implement is creating fiction. Yet now we have Anne stating that:

   "Examples that do not work everywhere yet is not a reason to change
the examples. It's an incentive to get the software fixed."

Yet, despite being in the HTML4 spec for more than a decade, we still do not have cross browser support for implicit labels, so clearly here the incentive has not worked, or (as I have argued with regard to other attributes) we need to be patient and wait, as the trailing software will ultimately get fixed.  

If that is the case (which is what Anne appears to be stating now), then we *can* accept that total adoption by the browsers of any element or attribute is not a requirement for insertion or retention of said elements or attributes; at which point that decision can be equally applied across the board for other decisions still to be resolved - such as @longdesc. If what Anne wrote is indeed true, then we can also state:

     "Examples (of @longdesc) that do not work everywhere yet is not a reason to <del>change the examples</del><ins>deprecate @longdesc</ins>. It's an incentive to get the software fixed."

It's about the philosophy.
Comment 15 Tab Atkins Jr. 2012-01-06 21:32:23 UTC
It is being argued that implicit labels should be removed (or at least removed from examples) because one implementation is buggy in one aspect of support for them.

You are attempting to argue that the same is true for @longdesc.  That is irrelevant here, because we're not talking about @longdesc.  Let's pretend for a moment that we are, though.  The analogy is flawed; we deprecated @longdesc not because one browser is buggy in one aspect of support for it, but rather because *authors* seem fundamentally unable to use it correctly.

We can fix implementations; that's what bug reports are for.  We can't fix authors; instead, we must fix specs.  If experience shows that something is difficult or confusing for most authors, we need to change/remove it to be less confusing.

So, no, this is not a question of philosophy.  The philosophy Anne is advocating has no relevance to the @longdesc discussion.
Comment 16 steve faulkner 2012-01-13 10:08:54 UTC
(In reply to comment #6)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, please change the state of this bug to CLOSED. If
> you have additional information and would like the editor to reconsider, please
> reopen this bug. If you would like to escalate the issue to the full HTML
> Working Group, please add the TrackerRequest keyword to this bug, and suggest
> title and text for the tracker issue; or you may create a tracker issue
> yourself, if you are able to do so. For more details, see this document:
> <http://dev.w3.org/html5/decision-policy/decision-policy.html>.
> 
> Status: Rejected
> Change Description: no spec change
> Rationale: Examples that do not work everywhere yet is not a reason to change
> the examples. It's an incentive to get the software fixed.

I am happy to say that in the latest round of testing:
http://www.html5accessibility.com/tests/form-labels.html
All major browsers (except Opera) tested now support both methods robustly and as Opera does not have practical support for assistive technology on any platform, its lack of support can be discounted.

so closing the bug.