As front-end developers, we’ve wished for a lot of things over the years \u2014 ways to center things in CSS, encapsulate styles, set an element\u2019s aspect ratio, get finer-grained control over our colors, select an element based on its children\u2019s properties, manage layers of specificity, allow elements to respond to the width of their parents\u2026 the list goes on and on.<\/p>\n\n\n\n
And now that we got all we wished for and more, some of us are asking \u2014 do we now have too much<\/em> CSS?<\/p>\n\n\n\n\n\n\n If you, like me, came up in web development during CSS\u2019s infancy, the idea of having too much of it seems ludicrous.<\/p>\n\n\n\n Back in the days, virtually the entire job description of a front-end developer consisted of dealing with CSS\u2019s limitations. The clearfix hack<\/a> to clear floats, the 100% padding hack<\/a> to make square divs, not to mention semi-randomly applying unrelated properties to trick Internet Explorer into doing your bidding.<\/p>\n\n\n\n At the time, the browser was a devious foe to be defeated through sheer cunning and arcane incantations. Today, the perfect property is waiting and just a copy-paste away on MDN.<\/p>\n\n\n But today things are vastly different: not only are things moving much faster, but browser vendors actually care<\/em> about making developers happy! I know, I couldn\u2019t believe it either. But I run the yearly State of CSS<\/a> developer survey (which is open now by the way \u2014 go take it!<\/a>) and I know for a fact that browser development teams use the survey results (among many other data points) to inform their roadmap.<\/p>\n\n\n\n Beyond this, Google has also helped finance my work on the survey, and even hired Lea Verou<\/a> to take the lead on selecting this year\u2019s survey questions.<\/p>\n\n\n\n It\u2019s not just Google. It\u2019s become fashionable to bash Safari and Apple in general (sometimes deservedly so), but you can\u2019t deny how passionate someone like Jen Simmons<\/a> is about listening to developers and improving the web.<\/p>\n\n\n\n And not only are browser vendors improving CSS on their own; they\u2019re even collaborating across battle lines with initiatives such as Interop 2023<\/a> to help reduce inconsistencies and incompatibilities between browsers.<\/p>\n\n\n The result of all this is that we are now faced with an embarrassment of CSS riches, and it can be hard to catch up. CSS Grid<\/a> started being supported in major browsers almost five years ago, yet I still check a reference every time I use it. And as cool as subgrid<\/a> seems, I\u2019ve yet to even try it out.<\/p>\n\n\n\n During the process of selecting which CSS features to include or not in the State of CSS<\/a>, Lea and myself considered many features, but we also rejected quite a few. Some examples of the feature we didn\u2019t<\/em> include are:<\/p>\n\n\n\n These are all potentially very useful, and would\u2019ve all been big news during the CSS drought of past years. But in today\u2019s context they have to fight for attention with much larger announcements, like the has() selector or CSS nesting!<\/p>\n\n\n As Silvestar Bistrovi\u0107 writes<\/a>, he is \u201cnot that excited about all these new CSS features.\u201d This found an echo on Twitter, with Sara Soueidan<\/a> stating that what she cares about is \u201cpracticality, not how shiny a feature looks at the moment.\u201d<\/p>\n\n\n\nThe dark times<\/strong><\/h3>\n\n\n
The new era of CSS<\/strong><\/h3>\n\n\n
Too much of a good thing?<\/strong><\/h3>\n\n\n
linear()<\/code> easing function<\/a>, which lets you define easing curves with more granularity. <\/li>env()<\/code> function<\/a>, which lets you use variables defined by the browser or device. <\/li>scrollbar-width<\/code><\/a> property, which helps control a scrollbar\u2019s appearance. <\/li>margin-trim<\/code><\/a> property, which lets you control how a container\u2019s children\u2019s margins behave. <\/li><\/ul>\n\n\n\nNot excited<\/strong><\/h3>\n\n\n