| 16:17 | <MikeSmith> | Mek: FYI https://github.com/mdn/browser-compat-data/pull/7660 “Mark FileSystem*Handle APIs as non-standard” |
| 16:18 | <MikeSmith> | > Since the APIs are a part of a WICG spec, they are currently non-standard. |
| 16:19 | <MikeSmith> | If it’s actually not appropriate to mark those as “not standards-track” in MDN, please consider weighing in on that issue to say so |
| 16:20 | <MikeSmith> | hmm well foolip just now already merged that PR |
| 16:59 | <Mek> | MikeSmith: I think that is consistent with other wicg specs (even ones all browsers implement like https://wicg.github.io/entries-api/ seem to be marked that way) |
| 17:28 | <MikeSmith> | Mek: yeah some are, some aren’t |
| 17:29 | <MikeSmith> | I personally wish we would just get rid of that standards_track flag completely from BCD and MDN |
| 17:29 | <Domenic> | +1... browser support data is way more useful |
| 17:29 | <MikeSmith> | yup |
| 17:29 | <MikeSmith> | ...since whether a particular feature is “standard” is not something web developers actually care about |
| 17:30 | <MikeSmith> | they care which browsers support it |
| 17:30 | <Domenic> | Like the warning at the top of https://developer.mozilla.org/en-US/docs/Web/API/File/webkitRelativePath is kind of silly, and not really accurate... |
| 17:31 | <Domenic> | If there is going to be a warning at the top, I'd rather it be something like "Be careful using this on production sites; it is only implemented in 97% of browsers weighted by usage." (caniuse style) |
| 17:34 | <MikeSmith> | yeah the corresponding wording that is used on the MDN articles is another problem |
| 17:35 | <MikeSmith> | the core problem is really that “standard” and “standards_track” are subjective |
| 17:35 | <MikeSmith> | and we should not be trying to record subjective data |
| 17:35 | <MikeSmith> | we can instead just generate actually-useful indicators like the caniuse style, based on the objective data we already have |
| 17:37 | <MikeSmith> | what we rightly should have in place of “standards_track” is just a clear indicator of whether a feature actually has a spec at all. Any spec, any where |
| 17:37 | <MikeSmith> | there are features in MDN that are not part of any current spec |
| 17:38 | <MikeSmith> | window.applicationCache, for example |
| 17:40 | <MikeSmith> | https://github.com/mdn/browser-compat-data/issues/6905#issuecomment-709047817 |
| 18:24 | <annevk> | Well, Chrome wants to get rid of file entries, no? So trying to get people to not rely on it seems worthwhile |
| 18:27 | <annevk> | I do think it makes sense to signal standards track in some way as they are much more likely to be long term relevant |
| 18:31 | <Domenic> | I don't believe there are any plans to get rid of file entries. |
| 18:31 | <Domenic> | Just the opposite, we wrote a spec so that it could be more widely and interoperably implemented |
| 18:50 | <annevk> | See the upstream to HTML issue |
| 18:54 | <Mek> | I think we would like to get rid of file entries, yes. Even before we wrote the spec we would have prefered something better to replace it, but when everybody else started implementing it that ship kind of sailed. But certainly now I'd love to get rid of file entries eventually (rather than largely duplicate functionality with two different APIs). Realistically I don't see that happening for a very long time though, certainly not for the cross browser |
| 18:54 | <Mek> | bits of file entries. |