Broken CSS Styling In Chrome, But Works Fine In Firefox
I built this website yesterday, and I wanted to show it off, so I sent it to a friend and I showed it to my girlfriend. They were both supportive, but to my dismay, the navbox up at the top of the page didn't render properly for anyone but me. I had done all of the design work and the site was fine moments earlier when I had walked out of my office, so why was it broken now? We tried on a few different web browsers:
- iOS Safari
- Android Firefox
But the nav buttons still did not render correctly. Today, I opened up the files expecting to find that I had accidentally removed some lines before stopping work, but to my surprise everything was there, the site even looked the way that it was supposed to in Firefox. When opened in Brave (a Chromium derivative) or in Android Firefox again, the list showed up as a plain unstyled list. For clarity, this is how things are supposed to look (and how they do in Desktop Firefox):
And this is how they looked in any other browser:
The list should be:
- Separated by " | "
- All on one line
- Nicely colored
I opened up the Inspect panel in Chrome and selected the
<div class="navbox"> line. I found that there was an
error in the CSS:
When I hover over the surprised little triangle, he tells me "Unknown property name", but the strikethrough ends at the bottom padding. I thought that the buttons should still render, just with the wrong colors, given the section of the CSS that is striken-through with an error. Simply removing the lines from the error in Brave does not make the list render correctly.
Idea: Maybe I Can Get Brave To Render Literally Any Styled List
It is best when testing to isolate things.
<html>
<ul>
<li>One</li>
<li>Two</li>
<li>Three</li>
</ul>
</html>
<style>
li {
display: inline;
}
</style>
Works. Wrapping the <ul> tag in a
<div> also works. However, changing the style section
to:
.navbox {
li {
display: inline;
}
}
Causes everything to break. Interestingly, when I instead collapse the full "path" (I'm not a webdev, that's probably the wrong term) into one line like so, it goes back to working:
.navbox li {
display: inline;
}
And in fact, collapsing the FQCEs (Fully Qualified CSS Element, a term that I just made up) for my website results in the rendering that I expect. A snippet:
.navbox a:link {
color: #1f9e89;
}
.navbox a:visited{
color: #1f9e89;
}
.navbox a:hover{
color: white;
background-color: #1f9e89;
}
.navbox a:active{
color: #1f9e89;
}
.navbox {
padding-bottom: 1%;
}
Why It Didn't Work
I'm not sure where the original broken syntax came from. When I was writing the template for this site, I had a million tabs open, and I may genuinely have invented the syntax from whole cloth. By a crazy random happenstance, it is actually a real thing.
There is a new CSS feature called nesting. This feature looks like it was introduced to the CSS specification in 2018. Chromium and its children have implemented this feature in the way that it is described in the linked documents. Firefox has implemented the standard in the latest beta version (117.0 at the time of writing), which is the version that I am using. However, Mozilla's implementation is maybe flawed and accepts CSS that should not be valid (yet). Here is an example that should and does work in both browsers:
<html>
<ul>
<li>One</li>
<li>Two</li>
<li>Three</li>
</ul>
</html>
<style>
.navbox {
& li {
display: inline;
}
}
</style>
Notice the & right there before the li. That is the character that should cause nesting to work. It was missing in my original code and Firefox just accepted that it should be there, while Chromium-based browsers instead silently failed. However, the CSS Working Group has discussed relaxing the syntax to no longer require the & and a Firefox developer was supportive of that goal. From the github discussion, I found this snippet useful:
This is about dropping the requirement of an explicit & in front of descendant selectors that start with an element selector. We have already resolved to make it optional in all other cases in #7834, so not sure how making it optional in all cases makes the language messier, if anything not having this exception makes it less messy. This is exactly the syntax nested rules would have in Option 4, which I see you voted you prefer over the now current (option 3) syntax. The ability to write selectors like this is the main reason people are considering option 4, so if we could get the same syntax and actually nest, it seems the best of both worlds. Also, when we polled authors, half wanted to omit the & whenever possible in a sample size of 1.6K people, which is not negligible.
And furthermore, during a CSSWG meeting, it was resolved to no longer require the ampersand going forward. People shit on Firefox for not following current standards, but here it seems that Chromium and friends are not following future standards. Firefox users are living in the future. According to CSSWG, the new stuff should be in the specification, however the spec at the time of writing just references the github issue without actually saying that you can ignore the &.
