Bug 126357 - [fragmentation] Create one border box for each fragment instead of one per fragmented element
Summary: [fragmentation] Create one border box for each fragment instead of one per fr...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL: http://lists.w3.org/Archives/Public/w...
Keywords: InRadar
Depends on:
Blocks: 126336
  Show dependency treegraph
 
Reported: 2014-01-01 00:48 PST by Dirk Schulze
Modified: 2022-07-28 20:16 PDT (History)
13 users (show)

See Also:


Attachments
Example (700 bytes, text/html)
2014-01-01 00:50 PST, Dirk Schulze
no flags Details
2nd example with explanations (2.67 KB, text/html)
2014-01-01 23:33 PST, Dirk Schulze
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Schulze 2014-01-01 00:48:48 PST
Firefox and Internet Explorer create a new border box for each fragment of an element. This has rather big consequences on layout and CSSOM View.

CSS Transforms does use border box for calculating the transform origin. For a multi-column layout each fragment is transformed individually "after" layout was done (each fragment has its own user space). Therefore, the origin changes for each fragment.

Clipping paths can be sized per fragment width instead of calculating a global dimension for a clipping path.

On the other hand, it is unclear how the width of a background tile is determined (another discussion on www-style).
Comment 1 Dirk Schulze 2014-01-01 00:50:22 PST
Created attachment 220183 [details]
Example
Comment 2 Simon Fraser (smfr) 2014-01-01 12:52:28 PST
It's not clear from the title of this bug what actual issue you are reporting.
Comment 3 Dirk Schulze 2014-01-01 22:33:42 PST
(In reply to comment #2)
> It's not clear from the title of this bug what actual issue you are reporting.

I hope that makes it a bit more understandable. I recommend to read the post from roc on wwww-style. See link above.
Comment 4 Sam Weinig 2014-01-01 22:38:51 PST
(In reply to comment #3)
> (In reply to comment #2)
> > It's not clear from the title of this bug what actual issue you are reporting.
> 
> I hope that makes it a bit more understandable. I recommend to read the post from roc on wwww-style. See link above.

One thing that might make it a bit easier to understand would be if the example test case had actual and expected values presented (or green and red boxes if you are into that kind of thing).
Comment 5 Dirk Schulze 2014-01-01 22:52:04 PST
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > It's not clear from the title of this bug what actual issue you are reporting.
> > 
> > I hope that makes it a bit more understandable. I recommend to read the post from roc on wwww-style. See link above.
> 
> One thing that might make it a bit easier to understand would be if the example test case had actual and expected values presented (or green and red boxes if you are into that kind of thing).

The test case adds a line for each client rect created per element. In WebKit, there is just one client rect created. In Firefox you get two. I will upload a second test case which demonstrates the difference of multiple border boxes on transform.
Comment 6 Dirk Schulze 2014-01-01 23:33:10 PST
Created attachment 220206 [details]
2nd example with explanations
Comment 7 Ahmad Saleem 2022-07-28 15:01:02 PDT
I am still able to reproduce this bug in Safari 15.6 on macOS 12.5 using attached test case, Safari renders the box different from other browsers (Chrome Canary 106 and Firefox Nightly 104). Thanks!
Comment 8 Radar WebKit Bug Importer 2022-07-28 20:16:52 PDT
<rdar://problem/97760056>