Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

consider replacing caniuse links with MDN links #375

Open
dbaron opened this issue Jun 24, 2020 · 4 comments · May be fixed by #1146
Open

consider replacing caniuse links with MDN links #375

dbaron opened this issue Jun 24, 2020 · 4 comments · May be fixed by #1146

Comments

@dbaron
Copy link
Contributor

dbaron commented Jun 24, 2020

To follow up on #371 (comment) and following comments -- I think we should consider replacing the links to Can I use with links to MDN. It seems like a number of the newer caniuse tables are (based on the IDs) powered by MDN data underneath anyway, and it seems like MDN provides more depth of information.

Thoughts?

@adamroach
Copy link
Contributor

Given how much more detail MDN provides, this sounds like a net improvement to me. On a quick glance through those few entries with non-null ciuName fields, I see straightforward replacements for most of them:

WebMIDI is an exception, as there is no parent article, so we'll probably want to support linking to multiple pages:

Client hints is another exception, as we have a compatibility table per header, all on different pages: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Client_hints

So maybe this needs to be an array of links instead of just a single link per entry.

@dbaron
Copy link
Contributor Author

dbaron commented Jun 24, 2020

It's also not clear to me that we'd want to link specifically to the Browser compatibility table rather than linking to the MDN article as a whole (which in turn has a browser compatibility table).

@martinthomson
Copy link
Member

An array of links to resources on compatibility seems fine. I am ambivalent on article vs. table - if the goal is to provide information on compatibility, then the table is probably OK.

(As Adam has done most of the legwork, I'm OK with doing some replacements, but I would be happy leaving caniuse links in place for older items and having MDN as the target for newer ones.)

dbaron added a commit to dbaron/standards-positions that referenced this issue Jul 15, 2020
This fixes part of mozilla#375.  It does the following:

 * adds an mdnUrl field to activities.json, using @adamroach's list in
   mozilla#375 (comment)
   which can either be a string or an array of strings (like mozBugUrl)

 * adds a way to show the MDN icon in the "More Info" column (which I
   commit as an asset rather than picking a glyphicon, and use via CSS
   mask).

 * adds code to validate the new field in activities.py (matching
   mozBugUrl)
dbaron added a commit to dbaron/standards-positions that referenced this issue Jul 15, 2020
This fixes part of mozilla#375.  It does the following:

 * adds an `mdnUrl` field to `activities.json`, using @adamroach's list in
   mozilla#375 (comment)
   which can either be a string or an array of strings (like `mozBugUrl`)

 * adds a way to show the MDN icon in the "More Info" column (which I
   commit as an asset rather than picking a glyphicon, and use via CSS
   mask).

 * adds code to validate the new field in activities.py (matching
   `mozBugUrl`)

 * adds code to add the new field for the `add` verb in `activities.py`
dbaron added a commit to dbaron/standards-positions that referenced this issue Jul 15, 2020
…ozilla#396, part 2)

This fixes part of mozilla#375.  It does the following:

 * adds an `mdnUrl` field to `activities.json`, using @adamroach's list in
   mozilla#375 (comment)
   which can either be a string or an array of strings (like `mozBugUrl`)

 * adds a way to show the MDN icon in the "More Info" column (which I
   commit as an asset rather than picking a glyphicon, and use via CSS
   mask).

 * adds code to validate the new field in activities.py (matching
   `mozBugUrl`)

 * adds code to add the new field for the `add` verb in `activities.py`
dbaron added a commit to dbaron/standards-positions that referenced this issue Jul 20, 2020
…ozilla#396, part 2)

This fixes part of mozilla#375.  It does the following:

 * adds an `mdnUrl` field to `activities.json`, using @adamroach's list in
   mozilla#375 (comment)
   which can either be a string or an array of strings (like `mozBugUrl`)

 * adds a way to show the MDN icon in the "More Info" column (which I
   commit as an asset rather than picking a glyphicon, and use via CSS
   mask).

 * adds code to validate the new field in activities.py (matching
   `mozBugUrl`)

 * adds code to add the new field for the `add` verb in `activities.py`

Co-authored-by: Martin Thomson <[email protected]>
dbaron added a commit that referenced this issue Jul 20, 2020
…396, part 2)

This fixes part of #375.  It does the following:

 * adds an `mdnUrl` field to `activities.json`, using @adamroach's list in
   #375 (comment)
   which can either be a string or an array of strings (like `mozBugUrl`)

 * adds a way to show the MDN icon in the "More Info" column (which I
   commit as an asset rather than picking a glyphicon, and use via CSS
   mask).

 * adds code to validate the new field in activities.py (matching
   `mozBugUrl`)

 * adds code to add the new field for the `add` verb in `activities.py`

Co-authored-by: Martin Thomson <[email protected]>
@zcorpan
Copy link
Member

zcorpan commented Nov 27, 2024

I suppose we should add an MDN field to the issue template, and maybe remove the caniuse field?

zcorpan added a commit that referenced this issue Dec 16, 2024
zcorpan added a commit that referenced this issue Dec 16, 2024
@zcorpan zcorpan linked a pull request Dec 16, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants