Add caniuse info boxes like the HTML spec #69
Comments
|
This would either require support in Bikeshed natively or some kind of pre-processor similar to that of HTML, but probably not written in Pascal. Neither is a priority for me, but I welcome PRs of course. |
|
In general web platform test boxes would be better IMO. Caniuse has such sporadic coverage and low granularity. |
|
Do you know of some data source that offers per-browser-version WPT results? |
|
This has been implemented in Bikeshed: speced/bikeshed#824 😄 |
|
That sounds very cool, but when I added |
|
(I also tried |
|
Per Tab's design choice, you need to also add a See https://github.com/tabatkins/bikeshed/blob/master/tests/caniuse001.bs for a trivial example. |
|
@tabatkins can we have an option to make it automatic instead? This seems like it would require too much maintenance. |
|
No, we can't, because there's no reasonable automatic mapping. The caniuse features are named in an ideosyncratic way that does not allow for automatic translation, and most of them are larger granularity than single methods/etc anyway, so I couldn't map them to a single WebIDL definition. |
|
They link to spec sections of though... |
|
Which works if you're viewing the exact URL that caniuse happens to be linking to. Breaks if you're publishing, or viewing locally, or otherwise letting a spec be viewable in more than one place. That's really fragile. (For example, I think it doesn't usually link to drafts.csswg.org.) |
|
So get them to update their links (for CSS documents)? For WHATWG anyway we don't have that problem, although maybe we should disable it for snapshots? |
|
@tabatkins, would a solution be adding a new metadata item, something like |
|
@annevk Updating won't help, because it's still just a single url, while documents can often be reached from multiple urls. (For example, the "latest" version of our EDs can be reached either with their versioned shortname, like @domenic Hm, maybe. Looking over the urls, tho, they're totally inconsistent:
|
|
Yeah. In the past we've fixed that by doing pull requests to caniuse to point to the latest spec; they're quite good about accepting such PRs. And that way we improve the ecosystem for everyone! Also from that list you can see how DOM would clearly benefit from just flipping a switch in that way; everything would just start working. |
|
Yeah, it looks like DOM is the only one that would benefit from it; it would be saved from having to enter 15 attributes. The rest of the WHATWG specs either have only a single item, or some features link to the spec itself, which means the auto-mapping won't work. I'll just write a PR for y'all adding the 15 attributes? |
|
I think that would be sad. It would mean every time someone adds a new DOM feature to caniuse, they also have to remember to come patch DOM. And it loses the incentive of ensuring caniuse is updated to the right spec URLs. And with a prefix URL solution, not only DOM benefits; browsing the lists, css-fonts-3, css-cascade-3, compositing-1, css-text-decor-3, CSS2, CSS21, css3-background would all benefit before getting too far down the list. |
|
Urgh, while I understand your position, I'm still resistant to doing it this way. Even presuming a world where all the URLs were "fixed" to something reasonable, this is still fragile. It doesn't respond well to things getting a new publication; you have to update Can I Use with the new URL and then remember to update your old spec as well. It means that well-meaning updates to Can I Use from external people to point the URL more accurately can break your spec. I'd be okay with a compromise - you can provide a URL, and any features with that URL that you don't put in your document trigger a warning. That way, you still have to be explicit about what features you're using, and things can't disappear without your knowledge, but you're still informed if new stuff comes up without having to regularly check it out on your own. Sound okay? |
|
I'll defer to @annevk. I'd prefer no warning so I don't have to duplicate the information in both places, but it does give some of the benefits, which is nice. |
|
I would rather avoid the duplication. I don't really understand the "new publication" concern. If features move around, Can I Use will have to be updated anyway to point to the new location. It seems that will sort itself out correctly within a week of moving or so. |
|
That (Can I Use being updated) hasn't happened for most of the specs it covers; there's a bewildering variety of URLs there, including some that I never even realized were in use ( As I said, the big thing I'm concerned about is Can I Use changing, and people not realizing that it did, thus losing the annotations. Most people don't seem to review diffs for the generated file, so it won't be noticed unless they happen to scroll by something that they know should have a CanIUse block and notice that it doesn't. I highly suspect this will happen when people "do the right thing" and update Can I Use with the new publication URL; any old drafts will stop showing annotations until the issue is noticed (if ever) and corrected. (This is especially problematic for CI-generated drafts.) There's additionally the placement problems that I alluded to previously - several of the CanIUse URLs do not have a fragment; they just have the bare spec URL. Some specs have both - one feature with just the bare URL, and then several with anchors pointing to the specific definition. It's unclear where that no-fragment annotation should be placed; if I choose a place by default, there will always be people who want something else. The "duplication" is super minor - you just add I'm gonna go ahead and go with what I proposed in the compromise. It avoids all the problems of trying to auto-associate caniuse annotations to a spec via URL, while also avoiding the "I need to regularly poll CanIUse to see if any new features of my specs are supported", as long as the URLs are set up properly (which is a requirement of either proposal). |
|
For HTML we just update Can I Use and it has gone fine thus far. Why don't we try out the way that requires less effort first? |
|
For the reasons I just gave above - it fails silently in cases that I think are reasonably possible to happen. Just adding a few attributes (that also give you the ability to position the panel where you want), with a warning-generator to watch out for new things, is a small price on the spec author, and is much safer in general. |
|
It basically means I won't use it. |
|
I mean... ok? You're free to refuse to use any feature. I'm not really willing to compromise on "this has a good chance of breaking in non-visible ways" because you don't want to put an attribute on fifteen elements across your spec. |
|
Maybe when I get some time I can hack up a tool we can use as a postprocessing step to add caniuse to WHATWG specs, since it looks like Bikeshed is not going to be suitable. |
|
:thinks accepting a PR for adding an attribute to 15 elements in the document is too much work: |
|
No, it would be a separate tool to do caniuse; it would not add the Bikeshed attributes. |
|
That just makes it worse! Now you're doing even more work (to produce the panels) solely to avoid using the existing Bikeshed feature. |
|
The problem is that the bikeshed feature requires active maintenance by those writing the specifications. Whereas the alternative we've been successfully using for HTML for a while now (I'll just repeat that here) requires a one-time cleanup for the specification in Can I Use and some caution when adding new entries there (though that should become pretty self-evident when most specifications adopt it). |
|
I just added the tracking metadata: you can add |
|
That does not help especially since Bikeshed is now mostly a server-side operation. What we need is automatic cross-referencing. |
I don't understand what this means. Are you saying that you don't have a way to look at the warnings from Bikeshed? Do I need to give you a flag that elevates warnings and link errors to be fatal, so they'll stop your auto-build?
And I've already explained why that doesn't actually work. Even if I can fix some of the cross-ref issues (like the URLs that are to just a spec itself, not a particular anchor), there's no way to fix the problem that it's impossible to use on a spec published at more than one URL, which is the common case for W3C specs; if you move a spec, the panels just stop working until you write a Can I Use PR and get it accepted; if one of the features has its URL changed by someone else (not one of the spec editors), the panel just silently disappears until you notice and update Can I Use. The current design is robust and easy to use. It relies on the stable identifiers from the CanIUse db, so nothing will change underneath you unless Can I Use goes totally crazy; it lets you position the panel wherever you want; it lets you publish the same spec to multiple URLs and it continues working without any effort on your part; it now warns you if someone changes the URLs away or adds new features to the same URL, so you can tell when you need to fix something; and the markup you add to tag it in is small and simple. |
For WHATWG this will never be the case (assuming we disable this feature for snapshots which we should). Can we get a WHATWG-specific option? |
|
I would rather write the PR to add the attributes for you than add a footgun feature that will be misused by others. :/ |
|
Just restrict it to our org. 😊 |
|
I'd prefer if we just parsed WebIDL for each browser and included the results that way. It will be exactly the right granularity needed (unlike canIUse…), the work would be useful for other things (such as MDN support tables, Intellisense data in browsers, etc.), and would be another justification to publish the Edge WebIDL. |
This would require understanding each browsers feature flag system, right? We often have webidl present but not enabled yet. |
|
Sure, but the WebIDL info is useful for other reasons too (we probably want to use it for Sonar too), so that will need to be worked out. It would be good to have that documented too as we look at WebIDL to see interop status with browsers. In Edge's case we use [Pref=featureKey] if it is disabled using a runtime flag. It would be useful if we could agree on common ones (although that doesn't help for historical data) |
|
This is a really interesting idea, and I think I like it---if we can get the infrastructure built. (Although I know both Edge and Chrome have projects that have done a lot of this already.) I'm just conflicted as to whether it should replace caniuse or supplement it. I guess that's an easier decision for things like DOM which currently don't have any caniuse boxes (only HTML does). |
|
What I'm picturing, by the way, is tiny little browser logos next to every API documented in the "Non-normative (for web developers)" boxes. |
For What It's Worth...I'm currently contributing to an initiative https://github.com/mdn/browser-compat-data to better define the compat table with JSON data from Github. Any value in extrapolating data from this repo? This is an area that has been frustrating to me previously. To be clear this is a fairly new initiative (i've been completing web components). Seems like the majority of momentum is around HTML and CSS. Web APIs relatively sparse with contributors working on respective interests from what i've seen. However, the intent is to have full coverage. I could be loading up a footgun as haven't done an assessment of what it would take to "complete the dom" to the liking of our requested needs but I know it will need to be done (eventually) and start down the cowpath. I was confused about how they were going to automate integration into MDN and was given explanation documentation Great idea (or at least better than updating a CMS via a WYSIWYG) on MDN nonetheless. And definitely should be brought to attention just for knowledge's sake.
With this strategy Feature Flags are *Batteries Included. |
|
We have this now, thanks to @sideshowbarker, in the form of MDN buttons. Nice! |
The HTML spec displays little info boxes with relevant caniuse data next to the definitions of various entities.
caniuse likewise has data for many DOM features. It would be nice if the DOM spec could display this data similar to the way it's done in the HTML spec.
The text was updated successfully, but these errors were encountered: