Almanac.httparchive.org: Finalize assignments: Chapter 2. CSS

[rviscomi]

Section | Chapter | Coauthors | Reviewers
-- | -- | -- | --
I. Page Content | 2. CSS | @una @argyleink | @meyerweb @huijing

Due date: To help us stay on schedule, please complete the action items in this issue by June 3.

To do:

• [x] Assign subject matter experts (coauthors)
• [x] Assign peer reviewers
• [x] Finalize metrics

Current list of metrics:

Section | Metric description
-- | --
Usage of popular/new APIs | Custom properties
Usage of popular/new APIs | @import @supports
Usage of popular/new APIs | Filters
Usage of popular/new APIs | Blend modes
Usage of popular/new APIs | Logical properties
Usage of Unit Types | Hsl vs hsla vs. rgb vs rgba vs. hex
Usage of Unit Types | rem vs em vs px vs ex vs cm etc.
Usage of Unit Types | classes vs ids
CSS Tooling Today | Top CSS development tools
Usage of Popular CSS Libraries | Top CSS libraries
Resets | Top reset utilities
Layout | RTL vs. LTR
Layout | Flexbox
Layout | Grid
Media Queries | Most Popular Snap Points
Media Queries | max vs. min-width
Media Queries | Ems vs rems vs px in media queries
Media Queries | How many people using print style media queries
Size of style payload | number of stylesheets per page
Size of style payload | Most popular names for stylesheets
Size of style payload | Minified vs unminified
Size of style payload | # of fonts downloaded
Size of style payload | Types of fonts downloaded
Size of style payload | Average size of CSS load per site
Size of style payload | Average size of images loaded by stylesheets (inline and linked)
Individual files vs bundled files | Came with the HTML
Individual files vs bundled files | Inserted post page load
Individual files vs bundled files | Async v sync
Individual files vs bundled files | Constructible stylesheets
Individual files vs bundled files | Inline Styles vs. one stylesheet link
Duplication / Etc | Shorthand vs. longhand properties
Duplication / Etc | Number of colors declared per site
Duplication / Etc | Number of duplicate colors per those sites
Duplication / Etc | Number of fonts declared per site
Duplication / Etc | Number of duplicate font family declarations
Duplication / Etc | Number different font size values per site
Duplication / Etc | Number of z-indices per site
Duplication / Etc | Most popular z index values (chart)
Duplication / Etc | Number of different media query values per site
Duplication / Etc | Number of different margins per site
Duplication / Etc | Number of transitions used per site
Duplication / Etc | Number of @keyframes declared per site
Duplication / Etc | Number of [id="foo"]
Duplication / Etc | Number of [class*='foo']``[class^='foo'] [class$='foo'] [class~='foo']
Duplication / Etc | Number of classes per element
Duplication / Etc | Average Length of classes

👉AI (coauthors): Assign peer reviewers. These are trusted experts who can support you when brainstorming metrics, interpreting results, and writing the report. Ideally this chapter will have 2 or more reviewers who can promote a diversity of perspectives.

The metrics should paint a holistic, data-driven picture of the CSS landscape. The HTTP Archive does have its limitations and blind spots, so if there are metrics out of scope it's still good to identify them now during the brainstorming phase. We can make a note of them in the final report so readers understand why they're not discussed and the HTTP Archive team can make an effort to improve our telemetry for next year's Almanac.

Next steps: Over the next couple of months analysts will write the queries and generate the results, then hand everything off to you to write up your interpretation of the data.

Additional resources:

• All chapter assignments
• Project timeline
• About the project

[rviscomi]

@jensimmons would you be interested in peer reviewing this chapter?

@una @argyleink can you think of anyone else who might be interested?

[una]

@argyleink and I updated the brainstorming doc with some metrics ideas. Please comment and let us know what's feasible!

(Also, would love to have you as a reviewer Jen!)

[jensimmons]

I'm sorry, what is this? I'm not familiar with this project.

On Thu, May 23, 2019, at 4:39 PM, Rick Viscomi wrote:

@jensimmons https://github.com/jensimmons would you be interested in peer reviewing this chapter?

@una https://github.com/una @argyleink https://github.com/argyleink can you think of anyone else who might be interested?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/HTTPArchive/almanac.httparchive.org/issues/4?email_source=notifications&email_token=AAA2POUYQCB2V3J7KJLMPODPW36HLA5CNFSM4HOOKXUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWDNQQI#issuecomment-495376449, or mute the thread https://github.com/notifications/unsubscribe-auth/AAA2POQJ7KTTXYA33JNUWNTPW36HLANCNFSM4HOOKXUA.

[rviscomi]

