Re: [csswg-drafts] [css-values] A way to dynamically construct custom-ident and dashed-ident values (#9141)

> > ([#](https://github.com/w3c/csswg-drafts/issues/9141#issuecomment-1759669029)) Iā€™m not sure if the best solution is a way to construct dynamic idents, or just better scoping for these features. E.g. what if nesting these inside other rules also scoped their idents?
> 
> Can you please elaborate? I don't fully understand.

I think @LeaVerou means that if names could be contained/scoped by _whatever trigger_, that would open up the way to safely allow duplicate names to exist alongside each other.

While that would work in some cases ā€“ i.e. where children look up the DOM tree to get access to a thing with a certain name ā€“ it does not work when all those named items are part of bigger whole.

For example: View Transitions with many cards still need a unique name on each card as they all participate in the same VT, or ScrollTimelines that all need to be hoisted up to a shared parent via `timeline-scope`, same with anchoring, etc.

> ([#](https://github.com/w3c/csswg-drafts/issues/9141#issuecomment-1759669029)) With dynamic idents authors still need to think of a way to ensure uniqueness, which increases cognitive overhead, and is error prone.

They already need to think about uniqueness in many cases (names for view-transition elements, containers, timelines, anchors, custom properties, etc). The solution that is pursued here would allow authors to dedupe a lot of repetitive uniqueness.

E.g. things like this:

```css
/* This requires uniqueness in HTML and CSS */
#item-1 { --item-id: item-1; }
#item-2 { --item-id: item-2; }
#item-3 { --item-id: item-3; }
#item-4 { --item-id: item-4; }

/* This requires uniqueness only in HTML, as CSS can access those values */
.item { --item-id: ident(attr(id)); }
```

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


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

Received on Tuesday, 9 April 2024 09:30:46 UTC