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? 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/CAGsbWzQEbqPmmiUKP0LWiZU6uqH%3DGmkONQ5LYCuvLta4NMRFow%40mail.gmail.com.
