W3C home > Mailing lists > Public > www-style@w3.org > July 2012

Re: [css3-break] Breaking replaced elements

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 18 Jul 2012 11:42:48 -0400
Message-ID: <5006D978.4040106@inkedblade.net>
To: www-style@w3.org
On 03/19/2012 09:45 AM, Vincent Hardy wrote:
> Hello,
> The rules for breaking (or not) a replaced element are that it should be avoided (section 4.5 of fragmentation spec., or
> 13.3.5 of CSS 2.1). Combined with the rules listed in the fragmentation spec. (about varying size fragmenters, see [1]), I
> read the recommendation as: if breaking a replaced element such as an image or a video cannot be avoided, then the box
> fragments are laid out and the relevant portion of the content is shown. Is that right?
> If so, what happens for an element such as video which may have controls (play/pause) in case the element is split? Shouldn't
> this be addressed in the spec? Or should we say that video is always non-breakable and may overflow the fragmenter?
> Likewise, for scrollable content, the draft says:
> "The UA is not required to fragment the contents of scrollable elements e.g. those with ‘overflow’ set to ‘auto’ or ‘scroll’,
> and may instead either graphically slice their contents as necessary to fragment the element or treat the element as
> unbreakable and overflow the fragmenter. In such cases it must treat the element as having ‘break-inside: avoid’."
> Since this text allow user agents to break scrollable elements, shouldn't the specification say something about the expected
> scrolling behavior? There are multiple options (e.g., scrolling only in the last fragment, scrolling in all the fragments,
> different syncrhonization between the way scrolling is done).
> Would it be better to require that scrollable elements and video are non breakable always?

We believe we've resolved this issue with the new text about monolithic elements in
Let us know if this addresses your comment.

Received on Wednesday, 18 July 2012 15:43:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:35:12 UTC