Document Body.p.formData as always rejecting#6619
Conversation
|
@ddbeck can you advise on how you'd like to handle this? It didn't work, but yet it was there and would break feature detection. Thus knowing about it is somewhat useful to web developers, but tooling using BCD might be better off thinking that it's not supported at all. |
ddbeck
left a comment
There was a problem hiding this comment.
Ugh, this is such a weird thing. Weird things make for weird data.
We have a guideline that's supposed to cover a situation like this: https://github.com/mdn/browser-compat-data/blob/master/docs/data-guidelines.md#non-functional-defined-names-imply-partial_implementation After re-reading the PR which prompted it, I think I still come down in the same place as before: we should report this as partial_implementation. It has an implementation, even if that implementation is non-standard (NotSupportedError notwithstanding).
That said, the new note here is much more descriptive. I think that's the core of the thing (it's going to be weird either way, but a good note helps).
Of course, this will be much friendlier as a table when Safari has a functioning release.
5d15614 to
91fc2f7
Compare
Even though it doesn't work at all, it should be partial_implementation per https://github.com/mdn/browser-compat-data/blob/master/docs/data-guidelines.md#non-functional-defined-names-imply-partial_implementation This is a follow-up to mdn#6616. Co-authored-by: Daniel D. Beck <daniel@ddbeck.com>
91fc2f7 to
7a491c5
Compare
|
Thanks @ddbeck! I don't know that I agree with https://github.com/mdn/browser-compat-data/blob/master/docs/data-guidelines.md#non-functional-defined-names-imply-partial_implementation in this case, but we don't have a perfect way to represent "feature detection would suggest it exists but it doesn't work at all" in the data, so I'm not going to try to overturn the guideline. Once this is shipped in Safari, which is soon, the data will look OK to MDN readers. Do you think we should have an issue to collect cases that break feature detection, to see if there are enough to warrant representing it in the data? |
Yes, I think it would be a good idea to collect such cases. I'd be open to revising the guidelines around this stuff, if we had a better idea of what's affected. For what it's worth, my thinking on this was mainly influenced by no-op CSS values (where no-op and invalid behave rather differently). Thinking on it now, it might make sense to have different guidelines for CSS and APIs. Having a list of known-problematic features would probably make it a lot easier to document the distinction (and encourage us to be a bit more prescriptive about what the notes would say). |
|
I've filed #6636. I know there are plenty of these, but won't hunt them all down now. |
Even though it doesn't work at all, it should be partial_implementation
per https://github.com/mdn/browser-compat-data/blob/master/docs/data-guidelines.md#non-functional-defined-names-imply-partial_implementation
This is a follow-up to #6616.