16364 – 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

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 16364 - 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

Summary: Paragraph: Within 'The "in body" insertion mode' the paragraph 'A start tag w...

Status:	RESOLVED WONTFIX

Alias:	None

Product:	HTML WG
Classification:	Unclassified
Component:	HTML5 spec (show other bugs)
Version:	unspecified
Hardware:	Other Linux

Importance:	P3 normal
Target Milestone:	---
Assignee:	This bug has no owner yet - up for the taking
QA Contact:	HTML WG Bugzilla archive list

URL:	http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:

Depends on:
Blocks:

Reported:	2012-03-14 10:20 UTC by contributor
Modified:	2012-09-14 11:21 UTC (History)
CC List:	5 users (show)

See Also:

Attachments

Description contributor 2012-03-14 10:20:48 UTC

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

Comment 1 Simon Pieters 2012-03-14 10:44:09 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: Rejected
Change Description: no spec change
Rationale: CSS should not affect HTML parsing.

Comment 2 Guus 2012-03-14 11:52:22 UTC

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.

Comment 3 Guus 2012-04-03 06:27:09 UTC

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.

Comment 4 Ms2ger 2012-04-03 20:05:43 UTC

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.

Comment 5 Guus 2012-04-04 05:58:04 UTC

Ok thanks. I will wait patiently and silently.
Hadn't heard of "bumping" in this context until now, will keep it in mind :).

Comment 6 contributor 2012-07-18 07:31:21 UTC

This bug was cloned to create bug 17996 as part of operation convergence.

Comment 7 Ms2ger 2012-08-15 17:13:21 UTC

Filter on [Idon'tcareaboutHTMLWGbugspam].

Comment 8 Robin Berjon 2012-09-14 11:21:25 UTC

Same decision as https://www.w3.org/Bugs/Public/show_bug.cgi?id=17996