193784 - Paragraph <P> tag refuses to appear within user defined <CONTAINER> tag

Status: RESOLVED INVALID

(Core :: DOM: HTML Parser, defect)

Description

[Nathan Kurz]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5

I'm having problems which I think must be parser related.  I'm trying to do:

<CONTAINER>
 <P>text</P>
</CONTAINER>

But it is not working.  The <CONTAINER> ends up containing only an empty string,
and the <P> occurs after the <CONTAINER> instead of inside of it.  All tags I've
tried other than <P> work fine and predefined tags (<B>, <SPAN>, <DIV>) other
than <CONTAINER> work as expected.

The test cases should make clearer than what I've said here.  I'm attaching two
of them, one bare bones, and one that includes a lot of debugging harness to
show more explicitly what is happening.

I also see this problem with a February 2003 build.


Reproducible: Always

Steps to Reproduce:

Comment 1

[Nathan Kurz]

Attachment: Simple test case for containing a "P" tag

Comment 2

[Nathan Kurz]

Attachment: Elaborate test case for containing a "P" tag

Comment 3

[Nathan Kurz]

Now I'm even more confused.  I just found that the same problem exists if I try
to have a list in a tag that I define:

  <CONTENT>
      [...]
      26
      <ul>
        <li>27 
	<li>28 
	<li>29 
      </ul>
      30
      [...]
  </CONTENT>

Is there some general rule here that I'm not getting?  Am I somehow triggering
something by using an incorrect DTD?  

Comment 4

[Boris Zbarsky [:bzbarsky]]

"container" is not a valid tag, and we probably don't allow it to contain <p>.

Note that specifying a DTD in such an invalid document is a _very_ odd thing to do.

Comment 5

[Nathan Kurz]

I've probably got the terminology wrong (I'm pretty DTD ignorant) but I've tried
this with and without a DOCTYPE set so I don't think the specified DTD is the
real problem.  Yes, I do realize that CONTAINER is not a valid HTML tag.  

Your comment makes it sound as if even in the absence of a DTD, Mozilla is
deciding that certain tags are not allowed to appear inside of new, user-defined
tags.  If this is by design, isn't this a bad thing?  Or is the problem that I
need to explicitly specify a DOCTYPE that will tell Mozilla that I want to allow
usage of non-HTML elements?  Or is that only possible with XHTML? 

I can happily sidestep this bug (or non-bug) by using subclasses of DIV's and
SPAN's instead of defining my own tags (with CSS formatting rules) but I had
thought it was better practice to use clear and specific (well-formed but
invalid) user-defined tags.  I've started doing it because it generally works,
but have always felt insecure about it.  Am I wrong to be doing so?

Comment 6

[Christopher Hoess (gone)]

Yes, that's wrong. Using <div> and <span> is the correct way to "extend" 
HTML; there's no mechanism for adding elements in the standard. (And 
it's impossible for our parser to know if a user-defined element should 
behave like <div> or <span>, for instance; that is, if it should be 
block-level, like paragraphs, or inline, within paragraphs, etc.) I suspect 
this is INVALID.

Comment 7

[Nathan Kurz]

Attachment: Working XHTML version of problem

I'm searching for defense of my practice of using user defined tags as
containers within HTML, and I can't find much explicit (spec based) defense for
it.   The best I can do is a waffly "If a user agent encounters an element it
does not recognize, it should try to render the element's content."

My thought was that the parser should be quite transparent and simply build a
tree based on what it was given.  If it encountered a well-formed tag it did
not recognize, it would insert it like any other and leave it up to layout to
decide how to display it.  Since via CSS I can define its display, everything
would work.  In fact, everything does work this way except for a few predefined
tags (P and LI) which refuse to be contained, which made me suspect a bug
rather than suspecting that all the other working parts were just by accident. 
Isn't accepting and processing unknown tags a time honored tradition?

I've got a complicated application to provide browser interface, so I need a
bunch of custom elements.  I guess either need to switch over to XHTML or have
10 different subclasses of DIV and SPAN.  Or just hijack other rarely used tags
to use for my nefarious purposes (when's the last time you used an INS or a
DEL?)  

A working XHTML example is attached.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> when's the last time you used an INS or a DEL?

Two days ago.  ;)

Comment 9

[Christopher Hoess (gone)]

Use subclasses for <div> and <span>. The HTML specification doesn't endow them
with any semantic value, so they're precisely what you want for your purposes.
XML "works" because it must be well-formed, which isn't the case in HTML, so the
parser doesn't have the knowledge to do it the way you want (see comment #6).
Resolving as INVALID.

Comment 10

[James Graham]

Out of interest, how will this affect compatibility with standardised extensions
to HTML (e.g. the WHATWG work)? Proposals such as <section> elements [1] would
degrade more gracefully to current-generation mozilla browsers if the DOM
retained the structure of the source document when faced with unknown tags.

Obviously I don't know the technical details here, in particular I suppose the
interaction with HTML error-handling might be problematic. 

[1]  http://whatwg.org/specs/web-apps/current-work/#document

Comment 11

[Boris Zbarsky [:bzbarsky]]

> if the DOM retained the structure of the source document when faced with unknown
> tags

That would actually break compat, apparently.  That's something the WHATWG needs
to worry about when defining extensions; I suggest bringing this up on the
WHATWG mailing list.

Comment 12

[Mats Palmgren (inactive)]

*** Bug 270599 has been marked as a duplicate of this bug. ***