W3C home > Mailing lists > Public > www-style@w3.org > November 2002

WD-CSS21-20020802 section 10, "Visual formatting model details", substantive comments

From: Etan Wexler <ewexler@stickdog.com>
Date: Thu, 14 Nov 2002 06:57:09 -0500
Message-Id: <v03102813b9f93fd97a26@[64.24.91.50]>
To: www-style@w3.org, Bert Bos <bert@w3.org>, Tantek Çelik <tantekc@microsoft.com>, Ian Hickson <ian@hixie.ch>, Håkon Wium Lie <howcome@opera.com>

Following are substantive comments on section 10, "Visual formatting model
details" (<http://www.w3.org/TR/2002/WD-CSS21-20020802/visudet.html>), of
the Cascading Style Sheets level 2.1 draft
(<http://www.w3.org/TR/2002/WD-CSS21-20020802>).



10.1 Definition of "containing block"


"The containing block in which the root element lives is chosen by the user
agent."

Change to "The containing block in which the root element sits, called the
initial containing block, is chosen by the user agent."  Add "It is
suggested that user agents with viewports choose the viewport as the
initial containing block."


"b.	In the case that the ancestor is inline-level, the containing block
depends on the 'direction' property of the ancestor:
1. If the 'direction' is 'ltr', the top and left of the containing block
are the top and left content edges of the first box generated by the
ancestor, and the bottom and right are the bottom and right content edges
of the last box of the ancestor.
2. If the 'direction' is 'rtl', the top and right are the top and right
edges of the first box generated by the ancestor, and the bottom and left
are the bottom and left content edges of the last box of the ancestor."

This can lead to a situation in which the containing block must have
negative width.  Consider the following XML document.

<doc>
What we have is a situation that can <emph><illo/> lead to fatal
problems</emph> for the formatting engine.
</doc>

Consider the following CSS applied to the document.

doc {
  display: block;
  direction: ltr;
  }
emph {
  position: relative;
  }
illo {
  content: url("something");
  position: absolute;
  }

Consider the following formatting of the normal flow content.

  What we have is a situation that can lead to fatal
  problems for the formatting engine.

According to the rules stated, the containing block that 'emph' forms for
'illo' must be to the right of the start of "lead" and to the left of the
end of "problems".  How can any block satisfy these constraints?


"With no positioning, the containing blocks (C.B.) in the following document:

<HTML>
   <HEAD>
      <TITLE>Illustration of containing blocks</TITLE>
   </HEAD>
   <BODY id="body">
      <DIV id="div1">
      <P id="p1">This is text in the first paragraph...</P>
      <P id="p2">This is text <EM id="em1"> in the
      <STRONG id="strong1">second</STRONG> paragraph.</EM></P>
      </DIV>
   </BODY>
</HTML>

are established as follows:

For box generated by    C.B. is established by
body                    initial C.B. (UA-dependent)"

The example document, which lacks a DTD, is not valid HTML.  It is,
however, well-formed XML.

Anyway, whether it is to be HTML or XML, the 'HTML' element, not the 'BODY'
element, is the root element.  Common user agent bugs to the contrary do
not change this basic fact of document structure.


"If we position "div1":
   #div1 { position: absolute; left: 50px; top: 50px }
its containing block is no longer "body"; it becomes the initial containing
block"

This example contradicts the normative text just prior:

"If there is no such ancestor, the content edge of the root element's box
establishes the containing block."

So, is it the initial containing block or the root element's content edge?


10.3.3 Block-level, non-replaced elements in normal flow


"If both 'margin-left' and 'margin-right' are 'auto', their computed values
are equal. This horizontally centers the element with respect to the edges
of the containing block."

It would be useful to have a subsection, containing the above paragraph,
titled "Centering block boxes: 'auto' margins".  This would make things
easier on authors scanning the table of contents in an attempt to locate
pointers on achieving effects.



10.4 Minimum and maximum widths: 'min-width' and 'max-width'


There needs to be a requirement for non-negative values.


"'min-width'"
"Initial:   UA dependent"

I suggest that the initial value be zero.  User agents can easily declare
their particular minimum in the user agent style sheet.


"the rules above are applied again"

Despite "above" being a link anchor, the reference requires too much
deduction.   Change to 'the rules under "Computing widths and margins"
above are applied again'.


10.5 Content height: the 'height' property


"A UA may compute a percentage height on the root element relative to the
viewport."

If the viewport is the initial containing block, then the user agent must
comppute a percentage height on the root element relative to the viewport.


10.6.1 Inline, non-replaced elements


"The vertical padding, border and margin of an inline, non-replaced box
start at the top and bottom of the content area"

This can be taken to mean that the margin starts at the content edge.  A
better wording, however, is difficult to craft.


10.7 Minimum and maximum heights: 'min-height' and 'max-height'


"If the height of the containing block is not specified explicitly (i.e.,
it depends on content height), the percentage value is interpreted like
'auto'."

There is no 'auto' value for these properties.



10.8.1 Leading and half-leading


"However, in this case, some user agents may use the line box to "clip" the
border and padding areas (i.e., not render them)."

Eliminate "some".  Either all user agents may or none may; it is not the
case that a few user agents sit in a position of privilege.  If the intent
was to to say that some user agents do use the line box to clip inline
boxes, state the matter as such.  Actual practice and the permission for it
are separate.


The algorithms for 'vertical-align' are barely specified.  This sets a
shaky base for interoperability.
Received on Thursday, 14 November 2002 07:12:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:17 GMT