Bug 126357

Summary: [fragmentation] Create one border box for each fragment instead of one per fragmented element
Product: WebKit Reporter: Dirk Schulze <krit>
Component: CSSAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: abucur, ahmad.saleem792, ap, bfulgham, hyatt, mibalan, mihnea, rniwa, sam, simon.fraser, webkit-bug-importer, WebkitBugTracker, zalan
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
URL: http://lists.w3.org/Archives/Public/www-style/2013Dec/0466.html
Bug Depends on:    
Bug Blocks: 126336    
Attachments:
Description Flags
Example
none
2nd example with explanations none

Dirk Schulze
Reported 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).
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
View All Add attachment proposed patch, testcase, etc.
Dirk Schulze
Comment 1 2014-01-01 00:50:22 PST
Created attachment 220183 [details] Example
Simon Fraser (smfr)
Comment 2 2014-01-01 12:52:28 PST
It's not clear from the title of this bug what actual issue you are reporting.
Dirk Schulze
Comment 3 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.
Sam Weinig
Comment 4 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).
Dirk Schulze
Comment 5 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.
Dirk Schulze
Comment 6 2014-01-01 23:33:10 PST
Created attachment 220206 [details] 2nd example with explanations
Ahmad Saleem
Comment 7 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!
Radar WebKit Bug Importer
Comment 8 2022-07-28 20:16:52 PDT
<rdar://problem/97760056>
Note You need to log in before you can comment on or make changes to this bug.