QuirksBlog

I am likely going to write a “CSS for JavaScripters” book, and therefore I need to figure out how to explain CSS to JavaScripters.

Below I take a stab at explaining CSS files as JSON files. What I’d like to know from you is if this comparison makes sense.

If you’re a JavaScripter who’d like to learn some more CSS, please tell me if this helps you understand CSS better or not, and what could be improved. I’d be grateful for your feedback.

If this article generates useful feedback I might do it again. What better way to figure out if you’re making sense than to actually ask the target audience?

CSS as JSON

Suppose your job is to revise a JSON file. This file is sent on to a module that produces a web page. This web page should be changed, and for Reasons the only way to do that is by revising the JSON. You do not have access to the module’s source code, but you have incomplete documentation.

Since JSON is declarative, the order of declarations/properties does not matter. Something like "heroImage": "/images/pngs/hero2.png" can occur anywhere. It’s clear that this property defines the hero image to be shown on the web page, and its exact position in the JSON file does not matter.

Which hero image will be shown? hero3.png, obviously. The second use of "heroImage" overwrites the first one.

Other properties are much broader and vaguer in their usage. Suppose you find "layout": "sidebar" in the JSON, and you read in the documentation that the values "main" and "footer" are also allowed. The documentation does not make very clear what these values do, so you’re forced to experiment: just change the value of "layout" and see what happens.

There are many more properties like this, that range widely in their effects and aren’t always very clearly documented. The only way to start understanding their purpose is to just try them.

And what if you add "lyout" : "sidebar" to the JSON? Your expected layout won’t materialise — but there’s no error message to alert you to the fact that you’ve made a syntax error. JSON files don’t do error messages — unless the entire file is invalid. That’s not the case here: "lyout" : "sidebar" is perfectly valid JSON. You’ll have to spot the typo by yourself.

This situation resembles web developers creating or revising CSS files. Like JSON files, CSS files are not programs. but a series of declarations that programs use in order to create output. Also, they fail silently when they contain instructions that the receiving program does not understand.

If you approach CSS as you approach JSON you’ve taken a step toward understanding it.

Will Microsoft’s decision make it harder for Firefox to prosper? It could. Making Google more powerful is risky on many fronts. [...] If one product like Chromium has enough market share, then it becomes easier for web developers and businesses to decide not to worry if their services and sites work with anything other than Chromium. That’s what happened when Microsoft had a monopoly on browsers in the early 2000s before Firefox was released. And it could happen again.

Before you lament the return to a Microsoft-like monopoly, remember what happened to Microsoft’s monopoly. In fact, remember what happened to the lineal descendant of that monopoly just last week. Near-monopolies do not necessarily mean the end of the web.

Browser diversity

Back then, Microsoft stopped developing IE because it thought it had won. Right now, Google is doing no such thing — in fact, I think it’s moving too fast rather than too slow.

Back then, Microsoft welcomed the IE-only badges that sprung up on countless websites. Right now, the Chrome devrel team does not. In fact, they don’t hesitate to criticise Chrome-only sites created by other parts of Google.

Also, don’t forget WebKit. Right now web developers pretend there are only two rendering engines left, Gecko and Blink, but there is in fact a third one, and especially on mobile it’s quite important. (When did you last create a site that didn’t really have to work on iOS?)

Today’s situation is very different from fifteen years ago — though I still think web developers switching to Firefox as their default browser is a good idea. (No, I haven’t yet done so either.)

Headcount

But I don’t really want to talk about browser diversity, or about the relative merits of present-day Google and past Microsoft.

Instead, I want to talk about headcount.

The IE team first asked for my regarded opinion somewhere in 2005 or so, when they were gearing up toward IE7. Since then I’ve been in touch with them, and followed their progress with interest, occasionally submitting feature lists or clarifying our web developer point of view.

During all those years, I had the distinct feeling the IE team was under-staffed — a feeling that was occasionally, if privately, confirmed by team members. It seemed that, while Microsoft had decided to continue the development of IE, it didn’t want to commit the full resources that the project warranted.

That’s why, in the immediate aftermath of Microsoft confirming the rumour, I was quite surprised to see a We’re hiring message. (Granted, the actual job descriptions don’t mention Chromium, but they were written in October or November.)

I understand why people are nervous about a Chrome monoculture. I think this case is a little different though. Microsoft has an army of engineers working on Edge. They’re one of the few companies who can go toe-to-toe with Google funding browser development.

Now I don’t follow Tom, and the only reason I saw his tweet is that it was retweeted by an Edge team member. Sure, RT !== endorsement, but this was a curious coincidence, to say the least.

Is one unexpected benefit of the switch to Chromium that the Edge team can actually expand? It’s easier to get Chromium engineers than EdgeHTML ones, that’s for sure.

Android

If Microsoft does solve its headcount problems, then things get interesting — especially on Android. Sure, Microsoft has more opportunities for expanding its market share elsewhere, notably Windows 7 (where EdgeHTML never ran), but Android is by far the most interesting one.

One huge advantage of moving to Chromium is that Edge can now be easily ported to Android. This tweet appears to confirm that an Android version is in the planning.

Let’s jump sideways for a moment. Google Services is a suite of Android apps such as Play, Search, Maps, YouTube, and other crucial services that pretty much define how useful a smartphone is. It also contains Google Chrome. Android vendors get the option of using Google Services for free, provided they use ALL of them. All non-Chinese ones actually do so, and Google Services is an important part of the hold Google has on the web and mobile markets. Also, it puts Google Chrome on every Android phone.

What if Microsoft offered the Android vendors an alternative? Microsoft has a search engine, maps, and other services. YouTube can be viewed in a browser as well as in an app — and now it has the browser. Only an alternative to the Play Store is missing — so far. It’s quite possible that some Android vendors would seriously consider such an offer. It would ease Google’s stranglehold.

In that light, I found it interesting that HTC is experimenting with Brave as its default browser on one phone model. (True, the HTC Exodus is a “blockchain phone” and when I recently visited the local phone store they didn’t have any HTC whatsoever on offer, and nomen is most definitely not an omen. Still, interesting.) And if this example doesn’t convince you, remember Samsung Internet. Non-Google Chromium browsers are a thing on Android. But they aren't part of a set of services — yet.

Anyway, IF the Edge team gets more people, and IF Microsoft decides to go the Android route, the switch to Chromium may become interesting very fast.

Microsoft is rumoured to pull the plug on their EdgeHTML rendering engine and move to Chromium for the next Edge version. It’s always a sad moment when a rendering engine leaves us.
Now as anyone who read my Chromium blog posts knows, one Chromium is not necessarily exactly the same as another. Thus I do not expect EdgeChromium to be 100% the same as Chrome — more like 98%.
How to solve this? Test more in Edge — 3 years ago. Of course my readers know this and do this; it’s the full-stackers that are the problem.

Speaking of which. Heydon takes a stab at defining the problem with full-stack developers. They try to do too much, and as a result, code quality suffers.

By assuming the role of the Full Stack Developer (which is, in practice, a computer scientist who also writes HTML and CSS), one takes responsibility for all the code, in spite of its radical variance in syntax and purpose, and becomes the gatekeeper of at least some kinds of code one simply doesn’t care about writing well.

He also points out that one full-stack developer is cheaper than three specialised developers, and cost cutting is certainly part of the reason why full-stack has become so popular.
Still, to me, it all comes down to the low esteem in which HTML/CSS is held (and Heydon also mentions that). It’s much easier to declare a low-status job redundant than a high-status one. I mean, are there large companies that have the same people do development and devops?

In case you’re wondering why full-stack programmers have such problems with CSS (and HTML), Robin Rendle explains. Front-end (i.e. HTML and CSS) is not a problem to be solved because, essentially, it’s already been solved. Just not by full-stack programmers.

What’s the point in learning about vanilla HTML, CSS and JavaScript if they wind up becoming transpiled by other tools and languages?

[...] Front-end development is complex because design is complex. Transpiling [...] into HTML and CSS requires vim and nuance, and always will. That’s not going to be resolved by a tool but by diligent work over a long period of time.

Jeremy compares CSS to a programming language, and finds that selectors, especially, qualify. Still, that’s exactly the part of CSS that isn’t used a lot, since we all have to go modular and use classes everywhere.Foor for thought; also for the book.

While ostensibly explaining a React feature, Dan Abramov gives a lesson about JavaScript prototypes and inheritance. Useful reading for all JavaScripters — I learned (or relearned) a thing or two here.

Addy Osmani takes a look at the cost of JavaScript. While they work OK-ish on modern desktop computers, huge scripts cause a lot of problems on low-end phones. (News? No, not really. But people don’t listen.) As he says,

The web is bloated by user “experience”

If you want facts and figures to convince others, look no further than this article.

If you ever wanted to know absolutely everything about the way stylesheets can block page rendering, read it all. Did you know, for instance, that you should not place stylesheets before async script snippets? That’s because browsers await the full stylesheet before evaluating the snippet. What if the script requests the colour of a certain element, and the CSS hasn’t come in yet? Better to wait.
Tons more good stuff here.

Interesting experiment by Daniel Buchner. He shows how to use the CSS :invalid pseudo, which triggers onkeypress, in a script, where normally the invalid event would fire onsubmit (or in a few edge cases).
Read my native form validation series for a LOT more background information about the differences. (I didn’t think of Daniel’s trick, though. Simple, elegant, useful.)

