Meeting minutes
<jgraham> RSSAgent: make minutes
Breakout: Web Features: Building an index for the web platform
<jgraham> RRSAgent: make logs public
<jgraham> RSSAgent: make minutes
<jgraham> RRSAgent: begin
jgraham: introducing web features. Expecting most of the session to be discussion.
jgraham: index of all features on the platform to answer questions about what is available to be used by devs. currently used for banner on MDN and caniuse and others.
jgraham: maintained in yaml files in the web-platform-dx repo. grouping of BCD keys to higher level features in the way devs think about features.
jgraham: Currently focused on backfilling.
<rachelandrew> there's also a baseline status universal widget to show status web-platform-dx/
jgraham: the purpose of this session to talk about use cases for web features beyond backfilling.
jgraham: in Interop we are asked to include something in Interop and we need to know vendor's standards positions, finding that out is a lot of manual work. Standard positions on web features would make that very easy to find.
jgraham: similarly, for intent emails it would be useful to see what the browser status is per browser.
jgraham: there are also some challenges here: when should we be defining features? Who has that responsibility. Early in the life cycle, things might go through a lot of changes before it's actually ready. What happens when features change, is that a new features?
TabAtkins: bikeshed currently consumes MDN and caniuse. so long as web features are similarly targetable that should be fine.
<queengooborg> web-platform-dx/
jgraham: might want to replace the MDN compat data with Baseline support data.
TabAtkins: might want to repalce in Bikeshed the MDN compat data with Baseline support data.
jgraham: both are based on BCD.
miriam: there is a tension between are we trying to capture the whole feature group and say it's partially implemented or break them so we can clearly say what is and isn't implemented. example container style queries. caniuse.com says its partially implemented.
rachelandrew: in CSS we often base features on top of features. Developers are not aware of how things are specced. This is an issue with adding things to the platform.
jgraham: over time people stop caring about things like subgrid being separate from grid, often times mediated by availability. Have to atomize early in the process and we haven't figured out yet how to glue them back together.
<jgraham> kadirtopal: That question came up recently, are we describing the platform as we'd like it to be or how developers think of features in the moment. At the moment we're doing what caniuse has been doing, which is to follow how developers think about features. It's not very clean. The only answer we currently have is that's how developers think about
<jgraham> it. Mostly but not entirely about avialability cross browser
mirim: we are still running into the same issue with something like container queries where what dev were refering to before has now changed.
past: for the blink launch process we'll introduce a requirement to define a web web-feature name. Should that be mandatory and how early in the process should we start, and what would the process be.
TabAtkins: looking at data files, want to know about stability. don't want spec authors to know about every single web feature that is associated with their spec.
TabAtkins: I can use the spec-url, and I know how to associate
jgraham: re the question from past: that's what this conversation is about.
jgraham: It should be as early as we need identifiers.
jgraham: might have to work with individuals to figure out whats difficult about that early in the process.
jgraham: an issue might be polluting the name space, when things that are shipped is very different from original proposal or things are not shipped at all.
jgraham: it's clearly not like using a hash that clearly refers to one thing. We might need to have a way to version things.
PeteLe: would you be able to have multiple Chrome status entries with the same web feature, since things are shipped in multiple iterations.
rachelandrew: that's something I struggle with, once those things get to widely available, nobody cares, but the time between availability in one browser, newly available and widely available is when things are hard.
ydaniv: As an author, I want to know what is available in an area, what is being worked on, so people can discover.
kadirtopal: Having something that's forward looking would be great. Currently, we're back filling, so not yet doing anything in that space.
… Chrome status and web features are slightly different in scope. That does not remove all issues, e.g. with Container queries.
… No silver bullet.
miriam: Yes, container size and container style were separated, but container style could get further divided.
kadirtopal: Right, not ideal :)
jgraham: when things are shipped piecemeal developers need to know that there is a gap between things being usable in one chrome release and then in a chrome release a year later
jgraham: we'll need to solve the issue of gluing thing together to solve the problem that we are creating by breaking things down.
past: going back to concern of naming things: given volatility we should have the ability to change the content of names. Given that we should be lenient of how names are given.
past: I'm proposing that it should be a first-come-first-serve thing were people can claim names as they need them, but we reserve the right to change the name later.
jgraham: nervous about making features mutable on the data level, that might make it difficult to refer to things in places like feature definitions.
<kadirtopal> s/feautre definitions/vendor positions
past: when we make changes in the feature we'd ask for a new vendor position.
jgraham: for early stuff we might need something like a vendor-id that implies that things will change in the feature definition.
jgraham: by the time you want to ship something to a general audience without flags, you'd ask for a permanent ID.
<rachelandrew> +1 for some kind of early stage prefix/namespace
<jgraham> kadirtopal: Before something is shipped there's a lot of flexibility. Once something is shipped not behind a flag that's more fixed. Before something is shipped, a lot of things associated with that aren't quite as necessary. Some kind of tentative prefix makes sense to me. Not sure what the process should be to turn it into a permanant thing. That
<jgraham> could be a PR.
jgraham: there is an infra requirement to make sure things go smoothly.
past: names are what the webdx features is bringing to the table, having a name with a prefix in it would be less useful.
past: we're shipping things iteratively, keeping the name in limbo until things are fully stable, seems unncessary.
jgraham: not sure how that addresses the issues it would create.
tidoust: I maintain browser spec which us used in WPT and MDN, and each time the question is when do we have a "new" spec, things are quite messy. So feature names are intertwined with spec status.
karlcow: how do you refer things from the past that have changed since then, eg things that had a name in the past and changed little by little in the meantime.
jgraham: When semantics have changed, but not the syntax, we consider it the same feature.
jgraham: it's about API surface, not behaviour.
jgraham: you could have an API and a part is removed, in that case you'd have to find a way to change the web-feature, but that seems rare
kadirtopal: Right now, we don't have the problem so much, because we're backfilling. We'll run into these issues later on, for sure.
jgraham: looks like there is agreement on using web features early in the process.
past: as early as when things are shipped, or earlier?
jgraham: things like standard positions, earlier than standards positions would be necessary.
jgraham: next step would be to propose a process, requirements, does that necessiate changes to the schema, how are pre-release keys handled, what is the process. That can then be brought back to the CG for discussion.
tidoust: join us every Thursday for conversation in the CG.
tidoust: careful subscribing to the repo, it's very active.
jgraham: re forecasting: there is value in making it clear what are things that browsers are interested in working on vs things that no browser is investing in.