Re: [CSS21] How to define "block-level box"

On Sun, Oct 14, 2012 at 11:25:19PM +0100, Anton Prowse wrote:
> On 14/10/2012 12:37, Peter Moulder wrote:

> >Of course www-style regulars will know that other parts of the spec
> >specifically describe certain boxes being generated as block-level, but
> >(a) those aren't referenced by this text that appears to be the definition,
> 
> True, but the section begins with
> 
>   # [...] The 'display' property, described below, specifies a box's
>   # type.
> 
> which indicates that the reader may need to look elsewhere to find
> out when and where boxes of a given type are generated

FWIW, there's nothing in that paragraph to indicate that "type" means "whether
it's block-level or inline-level or neither", and indeed I didn't interpret it
to have that meaning myself.  (I might even have written to the list about
"specifies a box's type" being unclear as to what it means; if I haven't, then
it's only because I didn't find any text depending on this sentence, so I took
this sentence to be a non-normative sentence introducing readers to 'display'
being central to how boxes behave.  I tried to file only the most important
issues, given that lots of reported issues weren't getting addressed.)

> >and (b) identifying some boxes as block-level doesn't tell us whether any
> >other boxes are also block-level;
> 
> Indeed, "block-level" is simply a label.

I'm not sure I know what you mean by "simply a label", but the current text
gives what appears to be a definition and wraps the term in <dfn>, and various
parts of CSS 2.1 depend on knowing whether a given box is block-level or not.
[We each come back to this a bit later, see below.]

> >Accepting this definition, the question then becomes how to determine
> >whether a given box "[participates] in a <a href="block-formatting">block
> >formatting context</a>".
> 
> The intention is [...]

I've no objection to that intention; this issue only concerns what the spec
says.  The resolution I proposed would make the spec text match that intention.

> >[...] we can only assume that we should take [...] "[certain elements and
> >boxes] establish new block formatting contexts for their contents" to imply
> >that their contents participate in said new established block formatting
> >contexts, and hence that their contents are block-level.
> 
> In theory, yes.  But, as you've noticed:
> 
> >This means that if the div below is a float/abspos/...:
> >
> >   <div><span>hello,</span> <span>world</span></div>
> >
> >then its child span elements/boxes are block-level, and hence should be
> >laid out one on top of the other, contrary to the behaviour of every known
> >visual UA.
> 
> which is of course problematic.

Indeed, which is why I reported it.

> >To resolve these problems, I suggest that block formatting context should
> >be defined in terms of block-level box, not the other way around.
> 
> Actually, I feel that "block-level" shouldn't be defined at all, and
> instead be merely a label.

Various text in CSS depends on deciding whether a given box is block-level
or not, so there needs to be some text that allows concluding that a given
box is not block-level.

If by "merely a label" you mean that the spec should be changed so that a
box is block-level if and only if it's described as being block-level, then
that's fine, and indeed the approach I proposed is along those lines.

> Yes, this is almost certainly what's needed, and is what css3-box
> will do.  
>
> In other words, I agree with the issues you're raising
> and, as it happens, they're being worked on right now.  But I don't
> yet have a feeling for the specifics of what will/should be ported
> back to CSS21 though.

Criteria for what changes should go to CSS21 is a subject for another
thread; if any such criteria are identified, then we can come back to the
question of whether or not this issue meets them.  I look forward to seeing
a css3-box spec that resolves the various box-tree issues in CSS21, though
I'm sorry to hear that it looks like such fixes won't appear in REC or CR
text for a number of years.

pjrm.

Received on Monday, 15 October 2012 01:08:57 UTC