Re: [csswg-drafts] [css-cascade-6] Should the scope proximity calculation be impacted by nesting scopes? (#10795)

(I said elsewhere that I'd look into the complexity and performance issues re. adding a dynamic number of cascade criteria, but I'm still working on that, so I won't comment on that yet.)

> Could adding a count of nested @scope work as an approximation that does not require dynamic sizing?

> I would be happy with that as an approximation.

That would be _much_ more acceptable, so +1 from me.

I would also argue that it's better for authors to _not_ over-complicate the cascade criteria _even more_, and outer scopes just adding a flat `1` to a single tie-breaker sounds like an easier model to manage mentally.

@mirisuzanne Once, you also believed in the benefit of keeping it simple here:

> "In my mind proximity is a useful heuristic in the simple cases - and this logic [single proximity] continues to handle those cases well. Once things get more complicated, authors will likely need to think about other cascade controls: layers, specificity, etc. With a heuristic like this, I think it would be a mistake to get too clever about solving more complex scenarios in an abstract or magical way."
[[1]](https://github.com/w3c/csswg-drafts/issues/8380#issuecomment-1414067778)

> "I don't see any reason to have a specificity-like cascade mechanic based on 'how many scopes were used to get here'. That would over-complicate what scope is about."
[[2]](https://github.com/w3c/csswg-drafts/issues/8380#issuecomment-1458758527)

I still haven't seen an actual reason to change anything here, but I can live with @dshin-moz' proposal in any case.

-- 
GitHub Notification of comment by andruud
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10795#issuecomment-2405792557 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 10 October 2024 18:36:19 UTC