Almanac.httparchive.org: CSS 2020

[obto]

Part I Chapter 1: CSS

Content team

| Authors | Reviewers | Analysts | Draft | Queries | Results |
| ------- | --------- | -------- | ----- | ------- | ------- |
| @LeaVerou @svgeesus @rachelandrew | @fantasai @mirisuzanne @j9t @catalinred @hankchizljaw | @dooman87 @rviscomi @leaverou | Doc | *.sql | Sheet |

Content team lead: @LeaVerou

Welcome chapter contributors! You'll be using this issue throughout the chapter lifecycle to coordinate on the content planning, analysis, and writing stages.

The content team is made up of the following contributors:

• Authors
• Reviewers
• Analysts

New contributors: If you're interested in joining the content team for this chapter, just leave a comment below and the content team lead will loop you in.

_Note: To ensure that you get notifications when tagged, you must be "watching" this repository._

Milestones

0. Form the content team

• [x] Jul 6th: Project owners have selected an author to be the content team lead
• [x] Jul 13th: The content team has at least one author, reviewer, and analyst (minimally viable team formed)

1. Plan content

• [x] Jul 20th: The content team has completed the chapter outline in the draft doc
• [x] Jul 27th: Analysts have triaged the feasibility of all proposed metrics

2. Gather data

• [x] Jul 27th: Analysts have added all necessary custom metrics and drafted a PR to track query progress
• Aug 1 - 31: August crawl
• [x] Sep 7th: Analysts have queried all metrics and saved the output to the results sheet

3. Validate results

• [x] Sep 14th: The content team has reviewed the results sheet

4. Draft content

• [ ] Nov 12th: Authors have completed the first draft in the doc
• [ ] Nov 26th: The content team has prototyped all data visualizations

5. Publication

• [ ] Nov 26th: The content team has reviewed the final draft, converted to markdown, and filed a PR to add it to the 2020 content directory
• Dec 9th: Target launch date

[rachelandrew]

I'd be happy to help here. Layout is my CSS specialism but I can write about most things. I'm also an experienced editor.

[j9t]

I’m happy to contribute, too. With my current workload the least I can commit to is reviewing—I look forward to coordinating with whoever would be driving this section.

[catalinred]

I'd love to help in any way.

[estelle]

I have a particular knack and interest in selectors and specificity, but can write about other topics as well.

[obto]

@LeaVerou thank you for agreeing to be the lead author for the CSS chapter! As the lead, you'll be responsible for driving the content planning and writing phases in collaboration with your content team, which will consist of yourself as lead, any coauthors you choose as needed, peer reviewers, and data analysts.

The immediate next steps for this chapter are:

1. Establish the rest of your content team. Several other people were interested or nominated (see below), so that's a great place to start. The larger the scope of the chapter, the more people you'll want to have on board.
2. Start sketching out ideas in your draft doc.
3. Catch up on last year's chapter and the project methodology to get a sense for what's possible.

There's a ton of info in the top comment, so check that out and feel free to ping myself or @rviscomi with any questions!

@rachelandrew @j9t @catalinred @estelle @hankchizljaw we'd still love to have you contribute as a peer reviewer or coauthor as needed. Let us know if you're still interested!

[hankchizljaw]

Yeh just let me know when and if you need me 🙂

[rviscomi]

Tentatively adding @rachelandrew and @estelle as coauthors and everyone who commented as a reviewer. @LeaVerou feel free to reassign at your discretion.

[LeaVerou]

Howdy everyone! 👋

Warm thanks @rviscomi and @obto for selecting me to lead this effort. I'm psyched!

I think @rachelandrew would be an excellent co-author, especially for anything layout.
@estelle, would you like to take on a selectors & specificity section?
@svgeesus will be a co-author for Web Fonts & Colors

I have a lot of ideas for reviewers and co-authors, to which I will reach out privately, then @-mention here (I would rather not ask them in public, as it makes it harder to say no). I do not have any ideas for analysts however. Should we be looking for people swapping areas of responsibility or look for new people to join? Perhaps anyone from the current reviewers would like to become an analyst?

I'm going to re-read last year's chapter and reflect on what has happened in CSS within the year. A few quick initial thoughts:

