- From: Etan Wexler <ewexler@stickdog.com>
- Date: Thu, 14 Nov 2002 06:57:09 -0500
- 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 UTC