CSS coding standard: outdated links

[PierceAndy]

• The link to Google's CSS Style Guide in the CSS coding standard at CodingStandard-Css.md is outdated.

https://google.github.io/styleguide/htmlcssguide.xml

has moved to

https://google.github.io/styleguide/htmlcssguide.html

• The link to Mozilla Developer Network's Writing efficient CSS is no longer there.

https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS#Guidelines_for_Efficient_CSS

A web archive presents us with the following warning:

Note: This document was originally written in 2000. Much has changed when it comes to writing CSS that is fast. This guide is not an accurate representation of the bottlenecks in the browser's rendering pipeline. For selectors in particular, read CSS Selector Performance has changed! (For the better) for a more recent take. For improving CSS speed, investigate improving costs of Reflow (layout) and Paint.

[PierceAndy]

Current situation

Currently, the section on efficient CSS selectors is as below:

Use of Efficient Selectors

• Do not qualify class/ID selectors using tag names (do not use: div.mainContent, simply use .mainContent).
  Refer to Writing efficient CSS for examples.

  This speeds up the css match lookup. If such a qualification is actually required, either use another
  class on top of this to change the style or use a completely different class to start with. In any case,
  if this kind of qualification is needed, then probably the class has not been named well enough
  (see naming standards for classes).

• Use child selector rather than descendant selector (use #container > span rather than #container span).
  Refer to Writing efficient CSS for examples.

  This is a strong recommendation as descendant selector is extremely expensive, especially when the
  specified ancestor has a lot of descendants.

After some amount of experimentation and research, I think the Mozilla Developer Network warning (as mentioned in the opening post) has merit. The section in the guidelines on writing efficient CSS selectors seems irrelevant and possibly outdated.

Let's look at whether these two points have merit:

Do not qualify class/ID selectors using tag names

Using the following tests, we can see that the differences in page load times and reflow times is pretty much non-existent, even when dealing with a page with 1000 elements affected by 1000 CSS selectors.

Unqualified class selectors
Qualified class selectors

Use child selector rather than descendant selector

The same non-existent difference can be observed with child vs descendant selectors here:

Child selector
Descendant selector

Conclusion

I think most resources (books, websites, etc.) when talking about writing efficient CSS based their advice on the article written by David Hyatt back in 2000. A lot has changed with CSS and browsers since then, and his original points don't seem too relevant now.

I would argue that even if they do make a difference, it is so insignificant that it's not worth the time and effort (a few ms difference, even with 1000 CSS selectors on 1000 elements). It is not a bottleneck in page load times, as evident from the above examples.

I think it would be better to focus on readability, maintainability, and flexibility rather than these micro-optimizations, and that this section should be removed.

Thoughts? @damithc @kychua @yamgent @chao1995 @MightyCupcakes

[damithc]

Copying @acjh

[acjh]

There are 2 main considerations:

1. Whether the "performance" rationale still sufficiently warrants each guideline.

I would agree that the difference in performance is no longer very significant. It may be noteworthy that Google still has that guideline, citing a 2009 article on performance. I believe that performance simply serves as an easy way to justify optimizations. In this case, it's not sufficient if it were the sole rationale.

2. Whether each guideline still has merits. If so, whether to update the rationale.

First, readability.

• If an unqualified class/ID selector is ambiguous, I would say that is a naming issue. Classes should convey meaning/identity, rather than be limited by tag/type. I'd compare this to pre/postfixing with types in programming languages (e.g. ColorsEnum), generally considered bad practice. Prefixing classes with UI elements (e.g. .btn-dismiss) is allowed and also consistent with that standard.
• It should be unambiguous that > is a child selector, so I believe that does not reduce readability. Descendant selectors are allowed when they are used appropriately.

Second, maintainability.

• Not qualifying with tags forces developers to use more meaningful names, helping maintainers.
• Using child selectors makes it easier for maintainers to trace specific elements that are affected.

Third, flexibility.

• Not qualifying with tags enables reuse of classes (e.g. .dark-theme) for different tag elements.
• Using descendant selectors appropriately is allowed; sometimes necessary. Update guideline?

Fourth, specificity.

• Qualified tags have greater specificity than unqualified tags, which leads to other implications.
• It appears that child selectors used to have greater specificity, but that is also no longer true.

[PierceAndy]

@acjh

Google still has that guideline, citing a 2009 article on performance.

As mentioned in the 2009 article, it is based off a chapter from the book, "Even Faster Web Sites: Performance Best Practices for Web Developers", also published in 2009. I have checked the book out, and in it the author states that he too based his points off the guidelines outlined in the original article from 2000.

I agree with the excellent points brought up about readability, maintainability, flexibility, and specificity.

The strongest argument to be made here is an update to the guideline for CSS selectors rather than an outright removal. Rather than focusing on efficiency of CSS selectors, I think it would be more meaningful to base guidelines on the four points mentioned above.

For instance, rather than stating

• "Do not qualify class/ID selectors using tag names because of efficiency reasons", it would be better to mention the other benefits like readability and maintainability.
• "Use child selector rather than descendant selector", it would be better to state it as a recommendation to do so where possible because of specificity. This being a recommendation allows for greater flexibility (as rightly mentioned above).

Ultimately, my point would be that it would be better to base the guidelines on other factors than efficiency. The existing guidelines on CSS selectors do not represent a significant bottleneck in page load times, and thus shouldn't be a priority.

Of course, it would be good to include a section on writing efficient CSS should there be any good points, but I think it should be backed by actual data, and right now it doesn't seem to be.

[yamgent]

Agree with @acjh's recommendation.

@PierceAndy If efficient CSS is irrelevant today, then that section shouldn't exist at all. Not an expert of browser-based CSS though, so you might want to consult the TEAMMATES people about that. :P

[li-kai]

Over at teammates, we're not using a lot of custom css thanks to bootstrap. Regarding performance, that should not be an issue, cutting down the size of the css file will do much more than optimizing selectors.

@acjh's points on maintainability and flexibility are still very valid. Personally I feel that good css should not have too many layers or nesting, thus I prescribe to BEM among other css architectures to keep css maintable.