Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No information providedNo milestones specified
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
No information providedThe form seems fields seem to be mostly left empty. I don't think anything should be empty (though a N/A may fit some things). I have questions, but they would mostly be answered by filling in the form and re-posting it.
/Daniel
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnfxj9fo12y5zfJ_TosXUU6LaQ6CAcRSX6nqBGnMUWvHZST9w%40mail.gmail.com.
The page at https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines lists most of the things we want to know before sending a feature out into the wild wild world.
One of the main questions regards compatibility. We want what we do to end up in a web where browsers agree on how something should be rendered which is why we typically require new features to probe Mozilla and WebKit through their web standards positions (unless they have already shipped).
Another aspect of compatibility, and risk, is about web compatibility. Will this change break things? Are we really, really sure? That is why we typically require every feature to have a finch flag so that at least Google Chrome can turn off something that causes unexpected problems.
When I say "typical", it's because no rule fits all, but then we instead need to know why a certain rule does not apply.
You will also see that we ask for some info texts, explainer, specification, that many implementers consider obvious. Often it is not obvious for other people though, and these texts end up in official blog posts and in other external communication.
/Daniel