[css-backgrounds][css3-background] Add CanIUse panels

[cvrebert]

Bikeshed has a feature to include CanIUse info panels in specs. (Example; Example commit)

I wonder if css-backgrounds would consider using this feature? Here are the spec anchors and corresponding CanIUse features for css-backgrounds (ignoring background-img-opts & background-repeat-round-space due to ambiguity):

CSS spec URL(s)	CanIUse feature URL
https://drafts.csswg.org/css-backgrounds/#border-images	https://caniuse.com/#feat=border-image
https://drafts.csswg.org/css-backgrounds/#box-shadow	https://caniuse.com/#feat=css-boxshadow
https://drafts.csswg.org/css-backgrounds/#the-background-attachment	https://caniuse.com/#feat=background-attachment
https://drafts.csswg.org/css-backgrounds/#background-position https://drafts.csswg.org/css-backgrounds-4/#the-background-position	https://caniuse.com/#feat=css-background-offsets
https://drafts.csswg.org/css-backgrounds/#the-border-radius https://drafts.csswg.org/css-backgrounds-4/#corner-sizing	https://caniuse.com/#feat=border-radius
https://drafts.csswg.org/css-backgrounds-4/#background-position-longhands	https://caniuse.com/#feat=background-position-x-y

CC: @LeaVerou

[LeaVerou]

Since you're doing all this work, it might be more effective to send a pull request. Have you considered that? :)

[cvrebert]

Given the legal rigamarole of actually sending edits to a W3C spec, I expect that would be slower.

[LeaVerou]

Not sure what you're referring to, as you can see there are plenty of merged pull requests: https://github.com/w3c/csswg-drafts/pulls?q=is%3Apr+is%3Aclosed

@svgeesus would there be a problem with merging pull requests?

[cvrebert]

Rigamarole on my side, not on y'all's side.

[fantasai]

Technically, css3-backgrounds still needs conversion to Bikeshed; it's on the old preprocessor. :)

[fantasai]

Regardless, I think we need to bring this up with the CSSWG, if they want to include such links in specs as a general policy. CanIUse is useful, but it's not a definitive source of information such as one typically links from a standard.

[cvrebert]

Noting for the record that HTML has had such info panels for a while now.

[tantek]

Do any other w3.org/TR specs have a CanIUse panel? Examples?

[css-meeting-bot]

The CSS Working Group just discussed caniuse, and agreed to the following resolutions:

RESOLVED: Add caniuse panels to CSS EDs

The full IRC log of that discussion

