W3C home > Mailing lists > Public > www-style@w3.org > July 2010

Re: [CSS21] stack level definitions in 9.9.1

From: Peter Moulder <peter.moulder@monash.edu>
Date: Fri, 09 Jul 2010 16:00:11 +1000
To: www-style@w3.org
Message-id: <20100709060011.GA21142@bowman.infotech.monash.edu.au>
On Thu, Jul 08, 2010 at 02:37:22AM +0200, Anton Prowse wrote:
> Bert Bos wrote:

> >a) There are some occurrences of "non-positioned floats," which
> >seem to mean simply "floats." (There is no such thing as a
> >positioned float.)
> 
> Sure there is.  A positioned float is an element which has 'float' other
> than 'none' and 'position' other than 'static'.
> 
> From 9.3.2:[4]
> 
> "An element is said to be positioned if its 'position' property has a
> value other than 'static'."

The other thing relevant to quote is the rule that Bert is likely
thinking of, in 9.7:

  Otherwise, if 'position' has the value 'absolute' or 'fixed', [then] the
  box is absolutely positioned, the computed value of 'float' is 'none',
  and display is set according to the table below.

In particular, position:relative elements retain their specified values
of 'float' and 'position'.

[Incidentally, it would be nice to insert that word `then' there, just to help
 parsing, i.e. so that readers know when the condition ends before getting to
 the end of the sentence.]


However, when I ask myself how a reader would get the right interpretation,
there are some other issues:

  - There is no glossary to say what a "float" is (even in conform.html), and
    no index entry for "float".

  - If one searches the text for "float is" (with or without any sort of
    quotation mark after float) to find a definition of float,
    then the only definition is the first sentence of §9.5 ‘Floats’:

      A float is a box that is shifted to the left or right on the
      current line.

    If this is indeed read as a definition, then it is a wrong one: that
    description would also apply to position:relative boxes or conceivably even
    boxes affected by margins.  Conversely, floats don't always stay on the
    current line, and aren't always shifted at all relative to where the box
    would be if it weren't floated.

Thus, I suggest the following changes:

  - Change §9.5 such that its first sentence gives a definition of what
    a float is, such as

      <p>A
      <span class="index-def" title="float"><a
        name="float"><dfn>float</dfn></a></span>
      is a box whose
      <a href="#propdef-float" class="noxref"><span
        class="propinst-float">'float'</span></a>
      property has a value other than 'none'.

    The existing "shifted to the left or right on current line" sentence could
    be changed to "Floats are usually placed as far left or right as possible
    on the current line (in a way defined more precisely below)."

  - Add to indexlist.html an entry for "float" that links to a definition of
    what a float is.  A good place for such a definition would be as the first
    sentence of §9.5.

  - Having done so, I'd be inclined to rename the existing "'float'" index
    entry to "'float' (property)".


The next problem is that the definition of "positioned" is inadequate to say
what a positioned box is:

  An element is said to be /positioned/ if its 'position' property has a
  value other than 'static'.  Positioned elements generate positioned boxes,
  laid out according to four properties: ...

I suggest changing the first sentence to say

  A box or element is said to be /positioned/ iff its 'position' property
  has a computed value other than 'static'.

The first part of the next sentence, "Positioned elements generate positioned
boxes", has the following issues:

  - It's not clear whether "generate" means "always generate" or
    "sometimes generate".  In the context of a specification document, one
    would hope that it would mean "always generate", but that isn't true: for
    example, it won't generate any boxes if it or an ancestor element has a
    computed 'display' value of 'none'.

  - Once we've made the above "box or element" change, it becomes unnecessary
    [see following] to point out that its generated boxes are positioned
    boxes.
    
Thus, please change this to simply "Positioned boxes are laid out
according to ...".


I say "unnecessary", though that assumes that the reader somehow knows that a
box's properties are the computed values of the corresponding properties of the
element that generates that box.  It is a well-known long-standing issue that
no part of CSS2.1 actually says this though, and I've just noticed that there's
no issue open for it in http://wiki.csswg.org/spec/css2.1.
Please add an issue for this.

I suggest that the appropriate place would be in section 9.1, after the
information that "each element in the document tree generates zero or more
boxes", probably immediately after.  I don't actually understand the remainder
of that sentence "according to the box model": the phrase "box model" is a
hyperlink to chapter 8 "Box model", but that chapter is (currently) devoted to
a description of the meaning of margins, borders, padding etc.  So I could
understand making the word "boxes" be a hyperlink to that chapter in an
attempt to explain what a box is, but I can't really see "according to" as
being appropriate.

Without understanding the intent of the existing wording, my proposal would be
to remove the phrase "according to the box model", instead make "boxes" a link
to chapter 8, and then add a sentence saying that the properties of a box have
the same values as the computed values of the element that generated that box.


> >b) Layer 6 in edit 3 contains a with-phrase ("with stack level 0")
> >that is ambiguous. The sentence can mean
> >
> >    [positioned descendants and stacking contexts] with stack level 0
> >or
> >    [positioned descendants] and [stacking contexts with stack level 0]
> >
> >It means the former, but that requires considerable thinking: one
> >tends to overlook that stack level zero includes elements with
> >'z-index: auto'.
> 
> One shouldn't do; the proposed definition of the 'auto' value of
> 'z-index' in Edit 1 (which you said was OK) says:
> 
> "The stack level of the generated box in the current stacking context is
> '0'"

I haven't yet read the changes carefully myself, but I'd guess that if Bert
says he had trouble understanding it, then other people will too.

How about

  6. those positioned descendants and stacking contexts whose
     stack level is 0.

(That may still be a bit subtle for people not native speakers of English,
because it assumes that the reader knows that *"those positioned descendents"
by itself would be stylistically wrong (wrong formality) in this sort of
document.)

I purposely removed the quotation marks from the 0, which I think also
helps to be more inclusive of the z-index:auto case.

(Though as noted, I haven't been following the stacking description issue
closely, so don't read an informed recommendation into that.)

pjrm.
Received on Friday, 9 July 2010 06:00:43 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:29 GMT