css3-overflow/Overview.src.html

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

mercurial