- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 27 Sep 2024 00:13:21 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-properties-values-api] "Property registration cannot be scoped" differs from all implementations in a consistent way`. <details><summary>The full IRC log of that discussion</summary> <bkardell_> just will note for the record that I'm not sure people really like parts<br> <khush> astearns nobody matches the spec issue. yay<br> <khush> noamr repeat of the prev one with @property<br> <khush> i opened bugs on all browsers. browsers match but don't match the spec<br> <khush> prop descriptor has spec text that says you can define it in any scope and they are global<br> <khush> but they actually work in the global document only. prop descriptors from shadow dom are ignored<br> <khush> they are diff from everything else, global and inherited by the shadow tree<br> <khush> current way is not bad, it's actually like an api contract<br> <khush> if you have a custom element which uses custom props, you have to import the CSS which will have prop declarations. rather than relying on shadow root to declare those props. it's like a header file<br> <flackr> q+<br> <khush> ideal resolution would be prop descriptor have to be in the Document<br> <astearns> ack flackr<br> <khush> flackr i agree that it's a better model for props which are meant to be used outside. but for the ones meant to be encapsulated, would be nice if they were defined internally only<br> <astearns> +1 to flackr<br> <noamr> q+<br> <astearns> ack TabAtkins<br> <khush> TabAtkins: any shadow internal custom props being in capable of being defined, unless you also include a script or stylesheet globally is bad<br> <emilio> q+<br> <khush> the fact that they can't be scoped at all is a consequence of inheritance. being able to define them internally with a well named internal semantic is worth it<br> <khush> i can accept it being global only.<br> <astearns> ack noamr<br> <khush> noamr one way to resolve this. problem with internal props is that it could be a mismatch. so if it's defined internally, let's make it not inherited<br> <khush> then this is your own property, deal with it<br> <khush> your prop would fallback to what you defined in the descriptor as initial value and not inherit from global scope<br> <khush> TabAtkins what happens on the host element itself. can define something. otherwise the idea sounds reasonable<br> <astearns> ack emilio<br> <khush> emilio was gonna argue for currently implemented behaviour<br> <kizu> q+<br> <khush> as soon as there are name conflicts. you need to remove all the niceties of the shadow dom data encapsulated. have preference for the current behaviour. i need to think through, you have properties with same name. one is defined outside via part one is inside via regular stylesheet. that also seems fairly annoying. preference to just spec what is<br> <khush> currently there<br> <khush> TabAtkins i want to explore the behaviour noam was talking about. if we can find a less annoying version. but ok with specing current behaviour<br> <astearns> ack kizu<br> <khush> kizu: this is something i encounter without shadow dom. multiple sources define the same prop name with different values. if some element registers it with a different value, custom element on the host or regular element on itself. as soon as it reaches this by inheritance it will use initial value if there is a type mismatch<br> <khush> you define for your scope. if an internal one defines the same type then inheritance works otherwise it's overridden<br> <astearns> q+<br> <khush> TabAtkins if noam's idea is limited to defining on tree roots it matches your idea<br> <khush> and sounds reasonable behaviour to me<br> <westbrook> q+<br> <astearns> ack westbrook<br> <khush> astearns my chair hat off, i would accept what noam is proposing. prop def scoped to the shadow root. accept what's currently there, everything is global. don't accept what is currently implemented that shadow dom can't define props.<br> <iank_> q?<br> <khush> westbrook cross shadow boundary and change if there is something defined inside the shadow dom.<br> <emilio> q+<br> <khush> TabAtkins if inheritance carries a font face to the shadow, the font face being defined won't changge<br> <khush> if the outer face defines font face foo, and shadow defines the same. outer sets font-family: foo, it is referring to the outer one. when inherited it refers to the outer one<br> <khush> it won't use the internal one, name collsiion was accident<br> <khush> if the shadow says font-family foo, now it's the internal one<br> <astearns> ack emilio<br> <khush> emilio what is the implemention for font-face. gecko ignores them<br> <fantasai> strong +1 to Tab's point about binding font-family to @font-face before inheritance<br> <khush> TabAtkins it's consisntent. some ignore them internally, some make it global<br> <TabAtkins> s/consisntent/inconsistent/<br> <khush> emilio wouldn't want to expose font faces to document.fonts. haven't discussed this<br> <khush> TabAtkins that is undefined. happy to do reasonable stuff there<br> <khush> TabAtkins we don't have a version of .fonts for shadow trees<br> <noamr> q+<br> <khush> emilio all shadow roots have their fonts in document.fonts is not good behaviour<br> <astearns> ack noamr<br> <khush> TabAtkins figuring out reasonable behaviour there is more complicated<br> <chrishtr> q+<br> <khush> noamr prop is an API surface between shadow roots by definition. and the desc defines an interface point, fonts don't have any of this. they define something else. so the parallel is not right<br> <astearns> ack chrishtr<br> <khush> there's reason default scopung is not for prop<br> <khush> chrishtr let's take it back to the issue<br> <khush> astearns take it back to the issue. see if we can scope the prop definition.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10541#issuecomment-2378154648 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 27 September 2024 00:13:22 UTC