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.
