LGTM1 On Thursday, February 20, 2025 at 6:45:09 AM UTC+1 Yoav Weiss wrote:
One point worth clarifying - this intent doesn't relax the current restrictions on visited styling, right? Are there plans to follow up with that? That seems like something designers would be happy with.. On Wednesday, February 19, 2025 at 9:55:13 PM UTC+1 Kyra Seevers wrote: Hi all - thanks for your review! > Couldn't this be tested with reftests <https://web-platform-tests.org/writing-tests/reftests.html>? I'm happy to work on a reftest to add the benefit of test automation, but in the meantime, I have landed a manual test <https://github.com/web-platform-tests/wpt/blob/master/css/selectors/partitioned-visited-manual.tentative.html> to verify the same behavior. > On compat, can we allay the concerns here with a fractional rollout (e.g., ~10% for a couple of releases) and a check-in at some point(s) before we go to 100% The plan is to do a cautious-style Finch rollout, rolling out by increasing percentages of stable (like Stable 10%), before completely rolling out to Stable 100%. I support a Finch rollout, but are there really compat concerns? Or more "user expectation" concerns? Let me know if you have any more questions! Thanks, Kyra On Wed, Feb 19, 2025 at 3:34 PM Tab Atkins Jr. <jackalm...@gmail.com> wrote: On Wed, Feb 19, 2025 at 3:44 AM Yoav Weiss (@Shopify) <yoavwe...@chromium.org> wrote: > Could the relevant spec language live in a PR? Having such language would make it easier to evaluate the gap between the current CSS spec and the ability to specify this behavior in an interoperable way. The current appendix should describe the behavior in sufficient detail for that purpose: it details exactly how to construct the caching key and what keys to add, using the specific HTML terms (origin, site) that we're relying on. Official spec text would just be slightly more precise with its terms, but not, afaict, in a way that would affect implementability. Re-reading through this, what I'd love to see is: * An HTML PR that properly integrates the "Whenever a navigation is triggered from within a page" parts of that appendix (maybe as part of "navigate a navigable <https://html.spec.whatwg.org/#navigate>". Domenic would know for sure), and defines "visited history" as a set owned by the user agent. * Define a "can show visited state" (or some other name) exported in algorithm in HTML that makes use of the above and replaces the "When determining if a link element" parts of the appendix. * Refer to all that from an appendix in CSS until a time when the CSSWG feels comfortable enforcing this instead of the current fuzzy set of mitigations. Talking to Tab and Kyra off list, I'm now convinced that the current spec is Good Enough™ (for now). There are a couple of questions to be answered: * When does the insertion to the "visited set" happen? * What navigations are considered from "within a page"? However, there's no current implementation consensus on the answers to these questions. The team seems committed to working towards alignment across implementations there after shipping, so I'm convinced we shouldn't block shipping this on precise specifications that won't necessarily help progress towards interop. This is already more detail than what is specified for our *existing* :visisted behavior, fwiw, which just exists in an MDN page and still leaves many precise details (such as exactly what selectors are allowed) to the imagination. That's a good point. But we should aim to improve our standards. ~TJ -- 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/91e9b0ed-6575-4876-83bb-55e12e244cc3n%40chromium.org.
