CSS 2021

[rviscomi]

Part I Chapter 1: CSS

If you're interested in contributing to the CSS chapter of the 2021 Web Almanac, please reply to this issue and indicate which role or roles best fit your interest and availability: author, reviewer, analyst, and/or editor.

Content team

Lead	Authors	Reviewers	Analysts	Editors	Coordinator
@meyerweb	@GeekBoySupreme @meyerweb	@j9t @svgeesus @argyleink @una @estelle @LeaVerou @rachelandrew @jabranr @tomhodgins	@rviscomi @thecraftysoul	-	@rviscomi

Expand for more information about each role

• The content team lead is the chapter owner and responsible for setting the scope of the chapter and managing contributors' day-to-day progress.
• Authors are subject matter experts and lead the content direction for each chapter. Chapters typically have one or two authors. Authors are responsible for planning the outline of the chapter, analyzing stats and trends, and writing the annual report.
• Reviewers are also subject matter experts and assist authors with technical reviews during the planning, analyzing, and writing phases.
• Analysts are responsible for researching the stats and trends used throughout the Almanac. Analysts work closely with authors and reviewers during the planning phase to give direction on the types of stats that are possible from the dataset, and during the analyzing/writing phases to ensure that the stats are used correctly.
• Editors are technical writers who have a penchant for both technical and non-technical content correctness. Editors have a mastery of the English language and work closely with authors to help wordsmith content and ensure that everything fits together as a cohesive unit.
• The section coordinator is the overall owner for all chapters within a section like "User Experience" or "Page Content" and helps to keep each chapter on schedule.

Note: The time commitment for each role varies by the chapter's scope and complexity as well as the number of contributors.

For an overview of how the roles work together at each phase of the project, see the Chapter Lifecycle doc.

Milestone checklist

0. Form the content team

• May 31: The content team has at least one author, reviewer, and analyst

1. Plan content

• June 15 The content team has completed the chapter outline in the draft doc

2. Gather data

• June 30: Analysts have added all necessary custom metrics and drafted a PR (example) to track query progress

• July 1 - 31: HTTP Archive runs the July crawl

3. Validate results

• September 30: Analysts have queried all metrics and saved the output to the results sheet

4. Draft content

• October 31: The content team has written, reviewed, and edited the chapter in the doc

5. Publication

• November 15: The completed chapter and all required metadata and figures are converted to markdown and submitted to GitHub

• December 1: Target launch date 🚀

Chapter resources

Refer to these 2021 CSS resources throughout the content creation process:

📄 Google Docs for outlining and drafting content
🔍 SQL files for committing the queries used during analysis
📊 Google Sheets for saving the results of queries
📝 Markdown file for publishing content and managing public metadata

[j9t]

Interested and available as a reviewer.

[GeekBoySupreme]

Interested and available as an author. Can double up as an Editor/Reviewer (if necessary)

[rviscomi]

📟 Paging CSS 2020 crew: @LeaVerou @svgeesus @rachelandrew @fantasai @mirisuzanne @catalinred @dooman87
📟 Paging CSS 2019 crew: @una @argyleink @meyerweb @huijing

Would any of you be interested to contribute to the CSS 2021 chapter? I'd especially like to see more 2019/2020 authors become 2021 reviewers to help ease the transition and similarly I think prior reviewers would make great 2021 authors, being familiar with the process already. And prior analysts would make excellent 2021 analysts 😁

Or is there anyone new you'd like to see?

[svgeesus]

I'm happy to contribute again as author or, if there are many excited new authors, as reviewer.

[argyleink]

I'll be a reviewer 🙂

[una]

Happy to review!

…

On Thu, May 6, 2021 at 2:21 PM Adam Argyle ***@***.***> wrote: I'll be a reviewer 🙂 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2140 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM5L3HFPGXU53WAFDDQFJLTMLMY7ANCNFSM43UFMBXA> .

[rviscomi]

@svgeesus would you be open to being the content team lead and drive the content planning/writing? You can coauthor with @GeekBoySupreme and anyone else who may be interested.

[estelle]

Please add me to the list of reviewers.

[LeaVerou]

I can review!

[rachelandrew]

I can review.

[rviscomi]

@meyerweb thanks for your interest in authoring this chapter! As the content team lead, you'll be responsible for the scope and direction of the chapter and keeping it on schedule. We automatically monitor the staffing and progress of each chapter based on the state of the initial comment so please keep that updated as you add new contributors and meet each milestone.

We've created a Google Doc for this chapter, which you're encouraged to use to collaborate with the content team on the initial outline, metrics, and ultimately the final draft.

Next steps for this chapter are:

• Due May 31: Complete Milestone 0: Form the content team—you can check this off now since you've already got at least one author, reviewer, and analyst ✨
• Due June 15: Get started on Milestone 1: Plan content by brainstorming some content ideas in the doc (you may need to request edit access)