• I see last year we only calculated how many websites use custom properties, I would like to go a lot deeper this year (what do they use them for? How do they use them? where do they use them?).
• Variable fonts! Lots of interesting stuff to calculate there and I'm sure @svgeesus would love to.
• Houdini! Are Houdini APIs used yet? How much? How?
• The point above brings us to the question: Is CSS-relevant JS within scope?
• I would love to calculate more on selectors. What's the average specificity per selector? Which pseudo-classes are the most popular and by how much?

If anyone has any ideas/suggestions, they are always welcome!

[j9t]

This is a world-class author team. I’m excited about the CSS chapter!

@obto, @LeaVerou, only to confirm, I’d absolutely be around for reviewing. And if the chapter is to dive deeper into the craft of writing CSS, I’d be happy and available to contribute more (it’s one of my focus areas).

[catalinred]

Hi everyone,

Happy that @LeaVerou accepted to be the lead author for the CSS chapter. The authors team is amazing.

Here are some of my random thoughts on what numbers I'd like to see in this new chapter:

• Would like to see numbers on various ways of hiding DOM elements, by trying to guess on: [aria-hidden], .hidden, .hide, .sr-only, .visually-hidden, .visuallyhidden, .invisible or [hidden].

• How many of the pages are using the latest border-box sizing model, compared to content-box? Is the border-box number high due to popular CSS libraries usage, such as Bootstrap or Zurb Foundation?

• Popular vendor prefix numbers. Are the -webkit-, -moz-, -o- or -ms- numbers still relevant, considering the improved browser support for most of the CSS properties that once required vendor prefixes?

• Popular shorthands, e.g. transition, background, font, animation. Are the numbers maybe low due to the fact that the order of the values is not that easy to remember without checking the documentation?

• When it comes to CSS units usage, I'd love to see some numbers on unitless 0 values, e.g. 0 vs 0px/em/rem/ numbers comparison.

• Are .clearfix, .clear or .cf still popular? How popular considering the current flexbox and grid usage?

• How many of the pages are using SVG favicons and are these SVG's using CSS @media (prefers-color-scheme: light/dark) to provide an alternate style depending on the OS color scheme?

• Flexbox and grid usage and frequency.

• Try to detect and show numbers for the native font stack variations, compared to the other popular font families like Open Sans and Roboto.

• Considering the unitless line-height is a best practice, would be interesting maybe to see which values authors prefer when setting the line-height: length, unitless or percentage.

• Last but not least, I'd like to see how CSS is applied to a page: style attribute, <style> element and/or the <link> element. Besides <link>, I'd expect numbers to be quite high on <style> elements mostly due to the critical CSS recommended practice.

Let me know what you think.

[LeaVerou]

I'd like to announce @fantasai as a reviewer.

@catalinred What fantastic ideas, thank you!

[bazzadp]

What a fantastic line-up! Very excited to see what we come up with in this chapter.

[LeaVerou]

Announcing @mirisuzanne as reviewer!

[j9t]

Hi @LeaVerou, CSS chapter team—if I’m not missing anything then ID and class _names_ hadn’t been covered in neither Markup nor CSS chapter last year. They may be more of a topic to cover in the Markup chapter but I wanted to raise this here in case you’ve flagged this on your side, too. Let’s coordinate on this if necessary—I’ll follow up as soon as I get a feeling for interest and feasibility on the Markup chapter side.

[rviscomi]

@estelle I've sent you an invite to join the 2020 Authors team on GitHub. Can you visit https://github.com/HTTPArchive/ to accept the invite? This will ensure you get notifications about important chapter milestones.

[svgeesus]

Variable fonts! Lots of interesting stuff to calculate there and I'm sure @svgeesus would love to.

I certainly would!

I'm unsure of the apportioning between this CSS chapter and the Fonts chapter though.

Popular vendor prefix numbers. Are the -webkit-, -moz-, -o- or -ms- numbers still relevant, considering the improved browser support for most of the CSS properties that once required vendor prefixes?

Nice one, although -webkit now falls into two categories which should be distinguished;

1. Things that are actually WebKit specific
2. Things that the other browsers have (wth varying degrees of reluctance) had to implement, primarily so that iOS-specific mobile content also works on browsers other than Safari. The -webkit vendor prefix merely being historical legacy, at this point.

The second one is interesting to analyze because it constitutes a part of the Open Web Platform that was added without the usual design debate or standards process.

[svgeesus]

@catalinred some great suggestions there!

[svgeesus]

I'm aware only Safari implements this now, but other browsers are showing interest so probing color(display-p3 r g b) would be timely this year. Interesting to see

• how much it is used (low, because Safari only)
• is it used with an sRGB fallback and if so, how
• what percentage of the colors declared in P3 are actually outside the sRGB gamut
• use of the color-gamut media query

[LeaVerou]

Alright people, some updates.

I think a single issue to manage which stats we are going to study (proposals, voting, methodology, discussion on the finer details of how to study them etc), would be a bit messy, so I made this repo. We should still keep this issue updated with resolutions etc, so that future authors can follow it.

I also made this app for one-click voting on issues that makes it easier to add the 👍 reactions. It's easy to change which repo its about, in case other chapter authors want to use it too.

Please post your stat suggestions as new issues in that repo and tag them proposed stat. Also please vote on existing stats (maybe give it a couple days for more stat proposals to be posted so they all get a fair chance). I already transferred all proposals I saw here and invited all co-authors and reviewers as collaborators in the repo, let me know if I missed anything!

I plan to tweet the link in a few days, so we get wider input from the community, but I'd like to solicit proposals and votes from contributors first.

[obto]

Hey @LeaVerou, just wanted to check in:

1. Looks like things are moving along pretty smoothly. Is there anything you need from me to keep things moving forward, and have the chapter outline and metrics settled on by the end of the week?
2. Can you remind your team to properly add and credit themselves in your chapter's Google Doc?

[LeaVerou]

@obto Well, we still don't have any analysts, so if you could help with that, that would be lovely!

Team (@LeaVerou @svgeesus @rachelandrew @estelle @fantasai @mirisuzanne @j9t @catalinred @hankchizljaw), please credit yourselves in the draft doc and request access if you don't have it!

[LeaVerou]

Hey team @svgeesus @rachelandrew @estelle @fantasai @mirisuzanne @j9t @catalinred @hankchizljaw,

Since we need to have decided on which stats we are studying by the end of this week, please post your suggestions as new issues in the repo: https://github.com/LeaVerou/css-almanac/issues as soon as possible so we have a few days for voting and wider community feedback.

[obto]

@LeaVerou Lot of awesome discussion going on here :tada: , but the Chapter doc could use some love. Think your team will be able to get an outline settled on by the end of the week?

[LeaVerou]

@obto I will try, though it's looking a little tight.

I've just posted on Twitter to solicit wider community feedback, so if anyone here is going to post more proposals, now would be the time to get them in, so they can get some votes.

[svgeesus]

@rachelandrew did you have any topics to add?

[obto]

@LeaVerou No worries. The main reason we have this week set as the deadline is because sometimes we come across metrics that require custom code (custom metrics) to be written and added to the Web Crawler -- which starts running on August 1st.

So if getting the chapter outline looks tough to complete... putting together a list of new metrics we didnt look at last year, that you're considering looking at this year, would be a big help.

[obto]

Fortunately @rviscomi implemented a script to parse all sites' CSS last year. Which should allow this chapter to do query almost everything already :)

[LeaVerou]

@obto I have posted the list a couple comments above :)
You can find it here: https://github.com/LeaVerou/css-almanac/issues

I can write a list of those that may require custom code later today, but I need to know the details of this parser that @rviscomi used. How does it handle invalid properties/pseudo-classes/values? Does it still parse them, or is it equivalent to using document.styleSheets and friends in a browser? If it's the latter, which browser is it like?
Also, what happens with JS? Some of the metrics we're considering would require looking into JS and correlating it with the CSS (Houdini, custom properties).

[rviscomi]

@LeaVerou the parser is https://github.com/reworkcss/css. It should parse everything, including invalid values. For example, see some of the fun invalid font-weight values explored in this post: https://discuss.httparchive.org/t/what-are-the-most-and-least-popular-numeric-font-weight-values/1732

[rviscomi]

Adding myself as an analyst to help this chapter out.

@HTTPArchive/analysts is anyone else available to share the analysis for this chapter?

[dooman87]

@rviscomi I'd like to help out. This is my first year, so I would need a bit of guidance. I got BigQuery part, but still learning what other things analysts do :)

[rviscomi]

Great thanks @dooman87! Can you request access to the doc so we can help triage metrics as they get planned?

[LeaVerou]

It just occurred to me that we could get HUGE insight about what CSS authors need by analyzing Sass stylesheets! We can find URLs to Sass files from the CSS files that have sourcemaps and there is a JS-based Sass parser. This will give us insight not just into the current state of CSS, but perhaps more importantly, its future.

@HTTPArchive/analysts @obto @rviscomi is this possible?

In other news, I've been looking into Rework CSS to see what kind of information its AST gives us. For anyone else who wants to experiment, I've made an online playground here.
You can also use it as a template.
It appears like it's doing rather loose parsing, which is good on one hand because it does not need to be constantly updated for new syntax, but only for major grammar changes, so it parses a very wide range of CSS. On the other hand, it means a lot of analysis would still need to be done via regexes on the JSON.

I would also be willing to help out with the analysis, but I'm not sure yet if I can commit properly to being one of the analysts, I'm reading the guide etc and will know soon.

[rviscomi]

It just occurred to me that we could get HUGE insight about what CSS authors need by analyzing Sass stylesheets!

We're limited to whatever resources are served over the network during the page load. IIUC sourcemaps only point to the source stylesheets, but they're not actually served with the page, so we wouldn't have the sources in the dataset :(

I would also be willing to help out with the analysis, but I'm not sure yet if I can commit properly to being one of the analysts, I'm reading the guide etc and will know soon.

Great, the team would be happy to have you! Let @paulcalvano or me know when you decide and if you need any help getting started.

In other news, I've been looking into Rework CSS to see what kind of information its AST gives us. For anyone else who wants to experiment, I've made an online playground here.

The Rework playground is a great idea. Could you also test it against the version used in the 2019 queries? I modified it a bit for efficiency, so I plan to reuse that unless there are any major changes we're missing.

[LeaVerou]

We're limited to whatever resources are served over the network during the page load. IIUC sourcemaps only point to the source stylesheets, but they're not actually served with the page, so we wouldn't have the sources in the dataset :(

I reached out to @obto over email, as I was keen to get a response asap, due to the tight timeline, and he said it may be possible:

The difficulties in pulling something like that off, is the Crawler only saves the response bodies of the URLs that the browser fetches. So we'd need to write a script to run after the page loads and fetch it, which is something the SEO chapter was talking about since they want to analyze the robots.txt file. I'm not sure how that proposal has been progressing but I'll check it out and get back to you

Is there a document detailing how the crawler works? E.g. if it can run dev tools, then sourcemaps would be fetched.

The Rework playground is a great idea. Could you also test it against the version used in the 2019 queries? I modified it a bit for efficiency, so I plan to reuse that unless there are any major changes we're missing.

Sure, here you go: https://codepen.io/leaverou/pen/PoZVeeE
And to use as a template: https://codepen.io/pen/?template=PoZVeeE
I can check if there are any major changes, do you know which commit yours was forked from?

[rviscomi]

Is there a document detailing how the crawler works? E.g. if it can run dev tools, then sourcemaps would be fetched.

https://almanac.httparchive.org/en/2019/methodology#tools is the best doc we have on the crawl tech. At its core, it's powered by WebPageTest. As of now I haven't found a reliable way to instrument it for HTTP Archive to load arbitrary resources in a way that doesn't interfere with the site's loading performance. cc @pmeenan

I can check if there are any major changes, do you know which commit yours was forked from?

Thanks! Looking at https://github.com/reworkcss/css/tags it seems like 3.0 was released a few weeks ago and the most recent release prior to that was 2.2.4 in 2018. Also parse/index.js doesn't actually seem to have been changed since 2015?? So maybe nothing changed?

[LeaVerou]

Alright, an initial chapter outline has been updated in the doc and on Github, though we are still iterating.
I did include Sass for now, since feasibility is evaluated later, and hope dies last. 😁

[LeaVerou]

I would also be willing to help out with the analysis, but I'm not sure yet if I can commit properly to being one of the analysts, I'm reading the guide etc and will know soon.

After a lot of back and forth with myself (I'm very interested, but worried about committing to doing yet another thing), I think I want to try, if it's not too late. What's the process to add myself @rviscomi?

[rviscomi]

Not too late at all! This chapter is shaping up to be very data-heavy (in the best possible way) so having more analysts on the team will be a big help. The process is:

1. Edit https://github.com/HTTPArchive/almanac.httparchive.org/issues/898#issue-646592132 to add yourself to the Analysts column
2. Submit a PR to add yourself to the analysts team in src/config/2020.json
3. Review the Analysts' Guide and let me or @paulcalvano know if you have any questions

[LeaVerou]

@rviscomi Done!

[obto]

@LeaVerou @dooman87 @rviscomi for the two milestones overdue on July 27 could you check the boxes if:

• the outline has been reviewed and all feasible metrics have been identified
• any necessary custom metrics have been created and you've created a draft PR to track which feasible metrics have had their queries implemented (we've updated the milestone description to clarify this)

Keeping the milestone checklist up to date helps us to see at a glance how all of the chapters are progressing. Thanks for helping us to stay on schedule!

[rviscomi]

I've updated the chapter metadata at the top of this issue to link to the public spreadsheet that will be used for this chapter's query results. The sheet serves 3 purposes:

1. Enable authors/reviewers to analyze the results for each metric without running the queries themselves
2. Generate data visualizations to be embedded in the chapter
3. Serve as a public audit trail of this chapter's data collection/analysis, linked from the chapter footer

[LeaVerou]

Hey editors & reviewers (@svgeesus @rachelandrew @estelle @fantasai @mirisuzanne @j9t @catalinred @hankchizljaw)!
Since the bulk of the analysis will be JS on the Rework AST, @rviscomi and I were wondering if any of you would be willing to help with the JS? We have over 40 stats to calculate and only 2.5 analysts.

[svgeesus]

I came across a comment in an old CSS Color 4 issue where I wondered aloud whether there was Web-compat risk on out of range sRGB values. I suspect not, but it would be nice to have data on whether sRGB values outside the range [0-255] or [0%-100%] are in actual use.

In practice browsers will either do per-component clip on these or treat them as invalid. The spec was only changed to require per-component clipping in 2016.

If it is easy to look for those out of range values in the wild,it would be a nice to have.

[LeaVerou]

@rviscomi Just spotted a bug with our Rework parser: It seems to parse @import statements incorrectly when the URL contains a colon. E.g. try this:

@import url('https://fonts.googleapis.com/css2?family=Playfair+Display:ital,wght@0,400..900;1,400..900&display=swap');
@import url('https://fonts.googleapis.com/css2?family=Public+Sans:[email protected]&display=swap');

foo {
}

I get:

{
    "type": "stylesheet",
    "stylesheet": {
        "rules": [
            {
                "type": "import",
                "import": "url('https://fonts.googleapis.com/css2?family=Playfair+Display:ital,wght@0,400..900"
            },
            {
                "type": "rule",
                "selectors": [
                    "1,400..900&display=swap'); @import url('https://fonts.googleapis.com/css2?family=Public+Sans:[email protected]&display=swap'); foo"
                ],
                "declarations": []
            }
        ],
        "parsingErrors": []
    }
}

[rviscomi]

Good catch! If you know of a fix, please patch css-parser.js. We can regenerate the parsed_css table if needed but I'd imagine the impact is small.

[svgeesus]

Since the bulk of the analysis will be JS on the Rework AST, @rviscomi and I were wondering if any of you would be willing to help with the JS?

I just sent a PR for JS to see if P3 colors out outside the sRGB gamut

[Tiggerito]

Hi CSS team. Tony here from the SEO team.

I've had a request to create a report in css media usage. Basically as a way to see if a design is responsive or not. Any chance on a pointer in the right direction on how to pull out that info?

Cheers.

[LeaVerou]

