LGTM3
/Daniel
On 2025-02-24 17:16, Chris Harrelson wrote:
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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-rm%2Bi2ppUT9di0XB%2BVB99-wiek1mCOcH8dSJLT%2BYKhtg%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/da492c94-fab2-4a58-ae03-84ec8582037d%40gmail.com.
