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 17917 - Consistent use of 'no value' attributes. The 'no value' attributes like "selected", "checked" and "required" are being used inconsistently in the examples throughout the HTML5 specifications. Where "required" is always used with no value ('required' vs 'r
Summary: Consistent use of 'no value' attributes. The 'no value' attributes like "sele...
Status: RESOLVED WORKSFORME
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-18 07:16 UTC by contributor
Modified: 2012-09-17 05:31 UTC (History)
4 users (show)

See Also:

Attachments

Description contributor 2012-07-18 07:16:49 UTC 
This was was cloned from bug 16067 as part of operation convergence.
Originally filed: 2012-02-21 22:32:00 +0000

================================================================================
 #0   contributor@whatwg.org                          2012-02-21 22:32:17 +0000 
--------------------------------------------------------------------------------
Specification: http://www.w3.org/TR/html5/Overview.html
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
Consistent use of 'no value' attributes.

The 'no value' attributes like "selected", "checked" and "required" are being
used inconsistently in the examples throughout the HTML5 specifications.

Where "required" is always used with no value ('required' vs
'required="required"'), the "selected" as well as the "checked" attribute use
both the style with and without value ('selected="selected"' and 'selected').
There is also no mention about the possibility to use either of these styles,
let alone one style being recommended over the other.
Only one style should be used throughout the document, and one of the two
should preferably be recommended.

Personally I would even opt for a new attribute that takes one of the three
attributes above as values. This would get rid of these rather awkward
attributes all together. E.g.

'state="selected"', 'state="required"'

I, however, do not know how viable such a proposal will be if made by me if it
hasn't been by others already.

Posted from: 87.195.226.142
User agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
================================================================================
 #1   Tab Atkins Jr.                                  2012-02-22 18:29:13 +0000 
--------------------------------------------------------------------------------
The HTML spec deliberately uses a mix of styles in its examples precisely so it *doesn't* advocate one way or another.  That is for authoring guides, tutorials, and other types of advocacy to do.

It seems that merging @required, @selected, and @checked together would add more characters for no benefit.
================================================================================
Comment 1 Ian 'Hixie' Hickson 2012-09-17 05:31:56 UTC 
> Where "required" is always used with no value ('required' vs
> 'required="required"'), the "selected" as well as the "checked" attribute use
> both the style with and without value ('selected="selected"' and 'selected').

I've made the examples have more variety.


> There is also no mention about the possibility to use either of these styles,
> let alone one style being recommended over the other.

Each of these attributes links to this section, which talks about the very topic:

   http://www.whatwg.org/specs/web-apps/current-work/#boolean-attribute


> Only one style should be used throughout the document, and one of the two
> should preferably be recommended.

There's no reason to prefer one style over another, it's a matter of personal preference. The spec intentionally takes no position on which of the various valid forms is the better one.


> Personally I would even opt for a new attribute that takes one of the three
> attributes above as values. This would get rid of these rather awkward
> attributes all together.

There are _many_ boolean attributes. I don't see how these three would be special here.