Re: [CSS21] 10.6.1, 10.6.3 and 10.6.7 - editorial issues

On Sun, Aug 01, 2010 at 08:22:12PM +0200, Anton Prowse wrote:

> and the first sentence of the section modified as follows:
> 
>   | In certain cases (see the preceding sections), the height of an
>   | element is computed as follows:
> 
> s/element/element that establishes a block formatting context/

I agree that it would be helpful if readers could find out what cases those
"certain cases" are, though I would suggest doing so differently.

As for what those "certain cases" are, and how to determine that from the
spec:

  Note that "the preceding sections" means almost the whole of that chapter
  (and a reader wouldn't even be certain that it's restricted to that chapter).

  A search for `context' or `10.6.7' finds no earlier matches within the
  chapter (other than in the table of contents).  There are no name/id attrs
  within 10.6.7 other than to the 10.6.7 heading itself (#root-height); there
  are links to #root-height from sections 10.6.4 and 10.6.6 (and from nowhere
  else in the CSS spec other than cover.html; while a search for `10.6.7' finds
  matches only in visudet.html, cover.html and changes.html).
  
  Thus, I believe that the "certain cases" in question are determined by the
  three places in the spec that have a hyperlink to #root-height (outside of
  tables of contents), which are in sections 10.6.4 and 10.6.6.

  The exact rule for when 10.6.7 applies is a bit complex: assuming that
  no text refers to sections 10.6.4, 10.6.6 or 10.6.7 other than by
  hyperlink to some anchor defined within those sections, and assuming that
  the words "the height depends on the element's descendants" and "the height
  is based on the content" with the accompanying links to 10.6.7 mean that
  section 10.6.7 always applies in these cases,
  then the rules for when section 10.6.7 applies are:
  
    the computed value of 'height' is 'auto', and
    it is a non-replaced element, and
    either:

      - it is an absolutely positioned element
        where one or more of 'top' and 'bottom' has value 'auto'; or

      - it is a block-level element in normal flow where 'overflow' does not
        compute to 'visible' (except if the 'overflow' property's value has
        been propagated to the viewport); or

      - it is an 'inline-block' element; or

      - it is a floating element.

  (The first of those is from §10.6.4, the other three are from §10.6.6.)


So I agree that it's hard for a reader to determine when section 10.6.7
applies, and I agree that some change is desirable (and, technically speaking,
necessary).

I would have no objection to adding text such as the above to 10.6.7, but
I'm also content with the existing approach of "certain cases (see ...)"
if instead the following changes were made [assuming I'm correct about
when the rules of section 10.6.7 do apply]:

  - Change "(see the preceding sections)" to "(see sections <a
    href="#abs-non-replaced-height">10.6.4</a> and <a
    href="#block-root-margin">10.6.6</a> above)".

  - Change the references to §10.6.7 in sections 10.6.4 & 10.6.6
    to mention "the rules of section&nbsp;10.6.7".  This is partly to
    facilitate searches, but also to address the problem that the
    existing wording introduces uncertainty as to whether "based on the
    content/descendents" always means specifically by the rules of 10.6.7
    or whether the hyperlink is there just because those rules are
    one possible way.  (Maybe this seems like a minor problem,
    but it's cheap to fix.)


In any case, the most important change to make to this sentence (like much of
the rest of this chapter) is s/element/box/.

(Are we agreed that that's an appropriate change here?  My reasons for saying
so are that readers need to know how high a box is; they don't need to know
"the height of an element", whatever that means, except to the extent that it
tells the reader how high boxes are.  The problem with assigning heights to
elements instead of boxes is that an element can generate more than one box,
not just in the list-item case but also when an element appears on or is split
over more than one column or page, and the different boxes can differ in both
width and height.  The spec have some wording to try to cater for this, but I'm
not convinced that it succeeds, and I'm not aware of the advantage of assigning
widths & heights to elements rather than directly assigning to boxes.)


> It's possible, however, that 10.6.7 is being deliberately decoupled from
> BFCs, perhaps for use on non-BFCs in future CSS levels.  (Although note
> that the title mentions BFCs.)  In this case, the faulty sentence will
> simply have to list the exceptions in full.
> 
> 
> Issue 3:
> 
> 10.6.1 (Inline, non-replaced elements), 10.6.3 (Block-level non-replaced
> elements in normal flow when 'overflow' computes to 'visible') and
> 10.6.7 ('Auto' heights for block formatting context roots) claim to
> describe element behaviour, but are really describing box behaviour.  If
> this doesn't get cleaned up,(*) I think it would instead be worthwhile
> to clearly state in 10.6.1 and 10.6.3 that those subsections apply to
> anonymous boxes.
> 
> (*) Besides the box under consideration, the many mentions of children
> and descendants in these sections also refer to boxes, since those terms
> leave various gaps (generated content, "loose" content without an
> inline-level parent, etc) when taken only in the context of elements.

Certainly something needs to change (e.g. because currently there's no text to
say how height the boxes themselves are).  I'd be interested in hearing if
there were any problem with s/element/box/ through most of at least sections
10.3 and 10.6 (and their subsections).

pjrm.

Received on Monday, 2 August 2010 04:45:25 UTC