Web-bugs: polygraph.cool - layout is messed up

[overholt]

URL: http://polygraph.cool/history/
Browser / Version: Firefox 49.0
Operating System: Windows 10
Problem type: Layout is messed up

Steps to Reproduce
1) Navigate to: http://polygraph.cool/history/

Expected Behavior: Layout should look like release

Actual Behavior: Layout looks odd in Firefox Nightly

_From webcompat.com with ❤️_

[adamopenweb]

Thanks @overholt. I am able to reproduce in Nightly on OSX. When I disable the webkit prefixes pref, the site looks normal. layout.css.prefixes.webkit: false
@miketaylr?

[adamopenweb]

Doing a little testing on this, leaving the css.prefixes.webkit pref enabled.

On the "screen" div display: -webkit-box is overriding display: flex.

.screen {
    background: #111;
    width: 100%;
    z-index: 10000000000000000000;
    top: 0;
    display: flex;
    display: -webkit-box;
    display: -ms-flexbox;
    display: -webkit-flex;
    flex-direction: column;
    -webkit-flex-direction: column;
    justify-content: center;
    overflow: hidden;
    -webkit-justify-content: center;
}

Disabling display: -webkit-box gets us closer:

Next looking at the "title-section" div, same thing. Webkit-box is overriding display: flex.