Microsoft is rumoured to pull the plug on their EdgeHTML rendering engine and move to Chromium for the next Edge version. It’s always a sad moment when a rendering engine leaves us.
Now as anyone who read my Chromium blog posts knows, one Chromium is not necessarily exactly the same as another. Thus I do not expect EdgeChromium to be 100% the same as Chrome — more like 98%.
How to solve this? Test more in Edge — 3 years ago. Of course my readers know this and do this; it’s the full-stackers that are the problem.

Speaking of which. Heydon takes a stab at defining the problem with full-stack developers. They try to do too much, and as a result, code quality suffers.

By assuming the role of the Full Stack Developer (which is, in practice, a computer scientist who also writes HTML and CSS), one takes responsibility for all the code, in spite of its radical variance in syntax and purpose, and becomes the gatekeeper of at least some kinds of code one simply doesn’t care about writing well.

He also points out that one full-stack developer is cheaper than three specialised developers, and cost cutting is certainly part of the reason why full-stack has become so popular.
Still, to me, it all comes down to the low esteem in which HTML/CSS is held (and Heydon also mentions that). It’s much easier to declare a low-status job redundant than a high-status one. I mean, are there large companies that have the same people do development and devops?

In case you’re wondering why full-stack programmers have such problems with CSS (and HTML), Robin Rendle explains. Front-end (i.e. HTML and CSS) is not a problem to be solved because, essentially, it’s already been solved. Just not by full-stack programmers.

What’s the point in learning about vanilla HTML, CSS and JavaScript if they wind up becoming transpiled by other tools and languages?

[...] Front-end development is complex because design is complex. Transpiling [...] into HTML and CSS requires vim and nuance, and always will. That’s not going to be resolved by a tool but by diligent work over a long period of time.

Jeremy compares CSS to a programming language, and finds that selectors, especially, qualify. Still, that’s exactly the part of CSS that isn’t used a lot, since we all have to go modular and use classes everywhere.Foor for thought; also for the book.

While ostensibly explaining a React feature, Dan Abramov gives a lesson about JavaScript prototypes and inheritance. Useful reading for all JavaScripters — I learned (or relearned) a thing or two here.

Addy Osmani takes a look at the cost of JavaScript. While they work OK-ish on modern desktop computers, huge scripts cause a lot of problems on low-end phones. (News? No, not really. But people don’t listen.) As he says,

The web is bloated by user “experience”

If you want facts and figures to convince others, look no further than this article.

If you ever wanted to know absolutely everything about the way stylesheets can block page rendering, read it all. Did you know, for instance, that you should not place stylesheets before async script snippets? That’s because browsers await the full stylesheet before evaluating the snippet. What if the script requests the colour of a certain element, and the CSS hasn’t come in yet? Better to wait.
Tons more good stuff here.

Interesting experiment by Daniel Buchner. He shows how to use the CSS :invalid pseudo, which triggers onkeypress, in a script, where normally the invalid event would fire onsubmit (or in a few edge cases).
Read my native form validation series for a LOT more background information about the differences. (I didn’t think of Daniel’s trick, though. Simple, elegant, useful.)

Months of planning come to a head, and the cat is out of the bag. Fronteers, the Dutch professional association of front-end developers, is planning to apply for W3C membership and appoint Rachel Andrew as our paid representative. This would solve the problem of front-end developer representation in W3C.

Note that this plan will be submitted to the Fronteers members on 19th of October, and that they can vote it down.

On its annual general member meeting on 19th of October, the Fronteers board will propose to become a member of the World Wide Web Consortium (W3C), and to hire Rachel Andrew as our representative in that standards body. By becoming a W3C member, Fronteers aims to be the first membership organisation to give front-end developers a voice (and vote) in web standards.

While W3C has always desired input from front-end developers, and some of them became Invited Experts and contributed to the discussions, these experts had to do so in their own spare time and at their own expense. Fronteers aims to change that.

Our W3C membership is not yet set in stone: the Fronteers general member meeting will have to approve of this plan (and its financial consequences), which will be laid before it on 19th of October. Rachel Andrew will be present to explain the consequences to the Fronteers members.

Founded in 2007, Fronteers is the professional association of Dutch front-end developers. It is best known for its annual Fronteers conference in October, but it has been locally active with workshops, meet-ups, a job board, and other activities for Dutch front-enders.

The World Wide Web Consortium (W3C) is the international organisation whose members and full-time staff, helped by specialised members of the public, develop the web standards used in all of today's browsers.

Rachel Andrew is a British front-end and back-end developer, speaker, author, and the editor-in-chief of Smashing Magazine. As an Invited Expert to W3C, especially for CSS layout matters such as flexbox and grid, she has ample experience in the standardisation process.