- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Sep 2024 23:56:46 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-scoping] Breaking name encapsulation`. <details><summary>The full IRC log of that discussion</summary> <khush> TabAtkins: we talked about tree scoping, names and references. filling context<br> <khush> when you are in a shadow tree you can see names defined in your tree and outer tree but not in other shadow trees<br> <khush> similarly you can't in the main page see names defined in inner shadow trees<br> <khush> good thing when you don't want to expose. but people complain about not being able to do componenets, example to anchor to elements in shadow trees<br> <khush> proposing a solution, allow exposing names in accessible fashion<br> <khush> new global func takes a custom ident. can be used anywehre you define a custom ident<br> <khush> instead of carrying the scope where it's defined, it becomes a global tree scope. not a root tree scope. explicit opt-in to the scope<br> <khush> so intentional process to both define and name things<br> <khush> you can get names from anywhere inn the tree, any shadow<br> <khush> if you're not using global, it acts the same as today<br> <khush> anders says its reasonable<br> <khush> right now tree scope is a tuple of ident and scope. this would just set scope to null. and null matches null<br> <khush> i'd like to turn this into the scoping spec<br> <emilio> q+<br> <noamr> q+<br> <lea> You might want to look at reference target and follow a similar design<br> <khush> we can resolve to republish the spec them<br> <khush> *then<br> <astearns> ack emilio<br> <khush> emilio: would this only be anchors or other names too<br> <khush> depending on the kind of data refernced by the name, might not trivial to get random data<br> <khush> TabAtkins: it should work for all tree scoped names and references<br> <khush> you'd still be able to do the encapsulation by default<br> <khush> only things defined by global are accessible<br> <khush> emilio: unless you have a global map of name or something else. you have to go through all the shadow trees<br> <lea> What is the use case for eg keyframes?<br> <khush> TabAtkins yes a global map is needed but not all references<br> <keithamus> q+<br> <khush> emilio: any other opinions? global map is based on the DOM. it's different for keyframes. That data in a centralized space in a shadow tree. keyframes won't be tree scoped names?<br> <westbrook> q+<br> <khush> TabAtkins: it's in the list of things in the scoping spec that need to be updated to be tree scoped<br> <astearns> ack noamr<br> <khush> noamr: i find globals to be messy. replacing something encapsulated with something which causes a footgun. people would want global but not too global. export semantic is better. we use the host pseudo class in the shadow dom to export names and import from outside. so you can track the chain, rather than one global map everything goes into<br> <khush> global is simpler than this, you just have one thing. css has shown that these things become a problem like z-index.<br> <khush> web apps become more complex as a result<br> <khush> TabAtkins hoping to get away with one additional scope. ok with import/export. it makes the concept harder. you need a way to explicitly refer, this name from keyframe is exported. this name from anchor is exported<br> <khush> so harder to use but not impossible<br> <astearns> ack keithamus<br> <khush> explicit import syntax would help emilio's concern. having to search everything in a global map<br> <khush> keithamus: what happens in a collision?<br> <khush> TabAtkins same as defining a name twice in the same scope. one wins, based on some order<br> <astearns> ack westbrook<br> <khush> TabAtkins you should rename using import/export<br> <khush> westbrook: like this idea. passing them across subtrees is good. could also extend to anchor across containing blocks?<br> <khush> TabAtkins wouldn't let you violate that. it's a required thing based on timing of layout. it's logically impossible, it would let you lift a name from a shadow and use it somewhere else<br> <khush> layout constraints are still obeyed<br> <khush> astearns any other comments?<br> <khush> q+<br> <fantasai> scribe+<br> <fantasai> khush: I just agree conceptually with what noamr said.<br> <fantasai> khush: a single global map is a footgun, better if can explicitly export / import / rename<br> <fserb> q+<br> <fantasai> khush: that gives an opt-in from both sides, otherwise shadow tree can export into global() stuff the outer context doesn't want<br> <astearns> ack khush<br> <fantasai> TabAtkins: how much can we get away with using global and just have shadow tree say<br> <khush> ScribeNick khush<br> <khush> TabAtkins you can grab what you want as a whole, don't have to ref everything indvidiauly. prevent accidental collision in the global space. let you know which shadow trees to recurse into so you don't have to walk all trees<br> <astearns> ack fserb<br> <noamr> It's like "import * from"<br> <khush> fserb: for this idea if you do something like import/export, you would have to go through the parent. Is this a use-case that matters, sharing things. you mention that on the explainer.<br> <noamr> q+<br> <astearns> ack noamr<br> <khush> fserb sibling shadow trees<br> <khush> noamr: would have to go through the parent. you can redo this with parts, probably have a semantic with this for names. anchor/ view transition are peer to peer rather than hierarchical.<br> <khush> fserb is there a real use-case for more direct sibling to sibling? global would do that.<br> <khush> fserb export from here, import in the root and then export to sibling<br> <khush> TabAtkins most refs walk the tree to find in parent space so just export to sibling. anchor is not doing but likely change has to happen for anchor. the use-case is important<br> <khush> TabAtkins: can take it back to the issue now<br> <khush> astearns come up with an import/export mechanism. get anders feedback<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10808#issuecomment-2378137610 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 26 September 2024 23:56:46 UTC