Remove totally unimplemented things #6768
Comments
|
+1 to removing all of those. And it seems like a good list at first glance — but it’d also be great if we could have reproducible automation/script anybody could run themselves that’d programatically identify such ought-to-be-removed features. Otherwise, without going in and manually double-checking one-by-one each feature in the list in the issue description, nobody has any way to know if some feature might have crept into the list by mistake but shouldn’t actually be included — nor whether there are features missing from the list which should have been included. |
queengooborg
added
the
bulk_update 📦
|
Should implemented and not specified be removed or remain? |
|
Yeah, I'm supportive of removing never-implemented features. We have a data guideline that is meant to cover just such situations. That said, a lot of these have corresponding MDN pages and a pretty old, so it's probably worth the effort to make sure these things actually don't exist in browsers (and not do a mass deletion).
Yes. BCD tracks the things browsers actually do, even if they're non-standard. We do have status information to note this, however. |
|
I think we can immediately remove "Not an interface nor a mixin" things, what do you think? |
|
Do we want to remove experimental-but-unimplemented things here or should I keep them? I guess notes to tracking bugs would be helpful if we want to keep them. |
|
@saschanaz Yeah, I think it makes sense to take a look at anything that hasn't been implemented, experimental or not. For each one, we could take a closer look to see if it's in an active spec or if an implementation is in progress. Then we can use notes to make it clear what's going on with those features that we should retain, or remove them if not. |
|
The following elements all had been included in the issue description here, but subsequently the data was updated to reflect that they all actually have been implemented, in WebKit.
I edited the issue description to mark them in strikethrough — but it seems like it’d be fine to further edit the issue description to completely remove any mention of them. |
The SVG color-profile & solidcolor elements have never been implemented in any browser engines, so this change removes the data for the elements as well as the data for their associated APIs. Related: mdn#6768
The SVG color-profile & solidcolor elements have never been implemented in any browser engines, so this change removes the data for the elements as well as the data for their associated APIs. Related: mdn#6768
The SVGStylable interface as such has had no shipping implementation for years. The current BCD data indicates it was previously in Firefox but removed years ago, and was (maybe) part of (pre-Blink) Edge. It was also apparently once part of Webkit, but in 2013 was removed in https://trac.webkit.org/changeset/140265/webkit, with change message: > SVG2 changes element inheritance so all SVGElements are stylable. As > a first-step towards a cleaner class hierarchy, this patch moves > SVGStylable into SVGStyledElement. https://developer.mozilla.org/en-US/docs/Web/API/SVGStylable already has it marked as deprecated. Related: mdn#6768
The SVG color-profile & solidcolor elements have never been implemented in any browser engines, so this change removes the data for the elements as well as the data for their associated APIs. Related: #6768
|
I just did a check and found that everything has either been removed or actually is supported, so this is now good to close! |
and others
Below are interfaces that have never been implemented per the data, or just no data.
Marked as deprecated/obsolete:
Not an interface nor a mixin:
Experimental (probably okay to exist):
The text was updated successfully, but these errors were encountered: