16364 2012-03-14 10:20:48 +0000 Paragraph: Within 'The "in body" insertion mode' the paragraph 'A start tag whose tag name is "xmp"'. This paragraph causes browser to always handle an xmp tag with a p tag as ending the p tag involved. In default xmp is a block element and this is no pr 2012-09-14 11:21:25 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified Other Linux RESOLVED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#top P3 normal --- 1 contributor dave.null gbonnema mike public-html-admin public-html-wg-issue-tracking robin public-html-bugzilla oldest_to_newest 65509 0 contributor 2012-03-14 10:20:48 +0000 Specification: http://dev.w3.org/html5/spec/Overview.html Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: Paragraph: Within 'The "in body" insertion mode' the paragraph 'A start tag whose tag name is "xmp"'. This paragraph causes browser to always handle an xmp tag with a p tag as ending the p tag involved. In default xmp is a block element and this is no problem. But when using 'display: inline' this specification will cause the first xmp tag in the p tag area to end the paragraph it is in. Subsequent xmp tags within this p area do not end any p tag. The question is whether this rule should take this into account so that xmp defined as inline will show up proper inline. Example code where the problem occurs: <p> This short code <xmp class="shortcode"><form></form></xmp> will break up the paragraph, but this code <xmp class="shortcode"><form></form></xmp> will not break up the paragraph, neither will the following code: <xmp class="shortcode"><p></p></xmp>. Should the specification be adjusted? </p> The question is whether this should be remedied in the specification. Guus Bonnema, gbonnema@(*spam-prevention*)xs4all.nl. Posted from: 2001:980:4536:1:92e6:baff:fe68:eb79 User agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 65510 1 zcorpan 2012-03-14 10:44:09 +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: no spec change Rationale: CSS should not affect HTML parsing. 65512 2 gbonnema 2012-03-14 11:52:22 +0000 Please reconsider. The problem occurs when defining the <xmp> tag as inline. This normally causes an element to be treated as equal to inline. Due to the specification paragraph at issue here, this is not the case when the <xmp> tag is subordinate to a <p> tag. Despite the inline specification, the <xmp> tag is specified to have an end tag (</p>) inserted. Subsequent inline <xmp> tags are not affected, because the specification only indicates the end-tag insertion for <p> tags. When the inline <xmp> tags are subordinate to another block element (like <h1> or <h2>) this is not the case and all inline <xmp> tags are treated like inline. It is not CSS that causes the problem, but the specification paragraph at issue here, that specifically states to insert and ending paragraph tag. The result is that the inline <xmp> is not treated equal to other inline elements. I quote the paragraph below. <quote> A start tag whose tag name is "xmp" If the stack of open elements has a p element in button scope, then act as if an end tag with the tag name "p" had been seen. Reconstruct the active formatting elements, if any. Set the frameset-ok flag to "not ok". Follow the generic raw text element parsing algorithm. </quote> So you can see, that the specification causes the problem, not CSS. I respectfully request you to reconsider. 66351 3 gbonnema 2012-04-03 06:27:09 +0000 I reopened this issue a few weeks ago: what is the next step? Do I need to do anything more to get this rolling again? Please let me know, Guus Bonnema. 66387 4 Ms2ger 2012-04-03 20:05:43 +0000 All you need is patience. Note that the editor fixes bugs in order of the time the last change to the bug was made, so "bumping" would be counterproductive. 66404 5 gbonnema 2012-04-04 05:58:04 +0000 Ok thanks. I will wait patiently and silently. Hadn't heard of "bumping" in this context until now, will keep it in mind :). 70454 6 contributor 2012-07-18 07:31:21 +0000 This bug was cloned to create bug 17996 as part of operation convergence. 72220 7 Ms2ger 2012-08-15 17:13:21 +0000 Filter on [Idon'tcareaboutHTMLWGbugspam]. 73894 8 robin 2012-09-14 11:21:25 +0000 Same decision as https://www.w3.org/Bugs/Public/show_bug.cgi?id=17996