On Tue, Dec 3, 2024 at 9:31 PM Stephen Chenney <schen...@chromium.org>
wrote:
On Tue, Dec 3, 2024 at 8:13 PM Vladimir Levin
<vmp...@chromium.org> wrote:
On Tue, Dec 3, 2024 at 10:34 AM Stephen Chenney
<schen...@chromium.org> wrote:
On Mon, Dec 2, 2024 at 11:38 AM Andrew Paseltiner
<apaselti...@chromium.org> wrote:
On Thu, Nov 21, 2024 at 9:50 PM Domenic Denicola
<dome...@chromium.org> wrote:
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.
Sounds to me like we should go ahead with this for
parity.
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.
It would surprise me if this data showed up in
HTTPArchive -- the majority of attributionsrc uses
will be in dynamically injected DOM elements.
We could try to go with UMA, but it may not be worth
the effort.
After recent breakage (caused by me) there's a desire to
add UseCounter or other lightweight UMA tracking before
changing web-facing behavior, particularly when there is
otherwise no real way of knowing if anyone is relying on
it. The lack of developer signals increases the risk, as
does the very long time the existing behavior has been in
place.
I do strongly agree that the feature is worth doing.
Stephen.
I'm not sure I understand what we would be measuring? As I
understand it, this intent is to expose attributionsrc on
<area> where previously it wasn't exposed, although it was
already processed. It doesn't sound any different from typical
"new feature" intents, in that we don't usually check if
names, for example, conflict with existing code. If anything,
this seems even safer in that the actual behavior wouldn't
change (due to a current Chromium bug).
Thanks,
Vlad
I made the comment about getting usage data because the
conversation so far seems to be indicating some chance of breakage.
I guess to get breaking behavior you would need to be trying to
set element.attributeSrc in JS on an <area> element and having it
fail now, while it would start to work once this change is made.
Is that right?
In which case I don't think there is any way to measure that ahead
of time. It's also hard to see how a site would depend on the call
failing. But you could add a use counter to the CL and see if
there is any immediate usage at all, as anything other than
near-zero initial usage suggests the JS code was already in place
somewhere.
Or is there some other path to breakage?
We can add a usage counter, but I'm not clear on how this change could
cause any breakage: Even setting element.attributionSrc in JS today on
an <area> element wouldn't throw an exception or otherwise break; it
would just create a new property on the element that does nothing.
Stephen.
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/CAP6jJUgkRFLr%3DP5FumrCoOh1bFembn6FqASLcm4BtZ5Vg4b7rw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP6jJUgkRFLr%3DP5FumrCoOh1bFembn6FqASLcm4BtZ5Vg4b7rw%40mail.gmail.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/CAGsbWzQispi5Y8N7oWLjhS26U5p3TRs7HbZXcfjGyQg17Mgkfw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzQispi5Y8N7oWLjhS26U5p3TRs7HbZXcfjGyQg17Mgkfw%40mail.gmail.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/CAP6jJUhuAYmCTDQXSNmC9uH4KGYeuN9DnMyYWTiQiRsFsnh1Zg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP6jJUhuAYmCTDQXSNmC9uH4KGYeuN9DnMyYWTiQiRsFsnh1Zg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
