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://
<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 :)
<foolip> What's the passcode?
<foolip> When I paste https://
<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
foolip: Reminder we're operating under W3C CoC
foolip: if you want to ask questions, please raise your hand in Zoom
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
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
Foolip: Accessibility changes made this year
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
Foolip: focus handling was mentioned several times
Foolip: respecting font scaling - useful e.g. for low vision users; that takes special efforts
… not sure how this can get tested
Foolip: one respondent suggested getting input from UX designers to order the DOM for screen reader flow
Foolip: Missing features
Foolip: a multi-select question asking what is currently missing from CSS, seeded by responses from last year
Foolip: also had an open ended question for that one
Foolip: parent selector made it there - the developer demand is strong on that one
Foolip: as well as other selectors, e.g. backward looking sibling selectors
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
Foolip: Browser incompatibilities, the part of the survey I've been spending the most time on
Foolip: which features create the most difficulties due to interop issues?
Foolip: this question received the most responses
… a sample of them follows
foolip: subgrid was definitely on people's minds, like last year
foolip: subgrid is only supported in Firefox
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
Foolip: a new one emerged: backdrop-filter()
… that one is missing only in Firefox (ignoring IE)
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
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)
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
Foolip: a particular aspect to this is the challenge in feature detecting it
Foolip: another refinement
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
Foolip: Questions about Pain points in CSS
Foolip: seeded with a set of options
Foolip: and an open ended question about "other CSS pain points"
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
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
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?
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
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
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
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
Discussion
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"
rachelandrew++
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?
https://
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://
Rob: CSS is integrated in WebVTT to some degree; I'm trying to extend it but I'm not sure how
<foolip> https://
fantasai: this sounds relevant for www-style - doesn't feel like a spec issue