W3C home > Mailing lists > Public > public-css-archive@w3.org > December 2018

Re: [csswg-drafts] [css-break-4] Should fragmentation of block-level replaced-elements be configurable? ("object-slice") (#3404)

From: fantasai via GitHub <sysbot+gh@w3.org>
Date: Fri, 07 Dec 2018 01:49:16 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-445094543-1544147355-sysbot+gh@w3.org>
The current spec behavior for monolithic box is `avoid`, and may or may not slice across pages depending on the UA's choice. See https://drafts.csswg.org/css-break-4/#unforced-breaks 

The current behavior in browsers seems to vary a lot. :) Chrome's behavior is pretty broken: it skips a page even if it's at the top, and then clips the image anyway. Gecko slices the image by default if it's block-level; there's a pending patch to make it obey `break-inside`. It clips it if it's inline-level, since it has no facility for breaking line boxes across lines.

Personally I think we shouldn't add a new property here, just re-use `break-inside` and maybe have it default to `avoid` in the UA style sheet for IMG, OBJECT, etc. An author that wants the `auto` behavior can then specify `break-inside: auto`. I don't think clipping the image without at least attempting to avoid a break in the first place is useful and certainly shouldn't be the default as it's the most lossy option. The default should probably be to avoid breaking, and then ideally to slice if it can't fit on one page.

What do you think of using `break-inside` to control this instead of adding `object-slice`?

Separately: Honoring `widows` and `orphans` in that way is a curious idea, but definitely a distinct one from controlling breaking at all. Would you mind filing it separately?

-- 
GitHub Notification of comment by fantasai
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3404#issuecomment-445094543 using your GitHub account
Received on Friday, 7 December 2018 01:49:18 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:40 UTC