Summary: | REGRESSION: Wrong layout in http://www.heroquestclassic.com/heroes-fe-de-erratas-y-un-breve-descanso/ | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Andres Gomez Garcia <agomez> | ||||
Component: | Evangelism | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED INVALID | ||||||
Severity: | Normal | CC: | ap, benjamin, cgarcia, darin, koivisto, rniwa, sam, simon.fraser, timothy, webkit-bug-importer, yoon | ||||
Priority: | P2 | Keywords: | InRadar, Regression | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
Andres Gomez Garcia
2015-04-07 05:42:33 PDT
It works with WebKitGTK+ 2.6.x, but fails with trunk/2.8. The problem is also reproducible in mac, so this looks like a recent regression in WebCore. Next step would be to reduce this to make a much smaller test case showing the problem. Knowing the revision that introduced the regression would also help. I started to bisect yesterday, but all the build breaks made it impossible to do a bisect using the GTK+ port :-( In Safari Version 8.0.5 (10600.5.17), it seems okay, but I don't know which revision it uses. Note that we need the reduction anyway to help us make a regression test, even if we don't figure out exactly what version this regressed in. (In reply to comment #5) > Note that we need the reduction anyway to help us make a regression test, > even if we don't figure out exactly what version this regressed in. I agree to make a regression test for this bug. If there is nobody have a time to do it, I'll do it. Created attachment 250595 [details]
reduced test case
It’s a CSS rule problem. I attached a simple test case.
Or some earlier change to the CSS rule system. Looks like this isn’t a bug at all. The website was depending on a bug in an older version of WebKit. The :not expression should match almost everything, and it does. The style sheet named pb-view.css has these rules in it: .template-wrapper .span3, :not(.portfolio-grid li.span3) { width: 22.75%; } .template-wrapper .span12 .span3, :not(.portfolio-grid li.span3) { width: 21.25%; } Those rules are going to apply to practically every element on the page, and are going to set their width to about a fifth of what the should be. Older versions of WebKit without proper :not support would incorrectly ignore these rules. I believe the error here was using a comma rather than using a space. I believe the :not is supposed to be a descendant selector. I suggest we not change WebKit and instead get the website to fix their broken style sheet. I’d like to understand why this problem doesn’t happen with non-WebKit web browsers. Note that I say these rules set the widths of elements to about a fifth what they should be. But this happens over and over again, since these rules apply to almost every element on the page, so they apply to the body element, and each div element, and the img element, and so on. So the widths get smaller and smaller (1/5 of 1/5 of 1/5). (In reply to comment #13) > I’d like to understand why this problem doesn’t happen with non-WebKit web > browsers. It is because of our support for CSS 4. The other browsers only support CSS Selectors Level 3. In Level 3, it was only valid to use a simple selector inside :not(). In WebKit, we support almost full selector lists (:visited and :link do not match). The rule ":not(.portfolio-grid li.span3)" would be invalid for older browsers. For us it is equivalent to ":not(.portfolio-grid >> li.span3)" and is completely valid. So this was skipped in older browsers because it was not valid. But in recent WebKit it matches everything. I think this is going to have to be fixed by the website owners. Unless we find this kind of mistake is common and we have to come up with some kind of compatibility quirk. Another way to think about this is that CSS 4 :not may not be web compatible as specified. Thanks guys! I will report back to the website. Jon Davis reached out to the site owner on 4/16. The issue comes from a WordPress plugin called Aqua Page Builder. Jon contacted the plugin author on 4/20, who has mentioned he is no longer actively developing the plugin, but said he was open to recommendations. We sent over the recommended changes and waiting to hear back on whether he will implement them or not. Can someone try a pull request? https://github.com/syamilmj/Aqua-Page-Builder/pulls Oh, great! Well, I sent a comment back to the site but it seems you have already done much more work on that direction. Thanks a lot! |