With my HTML editor hat on, I support keeping parity between <a> and <area>. Although <area> is used much less, we try to keep them symmetric whenever possible.
On Fri, Nov 22, 2024 at 5:19 AM Mike Taylor <miketa...@chromium.org> wrote: > On 11/21/24 1:37 PM, Andrew Paseltiner wrote: > > On Thu, Nov 21, 2024 at 1:26 PM Mike Taylor <miketa...@chromium.org> > wrote: > >> On 11/21/24 12:49 PM, Chromestatus wrote: >> >> Contact emails apaselti...@chromium.org >> >> Explainer >> https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md#registering-attribution-sources >> >> Specification >> https://wicg.github.io/attribution-reporting-api/#html-monkeypatches >> >> Summary >> >> For Attribution Reporting, the attributionsrc attribute was already >> unintentionally processed on <area> elements due to code shared with <a>, >> which intentionally supported that attribute. For completeness, we expose >> the attribute on <area> with identical syntax and semantics to <a> and >> without changing the previous processing: When an <area> tag with an >> attributionsrc attribute is navigated, the foreground request may register >> navigation sources and, if the attribute is non-empty, one or more >> background requests will likewise be able to register navigation sources. >> >> Is this something developers actually want, i.e. are imagemaps a use case >> advertisers are asking to be supported? If not, why not just fix what seems >> to be a bug? >> > It's true that we haven't specifically heard from developers that they > want this, but we also don't have any data about whether the existing > behavior is being relied on, and I'm not clear on the prevalence of image > maps for the relevant use cases in general. Is there existing precedent for > supporting a navigation-related feature on <a> but not <area>? > > I don't have the answer to that - perhaps someone else will know. > > > Given that we support this on multiple other navigation surfaces (<a>, > window.open, and context-menu on <a>), and that the fix is quite simple > <https://chromium-review.googlesource.com/c/chromium/src/+/6022268>, I'd > err on the side of not breaking anyone, but we could also try to gather > usage data first. > > Yes, agree - we should take a look at usage/potential breakage here. Have > you tried to look at HTTPArchive? This feature has shipped long enough that > there should be something there (if anything exists at all). Or there's the > regular UMA route, but that's slower. > > Blink component Blink >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink> >> >> TAG review Covered by existing Attribution Reporting I2S as this is a >> small change re-using the existing API surface. >> >> TAG review status Not applicable >> >> Risks >> >> >> Interoperability and Compatibility >> >> None >> >> >> *Gecko*: No signal >> >> *WebKit*: No signal >> >> *Web developers*: No signals >> >> *Other signals*: >> >> WebView application risks >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> >> No. >> >> >> Debuggability >> >> None >> >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, ChromeOS, Android, and Android WebView)? Yes >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? Yes >> >> Flag name on about://flags None >> >> Finch feature name None >> >> Non-finch justification >> >> This is a minor change largely reusing existing code and behavior. The >> only web-exposed detail here is the addition of an already-processed HTML >> attribute to the corresponding tag's IDL definition. >> >> >> Requires code in //chrome? False >> >> Tracking bug https://issues.chromium.org/379275911 >> >> Measurement n/a >> >> Availability expectation Covered by existing Attribution Reporting I2S >> as this is a small change re-using the existing API surface >> >> Adoption expectation Covered by existing Attribution Reporting I2S as >> this is a small change re-using the existing API surface >> >> Adoption plan n/a >> >> Non-OSS dependencies >> >> Does the feature depend on any code or APIs outside the Chromium open >> source repository and its open-source dependencies to function? >> No. >> >> Estimated milestones >> Shipping on desktop 133 >> Shipping on Android 133 >> Shipping on WebView 133 >> >> Anticipated spec changes >> >> 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). >> n/a >> >> Link to entry on the Chrome Platform Status >> https://chromestatus.com/feature/6547509428879360?gate=6545976813420544 >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com>. >> -- >> 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+unsubscr...@chromium.org. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/673f72a6.2b0a0220.3bb1d2.02f2.GAE%40google.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/673f72a6.2b0a0220.3bb1d2.02f2.GAE%40google.com?utm_medium=email&utm_source=footer> >> . >> >> -- > 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+unsubscr...@chromium.org. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5f406b3c-98f1-4f62-94e9-43e61bba4556%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5f406b3c-98f1-4f62-94e9-43e61bba4556%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_QftG9w%2BeZ6RjHtws3yqqH3tp89b7684VSNuhrhLPs%3DQ%40mail.gmail.com.