👋 Hey Jen! We're making a kind of ebook on the state of the web. There are 20 chapters spanning different areas of the web, written and reviewed by subject matter experts from the community. The goal is to release it annually with updated stats. You can learn more about it here and here.

[rviscomi]

@SaraSoueidan any interest in reviewing a post on the state of CSS? More info on the reviewer role here.

Also, @jensimmons let us know if you're interested or have any other questions.

Your consideration is much appreciated!

[rviscomi]

@una @argyleink any luck finding reviewers on your end?

[rviscomi]

FYI we're hoping to have the metrics and reviewers finalized today.

The median chapter has 9 metrics. This chapter has 40 metrics, which is awesome 🤘but I'm worried that it would be too much to write about.

For reference, each metric would probably translate to 1-2 paragraphs in the written report. If that sounds like more writing than you can handle, I'd suggest either trimming off any lower priority metrics or seeking an additional coauthor to help with the writing.

Take a closer look at the list of metrics and if there's anything you think can be removed, please update the list.

I also hate to nag but this is the only chapter without reviewers and since it's so comprehensive that's all the more reason to have a dugout full of reviewers ready to go.

Once both the metrics and reviewers are squared away, please check them off the TODO list and close this issue. Thanks!

[rviscomi]

Since the metrics LGTM, let's check this chapter on through to the analysis phase and we can worry about getting reviewers by the time you all write the content. Feel free to reopen if you disagree.

[una]

• @meyerweb as a peer reviewer

[rviscomi]

\o/ awesome thanks @una!

And thanks @meyerweb for joining the project! I've sent you an invite to the Reviewers team. All we need from you when you get the chance is to familiarize yourself with the project and review the list of metrics for this chapter. We're hoping to capture the state of CSS. Is there anything else we should be looking at?

[rviscomi]

On Twitter @huijing also volunteered to review this chapter 🎉

@huijing @meyerweb when you both get a chance, please to go https://github.com/HTTPArchive to accept your invitations to the Reviewers team. Then please review the metrics in the top comment and let us know if there's anything you'd add or change. Thanks for helping us stay on schedule!

[meyerweb]

Proposed metric: use of @supports (feature queries) and the most popular properties that are queried.

Proposed metric: number and total size of images (GIF JPG PNG SVG WEBP any others?) loaded by style sheets. Could try to narrow down background images versus other types, but that seems less interesting (I expect 95%+ will be background images).

In Hsl vs. rgb vs. hex as well as the color duplication metrics, make sure to check for four- and eight-digit hex values, which are valid and have a decent amount of support.

For classes vs ids I’d add attribute selectors as well. Authors sometimes use things like [id="foo"] to select IDs without raising specificity.

Relatedly, it’d be nice to have a metric on which attribute selector patterns get used, and how frequently.

Also relatedly, it’d be interesting to see a distribution of the number of classes per selector. I’ve been viewing source recently and boy howdy, do some people like to create long trains of class names.

I’d love to see counts (or averages) of which CSS properties are used. E.g., I assume padding and margin are in the top ten, but where would (say) background-size fall on the long tail?

[argyleink]

superb additions @meyerweb, thanks!

@supports and the queried within, love it

number and size of images loaded by stylesheets, nice! i'd even like to know # and size of base64 encoded inline images/svg are put into stylesheets as well, whether as background images or content.

good call on ensuring we're checking rgba, hsla and hex with alpha 👍

ooo, so you're curious about usage of attribute selectors that target id's, that's interesting yep, nice addition

i'm also interested in which attribute selectors are used and how many times per stylesheet. great addition

i like this class name breakdown for a few reasons and would like to offer a suggestion as well. so first, yes, let's see the # of classes per selector, that sounds interesting. i'd also like to know the length of classnames on average. curious if the average in a stylesheet is like 10+ characters. scenarios with BEM are very likely to have a long average. sidenote: i wonder if we should have a query that evaluates specificity of each selector and creates some metrics about average selector strength?

last one, looks like 1 big sorted list of css prop usage? sounds like a great job for a computer lol. i bet there's some interesting nuggets in there though if we made that list. might be super overwhelming too? i'm interested in it though, good idea.

[rviscomi]

If for example a page includes Bootstrap, do we care about including its count of things like padding/margin styles? Or is the ideal approach only to count first party CSS? We could use @patrickhulce's approach to detecting third parties in #8, but not sure if that's a reliable signal for this particular use case. Any other thoughts?

[patrickhulce]

Hm, yeah our third party detection probably isn't the best for library detection. You'd be able to detect bootstrap coming directly from the bootstrap CDN, but that's about it. Some sort of CSS bundle analysis is probably needed there (maybe a bootstrap license regex?)

[huijing]

For layout, LTR vs RTL is not specifically a CSS thing, but can I propose looking at writing-mode for vertical layout instead? Related to direction on the web, would Logical Properties fall under new API?
From the specification:

If a document language provides markup features to control bidi, authors and users should use those features instead and not specify CSS rules to override them.

Also, wrt @meyerweb's last point, I also agree it would be interesting to see these. There are so many properties like CSS shapes, clip-path, box alignment just to name a few that would be interesting to see metrics for.

[meyerweb]

For layout, LTR vs RTL is not specifically a CSS thing, but can I propose looking at writing-mode for vertical layout instead? Related to direction on the web, would Logical Properties fall under new API?

@huijing raises a good point, that LTR/RTL is as much about HTML as CSS. (In fact, the specification strongly encourages authors to put writing direction in markup, and not rely solely on CSS.) If we’re going to look for RTL/LTR in CSS, it should _also_ be looked for in HTML, and maybe the two results should be combined/compared.

[meyerweb]

last one, looks like 1 big sorted list of css prop usage? sounds like a great job for a computer lol. i bet there's some interesting nuggets in there though if we made that list. might be super overwhelming too?

@argyleink—yes, I see it as a Humongous Long List (so maybe an Appendix?). As @huijing says, there are a lot of up-and-coming properties that won’t be anywhere near the top 10 (or even top 50), but it would still be interesting to see usage information about them.

[bkardell]

@meyerweb getting at elements and attributes was previously done via some regexp querying but this is problematic for a number of reasons, not the least of which is that the datasets have grown truly gigantic, and ultimately the source of Truth you want is from the parser anyways, so this year we added some custom instrumentation for that re elements (including abilities to track custom element use and author provided shadow dom use)..

Unfortunately we decided to not capture all attribute data this year because there were worries about blowing up even more data, so I'm thinking this would be hard to come by this time around probably

[rviscomi]

I'd recommend listing the attribute metrics anyway and the @HTTPArchive/data-analysts team can determine whether it's feasible. I spoke with @pmeenan recently about how much we can push the custom metrics and it sounds like they're fairly tolerant of crunching lots of data, as long as the runtime costs aren't exponential or worse. (Pat is that accurate?)

[pmeenan]

Yep, should be able to suck up quite a bit of extra work there since it is
done on every agent at test time and not centrally.

On Wed, Jun 12, 2019 at 12:14 PM Rick Viscomi [e-mail]
wrote:

I'd recommend listing the attribute metrics anyway and the
@HTTPArchive/data-analysts
https://github.com/orgs/HTTPArchive/teams/data-analysts team can
determine whether it's feasible. I spoke with @pmeenan
https://github.com/pmeenan recently about how much we can push the
custom metrics and it sounds like they're fairly tolerant of crunching lots
of data, as long as the runtime costs aren't exponential or worse. (Pat is
that accurate?)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/HTTPArchive/almanac.httparchive.org/issues/4?email_source=notifications&email_token=AADMOBPZTHVNATZYGDE3YELP2FDIPA5CNFSM4HOOKXUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXRQM7I#issuecomment-501417597,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADMOBOPLYOOIUO6Y3V6L73P2FDIPANCNFSM4HOOKXUA
.

[bkardell]

What do we need to know about the attributes/elements/values connections - need to be kind of careful to capture the right values but not wind up with just a json object representation of HTML. Is it specifically just that we want a count of elements containing dir with any value? Is that enough of a hint? Otherwise we'd need to pick specific attributes/values I think or this will be very unweildy

[argyleink]

regarding interesting properties @meyerweb && @huijing , if you want to just see one at a time, this is a super fun place to see them! https://chromestatus.com/metrics/css/timeline/popularity/355 (clip-path chosen here as an example)

regarding LTR and RTL, which if i'm following properly is the topic regarding attributes/elements, sounds like we need to define some tight rules to get the data, which means we might muddy the results because our tight rules werent encompassing enough? and not being encompassing enough was the reason we wanted to cross reference html with css? rock and a hard place it sounds like... perhaps since this is a state of CSS, we let the HTML side of text direction slide? i'd rather we include it, but i want to try and avoid getting into the weeds.

logical properties is a great idea @huijing, since it's new it'll be a fun one to watch over the next few years as our fingers get used to tapping them instead of the non-writing mode equivalents. the hope would be we see padding/margin drop as logical props rise yeah?

[rviscomi]

@argyleink would you mind updating the top comment with any metrics discussed since this issue was last closed? once that's done we can close it _once and for all_ ™️.

[argyleink]

i think i got em but would love a double check 👍

[rviscomi]

FYI https://2019.stateofcss.com/

Similar research project into the state of CSS, the biggest difference being that one is a survey of developers while this is a survey of websites. Might be interesting to see if any of those results help inform some of the trends we see in HTTP Archive, if so feel free to cite that project in your chapter as needed.