[CSS21] 9.4: various issues (all presumed editorial)

Comments on section 9.4 of editors' draft of CSS2.1 as published Oct 2010.

§9.4.1, what boxes establish new BFC:

  Users of the specification need to know what boxes do or don't establish
  a new block formatting context, whereas the current text only gives an
  incomplete list of some cases that do establish a new block formatting
  context.

  Thus, please change the wording so that it gives a complete list of the
  boxes that arise in CSS2.1 that establish a new block formatting context.
  One possible wording would be: "A box establishes a block formatting
  context if and only if ...".

  Even if for some reason the incomplete list wording is retained, please
  nevertheless make the list of examples complete (with respect to CSS2.1):
  in particular, please add "outer table box" to the list (given §17.4 para
  3 which says that it does establish a block formatting context, and §17.4
  para 2 which says that it's a block box, and given that it does not in
  general match any of the existing items in the §9.4.1 list).


§9.4.2, para 1, line box definition:

  "The rectangular area that contains the boxes that form a line is called
   a <dfn>line box</dfn>."

  One problem with this definition is that there are an infinite number of
  rectangular areas that contain the boxes that form a line.

  Another issue is that such a definition establishes "line box" as a
  geometrical region ("rectangular area"), and thus that "contains" should
  be read in a geometrical sense.  However, this conflicts with e.g. rules
  for relative positioning, according to which some of the boxes that form
  the line are not contained by the line box rectangle.  I believe there
  are also a number of other mechanisms by which the boxes of a line can
  extend outside of (and thus are not "contained by") said rectangular
  area.

  Similarly, I believe we need phrases like a line box's "enclosing block
  box" (13.3.3) (and similarly number of line boxes "between" a page break
  and the start/end of a block box), an element containing a line box
  (8.3.1), line box in which an element appears (8.6), first in-flow line
  box "in" a table cell (17.5.3), and no doubt many other things, to be
  understood as relationsips in a tree rather than geometrical
  relationships.

  I suggest that the fix for these problems is that we don't actually want
  a definition for what a line box is: we want line boxes to exist where
  and only where the spec explicitly says that a line box exists, we don't
  want people to infer what rectangles are or aren't line boxes.  So rather
  than a definition, I believe we want just some clearly non-normative text
  that introduces line boxes as CSS's abstraction for breaking text into
  lines.

  We can then say (perhaps normatively) that each line box has an
  associated rectangle (i.e. a top, right, bottom and left) and that each
  line box is contained by a block container box with an inline formatting
  model, and contains a sequence of zero or more ordered inline-level
  boxes.


§9.4.2, para 3, "Thus, a paragraph is a vertical stack of line boxes."

  This seems not to be true in general.  "Paragraph" seems not to be a
  technical word in CSS (it isn't in the index or in conform.html for example),
  so we must take it to mean its sense in English.  A paragraph can be split
  between multiple pages, in which case it is not a vertical stack of line
  boxes.

  (One might even go further and argue that a "paragraph" in the english
  sense of the word isn't even required to limited to a single CSS block box,
  and might be split over side-by-side blocks in a column-like effect.)

  This sentence doesn't seem to be needed normatively, so I suggest simply
  inserting the word "typically".


§9.4.2, para 3 "Line boxes are stacked with no vertical separation":

  This seems to conflict with §9.5 para 4 "If a shortened line box is too
  small to contain any further content, then it is shifted downward until
  either it fits or there are no more floats present."

  In the same sentence (§9.4.2 para 3), "they [i.e. line boxes] never
  overlap" conflicts with e.g. the rules for negative margins.  I suggest
  changing it to "Line boxes of a given block box".


§9.4.2, para 4, "In general [line boxes touch the edge of their containing
                 block]":

  s/In general/Usually/; or, more helpfully, remove "In general", and add
  "; except that floating boxes ...".
   

§9.4.3, para 7: Typographical: missing single quote after 'ltr' in

  ... of the containing block is 'ltr, the value of 'left' wins


§9.4.3, para 7: missing specification of used value:

  [I wrote the following issue before I'd seen the editors' draft where it
   was changed from computed value to used value.  That change reduces the
   severity of this issue, just because there's a bit more expectation that
   used values are the same as computed values unless otherwise stated,
   compared to computed values.]

  In the over-constrained case, we're told that one or other "wins" and that
  one of them is ignored (or "'right' becomes −'left'": what does "becomes"
  here mean?), but aren't told what the used values are.

  I suggest dropping the "is ignored" and "becomes ..." parts, and adding
  text "The used value of the property that wins is its specified value;
  the used value of the other of the two properties is the negative of the
  value of the property that wins."  The text for the single-auto cases
  could then be phrased in terms of "the property that is not 'auto' wins".

  The overconstrained top/bottom paragraph has the same problem to a lesser
  extent: it still has the issue of what "becomes" means and a missing
  specification of what the used value is for 'top', though the "ignored"
  phrase is explained in that case.


§9.4.3, no definition of "relatively positioned":

  The phrase "relatively positioned" box or element (used in visuren.html
  and visudet.html) might be misunderstood, because "absolutely positioned"
  elements are said to be "positioned relative to ...", leaving doubt as to
  whether or not absolutely positioned elements are included in the phrase
  "relatively positioned" or not.

  I suggest adding to §9.4.3:

    A <dfn>relatively positioned</dfn> box or element is one whose
    'position' property has computed value 'relative'.

  where ‘'position'’ is hyperlinked to "#propdef-position", and
  ‘computed value’ is hyperlinked to "cascade.html#computed-value";
  and adding this term to the index (or whatever preferred device for
  marking a phrase as having a technical sense; note that indexlist.html
  is currently marked non-normative, so there'd be some case for a separate
  list or other device such as styling and some normative text about that
  styling in about.html).


pjrm.

Received on Wednesday, 3 November 2010 11:52:01 UTC