State of CSS 2021 - TPAC 2021 breakout

18 October 2021


Alan_Davalos, Atsushi, Ben_Tillyer, Brady_Duga, Bret_Little, Brian_Kardell, Bruce_Miller, dom, duga, Elika, Emmett_Miller, Eric_Meyer, Faraaz_M, foolip, Jean-Yves_Perrier, John_Riviello, Jonathan_Kew, Kazuhiro_Joya, Lea_Verou, Mason_Freed, MCF, Michael_Smith, Michal_Mocny, Phuc_Le, PLH, Rachel_Andrew, Ralph_Swick, Rob_Smith, Semesse, siri, Sophie_Yaniw, Weiwei_Zong, Wolfgang_Schindler
dom, fantasai

Meeting minutes

<foolip> Hi dom, will you be the staff contact for my session?

I will

<foolip> Neato!

<foolip> Should I present my own slides? I'm in the meeting now and tried screen sharing, but it says it's disabled by the host.

yes, I'll make sure you can present your own slides

<foolip> OK, I'll share the link here too before we start

if they're ready to share, maybe give me the link now and I'll add it to the session description?

I would also generate a PDF version for archival

<foolip> Alright: https://docs.google.com/presentation/d/1FIMa9TXTdGusG_oJBtMmQLSyOuF0xgHsrvn7CKZH7Yw/edit?usp=sharing&resourcekey=0-cFnhzvjncEEQaOB426PXnw

<foolip> But they're not done, so please no PDF yet :)

foolip, can I pdf-ize the slides now?

<foolip> dom: yes, let's call it done now :)

Slideset: https://lists.w3.org/Archives/Public/www-archive/2021Oct/att-0001/State_of_CSS_2021__TPAC_breakout_session.pdf

<foolip> What's the passcode?

<foolip> When I paste https://zoom.us/j/99461508942?pwd=a0ZTMDZzTjVSYm1GRHhtWUR1cUtLZz09 into my zoom.us app, it wants one

<foolip> I tried a0ZTMDZzTjVSYm1GRHhtWUR1cUtLZz09 and that worked, it looks kinda base64-encoded so I wasn't sure

foolip: we're going to look at state of css survey 2021 results
… I'm Philip, I work with the Chrome team and am involved in the survey this year

[ Slide 2 ]

foolip: Reminder we're operating under W3C CoC

[ Slide 3 ]

foolip: if you want to ask questions, please raise your hand in Zoom

[ Slide 4 ]

Foolip: the survey is open until the end of october at StateOfCSS.com
… Sacha Greif is the maintainer of that survey, 3rd year running
… ~4,400 responses so far
… the results are based on a snapshot of results
… Sarah Fossheim has also been helping out, with a focus on accessibility both on the survey tool & content

[ Slide 5 ]

Foolip: I don't want to influence the results in any way - we're using the results to set priorities for Chrome
… great if you're asking people to fill the survey
… but don't influence them based on what you'll hear today
… I won't share anything about rankings & percentages
… still hope this will be a worthwhile preview

[ Slide 6 ]

Foolip: Accessibility changes made this year

[ Slide 7 ]

Foolip: we added a new section on a11y in the survey
… and improved the accessibility of the survey tool itself - thanks to Sarah!
… In that section, we've asked e.g. "which accessibility features do you usually implement"
… incl alt text, aria attributes
… this included a more open ended question about "other accessibility features" in addition to the ones listed in the question

[ Slide 10 ]

Foolip: focus handling was mentioned several times

[ Slide 11 ]

Foolip: respecting font scaling - useful e.g. for low vision users; that takes special efforts
… not sure how this can get tested

[ Slide 12 ]

Foolip: one respondent suggested getting input from UX designers to order the DOM for screen reader flow

[ Slide 13 ]

Foolip: Missing features

[ Slide 14 ]

Foolip: a multi-select question asking what is currently missing from CSS, seeded by responses from last year

[ Slide 15 ]

Foolip: also had an open ended question for that one

[ Slide 16 ]

Foolip: parent selector made it there - the developer demand is strong on that one

[ Slide 17 ]

Foolip: as well as other selectors, e.g. backward looking sibling selectors

[ Slide 18 ]

Foolip: some requests related to grid - e.g. styling the lines of a grid
… All these quotes are from public data linked from the end of this presentation

[ Slide 19 ]

Foolip: Browser incompatibilities, the part of the survey I've been spending the most time on

[ Slide 20 ]

Foolip: which features create the most difficulties due to interop issues?

Foolip: this question received the most responses
… a sample of them follows

[ Slide 21 ]

foolip: subgrid was definitely on people's minds, like last year

foolip: subgrid is only supported in Firefox

[ Slide 22 ]

foolip: this should encourage us to prioritize sub-grid in terms of implementations
… Web developers demand for this is pretty big - was already last year, still this year

[ Slide 23 ]

Foolip: a new one emerged: backdrop-filter()
… that one is missing only in Firefox (ignoring IE)

[ Slide 24 ]

