CSS Timeline
Here’s a remarkably in-depth timeline of the web’s finest programming language, from before it existed to today’s thriving ecosystem. And the timeline is repsonsive too—lovely!
Here’s a remarkably in-depth timeline of the web’s finest programming language, from before it existed to today’s thriving ecosystem. And the timeline is repsonsive too—lovely!
I’m glad that Heydon has answered this question once and for all.
I’m sure that’ll be the end of it now.
Languages, platforms, and systems that break from the norms of computing.
If we, as a community, start to appreciate the complexity of writing CSS, perhaps we can ask for help instead of blaming the language when we’re confused or stuck. We might also stop looking down on CSS specialists.
PPK looks at the different mental models behind CSS and JavaScript. One is declarative and one is imperative.
There’s a lot here that ties in with what I was talking about at New Adventures around the rule of least power in technology choice.
I’m not sure if I agree with describing CSS as being state-based. The example that illustrates this—a :hover
style—feels like an exception rather than a typical example of CSS.
Programming lessons from Umberto Eco and Emily Wilson.
Converting the analog into the digital requires discretization, leaving things out. What we filter out—or what we focus on—depends on our biases. How do conventional translators handle issues of bias? What can programmers learn from them?
This is a great explanation of the difference between the [lang]
and :lang
CSS selectors. I wouldn’t even have thought’ve the differences so this is really valuable to me.
I don’t agree with Steven Pemberton on a lot of things—I’m not a fan of many of the Semantic Web technologies he likes, and I think that the Robustness Principle is well-suited to the web—but I always pay attention to what he has to say. I certainly share his concern that migrating everything to JavaScript is not good for interoperability:
This is why there are so few new elements in HTML5: they haven’t done any design, and instead said “if you need anything, you can always do it in Javascript”.
And they all have.
And they are all different.
Read this talk transcript, and even if you don’t agree with everything in it today, you may end up coming back to it in the future. He’s playing the long game:
The web is the way now that we distribute information. We will need the web pages we create now to be readable in 100 years time, just as we can still read 100-year-old books.
Requiring a webpage to depend on a particular 100-year-old implementation of Javascript is not exactly evidence of future-thinking.
It’s a terribly clickbaity (and negatively phrased) title, but if you turn it around, there’s some good advcie in here for deciding where to focus when it comes to dev technology:
- Programming languages are different, but design smells are alike.
- Frameworks are different, but the same design patterns shine through.
- Developers are different, but rules of dealing with people are uniform.
Backend logic? JavaScript. Styles? We do that in JavaScript now. Markup? JavaScript. Anything else? JavaScript.
Historically, different languages suggested different roles. “This language does style.” “This language does structure.” But now it’s “This JavaScript does style.” “This JavaScript does structure.” “This JavaScript does database queries.”
This is really good breakdown of what’s different about CSS (compared to other languages).
These differences may feel foreign, but it’s these differences that make CSS so powerful. And it’s my suspicion that developers who embrace these things, and have fully internalized them, tend to be far more proficient in CSS.
A lot of “CSS is not real programming” arguments are a basic misunderstanding what CSS is there to achieve. If you want full control over and interface and strive for pixel perfection – don’t use it. If you want to build an interface for an inclusive and diverse web, CSS is a great tool.
Christian does a good job of describing the much-misunderstood declarative nature of CSS.
Also:
In any case, belittling people who write CSS and considering them not real developers is arrogant nonsense.
A great piece from Danielle on the different mental models needed for different languages. When someone describes a language—like CSS—as “broken”, it may well be that there’s a mismatch in mental models.
CSS isn’t a programming language. It’s a stylesheet language. We shouldn’t expect it to behave like a programming language. It has its own unique landscape and structures, ones that people with programming language mental maps might not expect.
I believe that this mismatch of expectation is what has led to the current explosion of CSS-in-JS solutions. Confronted with a language that seems arbitrary and illogical, and having spent little or no time exposed to the landscape, developers dismiss CSS as ‘broken’ and use systems that either sweep it under the rug, or attempt to force it into alignment with the landscape of a programming language — often sacrificing some of the most powerful features of CSS.
It’s a bit finger-pointy but this blog should be useful for anyone working on internationalisation.
This blog has two general aims: to show the fundamental flaws in using flags to represent languages and how to create good experiences when dealing with multilingual and multi-regional content.
Google’s Noto (short for no-tofu; tofu being the rectangle of unicode sadness) is certainly ambitious. It has glyphs from pretty much every known alphabet …including Ogham and Linear B!
A wonderful deep dive into the history of styling languages before CSS. I love spelunking down these internet history potholes—fascinating stuff!