There's not currently a section coordinator for this chapter, so I'll be periodically checking in with you directly to make sure the chapter is staying on schedule. Reach out here in this issue if you have any questions about the process.

More information about the content team lead and author roles and responsibilities are available for reference in the wiki if needed.

To anyone else interested in contributing to this chapter, please comment below to join the team!

[jabranr]

@rviscomi Interested and available as a reviewer

[meyerweb]

looks at reviewer list
breaks into cold sweat

[tomhodgins]

Howdy, I'm willing/able to help out where it's needed, if it's needed!

[rviscomi]

Welcome @jabranr @tomhodgins! I'll defer to @meyerweb as content team lead to onboard you and update the role assignments in #2140 (comment). For now please request edit access to the chapter doc and add your thoughts/ideas to the outline.

Also, added myself as an analyst again but happy to share that with anyone if interested.

[rviscomi]

@meyerweb are you able to edit the top comment to update the list of reviewers and check off the 0th milestone?

[meyerweb]

Author and reviewer volunteers added — welcome, all! If I missed anyone, please let me know.

This is a good time to wish for things to analyze and talk about in CSS. @bkardell had a great suggestion in the accessibility issue:

it strikes me that in neither the CSS nor Accessibility chapters in 2019/2020 is there any analysis on focus stying (including the disabling of) which is very relevant to a lot of conversations and would be great to have more facts on

What else? Anything that hasn’t been done in the past that should be? Anything that’s been done in the past we should drop? Let’s hear ’em!

[meyerweb]

As a starting point for everyone, I’ve created a draft outline for the chapter on https://docs.google.com/document/d/18OV1ngkQxdJdENkYzHOdNRtzMLo1vVv9Tg6a9pGfSSE with some proposed additions and hanging questions.

[rviscomi]

There’s a huge discrepancy between this year’s custom property names analysis and last year’s. Last year, Avada was on top with nearly 35% of all custom names. This year, it got 3.7%. Both analyses are (or at least appear to be) based on mobile. It feels like either Avada didn’t get the credit it should this year, or got way too much last year.

The custom property name sheet only shows the top 1000 most popular values as a percentage of pages. It seems like this year there are many mobile pages with Avada that fell just below that threshold.

For example, about 50k desktop pages (0.8%) include Avada custom properties like --color_*. Since there are more than 1M fewer desktop pages than mobile, this makes up a larger percentage of all desktop pages. For comparison, 50k is only about 0.67% of all mobile pages, which is right at the 1000 cutoff.

This methodology doesn't really lend itself well to how the metric is being used in practice. We're manually annotating each custom property name with its corresponding tool (Avada, WordPress, Bootstrap, etc) so it would be impractical to scale this out beyond 1000 names. I think a better methodology we should explore for next year would be to automate that annotation logic in the SQL and remove the LIMIT 1000 so that we can aggregate tool-level stats over all custom properties.

For this year, we could use the more comparable desktop data and/or include a note in the chapter explaining how our approach affected the results.

Do the queries already check in such cases to make sure there are other, more obviously Bootstrap-ish custom properties (or other things, like a Bootstrap license statement) to be more certain of provenance? If not, could they?

This is partially answered above. Because we're manually annotating each custom property name in Sheets, we don't have the full context of what other properties are used on a given page. If we implement the annotations in SQL we'd have more control to implement a solution like the one you suggested.

[meyerweb]

The custom property name sheet only shows the top 1000 most popular values as a percentage of pages. It seems like this year there are many mobile pages with Avada that fell just below that threshold.

For example, about 50k desktop pages (0.8%) include Avada custom properties like --color_*. Since there are more than 1M fewer desktop pages than mobile, this makes up a larger percentage of all desktop pages. For comparison, 50k is only about 0.67% of all mobile pages, which is right at the 1000 cutoff.

This methodology doesn't really lend itself well to how the metric is being used in practice. We're manually annotating each custom property name with its corresponding tool (Avada, WordPress, Bootstrap, etc) so it would be impractical to scale this out beyond 1000 names. I think a better methodology we should explore for next year would be to automate that annotation logic in the SQL and remove the LIMIT 1000 so that we can aggregate tool-level stats over all custom properties.

For this year, we could use the more comparable desktop data and/or include a note in the chapter explaining how our approach affected the results.

Oof. I am fairly strongly motivated to drop this analysis this year (possibly with a note as to why) and come back to it in 2022, assuming more robust analysis is created. The only alternative I see is what you propose, switching to desktop and adding a note explaining the uncertainties in the methodology, and that is itself an argument for just taking the analysis out entirely.

I would be happy to take a part in crafting that more robust analysis, to be clear. I’m just not sure it can be put together in time for this year’s Almanac, given my delay in getting started and the likely complexity of the task.