.title-section {
    display: flex;
    display: -webkit-box;
    display: -ms-flexbox;
    display: -webkit-flex;
    justify-content: center;
    -webkit-justify-content: center;
    z-index: 10000;

Disabling display: -webkit-box here makes the front page look right.

If we hit play there is more content and the list of years under each decade could use the same treatment "chart-year-wide-data-year-wrapper". There is probably more examples of this on the page.

[miketaylr]

Paging @dholbert to give input on what our -webkit-box implementation is doing here.

(I wonder if we can't just get in touch and ask them to put the unprefixed properties _after_ the prefixed ones -- I see there's an email address at the bottom for getting in touch: [email protected])

[dholbert]

Our -webkit-box implementation is doing exactly what Chrome's would do. The difference is, Chrome isn't using -webkit-box -- it's honoring the display: -webkit-flex rule which comes a bit afterwards. That enables modern flexbox in Chrome (just as if they had display:flex there).

If I disable that -webkit-flex declaration, Chrome looks just like Firefox Nightly.

[dholbert]

Specifically, in Adam's style quote:

.screen {
  display: flex;         <-- Firefox (all versions) & Chrome understand; gives correct layout.
  display: -webkit-box;  <-- Firefox Nightly & Chrome understand; gives BROKEN layout
  display: -ms-flexbox;
  display: -webkit-flex; <-- Chrome understands, and this gives correct layout

So, it looks like we would need to implement support for display: -webkit-flex as an alias to enable modern flexbox in order to avoid breaking when given this fun ordering of display declarations. :-/

[dholbert]

I wonder if we should just do outreach to get them to reorder their styles, though?

We've declared that display:-webkit-box (old-style flexbox) is an absolute requirement for webcompat. But I'm not yet sure we should give up and support prefixed _modern_ flexbox (display:-webkit-flex) and prefixed versions of all its associated properties... I expect/hope it's pretty rare that sites specifically lean on modern -webkit-flex in a way that breaks in Firefox when we enable old-school -webkit-box support like this... (Note that it only breaks in this case because the -webkit-box version of the page is _broken_, as demonstrated by Chrome itself when you kill the -webkit-flex declaration.)

So: I think tech evang might be the best fix here. They should either:
(1) kill their (broken) display:-webkit-box declarations (since the layout breaks when they're active)
(2) move display:flex to the end as the final preferred style
... or do both of those things. (Either of those things on their own would fix this in Firefox Nightly, though.)

[hexalys]

@dholbert
Interesting problem... Sadly, you might want to alias -webkit-flex anyway.
Chomestatus.com indicates a depressing 12.0348% usage for alias-webkit-flex.

[karlcow]

@hexalys is it usage -webkit-flex as the last property without any other standard properties? or just being there in a pack of other properties? aka:

.foo {
  display: flex;
  display: -webkit-flex;
}

OR

.foo {
  display: -webkit-flex;
}

OR

.foo {
  display: -webkit-flex;
  display: flex;
}

@dholbert I agree if they get the cascade wrong we should try to contact them. If the cascade is wrong for MANY Web sites… we have a bigger issue. Or maybe the policy in the CSS WG should be changed, aka if in a group of properties whatever the order if the standard property is here and the browser implements it, pick it up instead of the prefixed one. Maybe it will create more breakage. Not sure.

[hexalys]

@karlcow Not sure what the alias reference means exactly. It's usage given by Chrome (with the CSS property used at least once ), looking up for alias-webkit-flex.

I don't think the order issue is a large prospect. But Chrome support for display: -webkit-flex presumably helps with a missing flex standard declaration, as the main use case.

Given such a pattern:

.foo {
    display: -webkit-box;
    display: -ms-flexbox;
    display: -webkit-flex;
}

Firefox could still fail.

[dholbert]

Agreed w/ @karlcow. The fact that many sites _include_ -webkit-flex in their CSS doesn't necessarily mean they _rely_ on it. If they do, that's a bit disturbing.

Also: supporting display:-webkit-flex on its own wouldn't make sense; if we did that, we'd really need to add support for all the associated modern-flexbox properties with webkit prefixes, as well (since any page that needs display:-webkit-flex would presumably need some of those as well). Those properties are: flex, flex-grow, flex-shrink, order, justify-content, align-items, align-self, align-content, and maybe another one or two that I forgot. So: it's not as simple as just supporting -webkit-flex as an alias on its own -- this is a whole pile of new aliasing, which I'd really rather avoid if possible.

@hexalys , you're correct that your .foo would be potentially broken there, but _ONLY_ if:
(1) the site was silly enough to use that ordering in the first place (with no modern display:flex fallback)
(2) the -webkit-box styling that the site uses happens to be broken. (e.g. they specify modern -webkit-justify-content without specifying its legacy -webkit-box-pack version, and the site breaks if that style isn't present.)

...and it would only manifest as a bug in new Firefox versions if:
(3) the site happens to render just fine if none of these styles at all are recognized (but it breaks if -webkit-box is honored).

I would bet that the first two things occurring in conjunction must be pretty rare, and all _three_ occurring in conjunction even rarer. (They happened to occur in conjunction at this particular polygraph.cool site, but that seems likely to be a one-off exception.)

Note also that we've been shipping display:-webkit-box support in Nightly (and later DevEdition) for 5 months now, and this is the first report we've come across with this particular dependence on display:-webkit-flex.

[dholbert]

(Also, somewhat pedantic note: the Chrome data that @hexalys is referring to seems based on CSS _property names_ -- so I would bet alias-webkit-flex is really referring to things like -webkit-flex:1, _not_ display:-webkit-flex. (i.e. it's likely about -webkit-flex as a property, not as a value for display). Those two things are associated, but distinct. I could totally imagine 12% of sites including CSS like -webkit-flex:1; flex: 1 -- I'll bet that's what that Chrome data is saying. It doesn't tell us much about whether those sites rely on display:-webkit-flex for rendering, though.)

[hexalys]

@dholbert Ok. It remains speculative indeed. Wasn't aware of the display:-webkit-box support either.
That said, I have seen all kind of weird syntax or order included in demos or stackoverflow examples.

I just found this one demo with a quick google search, from a nettuts article.

.simple-[failed]-example {
  /* Old Syntax */
  display: -webkit-box;
  display: -moz-box;
  /* New Syntax */
  display: -webkit-flexbox;
}

:(

[dholbert]

Let's not get too far in the weeds here -- but FWIW, I think Chrome would render that testcase just like Firefox would. (Both rendering engines would reject -webkit-flexbox; that's an old version of the modern syntax, and I don't think any modern browser version accepts that spelling of the display value anymore. So both Chrome & Firefox Nightly fall back to -webkit-box -- we explicitly ignore -moz-box when it follows -webkit-box because we know sites try to do this to try to be multi-prefix-friendly, despite the fact that -moz-box is its own separate thing.)

[miketaylr]

Thanks all -- I sent an email to the contact listed on the site (with a link back to this bug), suggesting he swap the order of unprefixed/prefixed props.

[matthewfdaniels]

Hey all. I made this site.

FWIW: the order of the flexbox css is ripped right from essentially every flexbox cross-browser best pracatice on stackoverflow and most flex-box guides.

[miketaylr]

Hey @matthewfdaniels, thanks for responding to my email so quickly.

FWIW: the order of the flexbox css is ripped right from essentially every flexbox cross-browser best practice on stackoverflow and most flex-box guides.

Yeah, there's a lot of mis-guided advice out there. :(

[dholbert]

@matthewfdaniels The canonical best practice for any prefixed CSS feature is to include the unprefixed version _last_ (so the most-modern version has the "final say", so to speak).

Anyone recommending against that is giving bad advice. (And bad advice does exist out there, unfortunately.)

[dholbert]

@matthewfdaniels (Do you happen to have a link to the particular guide(s) that you ripped this from? If we can get that fixed "upstream", it might prevent future problems for us. :) )

[hexalys]

@dholbert

How about an odd Opera blog post by @chrisdavidmills ;)

section {
    display: -ms-Flexbox;
    display: -webkit-flex;
    display: -moz-flex;
    display: -ms-flex;
    display: flex;
}

:O half of the prefixes are incorrect...

[dholbert]

@hexalys, that style you quoted is fine... The thing we're discussing at this point is: "display:flex needs to come last" -- and it does come last there.

[hexalys]

@dholbert Yeah, I know. Was actually looking for that in the wild, fixing a few bad answers on SO.

that style you quoted is fine...

There is a 'F' typo there... And the entire blog post is not fine. It mixes up -ms-box-orient with -ms-flexbox syntax, inline-flex with display: -webkit-flex, or prefixes that don't (or never came to) exist. This should be corrected.

[dholbert]

@hexalys, I think the issues you're describing with the prefixes on that blog post are all orthogonal to this github-issue. They may be worth fixing, but if you want to discuss them, please file a separate issue. :)

(my declaration that that blog post's style was "fine" was with respect to the issue being discussed here, which again is simply "modern unprefixed fallback should come last". Typos in earlier prefixed styles may merit fixing, but shouldn't impact the page if they're followed by correct unprefixed syntax.)

[dholbert]

So -- the remaining action items for this issue-page here are for @matthewfdaniels to kindly:
(1) fix the ordering so that modern display:flex comes last instead of first, which will keep the polygraph site working when Mozilla ships display:-webkit-box support.
(2) if he has it handy, report back about the place(s) he mentioned copypasting this flexbox style from (with display:flex incorrectly being listed first, before prefixed display values).

If other folks (besides @matthewfdaniels) run across any easily-discoverable-by-web-developers tutorials/resources that tell people to use a broken order (display:flex before prefixed display values), those resources may be worth reporting here. But otherwise, this page is already a bit long -- let's not let it scope-creep and get to the point of being unreadable/unfollowable. (So -- please file separate issues for stuff like that Opera blog post, or better yet just reach out to the blogger directly! :))

[matthewfdaniels]

Ok I changed over all of the css. No errors on mind end from the change. Let me know if it fixed the bug.

[dholbert]

Yup, looks good on my end -- thanks!

(I had to shift+reload to purge the old stylesheet from my cache, but after that, I'm getting the correct/expected layout. Hooray! And in devtools style-editor, I can confirm that the ordering now shows display: flex as the final display value for the .screen{...} style rule now.)

[karlcow]

@matthewfdaniels Fabulous!
Switching to Fixed. Thanks a lot.

@dholbert as always, all of our ❤️

[chrisdavidmills]

@hexalys argh, ghosts of old blog posts coming back to haunt me...I am surprised that half of this is wrong, as I did a load of research on this at the time, and it seemed correct for the state of Flexbox support in 2013 (this was for IE11 support, which supported that weird hybrid 2011 Flexbox syntax.) I no longer have the keys to dev.opera.com now I'm at Mozilla, but it might be worth having a chat to Bruce Lawson or Andreas Bovens about this on Twitter, see if they want to work on an update?

[hexalys]

@chrisdavidmills Well it's wrong now anyway... I wasn't fully aware of the hybrid syntax before; as I started looking into flexbox by summer 2013. That syntax wasn't published by MS as official one AFAIK. Besides the typo, it seems the fundamentals were perhaps correct. But only for a short period of time. And having ms-box-... while having no mention of -webkit-box or -moz-box is rather confusing or lacking a full cross-browser context with 2009 'box' spec.

Considering the _never-implemented_ properties. It could certainly introduce confusion for someone reading it now. Perhaps, a top page disclaimer with a link to a newer article with current syntax would suffice.

[dholbert]

FWIW, I ran across a StackOverflow post that had a similar pattern of CSS (such that Firefox with -webkit-box support would end up with display:-webkit-box and break, while Chrome would accept a later display:-webkit-flex).

I'm getting more worried about this causing more trouble than we can fix with one-off author outreach, so I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1274096 on possibly adding support for display: -webkit-flex as an alias for display:flex.

[hexalys]

FYI: I just saw and answered a much related SO question, that pointed out to an out-of-date MDN page.
which should be edited, if anyone feels inclined. Or I will edit it later when I get a chance.