12602 2011-05-05 03:27:31 +0000 "<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. 2011-08-04 05:14:45 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#concept-option-value P3 normal --- 1 contributor ian ayg ian jackalmage mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 48028 0 contributor 2011-05-05 03:27:31 +0000 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 48365 1 jackalmage 2011-05-09 17:51:52 +0000 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> 48403 2 mike 2011-05-10 04:59:06 +0000 (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.) 52032 3 ian 2011-08-02 23:43:41 +0000 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. 52033 4 contributor 2011-08-02 23:44:01 +0000 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 53529 5 mike 2011-08-04 05:14:45 +0000 mass-move component to LC1