codeinabox@programming.dev to CSS@programming.devEnglish · 5 days agoModern CSS Code Snippets: Stop writing CSS like it's 2015modern-css.comexternal-linkmessage-square8linkfedilinkarrow-up140arrow-down10file-text
arrow-up140arrow-down1external-linkModern CSS Code Snippets: Stop writing CSS like it's 2015modern-css.comcodeinabox@programming.dev to CSS@programming.devEnglish · 5 days agomessage-square8linkfedilinkfile-text
minus-squarefox2263@lemmy.worldlinkfedilinkEnglisharrow-up5·4 days agoSince CSS has changed so much that there are old and new ways of doing things, maybe they should have changed version numbers.
minus-squarelambalicious@lemmy.sdf.orglinkfedilinkEnglisharrow-up3·4 days agodiv.mydiv { template <Variable mycolor> requires std::is_named_color<mycolor> || is_function_color<mycolor> || is_hexa<mycolor> mydiv& background-color: mycolor noexcept( noexcept( background-color: mycolor) || !std::is_IE6 ) --> decltype (css_declaration<property>) ; }
minus-squareKissaki@programming.devlinkfedilinkEnglisharrow-up2·4 days agoPlease make them incompatible so that I have to upgrade.
minus-squareKissaki@programming.devlinkfedilinkEnglisharrow-up2·4 days agoTo what end? What would you expect version numbers to do? How would you specify or use them, which what consequences? Grouping changes into releases with explicit numbering instead of a living standard with generic @supports checks? I guess it would make some things easier and more obvious.
Since CSS has changed so much that there are old and new ways of doing things, maybe they should have changed version numbers.
Yeh, we need
c++ssdiv.mydiv { template <Variable mycolor> requires std::is_named_color<mycolor> || is_function_color<mycolor> || is_hexa<mycolor> mydiv& background-color: mycolor noexcept( noexcept( background-color: mycolor) || !std::is_IE6 ) --> decltype (css_declaration<property>) ; }Please make them incompatible so that I have to upgrade.
To what end? What would you expect version numbers to do? How would you specify or use them, which what consequences?
Grouping changes into releases with explicit numbering instead of a living standard with generic @supports checks?
I guess it would make some things easier and more obvious.