Linkbait 44
Links in times of chaos.
- Laura Schenck, whose thoughts on programming CSS are very interesting anyway, discusses a project where she had to battle specificity. Key thought:
Specificity breeds, much like conditionals breed in imperative languages [...]. Adding specificity is adding conditional logic. Once you start adding that logic, the code-base snowballs and it becomes difficult to understand, and thus difficult to maintain.
She also asks if anyone who writes CSS should understand specificity to this degree. My answer is a firm Yes, just like you're expected to understand if- and for-loops when programming in any other language.
- Rachel Andrew ponders the pros and cons of CSS4. She is afraid that people will get confused by “CSS4” because several articles said there will never be a CSS4, and the version number 4 does not align with the version numbers of existing modules. Although both are true, I seriously doubt whether the people that “CSS4” is aimed at (those I call the torso and long tail of the CSS world) are aware or care. To me, this argument is overly legalistic, in the sense that it doesn’t matter in the real world.
A much more important argument is that the announcement of “CSS4” will make people expect a list of new features that work in all browsers. In itself that’s great, and I think it would be really helpful, but the problem is that someone will have to decide what goes on the list and what does not — and the CSS WG is already stretched thin and cannot spare the time to do this. Maybe we need a community effort to help them? Worth thinking about.
- Interesting Twitter thread on why CSS is perceived as simultaneously very simple and very complicated.
Because we think it's a simple language, we don't dive deep into it like we do with "real" programming languages. background: blue; makes the background turn blue, why should we bother diving in?
But then it's time to build a layout and suddenly the combination of user agent styles and a lack of understanding in the fundamentals of CSS makes things break, or not behave how we expect them to.
Yup.
- Mostly for myself: the difference between
defer and async on script tags. Or, as Nicholas Zakas puts it:
- Do it now: <script src>
- Do it later: <script defer src>
- I don’t care when you do it, just not now: <script async src>
- Coil, the web monetization company, offers some interesting but too-much-under-the-radar thoughts on probabilistc revenue sharing. The idea is simple: if A, B, and C cooperate on a to-be-monetized article, and A is allotted 60% of the revenue, B 25% and C 15%, you simply add those probabilities to your payment pointers. Eventually a tool will draw a random and assign a specific payment to a specific author, but for now you can use a script to emulate that behaviour.
- Google proposes to sunset the User Agent string by freezing its version number and removing device information. The purpose here is to make fingerprinting (combining UA string, IP address, TCP/IP settings, device information and a host of other bits and pieces to accuratenly identify a web user) more difficult.
The UA string will be replaced by client hints that give web developers some information about the browser, device, and platform. These hints will likely be more generic than the UA string, and thus hamper fingerprinting.
The second problem with UA strings is the eternal arms race between clueless web developers and browser vendors, where web devs start using a certain badly-written browser detect, which forces browsers who want to end up on the good side of it to adjust their UA string, so that it gathers more and more cruft. (This is the reason every single browser string out there still starts with Mozilla.) I do not see this arms race go away. For instance, if the new Flow browser wants to defeat new browser detects written with client hints by clueless web developers, it will most likely be forced to announce itself as Chrome. Worse: we lose the ability to accurately identify it as Flow. As a result, new browser stats will make it appear as if Chrome is even more dominant than it actually is.
Maybe we need another field Sec-CH-RealUA or something, where the browser can use its true name. On the other hand, that will be more fodder for clueless web developers and will perpetuate the arms race.
In any case, to me it seems that more-or-less-accurate browser statistics will be the most important casualty of this switch.
Related links (mostly for myself): client hints as currently implemented; discussion on a previous Safari attempt to do something similar; Blink intent to ship
- Mozilla and KaiOS Technologies are going to cooperate on future versions of KaiOS, the operating system for “smart feature phones” (read: cheap phones) that’s based on Firefox OS. Included in the article is a whole list of features Mozilla will work on, but they essentially boil down to keeping KaiOS updated for the ever-evolving web.
Broadly speaking, these updates will mean many first-time internet users gain access to more of the web’s advanced digital services on devices that are affordable, reliable, and secure.
Remember: KaiOS is aimed at not-so-rich people from emerging markets. As of May 2019 there were about 100 million devices out there. That’s piss poor compared to iOS and especially Android, but let’s see if their use explodes or not.
- Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).
