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 12602 - "<select><option>\n<option></select>" isn't a placeholder label option because its value is "\n", which is silly. We should strip spaces from the start and end in the definition of the option's label when it comes from textContent.
Summary: "<select><option>\n<option></select>" isn't a placeholder label option becaus...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-05 03:27 UTC by contributor
Modified: 2011-08-04 05:14 UTC (History)
6 users (show)

See Also:

Attachments

Description contributor 2011-05-05 03:27:31 UTC 
Specification: http://www.whatwg.org/specs/web-apps/current-work/complete.html
Section: http://www.whatwg.org/specs/web-apps/current-work/#concept-option-value

Comment:
"<select><option>\n<option></select>" isn't a placeholder label option because
its value is "\n", which is silly. We should strip spaces from the start and
end in the definition of the option's label when it comes from textContent.

Posted from: 76.102.14.57 by ian@hixie.ch
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_7) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.57 Safari/534.24
Comment 1 Tab Atkins Jr. 2011-05-09 17:51:52 UTC 
This is easy to work around - if your code generator (or just your personal coding style) always puts the end tag on another line, thus filling the <option> with whitespace, just add an empty value attribute to it instead, like:

<select required>
  <option value=''>
  </option>
  ...other options...
</select>
Comment 2 Michael[tm] Smith 2011-05-10 04:59:06 UTC 
(In reply to comment #1)
> This is easy to work around

It's not so much the problem how to work around it, but instead what the document-conformance criteria should be for the general case of documents that contain value-less <select required><option>\s+</option></select> (where \s+ is one or more space, tab, LF, FF, or CR characters).

The spec as currently worded makes that invalid (and conformance checkers have to report it as an error) because the "value" of the option is considered non-empty, because (technically) the text content of the option is non-empty.

So the change this bug describes it to make the "value" of a value-attribute-less option be considered non-empty only if the text content of the option is non-empty after leading and trailing space characters are stripped from it. (And fwiw, the validator.nu check for this was implemented that way, with the anticipation that this change will get made to the spec.)
Comment 3 Ian 'Hixie' Hickson 2011-08-02 23:43:41 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: Accepted
Change Description: see diff given below
Rationale: This was actually a practical interop issue, not just a conformance problem.
Comment 4 contributor 2011-08-02 23:44:01 UTC 
Checked in as WHATWG revision r6351.
Check-in comment: Fix <option> to match reality better.
http://html5.org/tools/web-apps-tracker?from=6350&to=6351
Comment 5 Michael[tm] Smith 2011-08-04 05:14:45 UTC 
mass-move component to LC1