LGTM2 On Mon, Feb 24, 2025 at 2:15 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/91e9b0ed-6575-4876-83bb-55e12e244cc3n%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/CAOMQ%2Bw-rm%2Bi2ppUT9di0XB%2BVB99-wiek1mCOcH8dSJLT%2BYKhtg%40mail.gmail.com.