[meyerweb]

General progress update: I got up to “CSS Mistakes” today, which means I’ll need to write that and the “Sass” section tomorrow, then start back at beginning on resolving suggestions, making my own edits, tackling anything missing, etc. I’d hoped to finish primary drafting today, but pushing any further at this point would probably result in garbage I’d just have to replace tomorrow anyway.

So, reviewers: it’s time to really get started. Please make minor edits as suggestions (switch your edit mode in Google Docs to “Suggesting” in the top right of the Doc), and anything major can be either a comment on the Google Doc or here in the issue. I’d prefer comments in the Doc, but if the comment feels too huge for a sidebar comment, this is a reasonable alternative.

@GeekBoySupreme, given that I’ve gotten this far, how about you write the intro to each section as you go through the chapter? I marked missing intros with orange and the text “TK intro”. It would be a big help if you could do that in addition to editorial review.

[bkardell]

manually annotating each custom property name in Sheets, we don't have the full context of what other properties are used on a given page. If we implement the annotations in SQL we'd have more control to implement a solution like the one you suggested.

I kind of agree with eric's thought to drop or at least revise this part significantly. It might be nice to say something bland but interesting like about custom elements "X number of custom properties appear on over N pages" and then explain something like "here are the ones we feel really confident about" (--wp-* is pretty good/specific) but also note that there's a bunch that might or might not be other systems, and we haven't figured out a good way to count them yet.

[LeaVerou]

@rviscomi @LeaVerou There’s a huge discrepancy between this year’s custom property names analysis and last year’s. Last year, Avada was on top with nearly 35% of all custom names. This year, it got 3.7%. Both analyses are (or at least appear to be) based on mobile. It feels like either Avada didn’t get the credit it should this year, or got way too much last year.

A glance at the pivot table this year (see docs.google.com/spreadsheets/d/12vQIA0xsC5Jr3J9Sh03AcAvgFjMAmP1xSS6Tjai9LF0/edit#gid=725813203) makes me think the affiliation may have gone haywire one way or the other: Avada gets 31.48% of desktop, and 3.67% of mobile. There is a smaller but still substantial discrepancy with Bootstrap between desktop and mobile.

FYI: I filled in all the unaffiliated custom properties with “Miscellaneous” in this year’s sheet, so the pivot table and thus the pie chart wouldn’t have a (blank) entry. if those end up being overwritten by a new analysis run, no worries. Let me know what you find, or what I can do to help dig into this.

What was the methodology this year for assigning custom properties to software? I think last year I did it manually by searching on Github. But I see Avada still has 31.48% on desktop, are you sure last year's analysis was based on mobile?

[LeaVerou]

@rviscomi: On the subject of the custom property names, I’m dubious of some of the affiliation assignments. As an example, all color-like properties (--white, --black, --red, etc.) are credited to Bootstrap. Bootstrap may have those names baked in, but if there’s one class of custom property names I can imagine people inventing on their own, it’s names like those. Do the queries already check in such cases to make sure there are other, more obviously Bootstrap-ish custom properties (or other things, like a Bootstrap license statement) to be more certain of provenance? If not, could they?

(Also, shout out to WordPress for hand-namespacing all their custom properties. If only every project were so circumspect!)

Note that Bootstrap these days does namespace its custom properties, these ones are from old Bootstrap.
I think last year when I assigned them manually, I did take into account which groups of properties had similar usage percentages.

[rviscomi]

I kind of agree with eric's thought to drop or at least revise this part significantly. It might be nice to say something bland but interesting like about custom elements "X number of custom properties appear on over N pages"

+1 to dropping the software grouping if it's problematic this year.

We could still show ungrouped stats for individual custom properties if interesting, for example the top 10 custom property names:

name	desktop	mobile
--wp--style--color--link	18.58%	18.13%
--wp-admin-theme-color	7.36%	7.52%
--red	7.40%	7.23%
--blue	7.39%	7.21%
--green	7.37%	7.19%
--dark	7.31%	7.15%
--white	7.37%	7.07%
--primary	7.20%	6.93%
--secondary	7.14%	6.86%
--gray-dark	7.06%	6.82%

What was the methodology this year for assigning custom properties to software?

@LeaVerou I tried to manually reproduce your pattern matching from 2020 on the 2021 data.

[meyerweb]

We could still show ungrouped stats for individual custom properties if interesting, for example the top 10 custom property names:

That’s it, that’s the play. Thanks, Rick!

[meyerweb]

@rviscomi: New question: the Layout Methods tab returns a figure for Grid of 37% of pages. But the next tab, Flexbox and Grid, says Grid is used on 8% of pages. I feel like I must be misunderstanding one tab or the other, but I’m not sure how to tell or how to clarify them so that I understand what each is saying. Can you clarify, please?

[rviscomi]

@meyerweb see this comment thread

[meyerweb]

@j9t @svgeesus @argyleink @una @estelle @LeaVerou @rachelandrew @jabranr @tomhodgins @GeekBoySupreme @bkardell It’s time! Please review the now-complete draft at your earliest convenience. Thank you!

As mentioned before, it’s preferred to leave comments on the Google Doc with questions/comments/concerns, unless what you need to say is too long for a Google Doc sidenote. In that case, please comment on this issue and leave a comment in the Google Doc with the URL of your GitHub comment.

[GeekBoySupreme]

@rviscomi I pulled the data on methodology from last year's almanac and could you help modifying the numbers to fit with what we did for this year
The data in this chapter took 121 SQL queries to produce, totaling over 10K lines of SQL including 3K lines of JavaScript functions within the SQL. This makes it the largest chapter in the Web Almanac’s history.
and
A lot of engineering work went into making this scale of analysis feasible. Like last year, we put all CSS code through a CSS parser, and stored the Abstract Syntax Trees (AST) for all stylesheets in the corpus, resulting in 10 TB

[j9t]

Please review the now-complete draft at your earliest convenience. Thank you!

@meyerweb, on it; what timeframe can you grant us? (I’m pretty busy but would like to contribute, in time for it to be useful.)

[meyerweb]

I believe we’re supposed to be done with editing by this Sunday (@rviscomi?), so by Thursday of this week would be ideal. Or, if I’m wrong about the deadline or we can get a slight extension, by the end of the weekend.

[rviscomi]

Getting all reviewer feedback in by Thursday SGTM. If taking an extra day or two means having a more polished chapter, then that's a tradeoff I'd be willing to take.

Just to clarify, after the authors write the chapter and reviewers' technical feedback is incorporated, there's still a separate non-technical editing pass. We'll add all of the written-but-unedited chapters into a queue and someone from the Editors team will open a new PR with suggested edits to the markdown. If we had a bigger Editors team we would have assigned one of them to the chapter and streamlined their feedback directly in the doc.

[j9t]

Thanks for clarifying. I might only be able to provide feedback this weekend, but I’ll see what I can do.

[svgeesus]

I'm working my way through the doc.

One area that we didn't examine last year (mainly because of overlap with the Fonts chapter, so we ended up dropping all the font analysis - although it then ended up unexamined in both CSS and Fonts chapters) was the usage of font-* properties.

This year, it is at least briefly examined but the lack of usage isn't really commented on at all

(I also think there is some mis-characterisation regarding font-variant and font-stretch in the doc at present, which I commented on there).

I think it would be worth looking at that in a bit more detail because there is a good takeaway here for the readers this year. They are missing out on properties which are widely implemented, but simply not being used in the wild.

As an example the most common font-variant longhand, font-variant-ligatures is used on only 2.06% of mobile sites. But why? it is widely implemented, everything but IE11 and, like all the font-variant-* longhands, it has a great fallback story if unsupported.

Similarly for font-variant-numeric at 1.75% and again, implemented everywhere.

font-variant-caps is next at 0.69% on mobile, likely because people are using the shorthand to get the most common value.

And then font-variant-east-asian at 0.18% on mobile (maybe next year a per-country analysis would be more informative for that property, given the predominance of European languages on the Web at present)

Is it lack of typographic interest or awareness? Is it excessive caution on using these OpenType features, if the webfont doesn't load? Or is it the need to support older browsers (older than 2016-16), when this support mainly rolled out?

Usage at a couple of percent is common enough that this isn't some brand-new feature at 0.001%, but there are also literally no downsides to using these properties so I think we could make a bit of a story about that aspect.

In terms of visualizations, a separate chart with font-variant and font-variant-* would likely be helpful. And perhaps, a graphic showing what these OpenType features can do.

[svgeesus]

Okay I have gone through the whole doc now and added comments as needed.

[j9t]

Dto., I’m done, too. Hard to find something, Eric, team 🙏 I look forward to this being published.

[meyerweb]

And it’s off to editing! Thank you, everyone. And if I overlooked or misidentified anyone in the contributors listing (see https://20211115t173622-dot-webalmanac.uk.r.appspot.com/en/2021/css), please accept an abject apology and an offer to reinstate you forthwith.

[rviscomi]

🎉 This chapter is fully written, reviewed, edited, and ready to be launched on Wednesday! Thank you to all of the contributors who put in the time and effort to make this a great chapter.

[rviscomi]

@meyerweb @j9t @svgeesus @argyleink @una @estelle @LeaVerou @rachelandrew @jabranr @tomhodgins @thecraftysoul

When you get 5 minutes, I'd really appreciate if you could fill out our contributor survey to tell us (the project leads) about your experience. It's super helpful to hear what went well or what could be improved for next time. 🙏

Thank you all again and I'm excited for this to launch soon!