- From: Romain Menke via GitHub <sysbot+gh@w3.org>
- Date: Mon, 10 Apr 2023 13:57:44 +0000
- To: public-css-archive@w3.org
@LeaVerou I think the tone/intent of my comment got lost. We are basically saying the same thing. > I feel we need a new thread to discuss how authors will handle the transition period, and what we can do to improve that experience. Yes, that would be better than taking this further of topic :) ----- > And authors do use Flex (and grid) without shipping alternatives. They don't generally need features to reach 99.9% support to use them without backup The incorrect statement was that any feature would reach 99.9% in five years. If numbers are used to back things up, it is important that these are somewhat accurate. I didn't state anything about what 99.9% or any other level of support means for CSS authors, only that 99.9% in five years will be extremely unlikely. ----- > Authors don't want to use tools for anything. If nesting never ships it will also never reach the point when tools become unneeded. This was in response to : > Authors will either ship only nested stylesheets and break their sites for older browsers; ship both, making the user pay unnecessary download costs (violating one of the TAG's ethical principles); or just use a transpiler and ship un-nested stylesheets like they aready do today, **and we don't need to bother with the feature.** Arguing that the tools required during the transition period make the entire feature redundant doesn't make sense, exactly for the reasons you listed. ------ > Authors typically do not like a change that will both slow down their project for end users and add to the complexity of their stack. Even when it only causes perf issues for users on older browsers. _I should have elaborated a bit more here._ If we imagine that your proposal is supported by tooling, authors will have two choices : 1. always transpile their CSS during the transition period 2. produce two bundles, one for modern and one for older browsers during the transition period Option 1 doesn't require CSS Authors to make any other changes to their project. Simply pass the CSS source to whatever tool that can desugar nesting and what comes out will work everywhere. After the transition period the transpiling tool can be disabled/uninstalled. Option 2 requires CSS Authors to: - add JavaScript to dynamically load the right source (might also require HTML changes) - change their tooling to produce two outputs with two different configs - take the performance hit on older browsers - undo all changes after the transition period Option 1 is simpler and given that nesting is purely syntactic sugar there are few drawbacks to transpiling during the transition period. Most transpiling tools make it trivial to skip certain transforms during active/local development. Which give the benefits of rapid prototyping as you mentioned. ----- > If this were true, nobody would be using polyfills, which are regularly much slower than writing code without the new technology that is being polyfilled in the first place. With polyfills one typically exchanges speed in modern browsers and codebase simplicity for slowness in older browsers, and this is a tradeoff I've seen authors make over and over. The choices I am weighing are : - transpile for everyone, everything works and is fast everywhery - transpile for some, everything works but only fast for some (although this group grows to near 100% over time) When the second option is also more complex to setup, it doesn't make much sense to go down that road purely for the transition period. Some authors might chose to do so, and that is fine. My argument was not that other strategies are invalid, only that a simpler alternative already exists : transpile for everyone for as long as required for a given project. ------ _When I mention `transpile` or `transpile` I am never talking about Sass, only about tools that aim to desugar standard css nesting._ -- GitHub Notification of comment by romainmenke Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1501841062 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 10 April 2023 13:57:46 UTC