WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
126336
[fragmentation] Transforms shouldn't affect layout
https://bugs.webkit.org/show_bug.cgi?id=126336
Summary
[fragmentation] Transforms shouldn't affect layout
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.
Top of Page
Format For Printing
XML
Clone This Bug