12165 2011-02-23 20:22:03 +0000 The requirement on the plaintext element conflicts with its old definition and usage. It is better to avoid requiring any support than to require support that breaks legacy usage. The plaintext element should be regarded as undefined in HTML5. 2011-08-04 05:04:52 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified Other other RESOLVED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#other-elements,-attributes-and-apis P3 normal --- 1 contributor ian ayg ian julian.reschke mike Ms2ger public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 45977 0 contributor 2011-02-23 20:22:03 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html Section: http://www.whatwg.org/specs/web-apps/current-work/#other-elements,-attributes-and-apis Comment: The requirement on the plaintext element conflicts with its old definition and usage. It is better to avoid requiring any support than to require support that breaks legacy usage. The plaintext element should be regarded as undefined in HTML5. Posted from: 88.114.29.18 45987 1 ayg 2011-02-23 23:58:34 +0000 Actually, the legacy behavior of plaintext is pretty neat. Can we make it valid? :) 46298 2 ayg 2011-03-04 02:37:40 +0000 plaintext is treated differently by the HTML parser, as its conventional meaning requires. See the PLAINTEXT state in the parser: http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#plaintext-state A note to authors of this fact might be worthwhile, so that they don't have to look into the parser section. 46316 3 Ms2ger 2011-03-04 11:07:39 +0000 A note to the authors would not be worthwhile, as they should not use plaintext. 46344 4 ayg 2011-03-04 17:37:05 +0000 Okay, my bad. It should be class=impl, sure. But a note would still be helpful for people who run across a <plaintext> element and have no idea what crazy thing it's doing and look for <plaintext> under "Obsolete features" (which is the logical place to look for it) and find that the only mention seems to suggest it works the same as <pre>, which it clearly doesn't, so they assume it's an error in the spec and (if they're generous) file a bug report, like our good friend 88.114.29.18. It can just be a one-sentence pointer to the parsing section. The current spec is actively misleading, IMO. 48122 5 ian 2011-05-05 22:45:06 +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: Rejected Change Description: see diff below Rationale: The original comment seems incorrect to me; the requirements in the spec for <plaintext> do not contradict legacy. I've tried to clarify all this though. 48123 6 contributor 2011-05-05 22:45:31 +0000 Checked in as WHATWG revision r6088. Check-in comment: clarification http://html5.org/tools/web-apps-tracker?from=6087&to=6088 52859 7 mike 2011-08-04 05:04:52 +0000 mass-moved component to LC1