@Tiggerito I suppose your best bet is to check if there are any dimension media queries (with width, height, or aspect ratio). The JS here may be a good starting point (you could use the same JS and just filter the list to the features you're interested in), however there is no SQL for that yet. @rviscomi perhaps we could prioritize the SQL for that query so that @Tiggerito can base his off that?

[rviscomi]

Sure, I'm behind on queries for this chapter but I can prioritize this one first. Lea, I just noticed this JS also includes the incompatible ?. syntax that we've had to remove from other queries. Would you be able to rewrite this one slightly to make it work in BigQuery? It would be great to also do a sweep of the JS to make sure it's not hiding anywhere else.

[LeaVerou]

Whoops, I thought I had sweeped already, this one must have been under the carpet 😄
I just did a more thorough sweep and removed it from there and one other query.

[rviscomi]

@Tiggerito @LeaVerou I've added results for a media query feature query to the sheet. It suggest that ~79% of pages have responsiveness built in. We don't necessarily know if the whole page is responsive or just some part of it. Note that this is only based on max-width adoption but a design could also be responsive with min-width.

[LeaVerou]

@rviscomi Also in theory max-height and min-height, though that's more rare and typically not used in isolation. Since we don't know the intersection or union of these, we'd need a separate query to determine how many websites might be "responsive", that calculates the union of *-width, *-height, and *-aspect-ratio features.

[bazzadp]

I’d also argue that an HTML page is by default responsive - even without any media queries! 😀 It’s only when we add CSS with expectations that we stop it being responsive!

[rviscomi]

@LeaVerou added another query/sheet to count pages with any height/width/aspect-ratio feature.

[Tiggerito]

Cheers for all that. @aleyda hopefully that covers what you need.

[aleyda]

Thanks @Tiggerito and @rviscomi! This is great :D

[LeaVerou]

@rachelandrew All the layout queries are done and the results are in the spreadsheet could you please review as soon as you can and let us know if anything looks off?

[rachelandrew]

@LeaVerou this looks great, and really interesting.

[LeaVerou]

@rachelandrew Cool, if everything looks ok you could start the draft of your section in the doc whenever you want!
I'm still working on the queries, but will start my sections soon after.

@svgeesus I'm still working on fixing a few potential issues with the color results, but you could take a look at the spreadsheet too.

[rachelandrew]

@LeaVerou ok, so looking at the schedule, we've only got a few days until this is supposed to be complete which I'm not going to make. What's a realistic deadline for the layout stuff?

[LeaVerou]

I wouldn't be able to make that either. I'd bet money that @svgeesus can't make it either, given TPAC and ICC all meeting this week.

Indeed, according to the target schedule we're quite significantly behind, but looking at the chapter progress summary, it looks like we're not alone 😅

What would be a realistic deadline for you?

[rviscomi]

@rachelandrew @LeaVerou @svgeesus we'll be announcing a project timeline change soon that will effectively add a month to all of the milestones, given the unexpected delays many chapters are facing with the analysis phase. That would put the new first draft milestone at November 12. Is that feasible?

[LeaVerou]

Yay!! Absolutely feasible for me!

[rachelandrew]

Yep that sounds reasonable - thanks!

[svgeesus]

Is that feasible?
Yeah, that works for me!

[svgeesus]

but

(confused)

[svgeesus]

mobile | indianred | 7,139 | 98,027,821 | 0.01%

Okay, so calls to get rid of indianred (and navahowhite and mocossain) now have some usage data

[rviscomi]

(confused)

The top one is in terms of incidence on pages and the bottom in terms of frequency of use. Each sheet also comes with a comment with the correct interpretation of the results.

If you have any other data questions feel free to leave a comment in the sheet. I subscribe to all comments, so no need to @ me. That may scale better as you review all the data :)

[svgeesus]

A nice quote from Ars Technica “Tomato” versus “#FF6347”—the tragicomic history of CSS color names:

“I view it with amusement that the colors seem to have migrated into CSS. I just laugh at it,” Fulton told Ars. “I think if someone were to go and crawl over the top 100 or top 1,000 sites and take a look at how various colors are specified, I’m willing to bet you’d still find close to zero percent using color names beyond ‘white’ or ‘black.’”

Looks like that bet can be resolved.

[obto]

