To be fair, this is the first time I see this but I immediately got it. So might not be as hard / innovative for no reason. I believe someone working often with CSS should be able to parse *+*, and if not, take the time it takes once to understand it. It's nothing that implicit.
Anyway please please don't pull off a React to avoid CSS, just comment your CSS instead, or find a clearer way to write it if you prefer (:not(:first-child)).
This styles documents (puts margins on paragraphs), we don't want an app for this. And even for a React app, we have a nice language to style stuff at our disposal that our browsers are incredibly efficient at evaluating, I don't think reinventing CSS in React is a good thing.
Please do. I'd much rather see a system built in React with explicit logic, math, and names, than an implicit pile of obfuscated rules that are impossible to tweak without causing a cascading failure.
Comments
To be fair, this is the first time I see this but I immediately got it. So might not be as hard / innovative for no reason. I believe someone working often with CSS should be able to parse *+*, and if not, take the time it takes once to understand it. It's nothing that implicit.
Anyway please please don't pull off a React to avoid CSS, just comment your CSS instead, or find a clearer way to write it if you prefer (:not(:first-child)).
This styles documents (puts margins on paragraphs), we don't want an app for this. And even for a React app, we have a nice language to style stuff at our disposal that our browsers are incredibly efficient at evaluating, I don't think reinventing CSS in React is a good thing.
React will die before CSS anyway.
Please do. I'd much rather see a system built in React with explicit logic, math, and names, than an implicit pile of obfuscated rules that are impossible to tweak without causing a cascading failure.
Maybe you wouldn't if you had to pay for all the electricity that's wasted by using React.
Something tells me React uses less electricity than CSS `*` selectors.