Define overflow columns as creating new fragment boxes, as discussed at face-to-face meeting afternoon of 2012-08-13.

Thu, 16 Aug 2012 15:09:23 -0700

author
L. David Baron <dbaron@dbaron.org>
date
Thu, 16 Aug 2012 15:09:23 -0700
changeset 6492
dcb554a16adc
parent 6491
64dd301ea467
child 6493
bcbba88e4047

Define overflow columns as creating new fragment boxes, as discussed at face-to-face meeting afternoon of 2012-08-13.

css3-overflow/Overview.html file | annotate | diff | comparison | revisions
css3-overflow/Overview.src.html file | annotate | diff | comparison | revisions
     1.1 --- a/css3-overflow/Overview.html	Thu Aug 16 15:05:23 2012 -0700
     1.2 +++ b/css3-overflow/Overview.html	Thu Aug 16 15:09:23 2012 -0700
     1.3 @@ -376,19 +376,26 @@
     1.4     causes another <a href="#fragment-box"><i>fragment box</i></a> created as
     1.5     a next sibling of the previous one. <span class=issue>Or is it as though
     1.6     it's a next sibling of the element? Need to figure out exactly how this
     1.7 -   interacts with other box-level fixup.</span> However, fragment boxes may
     1.8 -   themselves be broken (due to fragmentation in a fragmentation context
     1.9 -   outside of them, such as pages, columns, or other fragment boxes); such
    1.10 -   breaking leads to fragments of the same fragment box rather than multiple
    1.11 -   fragment boxes. (This matters because fragment boxes may be styled by
    1.12 -   their index; such breaking leads to multiple fragments of a fragment box
    1.13 -   with a single index. This design choice is so that breaking a fragment box
    1.14 -   across pages does not break the association of indices to particular
    1.15 -   pieces of content.) <span class=issue>Should a forced break that breaks to
    1.16 -   an outer fragmentation context cause a new fragment of a single fragment
    1.17 -   box or a new fragment box?</span> <span class=issue>Should we find a term
    1.18 -   other than <a href="#fragment-box"><i>fragment box</i></a> here to make
    1.19 -   this a little less confusing?</span>
    1.20 +   interacts with other box-level fixup.</span> Additionally, if the <a
    1.21 +   href="#fragment-box"><i>fragment box</i></a> is also a multi-column box
    1.22 +   (as defined in <a href="#CSS3COL"
    1.23 +   rel=biblioentry>[CSS3COL]<!--{{!CSS3COL}}--></a> <span class=issue>though
    1.24 +   it defines <i>multi-column element</i></span>) any content that would lead
    1.25 +   to the creation of <i>overflow columns</i> <a href="#CSS3COL"
    1.26 +   rel=biblioentry>[CSS3COL]<!--{{!CSS3COL}}--></a> instead is flown into an
    1.27 +   additional fragment box. However, fragment boxes may themselves be broken
    1.28 +   (due to fragmentation in a fragmentation context outside of them, such as
    1.29 +   pages, columns, or other fragment boxes); such breaking leads to fragments
    1.30 +   of the same fragment box rather than multiple fragment boxes. (This
    1.31 +   matters because fragment boxes may be styled by their index; such breaking
    1.32 +   leads to multiple fragments of a fragment box with a single index. This
    1.33 +   design choice is so that breaking a fragment box across pages does not
    1.34 +   break the association of indices to particular pieces of content.) <span
    1.35 +   class=issue>Should a forced break that breaks to an outer fragmentation
    1.36 +   context cause a new fragment of a single fragment box or a new fragment
    1.37 +   box?</span> <span class=issue>Should we find a term other than <a
    1.38 +   href="#fragment-box"><i>fragment box</i></a> here to make this a little
    1.39 +   less confusing?</span>
    1.40  
    1.41    <p class=issue> What if we want to be able to style the pieces of an
    1.42     element split within another type of fragmentation context? These rules
    1.43 @@ -1141,6 +1148,16 @@
    1.44      </dd>
    1.45     <!---->
    1.46  
    1.47 +   <dt id=CSS3COL>[CSS3COL]
    1.48 +
    1.49 +   <dd>HÃ¥kon Wium Lie. <a
    1.50 +    href="http://www.w3.org/TR/2011/CR-css3-multicol-20110412"><cite>CSS
    1.51 +    Multi-column Layout Module.</cite></a> 12 April 2011. W3C Candidate
    1.52 +    Recommendation. (Work in progress.) URL: <a
    1.53 +    href="http://www.w3.org/TR/2011/CR-css3-multicol-20110412">http://www.w3.org/TR/2011/CR-css3-multicol-20110412</a>
    1.54 +    </dd>
    1.55 +   <!---->
    1.56 +
    1.57     <dt id=RFC2119>[RFC2119]
    1.58  
    1.59     <dd>S. Bradner. <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key
     2.1 --- a/css3-overflow/Overview.src.html	Thu Aug 16 15:05:23 2012 -0700
     2.2 +++ b/css3-overflow/Overview.src.html	Thu Aug 16 15:09:23 2012 -0700
     2.3 @@ -273,6 +273,11 @@
     2.4  		<span class="issue">Or is it as though it's a next sibling of
     2.5  		the element?  Need to figure out exactly how this interacts with
     2.6  		other box-level fixup.</span>
     2.7 +		Additionally, if the <i>fragment box</i> is also
     2.8 +		a multi-column box (as defined in [[!CSS3COL]]
     2.9 +		<span class="issue">though it defines <i>multi-column element</i></span>)
    2.10 +		any content that would lead to the creation of <i>overflow columns</i> [[!CSS3COL]]
    2.11 +		instead is flown into an additional fragment box.
    2.12  		However, fragment boxes may themselves be broken
    2.13  		(due to fragmentation in a fragmentation context outside of them,
    2.14  		such as pages, columns, or other fragment boxes);

mercurial