<ChrisL_> topic: caniuse
<TabAtkins> (Expanded explanation: syntax is `var( <custom-property-name> )`, where <custom-property-name> is a --name. Thus, per spec, using a non-dashed keyword is syntactically invalid and should be rejected at parse time.
<TabAtkins> )
<dbaron> Github topic: https://github.com/w3c/csswg-drafts/issues/1219
<ChrisL_> fantasai: we were asked to add these to our specs, bs supports
<ChrisL_> filed as an issue on individual specs? do it on all or none
<ChrisL_> Florian: seems useful
<ChrisL_> fantasai: main reason not ot is that it is unofficial
<ChrisL_> leaverou: better than nothing and they use tests
<dbaron> Florian: editors drafts or TR?
<fantasai> ChrisL_: There was this thing about using scripts on our own site
<fantasai> ChrisL_ talks about w3c publishing policy
<fantasai> TabAtkins: It's just the images that aren't local
<fantasai> ChrisL_: It's a static snapshot?
<fantasai> TabAtkins: Based on current state of database when you generate it
<fantasai> ChrisL_: Then it needs to be very careful to be labelled as such
<tantek> Do any other specs on /TR have it?
<fantasai> leaverou: Could we make it live?
<fantasai> TabAtkins: But then you have more live dependencies
<fantasai> TabAtkins: I don't like having lots of live dependencies
<fantasai> ChrisL_: We have live dependencies for tests, it's great
<fantasai> leaverou: It's extremely misleading for ppl, especially because we take years to publish a new spec
<fantasai> TabAtkins: Which is a reason to keep it for EDs only
<fantasai> tantek: What's being asked for?
<fantasai> Florian: Our specs don't have it, others doo
<fantasai> tantek: whatwg uses them
<ChrisL_> tantek: do any s[ecs on /TR have this now?
<ChrisL_> tantek: no-one else at w3c has done this, is that a blocker?
<ChrisL_> fantasai: want us to have an updated /TR rather than ED and what stops us is the process of publishing
<ChrisL_> ... now we have echidna, no readon why an editor can't get a resolution and push to /TR
<ChrisL_> tantek: lots of reasons why thwat doesn't happen
<ChrisL_> fantasai: once it is resilved no reason not to push to /TR.. want them to be a s useful as ED so ED can be the scratch space
<ChrisL_> tantek: agree but out of scope for this issue
<ChrisL_> fantasai: having useful stuff in ED and not TR stops us publishing
<ChrisL_> tantek: way out of scope
<ChrisL_> fantasai: want them to be equivalently useful
<ChrisL_> tantek: blocking on this is not reasonable
<ChrisL_> leaverou: idf we add them on ED then we should add on TR as well and live, not stale
<tantek> q?
<ChrisL_> fantasai: even ED can go for a time without being updated, like scroll snap where there are no edits but impl data updates
<ChrisL_> plinss: (explains multiple pass database regeneration)
<ChrisL_> astearns: want these to be in /TR and as that is not regwnerated we need it to be live. tab can we do that/
<ChrisL_> TabAtkins: annoying duplicate paths but can do
<ChrisL_> astearns: updated from spec
<ChrisL_> leaverou: how about bs does it and then a script updates
<ChrisL_> TabAtkins: sure
<ChrisL_> ... plins wil write it
<ChrisL_> leaverou: what about features behind a flag hides vendor interest
<ChrisL_> TabAtkins: decided that behind a prefix is hidden because wanting to see what can be used. explaining what is available with what prefixes is ....
<ChrisL_> ??: canisue can be updated very slowly
<ChrisL_> rachelandrew: fins caniuse often out of date
<ChrisL_> Rossen: microsoft updates mdn
<ChrisL_> till: we could make an api to get that easily from mdn
<fantasai> ScribeNick: fantasai
<ChrisL_> s/??/rbyers
<fantasai> rbyers: MDN doesn't have a nice API like caniuse does
<ChrisL_> s/we could/Mozilla could
<fantasai> rbyers: We've talked with MDN folks about that before
<fantasai> rbyers: For case of developers, they're already going to caniuse
<fantasai> till: If that's what it takes to get us all to agree on updating this data, then it's a stron greason to do this
<fantasai> Florian: There's also no reason for caniuse to not use that data, if it's available through an API
<fantasai> leaverou: Even if purpose is not for implementor nterest, but for developers
<fantasai> leaverou: But it makes a difference between not implemented at all maybe not arriving, or whether it's implemented behind a flag and coming up
<fantasai> leaverou: Recently I solved an issue in images 4 where there was a table, everything was gry, no implementations
<fantasai> leaverou: I clicked thorugh a link, and it was a wall of green. Why trust the tables if discrepency is so big
<fantasai> TabAtkins: No guarantee that stuff behind flag or prefix is anything similar to what's in the spec
<fantasai> rachelandrew: We need to expose things behind a flag so we can get feedback from developers
<fantasai> Florian: Cna we sort of resolve on this and file bugs on Tab and Peter or?
<fantasai> ...
<fantasai> eae: It's only really useful if there's a reasonable expectation that it's at least somewhat recen tor up to date
<fantasai> rbyers: Devs find caniuse very useful even though not up to date,
<fantasai> Florian: But it's not 3-4 years out of date
<fantasai> rbyers: If what you really wnat is behind a flagg use case, the only wayt ot get that is an automated system
<fantasai> rbyers: W...
<fantasai> rbyers: We're going to make a tool available later, called API Confluence Dashboard, similar to Edge API Catalog, but it's an automated tool that lists all fo the APIs available in every browser and how they've changed over time.
<fantasai> rbyers: This is furhter out, but if we want to tackle what things are under development, this might be more practical way to tackle long term. It'll always be fresh
<leaverou> s/I clicked thorugh a link/I clicked through the caniuse link/
<fantasai> smfr: geneated by software?
<fantasai> rbyers: Yes, used by walking ? graph
<fantasai> rbyers: Not good for all features, but somethings
<fantasai> rbyers: Depends on browser being available on browser stack
<fantasai> ...
<fantasai> ChrisL_: Safari Tech Preview, I was using it in browser stack yesterday
<Rossen> fantasai: sounds like we have lots of ideas but haven't documented how/where to do it
<fantasai> rbyers: maybe 2 outcomes from this, use Tab's caniuse for now
<fantasai> rbyers: And have a small group to discuss making btter
<fantasai> tantek: Yeah, have something that works today, let's go with that, experiment on ED
<fantasai> tantek: and then solve in /TR later
<fantasai> eae: Risk of bad data being propagated
<fantasai> tantek: Yeah, so try out on EDs
<fantasai> tantek: Don't wait for perfect being enemy of the good
<fantasai> fantasai: So, plan is enable caniuse panels on EDs, and investigate better ways of exposing data and putting on /TR
<fantasai> RESOLVED: Add caniuse panels to CSS EDs
<fantasai> Rossen: Further fallout is to discuss better ways of exposing the data
<fantasai> Rossen: in useful and more predictable ways
<fantasai> Rossen: Don't have to decide on this now.
<dbaron> fantasai: people who are interested in figuring out how to collect/expose data should have a side discussion
<dbaron> tantek: drop it into a github issue?
<smfr> s/walking ? graph/walking the object graph/
<dbaron> fantasai: sure, side discussion while we're here, but keep things someplace where others can participate