Finalize assignments: Chapter 2. CSS #4
Comments
rviscomi
changed the title
|
@jensimmons would you be interested in peer reviewing this chapter? @una @argyleink can you think of anyone else who might be interested? |
|
@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!) |
|
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 <#4?email_source=notifications&email_token=AAA2POUYQCB2V3J7KJLMPODPW36HLA5CNFSM4HOOKXUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWDNQQI#issuecomment-495376449>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAA2POQJ7KTTXYA33JNUWNTPW36HLANCNFSM4HOOKXUA>.
|
|
@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! |
|
@una @argyleink any luck finding reviewers on your end? |
|
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! |
|
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. |
|
|
\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? |
|
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! |
|
Proposed metric: use of 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 For 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 |
|
superb additions @meyerweb, thanks!
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. |
|
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? |
|
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?) |
|
For layout, LTR vs RTL is not specifically a CSS thing, but can I propose looking at
Also, wrt @meyerweb's last point, I also agree it would be interesting to see these. There are so many properties like CSS shapes, |
@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. |
@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. |
|
@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 |
|
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?) |
|
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 ***@***.***> 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
<#4?email_source=notifications&email_token=AADMOBPZTHVNATZYGDE3YELP2FDIPA5CNFSM4HOOKXUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXRQM7I#issuecomment-501417597>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADMOBOPLYOOIUO6Y3V6L73P2FDIPANCNFSM4HOOKXUA>
.
|
|
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 |
|
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? |
|
@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 ™️. |
|
i think i got em but would love a double check 👍 |
|
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. |
* start traduction * process trad * # This is a combination of 9 commits. # This is the 1st commit message: update # The commit message #2 will be skipped: # review # The commit message #3 will be skipped: # review #2 # The commit message #4 will be skipped: # advance # The commit message #5 will be skipped: # update # The commit message #6 will be skipped: # update translation # The commit message #7 will be skipped: # update # The commit message #8 will be skipped: # update # # update # The commit message #9 will be skipped: # update * First quick review (typofixes, translating alternatives) * Preserve original line numbers To facilitate the review of original text vs. translation side-by-side. Also: microtypo fixes. * Review => l338 * End of fine review * Adding @allemas to translators * Rename mise-en-cache to caching * final updates * update accessibility * merge line * Update src/content/fr/2019/caching.md Co-Authored-By: Barry Pollard <barry_pollard@hotmail.com> * Update src/content/fr/2019/caching.md If it's not too much effort, could you also fix this in the English version as part of this PR as looks wrong there: 6% of requests have a time to time (TTL) should be: 6% of requests have a Time to Live (TTL) Co-Authored-By: Barry Pollard <barry_pollard@hotmail.com> * Update src/content/fr/2019/caching.md Do we need to state that all the directives are English language terms or is that overkill? If so need to check this doesn't mess up the markdown->HTML script. Co-Authored-By: Barry Pollard <barry_pollard@hotmail.com> Co-authored-by: Boris SCHAPIRA <borisschapira@gmail.com> Co-authored-by: Barry Pollard <barry_pollard@hotmail.com>
* start traduction * process trad * # This is a combination of 9 commits. # This is the 1st commit message: update # The commit message #2 will be skipped: # review # The commit message #3 will be skipped: # review #2 # The commit message #4 will be skipped: # advance # The commit message #5 will be skipped: # update # The commit message #6 will be skipped: # update translation # The commit message #7 will be skipped: # update # The commit message #8 will be skipped: # update # # update # The commit message #9 will be skipped: # update * First quick review (typofixes, translating alternatives) * Preserve original line numbers To facilitate the review of original text vs. translation side-by-side. Also: microtypo fixes. * Review => l338 * End of fine review * Adding @allemas to translators * Rename mise-en-cache to caching * final updates * update accessibility * merge line * Update src/content/fr/2019/caching.md Co-Authored-By: Barry Pollard <barry_pollard@hotmail.com> * Update src/content/fr/2019/caching.md If it's not too much effort, could you also fix this in the English version as part of this PR as looks wrong there: 6% of requests have a time to time (TTL) should be: 6% of requests have a Time to Live (TTL) Co-Authored-By: Barry Pollard <barry_pollard@hotmail.com> * Update src/content/fr/2019/caching.md Do we need to state that all the directives are English language terms or is that overkill? If so need to check this doesn't mess up the markdown->HTML script. Co-Authored-By: Barry Pollard <barry_pollard@hotmail.com> * generate caching content in french * Update src/content/fr/2019/caching.md Co-Authored-By: Barry Pollard <barry_pollard@hotmail.com> * Update src/content/fr/2019/caching.md Co-Authored-By: Barry Pollard <barry_pollard@hotmail.com> Co-authored-by: Boris SCHAPIRA <borisschapira@gmail.com> Co-authored-by: Barry Pollard <barry_pollard@hotmail.com>
Due date: To help us stay on schedule, please complete the action items in this issue by June 3.
To do:
Current list of metrics:
@import@supports@keyframesdeclared per site[id="foo"][class*='foo']``[class^='foo'][class$='foo'][class~='foo']👉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:
The text was updated successfully, but these errors were encountered: