-
Notifications
You must be signed in to change notification settings - Fork 10
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
Need for a predictable error type for unimplemented Element subtypes #55
Comments
The cropTo spec algorithm should not require per-Element implementation AFAIK (if it does, we should clarify that). The algorithm relies solely on the element's bounding client rectangle, something every Element should have — even if it's
Then they're not spec compliant, I think is the answer. Allowing implementations some time to catch up with specs seems fine and normal for a while — Firefox throws
I think that would send the wrong message. Web developers need to know when they're expected to file bugs on vendors and when they should not. In this case, I'd prefer they file bugs. To that end, I think having the spec say failing in this way is NOT to spec, helps clarify that they're expected to file bugs. I do see some uses of |
Youenn has brought up a similar concern. This is unclear to me. Users installing a browser would notice when applications don't work. That the failure makes the browser "compliant" is not going to help such a browser gain/retrain market-share. Implementers are motivated to implement missing functionality, independently of compliance.
Similarly, I don't think Web-developers would refrain from filing a bug over missing functionality under the assumption that a "compliant" browser is complete by definition. I imagine people ask for Firefox and Safari to support tab-capture, without caring whether the spec allows getDisplayMedia() to not offer tab-capture.
Where is the bar? |
Here you seem motivated by compliance.
Some specs deliberately allow UAs to support types beyond a minimal required set, which is not the case here. This spec says all elements must work. This spec suggests a way to implement this that doesn't fail for future element types. |
+1 to what said @jan-ivar. |
That's a non sequitur. Of course Chrome cares about compliance, but how is that relevant? Would Chrome now ship null-functioning APIs and declare success? Has Chrome funded this effort of standardization and implementation of Region Capture as a strange joke? What do you mean to say here? I also ask you to examine with your chair's hat on, whether your comment here falls within the guidelines of this WG's discourse.
Thanks for clarifying your positions here, @jan-ivar and @youennf. I disagree with your bar, but now I know where it is. |
FWIW, I am basing my assessment of what the bar is on how existing specs are written. |
CropTarget.fromElement()
receives anElement
as input.Element
has many subtypes, and some new ones will be introduced over time. Some implementations will, at certain timepoints, not support certain subtypes. Web-developers would appreciate a predictable failure path for still-unimplemented subtypes. (The alternative - each user agent failing differently - is clearly undesirable for Web developers.)Note on background discussions: Three criteria have been described in previous discussions. The current issue refers to the second of these.
The text was updated successfully, but these errors were encountered: