[whatwg] Tag Soup: Blocks-in-inlines
alexey at feldgendler.ru
Thu Jan 26 06:29:42 PST 2006
On Thu, 26 Jan 2006 08:57:55 +0600, Lachlan Hunt
<lachlan.hunt at lachy.id.au> wrote:
>>> Semantically, it makes no sense at all to put a block level element
>>> within an inline element.
>> Because CSS lets you redefine what's inline and what's block by means
>> of the display property, there sometimes is sense in having block
>> elements inside inline.
> Your argument is self defeating. There is no need to put a block-level
> element inside an inline-level element, for the simple fact that CSS
> does let you style any element as 'inline' or 'block'. If you do have a
> legitimate reason for it, please present a semantic/non-presentational
The simplest, and actually the one being discussed:
Why not? These two paragraphs are highlighted with emphasis. What's wrong
here, in the semantical sense?
The classification of elements into "block" and "inline" is purely
presentational (in fact, even the words "block" and "inline" themselves
are bound to the graphical representation of a document and lose their
meaning for voice rendering, where there are no "lines").
I think the rule of not putting block elements inside inline elements
shouldn't be applied to elements themselves. It should rather be applied
to the computed values of "display" property after evalutaion of CSS: "In
a graphically rendered document, elements with display: block shouldn't be
directly nested inside elements with display: inline". Breaking this rule
would leave it undefined how to calculate the positions and dimensions of
the elements. On the other hand, for voice rendering there is no
difference between display: block and display: inline (the only value that
makes a difference is display: none), so there's no need to inforce the
correct inline/block nesting.
Opera M2 8.5 on Debian Linux 2.6.12-1-k7
* Origin: X-Man's Station [ICQ: 115226275] <alexey at feldgendler.ru>
More information about the whatwg