Code Monkey home page Code Monkey logo

Comments (9)

sideshowbarker avatar sideshowbarker commented on July 28, 2024 1

Here’s a checklist with URLs for the targets of all caniuse annotations in the HTML spec.

All the URLs that are checked off are ones for which we have corresponding MDN annos.

All the URLs that aren’t checked off are ones for which we’re missing corresponding MDN annos.

checklist

from html-build.

annevk avatar annevk commented on July 28, 2024

cc @whatwg/documentation

from html-build.

sideshowbarker avatar sideshowbarker commented on July 28, 2024

Here for now are some responses about the specific cases @domenic found in his spot check:

Examples of where caniuse is better:

mdn/browser-compat-data#5968

https://html.spec.whatwg.org/#dom-btoa and https://html.spec.whatwg.org/#dom-atob at this point seem to have what looks to be pretty-complete details

(Also MDN has 2 entries for Firefox and 2 for Firefox for Android, which is bad.)

That’s since been fixed.

The MDN anno there and Can I Use anno there both now show version 79 for Edge.

mdn/browser-compat-data#5970

mdn/browser-compat-data#5980

After this, I’ll post a comment with checklist for all 91 of the current caniuse annos we have.

from html-build.

domenic avatar domenic commented on July 28, 2024

Amazing work; thank you!

https://html.spec.whatwg.org/#offline 👎 deprecated — application cache

I think MDN should still have data for this, especially because it will soon start showing "upper ranges" where the feature was removed. But, I don't think adding such data needs to block our work on removing caniuse boxes, since about the time that data becomes extra-useful, we'll be removing the feature from the spec anyway, so the annotation wouldn't even be visible.

🤔 we don’t really need an anno for this

For SVG and XHTML I kind of like the historical value of knowing when browsers started supporting those. But, it's not really important for 99% of readers, so yeah, probably best to omit.

from html-build.

Elchi3 avatar Elchi3 commented on July 28, 2024

fwiw, if you are curious about how the two data sets compare: I researched this here mdn/browser-compat-data#4051. Let me know if there are any questions.

from html-build.

sideshowbarker avatar sideshowbarker commented on July 28, 2024

So I came around to deciding it’d kind of be a UX regression for readers of the spec if we removed any caniuse annotations that didn’t have corresponding MDN annotations.

I think it’d also be a UX regression if we quit providing readers with information about the fact that caniuse has a page associated with a particular feature.

Therefore I made some changes to https://github.com/w3c/mdn-spec-links which ensure:

  1. Every current caniuse.com anno in the spec now has a corresponding MDN anno.
  2. Every MDN anno for which there’s a corresponding caniuse.cm page now has a link to the caniuse.com page

Below is the complete set of has-caniuse-annotation anchors. We should review to confirm that each now also has an MDN anno, and to confirm that the MDN anno has a caniuse.com link.

from html-build.

domenic avatar domenic commented on July 28, 2024

So I came around to deciding it’d kind of be a UX regression for readers of the spec if we removed any caniuse annotations that didn’t have corresponding MDN annotations.

I agree, thus this issue, saying that we should make sure MDN has data for everything :).

I think it’d also be a UX regression if we quit providing readers with information about the fact that caniuse has a page associated with a particular feature.

I'm not sure I agree with this. Caniuse seems like just a worse version of MDN compat data. (In that, the community seems to be rallying around MDN compat data. And also, MDN pages have documentation.) What is the value in linking to both?

Every current caniuse.com anno in the spec now has a corresponding MDN anno.

Yay!

Every MDN anno for which there’s a corresponding caniuse.cm page now has a link to the caniuse.com page

I'm not sure I see the need for this. It also requires us to continue downloading and dealing with caniuse.json, which I was hoping to remove and thus simplify the build process. (That's pretty far down on the priority of constituencies, though.)

Thoughts welcome, and feel free to reach out on IRC if you'd like more real-time discussion... in the end I'm happy to trust your judgment on this area more than my own, and have you be the owner of any ultimate decisions. But I think it's worth talking things through.

from html-build.

sideshowbarker avatar sideshowbarker commented on July 28, 2024

So I came around to deciding it’d kind of be a UX regression for readers of the spec if we removed any caniuse annotations that didn’t have corresponding MDN annotations.

I agree, thus this issue, saying that we should make sure MDN has data for everything :).

I think it’d also be a UX regression if we quit providing readers with information about the fact that caniuse has a page associated with a particular feature.

I'm not sure I agree with this. Caniuse seems like just a worse version of MDN compat data.

I think that may not be a fair characterization.

(In that, the community seems to be rallying around MDN compat data.

It’s not an either-or. I think a lot of developers still find some value in Caniuse. It’s still widely used. One thing that I think people find appealing about it is the way the data is presented and the options that are provided for filtering it and viewing it in different ways — the site UI.

And also, MDN pages have documentation.) What is the value in linking to both?

What I wrote above and also what @Elchi3 alluded to in #213 (comment) here and wrote about in detail at mdn/browser-compat-data#4051

Every MDN anno for which there’s a corresponding caniuse.cm page now has a link to the caniuse.com page

I'm not sure I see the need for this. It also requires us to continue downloading and dealing with caniuse.json,

No, it doesn’t require that. I instead wrote a mechanism that adds the Caniuse data upstream in the https://github.com/w3c/mdn-spec-links JSON files — and not just for the HTML spec but also for all other specs in https://github.com/w3c/mdn-spec-links which Caniuse has links to.

which I was hoping to remove and thus simplify the build process.

Yeah, we’ll still be able to remove it. See #237 and whatwg/wattsi#124

from html-build.

domenic avatar domenic commented on July 28, 2024

Alright, I'm convinced; thanks for walking me through it. And the unobtrusive way you've added caniuse links is pretty attractive. I'll go review some PRs now.

from html-build.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.