Meeting minutes
<jgraham_> Chair Kadir Topal
<jgraham_> RRSAgent: make logs public
<jgraham_> RRSAgent: make minutes
kadirtopal: First question is "Why baseline"?
kadirtopal: We recently shared one of our internal developers survey.
… We asked devs about top pain points
… We've been runnning these for years now and top pain point is keeping up with changes
… new APIs, practices, etc.
<dom__> Research results from which this slide is quoted
kadirtopal: Even if you think about subgrid, landed in Firefox in 2016 I think, then you have a gap for 5 years to get another implementation, then another year for a third.
… As a dev, how you can keep up with that?
… New browser versions are coming up every few weeks, changing what the web platform is
kadirtopal: At some point, after a number of years developing, you need to be able to tell developers that the feature is here!
kadirtopal: But there's no feedback loop.
kadirtopal: That's where Interop kicked in
… Interop is a huge step forward.
<jgraham_> RRSAgent: make minutes
kadirtopal: But there's a step before, and a step after.
… It still makes sense to look at interop, but also before and after.
kadirtopal: We got together with like-minded people and the WebDX CG was created about a year ago to look at the research, which will be discussed this afternoon in another breakout, and on what comes after Interop, which is the topic of this session.
kadirtopal: We want to make it easier for devs to track the list of features that are widely available.
kadirtopal: One aspect is naming feature and grouping features.
kadirtopal: But before we get to that, there's baseline.
… When a feature is widely available.
kadirtopal: Initial definition was "in 2 last major versions of Chrome, Firefox, Safari, Edge".
kadirtopal: And then we can set some baseline badge, displayed on top of MDN pages.
kadirtopal: We've been iterating on the definition of baseline in the past few months.
kadirtopal: There is a point at which the feature is supported across browsers, and then there is uptake.
… There is a power curve: adoption, then diminution of increase.
… You never reach 100% of support for any feature.
… As long as IE was to be supported, we were stuck. Since then, all browsers are evergreen. However, there are still issues with that path.
… The vast majority of people don't even have to worry about that, they run the latest version.
… But others may run on specific platforms that no longer are updated. Or running on a platform that is updated every 6 months, or that is managed.
… Lots of reasons that explain why the curve is not an immediate massive adoption.
… Most adoption is within the first 6 months.
<dom__> [have we confirmed the rough shape of the uptake curve, out of curiosity?]
kadirtopal: But still some significant, say ~20% of users, that will need more time to get the features.
… Some of that is on smartphones. But also on TVs where the uptake cycle is vastly different and can take 10 years.
… That explains why the curve looks like this.
… What this brings us to is: there is one point, and then there is an interval. When can you say that a feature is widely available?
… Very diminishing returns some time between 6 months and 2 years. 3 years seems a max.
… That's what we're discussing.
kadirtopal: All of this requires being able to talk about features and feature groups.
Web features
daniel: When we talk about features, what are we talking about?
… Most of discussions on features from an implementation perspective are specification specific, for internal purpose. Devs have a different perspective.
… The web-features project is an NPM package that tries to identify features.
… We try to capture the things that we hope make sense for developers.
<dom__> web-features repo
daniel: We give features a short identifier, link to specifications, compat data, Can I Use entries
<dom__> Daniel's recorded presentation on web-features
<whimboo_> Hi, I just joined and wonder if the room is muted?
Video presentation on web-features
daniel: Flags about implementation, baseline, deprecation status, etc.
… This may be helpful as a tool for more accurate documentation of features and compat data, e.g., on MDN.
… This is going to be an important underlying thing to the overall project.
Open discussion
<Zakim> dom__, you wanted to ask how confident we are on the shape of the uptake curve (illustrated on slide 13)
dom: How confident we are that the adoption curve has that shape?
kadirtopal: We spent quite a bit of time studying that, yes.
… One problem is tracking usage metrics. Quite tricky to get access to valid and representative public usage data.
… Can I Use agglomerates usage data from StatCounter.
… But all versions and regions are not represented in that usage data.
… Anyway, we've looked at all data available, and it always looks like a power curve.
… Depending on when the interop moment happens, you may start at 80% already or lower than that. That depends on which browser is the last one to ship the feature.
daniel: One thing that is interesting is that this curve has gone steeper over time.
… A 2015 feature took longer to be widely available than a 2020 feature.
jgraham_: About the shape of the curve, there's a bit of approximation. At the start, it goes up over the initial weeks. But then you might see bugs in the released feature.
… Or at some point the browser drops support for a particular old platform, and people will stop using some older version of a browser. Or people using Firefox ESR.
… That will create bumps in the curve.
… If you look at stats, a few percents still on Windows 7 for instance.
… Browser vendors drop support for an OS correlated with how much users have upgraded.
<ddbeck> Dan Fabulich used caniuse features to analyze the curve, with the summary table here: dfabulich/
jgraham_: In an ideal world, we would just mention versions and the marketshare. But the usage data is indeed not super reliable.
… No way to track the different steps which in the end create the curve.
bkardell_: The notion of having a power curve seems very natural.
… given what we discussed. You expect to get a big chunk of users, then additional updates over time.
… Does that happen incrementally? I don't really know. This may change over time.
… We've talked about not dropping X% of users. I agree with the goal.
… But we're not counting for instance Samsung Internet, which should account for some users.
jgraham_: I don't think that it's true when we look at usage data
bkardell_: Right, but the definition does not include Samsung Internet. Significant browser in the UK for example.
… Anything that we do is ultimately going to have simple rules. It's a delicate balance to be found.
<dom__> [part of my question on the shape of the curve is to understand if we can measure our impact in making it more vertical]
bkardell_: I don't have an answer but need to carefully consider all perspectives.
kadirtopal: Back to the top pain point raised by developers. No definition is going to be perfect indeed.
jgraham_: About ignoring Samsung Internet, that's true the way baseline has been defined so far. Any definition that mentions marketshare would not ignore Samsung Internet.
… If we're using a proxy for marketshare, Samsung Internet is still being indirectly included.
… If we have other criteria: all versions of browsers that still receive critical updates for instance, then we should be able to make sure that we include needed browsers and users.
<Zakim> bkardell_, you wanted to clarify something
jgraham_: I think you can work with data even if the vendor is not in the room.
bkardell_: I didn't mean to suggest that we're intentionnally excluding anyone. We're relying on StatCounter, and there may be much better data elsewhere.
… We're doing with the data that we have.
… Developers do not have this level of conversation. They may look at boxes, check they're green and be done.
kadirtopal: Goal is to offer baseline as a tool to developers and gather feedback on whether it's useful. Then iterate.
… I think that we can adjust over time, act on the feedback.
… The other part of it, raised by Patrick, is to provide feedback on features that are not baseline.
… A set of features that is not yet interoperable, is there opportunity to provide feedback to developers?
… Also, does the feature actually solve the problem it was developed for? Is there opportunity to gather that feedback?
patrickbrosset: The baseline status comes with a little bit of a risk of hiding what's not baseline out there. I would hate for a world where everyone just considers baseline features and ignore the rest, leaving it for us to play with these features.
… An opportunity for us to track complaints to these things.
<Zakim> dom__, you wanted to ask about the duration of ~FPWD to baseline
patrickbrosset: Maybe not something that the WebDX CG should work on, could be done by Can I Use, MDN, etc.
dom: One metric that would be interesting to look at is maybe the time from certain phases of standardization to baseline status.
… Also could be used to evaluate the impact of the discussions.
… Time to interop and time to baseline. Giving that kind of feedback to the working groups so that they get a better sense of durations.
kadirtopal: I don't think that's been raised before, fantastic idea
<Zakim> romain, you wanted to ask how would an iterative process account for biases?
romain: One thing that worries me is introducing bias with feedback. Those who have less access to Internet will be less likely to give feedback.
… Iterating is interesting. First definition was wrong, we're somehow over-compensating the thing. Surveying developers about the definition without introducing bias is hard.
miriam: When talking to developers about new features, I spend time convincing them that all green is not baseline. Big difference between container queries and cascade layers as well.
… One can be added on top of it, the other would break your content.
… Not conveyed in the definition of baseline.
kadirtopal: Very important point.
… At some point, we had mainline on top of baseline.
… The more you simplify, the more you ignore things that do have an impact.
… Progressive enhancement is maybe still worth folding into this.
rachel: [missed]
<kadirtopal> rachel: defining a line in the sand for "widely supported" means that people don't have to worry about progressive enhancements for things before that line
bkardell_: The current definition that we're working on, is 6 months to 3 years after interop. Most developers won't be caught by surprise on something that shipped that could be qualified as new.
<kadirtopal> rachel: and can focus on making decisions about progressive enhancements for things after that
bkardell_: Devs could use "why isn't that in baseline?" to report on lack on interoperability. But we may be getting feedback on things that got fixes some time ago, just not with baseline status yet.
<Zakim> jgraham_, you wanted to talk about time to baseline
kadirtopal: If we do this with 3 stages, not widely supported, interop, baseline, the message could be specialized to the different stages.
jgraham_: About the time baseline, there's always a danger. Browsers changing the frequency of releases. Also some OS or hardware versions that were shipped long long time ago that could be still be worth supported.
… I'm always worried about making it a metric. How do you make sure that you're promoting the right thing.
… If you can polyfill something with 0 performance impact, why would we standardize it? That will often be considered by users as broken if we tell them to use a polyfill.
… There's a balance to be found.
daniel: General response. We will have to get better than we are now. We have real limitations that we cannot change.
… No matter the definition, we'll have to teach devs that it is an answer to some questions, but not all of them.
… We also need to communicate with them about what's missing.
<dom__> [re accessibility support, a breakout on the topic in the next session: w3c/
kadirtopal: WebDX CG meets every other week, you're all most welcome to join!