- From: Peter Linss via GitHub <sysbot+gh@w3.org>
- Date: Fri, 14 Apr 2023 23:38:05 +0000
- To: public-css-archive@w3.org
> In general, having the OM not reflect the stylesheet is something we should avoid as much as possible; I agree (and as I said above I'm not sure I'm actually in favor of this proposal). Normally, I'm already bothered by the amount of normalization we do in serialization. Where this came from was the thought experiment of a site serving a nested stylesheet but having a polyfill to desugar it for older clients (or differentially serving the desugared version as needed). In that case, any code that interacts with the stylesheet needs to be prepared to work with either version of the OM, which can get awkward. If the client just always desugared, they'd both have the same OM. Provided the polyfill and/or transpiler did the desugaring correctly, and we'd need to specify that, but we sort of do that anyway by explaining how the nested rules behave. If we did this tho, we'd consider the desuarging part of the normalization (yeah, it's a stretch). An other aspect of that would be possibly converting existing rules into nested ones during serialization. Again, a stretch, and not something I think I'm in favor of, but it's sort of consistent... A possible alternative would be adding a method that converts a nested stylesheet to a desugared one (and possibly one to nest everything that can be). That way if an author can get either version of a stylesheet, and wants to only write one set of code to deal with it, they can convert back and forth at runtime... That might make more sense as a library in userland tho. -- GitHub Notification of comment by plinss Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8698#issuecomment-1509393831 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 14 April 2023 23:38:07 UTC