@LeaVerou in case you missed it, we've adjusted the milestones to push the launch date back from November 9 to December 9. This gives all chapters exactly 7 weeks from now to wrap up the analysis, write a draft, get it reviewed, and submit it for publication. So the next milestone will be to complete the first draft by November 12.

However if you're still on schedule to be done by the original November 9 launch date we want you to know that this change doesn't mean your hard work was wasted, and that you'll get the privilege of being part of our "Early Access" launch.

Please see the link above for more info and reach out to @rviscomi or me if you have any questions or concerns about the timeline. We hope this change gives you a bit more breathing room to finish the chapter comfortably and we're excited to see it go live!

[svgeesus]

So 2.8% of pages use named colors which is lower than I would have expected, and only 0.3% use the deprecated, then partly undeprecated system colors

And the most common system color is Background, which is deprecated and represents the desktop background color.

[LeaVerou]

@svgeesus I believe that is 2.8% of colors are named color, not 2.8% of pages use named colors.

And the most common system color is Background, which is deprecated and represents the desktop background color.

That is a mistake of the query which has been fixed. @rviscomi ?

[rviscomi]

I believe that is 2.8% of colors are named color, not 2.8% of pages use named colors.

Yes, also each sheet should also have a comment with the intended interpretation.

That is a mistake of the query which has been fixed. @rviscomi ?

The query did need to be rerun but the results have only changed very slightly. Background on desktop is still used 2.3% of the time.

---

Also FYI for all authors and reviewers, the sheet has been updated with the results of all 103 (!!) queries for this chapter. Please review the results and let me know if you see anything unexpected. It's easiest for me if you leave a comment in the sheet so I can track everything in the context of the metric/results. You may need to request edit access to be able to comment.

[LeaVerou]

Since we have 6 (!) times as many metrics as the average chapter, and one of the authors has pulled out, I was wondering if any of the reviewers (@fantasai @mirisuzanne @j9t @catalinred @hankchizljaw) were interested in authoring a section or two?

Sections that are up for grabs are: Selectors, Values & Units, Transitions & Animations, Responsive Design (though @rachelandrew may have dibs on that), Browser Support

[j9t]

were interested in authoring a section

I’d love to but I’ve been using up my spare capacity on Markup/HTML. (Count me in for review though, that’s not affected.)

[LeaVerou]

Hi reviewers @fantasai @mirisuzanne @j9t @catalinred @hankchizljaw !

Since we are only 16 days from launch, it may be a good idea to start iterating earlier, rather than later.
There are many sections whose draft is at a stage it could benefit from some review, namely those whose title does not include "[TBD]" or "[WIP]". Visualizations have not been added yet, though there are placeholders for them. A few numbers are also missing, those are noted in the prose with ??%, and in the title with [missing numbers].

Feel free to edit directly if you are reasonably certain about a correction (e.g. typos, grammar mistakes etc), or add comments for more substantive changes.

[j9t]

Hi @LeaVerou—this is probably very present for you, but which documents are you referring to? Is there an overview? (I can’t spot any pointers scanning this thread.)

[svgeesus]

Hi @j9t this document which is linked from the first post in this issue

[j9t]

Leaving some feedback here that I couldn’t quite leave in the doc. This was a first scan, I’m on standby to help where I can.

• General feedback: This is already great! You’ve collected a huge wealth of information and the doc will make more for a meaningful snapshot of where we are with CSS in 2020. I think everyone interested in CSS can and should look forward to this chapter.

• Structure: On reading I found the impact of the different sections to be a bit “volatile”—maybe it’s already on your radar, perhaps on the editors’, however revisiting the order of the sections could make it easier to work with.

• Style (up to the editors, but this one stood out): The chapter uses _many_ exclamation marks (47 on searching) 😅

• Contents, side note: I hope I raised this in the very beginning—do you plan to look into CSS DRYness (ratio unique/total declarations)? Though convinced in the value of looking at this, I’m mostly curious. I understand the chapter to be quite comprehensive already.

• Reviewing: Many missing numbers as well as lack of graphics currently makes reviewing very difficult—to summon all reviewers it may be helpful to get this all into place, or to ask for very specific reviews to use us reviewers effectively.

