- O and CSS

There is, in my opinion, a need to better specify the end of elements
whose closing tags have been omitted when their contents have display:
block.

For example, 
<p style="background: red">
A P element
<span style="display: block">
A SPAN element that is behaving as a block element
</span>
Is this in the P element?
</p>

Browsers seem to give all the text is given the red backround, which I
find odd in view of:

<q cite="http://www.w3.org/TR/REC-HTML401/struct/text.html#h-9.3.1>
It cannot contain block-level elements (including P itself).
</q>

The HTML definition of block-level elements specifically mentions the fact
that elements can have their behaviour changed by style sheets, so one
would assume that this definition also prevents the inclusion of
block-level elements that have been made so by style sheets. 
(Here's the DTD entry:
<!ELEMENT P - O (%inline;)*            -- paragraph -->
)
<blockquote
cite="http://www.w3.org/TR/REC-HTML401/intro/sgmltut.html#h-3.2.1>
For example, the following paragraph:
<P>This is the first paragraph.</P>
...a block element...
may be rewritten without its end tag:
<P>This is the first paragraph.
...a block element...
since the <P> start tag is closed by the following block element.
</blockquote>

The trouble with saying:
<p style="background: red">
A P element
<span style="display: block">
This shouldn't be red?
</span>
This shouldn't be red?
</p>
is that it means that one cannot format a P element without having access
to the DTD, in particular '- O'. Furthermore, display: block does not
completely describe the behaviour of a P element.

In HTML, this is not especially serious, but in other languages it may be:

<!ELEMENT (TH|TD)  - O (%flow;)*>
<!ELEMENT P - O (%inline;)*>

If one simply acts on the basis of DTD entries such as these, and does not
have information as to the content, one cannot know what implies the
closing tag. For example, if a UA knows what HTML elements contain, it
will realise that given <TD>A table cell<TD>Another table cell, the <TD>
implies the end of the first table cell.

Equally so given <ELEMENT style="display: table-cell"> and
<!ELEMENT ELEMENT - 0 (%whatever;)*>, this would make it obvious that
another table cell implies the end of the first one, but what of
<ANELEMENT style="display: block">.  For example, do the DTD and style
sheet interact, so that <!ELEMENT ELEMENT - 0 (%whatever;)*> with ELEMENT
{display: block} mean that another element with display: block will imply
the end of the first one; equally for display: inline or whatever else.

OTOH, should the UA simply use (%whatever;)* and thus imply the next
element by a !whatever element?

It is particularly important to determine whether the HTML specification
is wrong or not - should 
<blockquote
cite="http://www.w3.org/TR/REC-HTML401/intro/sgmltut.html#h-3.2.1>
For example, the following paragraph:
<P>This is the first paragraph.</P>
...a block element...
may be rewritten without its end tag:
<P>This is the first paragraph.
...a block element...
since the <P> start tag is closed by the following block element.
</blockquote>
read:
<blockquote
cite="http://www.w3.org/TR/REC-HTML401/intro/sgmltut.html#h-3.2.1>
For example, the following paragraph:
<P>This is the first paragraph.</P>
...a %block; element...
may be rewritten without its end tag:
<P>This is the first paragraph.
...a %block; element...
since the <P> start tag is closed by the following %block; element.
</blockquote>
I am inclined to think that HTML is right (and that does not need to be
changed) and the browsers wrong; it is important to determine a correct
and consistent approach because whatever approach is used must also be
used for other markup languages such as XML.

In view of this, I would suggest this:
<BLOCKQUOTE>
Where a document type definiton indicates that an end tag may be omitted,
the end tag is implied by the value for the display property on the
element. For example, given the following hypothetical DTD fragment:
<!ELEMENT X - O (%whatever;)*>
, and X {display: block}, the next element that has display: block implies
the end of that element.
</BLOCKQUOTE>

If what I say is correct, HTML is right and the (display: block
supporting) browsers wrong; if I am wrong, the browsers are right and HTML
is wrong.

If what I say is correct, it makes it impossible for programs like HTML
Tidy to insert omitted tags without knowing the style sheet for the page
(although it already destroys white-space: pre, so perhaps this isn't such
a big deal).


=====
----------------------------------------------------------
From Matthew Brealey (http://members.tripod.co.uk/lawnet (for law)or http://members.tripod.co.uk/lawnet/WEBFRAME.HTM (for CSS))
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Received on Friday, 4 February 2000 08:39:13 UTC