Foolip: illustration of what the feature does, a frosted glass effect above images
… it has been identified as a site-compat issue in firefox, but no clear plans for implementation

[ Slide 25 ]

Foolip: the :focus-visible pseudo-class
… applied only when the browser would apply it by default - there are differences across platforms about when items get a focus ring, e.g. buttons
… :focus-visible allows to match the defaults of the platform
… not yet shipping in Safari yet
… Igalia has been working on developing it in Webkit, following the open prioritization effort
… not enabled by default, so not shipped in Safari (but available in Safari TP)

[ Slide 26 ]

Foolip: another popular time - flex gap
… it has shipped, but can't be depended on yet
… it was in the MDN DNA report in 2019
… and gained prioritization based on that

[ Slide 27 ]

Foolip: a particular aspect to this is the challenge in feature detecting it

[ Slide 28 ]

Foolip: another refinement

[ Slide 29 ]

Foolip: initially, this came as grid-gap, then renamed as gap to work also with flex
… the @supports(gap) feature detection has returned true before it became available for flex
… which breaks feature detection
… this has been discussed in the CSS WG, without too much of a conclusion
… if a flex-gap alias had been added, this problem would have been different
… it's probably too late to do that at this point
… but that's an interesting insight, maybe for the CSS WG consideration

This kind of thing is quite likely to happen again, where a property is expanded to a new display type

Foolip: considering an alias for feature detection, or avoiding to merge two features in one

[ Slide 31 ]

Foolip: Questions about Pain points in CSS

[ Slide 32 ]

Foolip: seeded with a set of options

[ Slide 33 ]

Foolip: and an open ended question about "other CSS pain points"

[ Slide 34 ]

Foolip: a couple of mention that CSS is hard to learn / remember
… not surprisingly given the history & evolution
… this echoes something I heard from developers e.g. on flexbox

[ Slide 35 ]

Foolip: multiple comments related to the community mocking having challenges with CSS
… related to the devaluation of the front-end skills, or the general discussion about whether CSS is a programming language
… probably not a W3C problem per se, but it's interesting to seeing it emerge here

[ Slide 36 ]

Foolip: one comment saying properties emerge from vendor needs rather than developer needs
… lots of efforts in trying to collect developer input to drive prioritization
… what should we do to change this and have a tighter feedback loop?

[ Slide 37 ]

Foolip: WHat next? What are we going to do with these results?
… the full results will come in a few weeks

Brian: I gather these are summaries of results

Foolip: these are the exact words from the responses, but sometimes just an extract

Brian: is there any way to follow up with people who've given these answers?
… this would help to get to more specific needs

Foolip: re can we follow-up, I'll have to ask Sacha; I'm pretty sure this hasn't been done in past years
… the survey can be filled anonymously, but you can optionally share you github or twitter account
… but that will depend on what the survey promised in terms of data handling

Brian: we could also follow up through a twitter poll - e.g. do you agree with that perspective?

foolip: following up is a lot of work from past experience
… also people may not have that strong an opinion once you start following up
… in any case, I'll ask Sacha about possible follow up

[ Slide 38 ]

Foolip: I think the browser vendors should use the results of survey like that one as a prioritization signal
… e.g. subgrid should gain higher priority
… a feature I haven't mentioned is "container query" - my guess is that it will be even stronger
… this also applies for standard makers prioritization
… one way of doing that is in Compat 2022 effort

Compat 2022 effort

Foolip: in the WPT community, trying to take a few areas and their test suites and prioritize their improvement over the course of next year
… the same way we did that in 2021 - sticky, grid, flexbox

Container Queries is being prioritized, it's just a hard problem, so browsers have been laying down the groundwork for that for awhile. Chrome especially has put in a lot of work on the implementation side, exploring how to make it actually work.

Foolip: maybe useful to present something to the CSS WG too - maybe some of the members of the group here can help me toward that

[ Slide 39 ]

Subgrid I think is one area where browser vendors did not prioritize for a long time, perhaps seeing it as not important enough.

(Aside from Firefox)

Foolip: The data used for the presentation is available in the spreadsheet

State of CSS 2021 TPAC analysis

Foolip: it's not complete, but quite a bit of work to put responses in relevant buckets


Brian: once the results are complete and compiled, it would be great to come present that to the CSS WG
… the chairs probably could figure that out

Foolip: I've been to CSS WG meetings at TPAC; I can ask indeed, either Tab or one of the chairs

Elika: just sending an email to Alan and Rossen

Foolip: anything in particular that would be interesting to the CSS WG?
… there will be a lot of results
… maybe I can throw a draft to someone to help filter it out

Brian: several of us here would be happen to have a look at it

Foolip: there have been lots of surveys, other research can be done
… to what extent is that part of the CSS WG working mode?
… e.g. test different CSS syntax with web developers

fantasai: historically, mostly informal feedback through twitter, conferences, devrel conversations
… like Jen or Rachel
… we haven't done any kind of very broad outreach survey
… the closest thing was in 2008 through the Web Standards Project
… which came back with a very long list

