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 17996 - 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: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-18 07:31 UTC by contributor
Modified: 2012-08-27 22:14 UTC (History)
4 users (show)

See Also:

Attachments

Description contributor 2012-07-18 07:31:18 UTC 
This was was cloned from bug 16364 as part of operation convergence.
Originally filed: 2012-03-14 10:20:00 +0000

================================================================================
 #0   contributor@whatwg.org                          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
================================================================================
 #1   Simon Pieters                                   2012-03-14 10:44:09 +0000 
--------------------------------------------------------------------------------
Status: Rejected
Change Description: no spec change
Rationale: CSS should not affect HTML parsing.
================================================================================
 #2   Guus                                            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.
================================================================================
 #3   Guus                                            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.
================================================================================
 #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.
================================================================================
 #5   Guus                                            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 :).
================================================================================
Comment 1 Ian 'Hixie' Hickson 2012-08-23 20:00:44 UTC 
We can't make the HTML parser depend on CSS, because the HTML parser can run in contexts where there is no CSS support, and it would be disastrous if the DOM differed based on whether CSS is supported or not.

In any case <xmp> is obsolete. Don't use it. Problem solved. :-)
Comment 2 Guus 2012-08-23 20:56:50 UTC 
(1)
The point is not to alter the DOM tree depending on CSS support, but the tag works fine outside <p> and malfunctions inside <p> because of the extra insertion of </p>. So everything works as long as the <xmp> is not under a <p> element.

That suggests the insertion shouldn't have been specified: let the parser handle the <xmp>. As it is a block element, why add the extra </p> anyway?

(2) 
I can accept a wontfix if <xmp> is obsolete and there is an alternative. Is there?
Otherwise: as long as <xmp> is part of the spec, the spec should at least be correct and work correctly. As it is now, it does not.

Guus.
Comment 3 Ian 'Hixie' Hickson 2012-08-27 22:14:42 UTC 
(In reply to comment #2)
> The point is not to alter the DOM tree depending on CSS support, but the tag
> works fine outside <p> and malfunctions inside <p> because of the extra
> insertion of </p>. So everything works as long as the <xmp> is not under a <p>
> element.
>
> That suggests the insertion shouldn't have been specified: let the parser
> handle the <xmp>. As it is a block element, why add the extra </p> anyway?

I'm not sure I understand what you mean by "malfunctions". On what basis are you determining what the "correct" behaviour is?

 
> I can accept a wontfix if <xmp> is obsolete and there is an alternative. Is
> there?

Hard to know without knowing what are you trying to do with it, but in general <pre> or <code> are the modern day versions (and by "modern day" I mean, like, since the late 90s). (If you need more advice on this, pleae e-mail me privately <ian@hixie.ch> or ask on #whatwg on Freenode.)


> Otherwise: as long as <xmp> is part of the spec, the spec should at least be
> correct and work correctly. As it is now, it does not.

<xmp> is explicitly listed as an obsolete feature in the spec. Nowhere does the spec say that <xmp> is a valid feature. It's only included for backwards-compatibility with legacy documents.