Bug 126336

Summary: [fragmentation] Transforms shouldn't affect layout
Product: WebKit Reporter: Dirk Schulze <krit>
Component: CSSAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: abucur, achicu, bjonesbe, hyatt, mibalan, mihnea, simon.fraser, WebkitBugTracker
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 126357    
Bug Blocks: 113050    
Attachments:
Description Flags
Continues painting - hover over content. none

Dirk Schulze
Reported 2013-12-31 05:32:56 PST
Created attachment 220155 [details] Continues painting - hover over content. The title doesn't really describe the actual problem correctly. If you have an element that is fragmented, it is split into different border boxes. If you apply a transform on the fragmented element, it should appear as if each fragment was transformed individually by its own border box (transform-origin is affected as well of course). For certain transforms, like rotation, more content can be visible up to the break. WebKit continues painting up to this break. This is incorrect. It seems as if the break is implemented as clipping rect and this clipping rect is not transformed as well. This leads to these weird effects that can be seen in the example. There is a second weird thing happening. I assume it is related to the described problem. If there is a translate or scale, the content can leave the region or current column of multi-column layout. Right now this content is clipped to the boundaries of the column/region. Since transforms do not effect layout, this should not happen. The attached example demonstrates both problems on multi-column. The same happens for regions as well of course. My assumption is that we should just transform the clipping region that is responsible for the breaking as well.
Attachments
Continues painting - hover over content. (655 bytes, text/html)
2013-12-31 05:32 PST, Dirk Schulze 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Simon Fraser (smfr)
Comment 1 2013-12-31 12:32:32 PST
> it should appear as if each fragment was transformed individually by its own border box Is that actually speced anywhere? I remember talking about it at Tucson, but don't know if we resolved or if Hyatt agrees with the resolution.
Dirk Schulze
Comment 2 2013-12-31 12:43:55 PST
(In reply to comment #1) > > it should appear as if each fragment was transformed individually by its own border box > > Is that actually speced anywhere? I remember talking about it at Tucson, but don't know if we resolved or if Hyatt agrees with the resolution. Yes, it is specified now: http://dev.w3.org/csswg/css-break/#transforms I do not know when it was discussed and if there was an outcome other then the spec test. Open the example in Firefox, it looks much better and fulfills the expectation of authors IMO.
Dirk Schulze
Comment 3 2014-01-01 00:57:46 PST
(In reply to comment #2) The current behavior also has the problem that on certain transforms the content of a different fragment gets visible. See the image http://blogs.adobe.com/webplatform/files/2013/02/pic3.png as example. With rotating Region A a bit, Line 5 can get visible. I do not think that this is desirable at all. Otherwise, we wouldn't even need to introduce a break spacing.
Andrei Bucur
Comment 4 2014-04-04 00:26:47 PDT
For regions we've got most of the core fragments painting functionality done. Relative positioning works well, the next step is to handle transforms properly.
Note You need to log in before you can comment on or make changes to this bug.