brian: I remember some discussions where people saw things very differently
… and we crafted a very specific kind of poll and asked everybody in the WG to promote it and get some feedback

fantasai: we've done that in a handful of times, but not very oftne
… in terms of what to work on, that's everybody that comes ot the CSS WG that has ideas about that
… what ends up being worked on depends on what people are ready to work on

lea: implementors have more influence than developers, that's the unfortunate reality

foolip: that matches one of the comments I mentioned earlier
… this is where i suggest vendors should take into account more the signal from developers

Brian: part of the challenge is that some things, everybody ask for but they're very complex to do
… and conversely, some things don't get asked for so much, but can really change what CSS can accomplish

Lea: people know the problem they have, but don't always know some of the features that can help solve them

Foolip: respondents did note they stay away from features that aren't x-browser implemented
… e.g. flex gap
… my question about the CSS WG was how to arrange this
… I'm not aware that any other WG has a more formal approach
… I'm not sure there is a need for a big fancy research thing
… but I hope State of CSS can be useful to the WG and to the vendors

AlanD: re vendor prioritization
… I've only gotten involved very recently
… most users don't know what's coming, or when it's coming
… if we could do better with signals about what features are being implemented, and when
… it would help a lot mitigate that sentiment
… esp since CSS is hard to polyfill

foolip: where would you be looking for this?

AlanD: all browsers have their own status pages; but it's not very clear how uptodate and accurate it is
… having a centralized store might help too

Foolip: would you trust canIUse (or BCD) with information about the future?
… getting promises from vendors before they ship is something no vendors want to do
… but that problem aside, would caniuse be a place?

AlanD: yes, both caniuse and MDN would be relevant
… I know exact dates would be difficult, but at least some signal of interest of implementation would be useful

Brian: I know this has been discussed in MDN and other places
… when do we achieve a new level of compat across 3 engines
… it's rare enough that it would be interesting to the broadest set of people
… having some way to track that would be really helpful
… we have several comments that there are so many things happening that it's hard to keep up
… and you don't always need the said feature right at the moment, or you need some delay before you can apply it
… the challenge is to find something with a high signal/noise ratio

foolip: a Web platform newsletter with what's new and usable on the Web - that seems very doable
… but you still have the problem of the relevance of that

AlanD: worth trying; not sure what the right solution would be
… but centralizing the information owuld help in the long term

lea: it looks like something that could be done automatically based on the canIUse data?

foolip: yes, that's what I've been looking to
… but it needs some writing to decorate it

lea: we should decouple the two
… just a notification of features that become x-browser usable would be useful
… sometimes I discover a feature I had put aside has become x-browser compat a year after it happened

brian: we have "web standards in 2 minutes" that curate specific useful features into short term format

foolip: this could be just for CSS, or JS, or the whole Web
… seems like a good idea, and not too hard to put together
… MDN folks have also suggested allowing to subscribe to Browser Compat Data updates

fantasai: re the question about most wanted feature - what's the thinking about giving a list of choices vs just an open text field?

foolip: last year it was just an open text field
… the results of last years were used to populate the 8 initial values
… if we had just had the open box, we would have received similar signals - this allows to get more of the below-the-fold data
… the downside is that you're almost guaranteed the pre-selected ones will be seen as important
… also you can't rank the pre-selected against the open-ended values

<alangdm> I had to move to a different session, great talk @foolip, it was really insightful :D

fantasai: that makes sense

Rachel: the question I would really like to ask is "what can't you do"


Rachel: asking about features pre-suppose people know what a feature can do
… e.g. a number of container queries use cases can be done with e.g. grid
… finding out what people can't do with the existing technology is what's difficult to get

foolip: one recent example is the scrolling survey that Adam Argyle put together
… e.g. cyclical scrolling or carousel
… instead of feature-targets
… wouldn't it too broad to ask what you can't do?

Scroll Survey Report


Rachel: that's the kind of signals that I'm missing from conferences
… surveys tend to speak to people that know already quite a bit about these
… not sure how much they represent the feeling of developers in general

foolip: there is one area where this issue is clear: viewport
… people don't have ways to express to say they want to use the whole viewport @@@

RobSmith: I'm trying to integrate CSS with a format based on WebVMT
… I'm not a CSS guru, and wanted to get expertise
… which github should I raise my questions?

fantasai: #css on IRC
… www-style
… and for spec issues, https://github.com/w3c/csswg-drafts/

Rob: CSS is integrated in WebVTT to some degree; I'm trying to extend it but I'm not sure how

<foolip> https://github.com/w3c/webvtt/issues

fantasai: this sounds relevant for www-style - doesn't feel like a spec issue


Minutes manually created (not a transcript), formatted by scribe.perl version 149 (Tue Oct 12 21:11:27 2021 UTC).


Succeeded: s/... [/[/

Succeeded: s/@@@/Rossen/

No scribenick or scribe found. Guessed: dom

Maybe present: AlanD, Brian, fantasai, lea, Rachel, Rob, RobSmith