[rachelandrew]

I just added an initial draft of layout.

Is someone doing a copy edit of this? I know we have tech editors/reviewers.

[bazzadp]

Yes there will be a copy edit once Authors and Reviewers are finish and have converted to Markdown and committed it to Git - see #1432 .

The expectation, however, is that the Authors and Reviewers have it in a state they'd be happy to publish, to help ease that load on editing and then copy editing is to get a consistent style across the chapters and have an independent pairs of eyes on it from a readability perspective, outside of the main content team for that chapter. Still the editing process can take a fair bit of time as we ask Authors to review all the edits to make sure they are happy with the suggested changes and we haven't introduced any inaccuracies. More details of the process and what we typically look for in the Editor's Guide.

But that's ahead of us. Let's get the draft in a state you all are happy with, and then convert to Markdown, and then we can look at editing.

Btw if we have any professional editors then we'll gladly accept any more help in the editing team for other chapters 😉

[LeaVerou]

• General feedback: This is already great! You’ve collected a huge wealth of information and the doc will make more for a meaningful snapshot of where we are with CSS in 2020. I think everyone interested in CSS can and should look forward to this chapter.

Thank you!

• Structure: On reading I found the impact of the different sections to be a bit “volatile”—maybe it’s already on your radar, perhaps on the editors’, however revisiting the order of the sections could make it easier to work with.

Could you elaborate? Is there a different order you'd recommend?

• Style (up to the editors, but this one stood out): The chapter uses _many_ exclamation marks (47 on searching) 😅

I do like my exclamation marks 😛 But feel free to remove any obviously superfluous ones (or use the "suggest edits" feature if you’re not comfortable directly removing)

• Contents, side note: I hope I raised this in the very beginning—do you plan to look into CSS DRYness (ratio unique/total declarations)? Though convinced in the value of looking at this, I’m mostly curious. I understand the chapter to be quite comprehensive already.

It's a little late to add additional metrics, the call for metrics was in July... However I'm intrigued by this and I think it could be an interesting metric. I could try to sneak it in at the last moment, but I'll need your help. Could you please open an issue here and elaborate a little on the algorithm you envision (is it just number of unique declarations? What kind of normalization would we do?), how you'd interpret the data, and what kind of visualizations would be helpful. I can't promise anything, but I'll try.

I assume you're criticizing this repetition when it comes to CSS as an output target, since when authoring DRY is not the begin all and end all, but repetition can aid understandability.

• Reviewing: Many missing numbers as well as lack of graphics currently makes reviewing very difficult—to summon all reviewers it may be helpful to get this all into place, or to ask for very specific reviews to use us reviewers effectively.

Oh ok. In most of my experience writing and reviewing, most figures tended to come after review, and existed solely as placeholders during the review stage. However, if reviewers feel it's best to wait until visualizations are in place and the document is in better shape, that's fine too. In general though, the more fleshed out a draft is, the harder it is to iterate and make drastic changes (not just in writing; e.g. in usability initial user studies and iterations are often done on paper prototypes).

[j9t]

I filed https://github.com/LeaVerou/css-almanac/issues/54 for declaration repetition.

On the other items I’ll either follow up in the doc or wait for additional calls for review to check again.

[LeaVerou]

Hi everyone,

I figured I'd post a progress update. At this point, we have most of the visualizations and missing numbers in place, and the draft is in much better shape. These are the things that still need to be done, please let me know if I'm forgetting anything:

• [ ] Introduction & conclusion (@leaverou though input from everyone is more than welcome!)
• [ ] Responsive Web Design section (@rachelandrew)
• [ ] Finishing Internationalization (@svgeesus)
• [ ] Missing number: "Almost every SCSS sheet (??%) uses at least one explicitly nested selector" (@rviscomi or @leaverou)
• [ ] A few visualizations and comments to address here and there
• [ ] Figure captions for figures whose caption is not identical to the chart title
• [ ] If there’s time: Stats & paragraph for declaration repetition (@j9t, @leaverou)

8 days left until launch!

[rachelandrew]

I'll finish the RWD section tomorrow, sorry for the delay. I'd offered to do it then assumed someone else was, however I'll get it done.