[css2] Tantek's changes after Oslo ftf

bert-github · bert-github · commit 4b99866a0a57 · 2003-08-27T16:15:48.000Z
--HG--
extra : convert_revision : svn%3A73dc7c4b-06e6-40f3-b4f7-9ed1dbc14bfc/trunk%402147
diff --git a/css2/visudet.src b/css2/visudet.src
@@ -1,6 +1,6 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 <html lang="en">
-<!-- $Id: visudet.src,v 2.79 2003-08-27 12:23:16 bbos Exp $ -->
+<!-- $Id: visudet.src,v 2.80 2003-08-27 16:15:48 bbos Exp $ -->
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
 <title>Visual formatting model details</title>
@@ -78,17 +78,15 @@ containing block.
 </li>
 </ol>
 
-<ins class="proposed">
 <p>In paged media, an absolutely positioned element is positioned
 relative to its containing block ignoring any page breaks (as if the
 document were continuous). The element may subsequently be broken over
-several pages. Page break properties may apply, however if more than one block formatting context on a page attempts to break the page, the results (e.g. where the page is broken, if at all) are undefined.
+several pages.
 </p>
 <p class="note">Note that a
 block-level element that is split over several pages may have a different
 width on each page and that there may be device-specific limits.
 </p>
-</ins>
 
 <div class="example">
 <p>With no positioning, the containing blocks (C.B.) in the
@@ -198,14 +196,10 @@ user agent if the value of this property is different than 'auto'.
 <dd>Specifies a percentage width. The percentage is calculated
 with respect to the width of the generated box's 
 <a href="visuren.html#containing-block">containing block</a>.
-If the containing block is intrinsically sized (i.e., it depends on
-its content's width) and the current element is not absolutely
-positioned, then a percentage <span class="delcurrent">is</span><span class="insproposed">may be</span> interpreted as 'auto'.
-<span class="insproposed">
+If the containing block's width depends on this element's width, then the resulting layout is undefined in CSS 2.1.
 <span class="note">
 Note: For absolutely positioned elements whose containing block is based on a block-level element, the percentage is calculated with respect to the width of the <em>padding box</em> of that element.  This is a change from CSS1, where the percentage width was always calculated with respect to the <em>content box</em> of the parent element.
 </span>
-</span>
 </dd>
 <dt><strong>auto</strong>
 </dt>
diff --git a/css2/visuren.src b/css2/visuren.src
@@ -1,6 +1,6 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 <html lang="en">
-<!-- $Id: visuren.src,v 2.104 2003-08-27 09:46:13 bbos Exp $ -->
+<!-- $Id: visuren.src,v 2.105 2003-08-27 16:15:48 bbos Exp $ -->
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
 <title>Visual formatting model</title>
@@ -170,12 +170,9 @@ above), then we force it to have <em>only</em> block boxes
 inside it, by wrapping any inline boxes in an anonymous block box.
 </p>
 
-<ins class="proposed">
 <p>
-Block boxes within inline boxes are inserted adjacent to line boxes. 
-The line boxes are wrapped in anonymous block boxes which contain the contents of the inline boxes, while the block boxes are, in the rendering tree, adjacent to the anonymous block boxes.
+When an inline box contains a block box, the inline box (and its inline ancestors within the same line box) are broken around the block.  The line boxes before the break and after the break are enclosed in anonymous boxes, and the block box becomes a sibling of those anonymous boxes.
 </p>
-</ins>
 
 <div class="example">
 <p>This model would apply in the following example if the following
@@ -255,11 +252,9 @@ value. In the example, the color of the anonymous inline boxes is
 inherited from the P, but the background is transparent.
 </p>
 
-<ins class="proposed">
 <p>
-Whitespace content that would subsequently be collapsed away according to the 'white-space' property does not generate any anonymous inline boxes.
+Whitespace content that would subsequently be collapsed away according to the '<span class="propinst-white-space">white-space</span>' property does not generate any anonymous inline boxes.
 </p>
-</ins>
 
 <p>If it is clear from the context which type of anonymous box is
 meant, both anonymous inline boxes and anonymous block boxes are
@@ -274,7 +269,7 @@ simply called anonymous boxes in this specification.
 box</dfn></span> behaves as follows:</p>
 
 <ol>
-<li class="insproposed">
+<li>
 If the run-in box contains a <a href="#block-box">block</a>
 box, the run-in box becomes a block box.
 </li>
@@ -1203,10 +1198,7 @@ the <span class="propinst-clear">'clear'</span> property</h3>
 <!-- #include src=properties/clear.srb -->
 
 <p>This property indicates which sides of an element's box(es) may
-<em>not</em> be adjacent to an earlier floating box. (It may be that
-the element itself has floating descendants; the <span
-class="propinst-clear">'clear'</span> property has no effect on
-those<span class="insproposed">, neither does it affect elements in a different block formatting context</span>.)
+<em>not</em> be adjacent to an earlier floating box. The 'clear' property does not consider floats inside the element itself or in other block formatting contexts.
 </p>
 
 <p>
