Mercurial > drafts / changeset

     1.1 --- a/css3-overflow/Overview.html	Thu Aug 16 14:50:09 2012 -0700
     1.2 +++ b/css3-overflow/Overview.html	Thu Aug 16 15:05:23 2012 -0700
     1.3 @@ -364,38 +364,36 @@
     1.4    <p> When the computed value of ‘<code class=property>overflow</code>’
     1.5     for an element is ‘<code class=css>fragments</code>’, and
     1.6     implementations would otherwise have created a box for the element, then
     1.7 -   implementations must create at least one box for that element. Each box
     1.8 -   created for the element is called a <dfn id=fragment-box>fragment
     1.9 -   box</dfn> for that element. (If an element with ‘<code
    1.10 -   class=css>overflow: fragments</code>’ generates only one box, that box
    1.11 -   is a <a href="#fragment-box"><i>fragment box</i></a>. However, if an
    1.12 -   element's computed ‘<code class=property>overflow</code>’ is not
    1.13 -   ‘<code class=css>fragments</code>’, then its box is not a <a
    1.14 +   implementations must create a sequence of <dfn id=fragment-box>fragment
    1.15 +   box</dfn>es for that element. (It is possible for an element with ‘<code
    1.16 +   class=css>overflow: fragments</code>’ to generate only one <a
    1.17 +   href="#fragment-box"><i>fragment box</i></a>. However, if an element's
    1.18 +   computed ‘<code class=property>overflow</code>’ is not ‘<code
    1.19 +   class=css>fragments</code>’, then its box is not a <a
    1.20     href="#fragment-box"><i>fragment box</i></a>.) Every <a
    1.21     href="#fragment-box"><i>fragment box</i></a> is a fragmentation container,
    1.22 -   and for each <a href="#fragment-box"><i>fragment box</i></a> which ends
    1.23 -   with a fragmentation break, (which could happen because breakable content
    1.24 -   overflows in the block dimension or because of a forced break), there must
    1.25 -   be another <a href="#fragment-box"><i>fragment box</i></a> created as a
    1.26 -   next sibling of the previous one. <span class=issue>Or is it as though
    1.27 +   and any overflow that would cause that fragmentation container to fragment
    1.28 +   causes another <a href="#fragment-box"><i>fragment box</i></a> created as
    1.29 +   a next sibling of the previous one. <span class=issue>Or is it as though
    1.30     it's a next sibling of the element? Need to figure out exactly how this
    1.31 -   interacts with other box-level fixup.</span> (Breakable content might
    1.32 -   overflow in the box dimension either because of a specified size on the <a
    1.33 -   href="#fragment-box"><i>fragment box</i></a> or because the <a
    1.34 -   href="#fragment-box"><i>fragment box</i></a> is within a fragmentation
    1.35 -   context in which it is being broken. In other words, a single <a
    1.36 -   href="#fragment-box"><i>fragment box</i></a> is never broken across
    1.37 -   columns or pages; the pieces that are in separate columns or pages are
    1.38 -   always distinct <a href="#fragment-box"><i>fragment box</i></a>es.)
    1.39 +   interacts with other box-level fixup.</span> However, fragment boxes may
    1.40 +   themselves be broken (due to fragmentation in a fragmentation context
    1.41 +   outside of them, such as pages, columns, or other fragment boxes); such
    1.42 +   breaking leads to fragments of the same fragment box rather than multiple
    1.43 +   fragment boxes. (This matters because fragment boxes may be styled by
    1.44 +   their index; such breaking leads to multiple fragments of a fragment box
    1.45 +   with a single index. This design choice is so that breaking a fragment box
    1.46 +   across pages does not break the association of indices to particular
    1.47 +   pieces of content.) <span class=issue>Should a forced break that breaks to
    1.48 +   an outer fragmentation context cause a new fragment of a single fragment
    1.49 +   box or a new fragment box?</span> <span class=issue>Should we find a term
    1.50 +   other than <a href="#fragment-box"><i>fragment box</i></a> here to make
    1.51 +   this a little less confusing?</span>
    1.52  
    1.53 -  <p class=issue> We also want ‘<code class=css>::nth-fragment()</code>’
    1.54 -   pseudo-elements to be able to apply to the pieces of an element split
    1.55 -   within a fragmentation context. Should we require that authors who want to
    1.56 -   use ‘<code class=css>::nth-fragment()</code>’ in this way specify
    1.57 -   ‘<code class=css>overflow:fragments</code>’ (even if they don't
    1.58 -   specify a constrained height), or should it work automatically for all
    1.59 -   elements even if they don't have ‘<code class=css>overflow:
    1.60 -   fragments</code>’?
    1.61 +  <p class=issue> What if we want to be able to style the pieces of an
    1.62 +   element split within another type of fragmentation context? These rules
    1.63 +   prevent ever using ‘<code class=css>::nth-fragment()</code>’ for that,
    1.64 +   despite that the name seems the most logical name for such a feature.
    1.65  
    1.66    <div class=example>
    1.67     <table class=source-demo-pair>
    1.68 @@ -631,8 +629,7 @@
    1.69      margin-bottom: 1em;
    1.70      height: 4em;
    1.71    }
    1.72 -  .article::nth-fragment(n+2) {
    1.73 -    /* 2 and up */
    1.74 +  .article::nth-fragment(2) {
    1.75      margin-left: 5em;
    1.76      margin-right: 2em;
    1.77    }
    1.78 @@ -866,8 +863,7 @@
    1.79      font-size: 1.5em;
    1.80      max-lines: 3;
    1.81    }
    1.82 -  .article::nth-fragment(n+2) {
    1.83 -    /* 2 and up */
    1.84 +  .article::nth-fragment(2) {
    1.85      column-count: 2;
    1.86    }
    1.87  &lt;/style&gt;

     2.1 --- a/css3-overflow/Overview.src.html	Thu Aug 16 14:50:09 2012 -0700
     2.2 +++ b/css3-overflow/Overview.src.html	Thu Aug 16 15:05:23 2012 -0700
     2.3 @@ -259,42 +259,43 @@
     2.4  	<p>
     2.5  		When the computed value of 'overflow' for an element is ''fragments'',
     2.6  		and implementations would otherwise have created a box for the element,
     2.7 -		then implementations must create at least one box for that element.
     2.8 -		Each box created for the element is called a <dfn>fragment box</dfn>
     2.9 +		then implementations must create a sequence of <dfn>fragment box</dfn>es
    2.10  		for that element.
    2.11 -		(If an element with ''overflow: fragments'' generates only one box,
    2.12 -		that box is a <i>fragment box</i>.
    2.13 +		(It is possible for an element with ''overflow: fragments''
    2.14 +		to generate only one <i>fragment box</i>.
    2.15  		However, if an element's computed 'overflow' is not ''fragments'',
    2.16  		then its box is not a <i>fragment box</i>.)
    2.17  		Every <i>fragment box</i> is a fragmentation container,
    2.18 -		and for each <i>fragment box</i> which ends with a fragmentation break,
    2.19 -		(which could happen
    2.20 -		because breakable content overflows in the block dimension
    2.21 -		or because of a forced break),
    2.22 -		there must be another <i>fragment box</i> created as a next sibling
    2.23 +		and any overflow
    2.24 +		that would cause that fragmentation container to fragment
    2.25 +		causes another <i>fragment box</i> created as a next sibling
    2.26  		of the previous one.
    2.27  		<span class="issue">Or is it as though it's a next sibling of
    2.28  		the element?  Need to figure out exactly how this interacts with
    2.29  		other box-level fixup.</span>
    2.30 -		(Breakable content might overflow in the box dimension either
    2.31 -		because of a specified size on the <i>fragment box</i>
    2.32 -		or because the <i>fragment box</i> is within a fragmentation context
    2.33 -		in which it is being broken.
    2.34 -		In other words, a single <i>fragment box</i> is never broken
    2.35 -		across columns or pages;
    2.36 -		the pieces that are in separate columns or pages
    2.37 -		are always distinct <i>fragment box</i>es.)
    2.38 +		However, fragment boxes may themselves be broken
    2.39 +		(due to fragmentation in a fragmentation context outside of them,
    2.40 +		such as pages, columns, or other fragment boxes);
    2.41 +		such breaking leads to fragments of the same fragment box
    2.42 +		rather than multiple fragment boxes.
    2.43 +		(This matters because fragment boxes may be styled by their index;
    2.44 +		such breaking leads to multiple fragments of a fragment box
    2.45 +		with a single index.
    2.46 +		This design choice is so that
    2.47 +		breaking a fragment box across pages does not break
    2.48 +		the association of indices to particular pieces of content.)
    2.49 +		<span class="issue">Should a forced break that breaks to
    2.50 +		an outer fragmentation context cause a new fragment of a single
    2.51 +		fragment box or a new fragment box?</span>
    2.52 +		<span class="issue">Should we find a term other than
    2.53 +		<i>fragment box</i> here to make this a little less confusing?</span>
    2.54  	</p>
    2.55  
    2.56  	<p class="issue">
    2.57 -		We also want ''::nth-fragment()'' pseudo-elements
    2.58 -		to be able to apply to the pieces of an element
    2.59 -		split within a fragmentation context.
    2.60 -		Should we require that authors who want to use
    2.61 -		''::nth-fragment()'' in this way specify ''overflow:fragments''
    2.62 -		(even if they don't specify a constrained height),
    2.63 -		or should it work automatically for all elements
    2.64 -		even if they don't have ''overflow: fragments''?
    2.65 +		What if we want to be able to style the pieces of an element
    2.66 +		split within another type of fragmentation context?
    2.67 +		These rules prevent ever using ''::nth-fragment()'' for that,
    2.68 +		despite that the name seems the most logical name for such a feature.
    2.69  	</p>
    2.70  
    2.71  	<div class="example">
    2.72 @@ -516,8 +517,7 @@
    2.73      margin-bottom: 1em;
    2.74      height: 4em;
    2.75    }
    2.76 -  .article::nth-fragment(n+2) {
    2.77 -    /* 2 and up */
    2.78 +  .article::nth-fragment(2) {
    2.79      margin-left: 5em;
    2.80      margin-right: 2em;
    2.81    }
    2.82 @@ -722,8 +722,7 @@
    2.83      font-size: 1.5em;
    2.84      max-lines: 3;
    2.85    }
    2.86 -  .article::nth-fragment(n+2) {
    2.87 -    /* 2 and up */
    2.88 +  .article::nth-fragment(2) {
    2.89      column-count: 2;
    2.90    }
    2.91  &lt;/style&gt;