- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Thu, 27 Oct 2022 17:00:37 +0000
- To: public-css-archive@w3.org
> Blink's tokenizer would not be happy about that; we don't always keep the raw string around after tokenization, so it would not be easy for us to re-tokenize How difficult/expensive would it be to *change it* to do so? > (and tokenization is a nontrivial part of the page load cost, so tokenizing things twice would also be bad). Please read the first post more carefully — the retokenization would only be needed on a tiny fraction of nested rules (namely element selectors followed by a pseudo-class). > So that's both a confirmation that keeping the tokens around are bad, and a NAK on the workaround of re-tokenizing. I opened this issue so we could all think hard about this problem, instead of treating it as insurmountable from the get go. So far we have been designing syntax around it, accepting it cannot possibly be solved in a performant way as an axiom. I'd like us to challenge that assumption, and for that we need more details from implementers than "NAK". If all implementations have similar issues, that's a stronger argument, but I’m wary about designing syntax that will be suboptimal for authors forever, so that Nesting can be implemented without many changes to Blink's CSS parser. Could we please examine the impact more closely, and maybe do actual measurements, as @emilio is willing to do for Gecko? ----- @tabatkins Yeah, that's unfortunate but I could ping the httparchive guys to measure how many custom property declarations actually have curly braces in them, I suspect it's going to be a negligible amount. It is already illegal to include an opening curly brace without a closing one, so it's not like custom properties are completely unrestricted rn and would have to become restricted — they'd just become a tiny bit more restricted. -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7961#issuecomment-1293817181 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 27 October 2022 17:00:39 UTC