@@ -1273,7 +1265,7 @@ and CSS 2.1 the 'clear' property only applies to block-level elements.
 Therefore authors should only use this property on block-level
 elements.  If an implementation does support clear on inline elements, 
 rather than increasing the top margin as explained above, 
-the implementation should <span class="insproposed">force a break and effectively</span> insert one or more empty line boxes <span class="insproposed">(or shifting the new line box downward as described in <a href="#floats">section 9.5</a>)</span> to move the top of the cleared inline's line box to below the respective floating box(es).
+the implementation should force a break and effectively insert one or more empty line boxes (or shifting the new line box downward as described in <a href="#floats">section 9.5</a>) to move the top of the cleared inline's line box to below the respective floating box(es).
 </em>
 </p>
 </div>
@@ -1292,7 +1284,7 @@ span { clear: left }
 respect to its containing block.  It is removed from the normal flow
 entirely (it has no impact on later siblings).  An absolutely
 positioned box establishes a new containing block for normal flow
-children and <span class="insproposed">absolutely (but not fixed)</span> positioned descendants.  However, the contents of an
+children and absolutely (but not fixed) positioned descendants.  However, the contents of an
 absolutely positioned element do not flow around any other boxes. They
 may obscure the contents of another box (or be obscured themselves), 
 depending on the
@@ -1776,15 +1768,13 @@ and are formatted one on top of the other.  Z-axis positions are
 particularly relevant when boxes overlap visually. This section
 discusses how boxes may be positioned along the z-axis.
 </p>
-<ins class="proposed">
 <p>
 The order in which the rendering tree is painted onto the canvas is 
 described in terms of stacking contexts. Stacking contexts can 
 contain further stacking contexts. A stacking context is atomic from 
 the point of view of its parent stacking context; boxes in other 
 stacking contexts may not come between any of its boxes.
 </p>
-</ins>
 <p>Each box belongs to one <span class="index-def" title="stacking
 context"><dfn>stacking context</dfn></span>. Each box in a given
 stacking context has an integer <span class="index-def" title="stack
@@ -1796,43 +1786,20 @@ stack levels.  Boxes with the same stack level in a stacking context
 are stacked bottom-to-top according to document tree order.
 </p>
 
-<del class="current">
-<p>The <a href="conform.html#root">root</a> element creates a <span
-class="index-def" title="root stacking context"><dfn>root stacking
-context</dfn></span>, but other elements may establish <span
-class="index-def" title="local stacking context"><dfn>local stacking
-contexts</dfn></span>. Stacking contexts are inherited. A local
-stacking context is atomic; boxes in other stacking contexts may not
-come between any of its boxes.
-</p>
-
-<p>An element that establishes a local stacking context generates a
-box that has two stack levels: one for the stacking context it creates
-(always '0') and one for the stacking context to which it belongs
-(given by the <span class="propinst-z-index">'z-index'</span>
-property).
-</p>
-
-<p>An element's box has the same stack level as its parent's box
-unless given a different stack level with the <span
-class="propinst-z-index">'z-index'</span> property.
-</p>
-</del>
-<ins class="proposed">
 <p>
 The root element forms the root stacking context. Other stacking 
 contexts are generated by any positioned element (including 
 relatively positioned elements) having a computed value of 'z-index' 
 other than 'auto'. Stacking contexts are not necessarily related to 
 containing blocks. In future levels of CSS, other properties may 
-introduce stacking contexts. (For example, '<a href="http://www.w3.org/TR/css3-color/#transparency">opacity</a>'.)
+introduce stacking contexts, for example '<a href="http://www.w3.org/TR/css3-color/#transparency">opacity</a>'.
 </p>
 <p>
-Each stacking context consists of first the background and borders
-of the element forming the stacking context, then the following
-stacking levels:
+Each stacking context consists of the following
+stacking levels (from back to front):
 </p>
 <ol>
+<li>the background and borders of the element forming the stacking context.</li>
 <li>the stacking contexts of descendants with negative stack
      levels.</li>
 <li>a stacking level containing in-flow non-inline-level
@@ -1850,7 +1817,6 @@ actually create new stacking contexts take part in the parent
 stacking context. They are then painted atomically in the inline
 stacking level.
 </p>
-</ins>
 
 <div class="html-example">
 <p>In the following example, the stack levels of
@@ -2027,11 +1993,9 @@ corresponds to adding a LRE (U+202A; for 'direction: ltr') or RLE
 <dt><strong>bidi-override</strong></dt>
 
 <dd>
-<span class="delcurrent">If the element is inline-level or a block-level element that
-contains only inline-level elements, this creates an override.</span>
-<span class="insproposed">For inline-level elements this creates an override. For 
+For inline-level elements this creates an override. For 
 block-level elements this creates an override for inline-level 
-descendents not within another block.</span>
+descendents not within another block.
 This means that inside the element, reordering is strictly in sequence
 according to the <span class="propinst-direction">'direction'</span>
 property; the implicit part of the bidirectional algorithm is
