Syndicate content
Updated: 5 hours 39 min ago

Why is not using the CSS cascade a problem?

Tue, 04/17/2018 - 3:45am

When I announced I was going to write something for JavaScript developers who don't understand CSS, plenty of people (including Jeremy) said that the Cascading & Inheritance chapter would be crucial, since so many JS developers didn’t seem to understand it.

At first I agreed, but later I started to harbour some doubts, which is the reason I’m writing this piece.

As far as I can see, the problem is not that JavaScript developers do not understand the cascade, the problem is that they do not desire to use it. But is this really a problem?

Global scope

CSS only has a global scope. A button.primary rule affects all buttons with that class on the entire page. This is the strength of the cascade. In a recent project I spent half an hour with the designer defining a primary, secondary, and tertiary button/link class. That was time well-spent: both of us could drop buttons into the code from that time on, and their styles would just work.

JavaScripters have learned to dislike and distrust the global scope, however. Although this is an excellent idea in JavaScript, so the theory goes, it makes a lot less sense in CSS, since part of the strength of CSS is exactly its cascade-induced global scope. Therefore JavaScripters do not like CSS; see, for instance, CSS: the bad bits, which opens prominently with complaints about the global scope.

But don’t JavaScripters see the advantages of the CSS cascade? Aren’t they ignoring part of what makes CSS so powerful?

Local scope

Well, yes and no. To return to my earlier primary button example, it makes excellent sense in a relatively simple site like the one we were making. It starts making less sense when you want to drop not a single button, but an entire component, which might include a button, but needs the button style to conform to the component style. In that case you want to make sure that general styles don’t influence the component’s button. You want your CSS to be local in scope.

None of this is particularly surprising, and I have no doubt that my readers have figured this out for themselves and hit on the remarkable solution of using both global and local styles, depending on the exact nature of their project. As Charlie Owen said:

I hear people making out that scoped and cascade are incompatible. But using the cascade just means (to me) making use of the global aspects of CSS. Set your default block level margins, your typography, etc high up. Then each component can scope anything extra.

So far so good. This, as far as I can see, is the correct solution to the problem.

What’s the problem?

But what am I to make of the complaints about JavaScripters not understanding the cascade? I think they understand it perfectly fine; they just decide not to use it.

So I don’t think there’s really a problem here. Still, I decided to write this piece and ask this question because I might overlook something.

So what’s the problem with JavaScript developers and the cascade beyond them overlooking some use cases for global styles, wrapped up as they are in making everything local? Could someone please explain?


Know JS online event

Mon, 04/02/2018 - 5:24am

On 13th of April the inaugural Know JS online conference takes place. I’m tangentially involved, though I will not speak. The conference is online, and runs from 9am to 6pm Eastern on 13th of April. You can attend from the comforts of your own house.

Know JS is a fairly special type of online conference. Four speakers, Kyle Simpson, Bianca Gandolfo, Kent C. Dodds, and Jem Young, will give not a conference talk, but a full two-hour workshop about a topic of their choice. By buying a ticket you get access to all four of these workshops.

In addition, all four speakers will release a pre-recorded short presentation that sets the tone for their workshops, and these presentations will be available for anyone, not just for ticket holders. They will be published as they come in, starting today.

Tickets are $299, and we decided to cap their number at 50, so that some sort of live interaction between the attendee (that’s you!) and the teacher is possible.

This is a fairly unique type of conference, and credit wholly goes to Kyle, who came up with the idea. His fellow organisers, Brian Rinaldi and me, thought this was a very interesting take that we should try. So here we are, trying it.

This project started with Brian and me meeting in Sofia, and since we’re both conference organisers the conversation quickly turned to conference organising. We found that both of us would like to run a JavaScript event that was not focused on one or more of the popular framenworks, but instead on the language itself. We feel this topic is somewhat underrepresented in today’s conference cycle.

We decided to get Kyle Simpson on board, and our thoughts started to run toward an online event. Although all three of us would prefer a real conference, we weren’t sure how well the topic would be received. So we’re testing the waters, as it were, and if this event is a success, we’ll probably make the jump to an offline conference, ideally with editions in the States and in Europe.

We’ll see what happens next. But if you’re interested in JavaScript the language, please take a good look at what we’re offering.

Linkbait 39

Tue, 03/20/2018 - 1:31am

More like a link-late, but here it finally is.

  • Tim Kadlec takes a look at how fast AMP really is, spurred on by Ferdy Christiant’s research that we featured earlier. Tim concludes that the main performance benefit comes from AMP pages being served from Google’s CDN. Other than that AMP pages are mildly more performant than non-AMP pages, mostly because it arranges some optimizations and resource loading for you. The cost, however, is a slightly slower Start Render time, because the scripts that arrange all those optimizations and loading have to run before the AMP page is ready to be shown.

    Right now, the incentives being placed on AMP content seem to be accomplishing exactly what you would think: they’re incentivizing AMP, not performance.

  • Steve Yegge shares his thoughts on the current state of Android. While Google still retains control over Android itself, it may be losing its grip on important auxiliaries:

    We’ve seen that there are at least three coordinated types of attack happening in different dimensions: The developer ecosystem (React Native and friends), the store (Amazon’s app store and Cyanogen’s rumored successor), and the lightweight in-app marketplaces (Facebook and WeChat, so far). Google’s reactions to each of these threats so far have been… well, let’s just say they’re still on top. For now.

    Does that matter? Yes, for tech shops it does.

    If you think there’s any risk at all that Google might lose control of Android, then your best bet is to use a cross-platform framework, because it hedges your bet via improved portability.

    React Native, in other words. If it can survive the current storm aimed against Facebook — but it probably can, because it can always be spun off.
  • Why I quit Google is an interesting article about self-defeating “objective” promotion criteria at Google.
  • Steve Faulkner clarifies how the HTML/CSS DOM, which can be changed by, among others, the flexbox order property, isn’t reflected in the browser’s accessibility tree. This is a reaction to last time’s discussion about CSS variable use for table sorting.
  • Chris Coyier shows how to make notched boxes in kind-of Battlestar Galactica style. Nice.
  • Excellent article on dealing with huge collections of DOM nodes — think tables with 1,000 rows. Vanilla JavaScript remains by far the best option performance-wise. Also, don’t bother optimising your core JavaScript loops and stuff — instead, optimise DOM handling. Clear DOM subtrees through innerHTML. On the other hand, don’t destroy nodes you may need later on — re-building them is way more expensive than keeping them around in memory.
    And no, this is nothing new. Ten years ago I would have given the same advice. But it’s good to know that the old rules are still being supported by the current data.
  • Food for thought:

    I’m beginning to think JS may be bifurcating into two largely disjoint communities. The “sw engineers” comfortable with pre-deployment tool chains and the “explorers” who want "live programming" tools

    I’m not 100% sure what Allen means by live programmers, and when I wanted to ask them I hit on my own definition and tweeted that instead.
    I think that the big split in JavaScript land is between those who firmly keep their eyes on browsers as our development platforms, and those who want to abstract away browsers.
    And yes, I think the first group is right and the second one is wrong, and that the second one will run into problems due to not understanding the platforms it’s creating software for.
  • This article calls the front-end/back-end division an antipattern. While I disagree with that premise, most of the article treats how back-enders look down on front-enders, and why that attitude should end — which is something I agree with.

    Frontend engineers now solve the same kinds of problems as their backend counterparts, using the same kinds of solutions, and it is harmful to continue arbitrarily dividing us.

    To be clear, I’m not saying that we all need to be experts in everything. [...] While it is perfectly valid to dislike a particular technology, such as CSS, the industry's culture of contempt for frontend work feeds into the outdated divide between frontend and backend, and detracts from building fast-moving, competitive teams and companies.

    Such as CSS. Thar’s a problem I’ll have to get back to one of these days.
    Pointing out that front-end can be as complex as back-end, and doing so in a back-ender-friendly way, is a good idea. Still, the article manages to ignore browsers as a developer platform entirely, despite the fact that mentioning them would have made its point even stronger. But maybe back-enders don’t want to hear about browsers because they’re terrified of them.
  • According to Tobie Langel contributing to OSS has ROI roughly equal to using OSS. Twenty years ago large companies were leery of using it; now they're leery of contributing to open source. So we have to convince them.
  • Insights and data, baby! The StackOverflow developer survey and the Design Census have been released. These surveys always yield interesting data.
  • Seems like an awful place to work for the health-unconscious such as myself.
  • Chronicles of Crime is a board game that incorporates an app, VR, and QR codes. Apps and VR have been done before in board games — the wonderful Alchemists was the poster child for apps in games — but as far as I know nobody yet combined them (i.e. let the app do more than just show VR), and nobody yet added QR codes, which are supposed to be a dying technology.
  • Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).

Linkbait 38

Tue, 02/27/2018 - 6:16am

The missing links.

  • Elegant and simple solution by Mr. M. that shows breakpoint information during website development. So simple that it surprises me this isn’t being used widely yet.
    Emil Björklund adds a slight twist and a few notes.
  • VERY cute animated avatar. Simple, subtle, efficient animations FTW!
  • Excellent article about designing with grids. Not exactly a tutorial; more like a showcase of how to bring all those grid elements together to form a nice, and above all non-standard site design.
  • Lea has a new talk: an introduction to web development for CS students. It contains a JavaScript context quiz (I had only two errors), and highlights CSS Grid Garden, where you can learn grid, and a CSS Selector challenge with plates, bento boxes, apples, and more.
  • Good piece by Ronald Méndez on ALA about earning a seat at the table as a front-end engineer. His early steps mirror the ones I made about ten years earlier: the biggest change was me just sitting down with graphic designers to go over their work before showing it to clients. This worked amazingly, as Ronald also found.
    Anyway, worth a read if you feel under-appreciated as a web developer.
  • Stuart muses about collecting data, and shows that it’s possible to collect meaningful data without compromising individual users’ privacy. The trick is that users should lie. Not all the time, and not all the users, but you should ask a certain percentage of your users to lie.
    If, say, 10% of Chrome users say they use Firefox and 10% of Firefox users say they use Chrome, the aggregate browser use statistics remain roughly the same, but you cannot say with certainty which browser an individual is using.
  • Roman Koramov published a truly eye-opening use of CSS variables for making a sortable table. No JavaScript needed.
    Unfortunately, the technique causes accessibility issues because screen readers cannot follow CSS order — just DOM order. So they ignore the sorting.
    It seems to me we can invoke progressive enhancement for some problems. Table isn’t sorted? Pity; it works OK enough without being sorted. Patrick Lauke disagreed, but I feel he’s arguing strictly from a worst-case scenario.
    Anyway, make up your own mind — as long as you remember CSS variables are awesome.
  • Frank Chimero defines spaghetti toolchains. I wish I thought of that term.

    simply npm your webpack via grunt with vue babel or bower to react asdfjkl;lkdhgxdlciuhw

    [...] Last month, I had to install a package manager to install a package manager. That’s when I closed my laptop and slowly backed away from it. We’re a long way from the CSS Zen Garden where I started.

    If you go talk to a senior software developer, you’ll probably hear them complain about spaghetti code. [...] while I can’t identify spaghetti code as a designer, I sure as hell know about spaghetti workflows and spaghetti toolchains. It feels like we’re there now on the web.

  • Chris Coyier reacts to that article. He doesn’t exactly disagree, but points out that the web is a big place, and while some sites don’t need complexity, others do.

    Developers generally aren't asked to innovate on the business and product side. They build what they are told to, so they use their smarts to innovate on their own tools.


    We talk about complexity, but it's all opt-in. A wonderfully useful (and simple) website of a decade ago remains wonderfully useful and simple. Fortunately for all involved, the web, thus far, has taken compatibility quite seriously. Old websites don't just break.

    What I’m afraid of, though, is that today a simple website is regarded as a sub-optimal solution. A website has to opt into everything the web has to offer, or ... well, I’m not sure why, but there must be a huge downside to not making it complex.
  • An inside look at Facebook in the 2016 campaign, and more in general the way it sells ads, with controversial ads getting a discount.

    The Trump and Clinton campaigns bid ruthlessly for the same online real estate in front of the same swing-state voters. But because Trump used provocative content to stoke social media buzz, and he was better able to drive likes, comments, and shares than Clinton, his bids received a boost from Facebook’s click model, effectively winning him more media for less money.

    No Russians necessary. The Russian involvement existed, but it was hyped up by the tech caste in order to show that technology was still magic, and was gratefully accepted by “moderate” right-wing voters wishing to be absolved from Trump — and possibly hardcore Clinton supporters wanting to shift blame away from her.
    As Matt Yglesias said:

    Given that Trump’s strongest support is among the least-online generation we should be a little skeptical of attributing anything to digital wizardry.

  • Jeremy continues last week’s AMP discussion with the fundamental question: should we countenance companies’ power over the web, even if they mostly use their power for good?

    One of my greatest fears for the web is that building it becomes the domain of a professional priesthood. Anything that raises the bar to writing some HTML or CSS makes me very worried. Usually it’s toolchains that make things more complex, but in this case the barrier to entry is being brought right into the browser itself.

    [...] some CSS will be off-limits until they meet the entry requirements of HTTPS …even though CSS and HTTPS have literally nothing to do with one another. [...]

    No doubt Mozilla (and the W3C Technical Architecture Group) believe that they are doing the right thing. [...] They believe that, in this particular case, the ends justify the means.

    I strongly disagree.

  • Interesting examples of AR by Luke Wroblewski.
  • Samsung puts on its first own web conference, Samsung Create. I approve of browser makers setting up their own conferences. It makes the engineers accessible to web developers, and allows both sides to find out what the other is thinking. Also, I approve of more browser vendors, since it helps diversity. Pity the conference is in San Francisco; let’s hope for a European edition. Also a pity there’s not much more information yet.
  • And Tomi gives us the definitive 2017 smartphone stats.
    1. Samsung
    2. BBK
    3. Apple
    WTF is BBK? Read the article; was new for me, too.
  • Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).

Linkbait 37

Tue, 02/20/2018 - 1:46am

We are an equal opportunity linkbait. Last week we bashed Facebook; this week we bash Google.

  • Tim Kadlec on AMP — again.

    The web community has stated over and over again that we’re not comfortable with Google incentivizing the use of AMP with search engine carrots. In response, Google has provided yet another search engine carrot for AMP.
    This wouldn’t bother me if AMP was open about what it is: a tool for folks to optimize their search engine placement. But of course, that’s not the claim. The claim is that AMP is “for the open web.”

    The fact that Google tries to use our ideology is one thing. The fact that we continue to fall for it is quite another.

    Why a subset of HTML you ask? Well, mostly because web developers suck at their jobs and have loaded the web with a ton of JavaScript no one wants. Can't fault Google for wanting to change that. That part I can support. The less JavaScript the better.

    And here we’re back smack bang in the middle of the problem. Today’s average web developer doesn’t have the faintest clue what he’s doing and can’t do it anyway without sixteen libraries and frameworks. Solve that problem and AMP goes away.
    (Masculine pronoun used deliberately, and if there were a white pronoun I’d also have used it. I more and more think that frameworks and libraries are the things mediocre white men need to survive in today’s front-end world.)
  • It’s useful to post a repeat link to an older The Register article that calls for killing AMP before it kills us.

    Except that, hilariously, to create an AMP page you have to load a, wait for it, yes a JavaScript file from Google. Pinboard founder Maciej Ceg?owski already recreated the Google AMP demo page without the Google AMP JavaScript and, unsurprisingly, it's faster than Google's version.


    If we reject AMP, AMP dies.

    In order to reject AMP we need to tone down significantly on the frameworks. Could happen, but right now it’s not happening.
  • Ferdy Christiant agrees with the performance findings. He studied AMP’s performance profile (supposedly its biggest advantage) and found that his test AMP page is not noticeably faster than a regular web page. Also, he found that AMP is effectively preloading assets for a better perceived performance. If your goal is to improve perceived performance, this is a clever idea. Ferdy adds, however, that this gives Google, owner of the world’s most important search, an unfair advantage, especially since it does not run this preloading trick on non-AMP pages, while I suppose it could if it wanted to.
  • Luke Stevens feels Google is forking the web. This is reinforced by the news that AMP will now get a JavaScript component as well; something that was purposely omitted so far. But it will of course be a special type of JavaScript that (only?) offers simple DOM methods that are ’sanitized” by the AMP app itself.
    In other words, a subset of JavaScript that will (surprise!) turn out to be not enough for AMP developers, who will either demand more and thus import the web’s performance problems to AMP, or leave AMP altogether, which leads to a win for the web.
    In any case, it makes it less and less clear what AMP is supposed to be a solution to. And people have tried and failed to fork the web so often that I am not terribly worried right now.
  • Mike Monteiro calls for some sort of licensing for designers. This is an interesting idea, but from experience with attempting the same on the front-end side I’ll warn him it’s an uphill battle. On the other hand, my attempt was more than ten years ago, and meanwhile the world has changed.
    While discussing this article I had an idea: how would designers and back-end developers feel about front-end certification? Would they think it’s a good idea?
    Designers who agree with Mike should ask themselves something similar: would developers care? Possibly, I’d say.
  • Patterns for writing manageable CSS without a framework. Simple, solid, sensible advice for managing your CSS. From a purely visual standpoint you can achieve the same by using a CSS framework, but

    My preference for manually writing layout styles is to reduce dependencies, write less-complicated markup (not littered with wrappers and generic class names), and retain the greatest control possible. By writing my own layout system, I can make exceptions for certain cases without relying on “overrides”. When there are edge cases, exceptions can be easily made without hideous hacks upon CSS written by someone else.

    Makes sense.
  • Turns out Mozilla created a JSON feed for browser compatibility data. Interesting idea; I toyed with it ages ago but was too lazy busy to actually implement it.
    As far as I know, except for individual MDN pages, there is no interface yet where you can easily access the information (yeah, I know I could write one myself, but time constraints, and my profound lack of experience with GitHub).
    Still, excellent idea, as long as the data is valid. I occasionally have beef with MDN data, and I also think they do not cover enough browsers. UC and Opera Mini, for instance, are missing. World wide web, remember?
    (Via Jens Grochtdreis)
  • A very neat trick: CSS-only sortable tables. Say again? CSS only? Yup.
    How? By clever use of CSS variables. Read and make your head explode with possibilities.
  • For the mobile history buffs among us: a long look back at the fall of Nokia during the tenure of Stephen Elop, drawn mainly from Finnish inside sources.
  • Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).

Linkbait 36

Tue, 02/13/2018 - 12:32am

Facebook-bashing edition. (I’m merely quoting other people’s bashing, mind you.)

  • An overview of browser testing services because you deserve to test on IE9 and older Chromes.
  • Ada built a game in a week using tools currently available on the web. She wrote a report, and introduces many new tools in the process.
  • Bad if true: W3C uses browser detects.

    Are you aware that since Edge enabled Upgrade-Insecure-Request on our internal builds, we cannot reach any spec because we get redirected from https to http, which we upgrade to https, and loop? If we masquerade our user agent to Chrome's one all works fine.

  • Something that interests me a lot lately: Teaching CSS Grid to newcomers. Well, not specifically Grid in my case, but this article has some excellent ideas and notions about why techies find CSS so complicated, and how to explain it to them.

    Water, for explaining the cascading, global nature of CSS versus the modular, encapsulated nature of most traditional programming languages. Like, traditional programming paradigms treat functions discretely, like stones you can pick up, but CSS is like water, which flows and cannot be controlled, only shaped.

    And the author, Hui Jing Chen, is coming to speak at CSS Day, which is also kind of cool because I can quiz her in person.
  • High drama in time-honoured American fashion about Facebook having a terrible two years. Facebook once was Shiny and Golden; now it’s Hideous and Dark. The truth lies somewhere in the middle, but this article ignores that for obvious clickbait reasons.
    Much more important is the fact that Facebook-bashing has now reached serious momentum. I think that’s healthy. See also the next few items.
  • A study of fake news sites in France and Italy. It turns out the problem is somewhat less serious than was assumed; the fake news sites themselves see only very modest numbers of visitors (the most popular reached 3.5% of the online population). The real problem lies with Facebook, where some fake news items generate more interactions that real news items.
    Facebook is the problem (and Twitter, too, I suppose, but to a lesser degree). That’s something I already assumed, but it’s very good to have it confirmed by research.
    So what are we going to do about it? Block Facebook? It’s too early for that, but the option must be on some internal lists higher up in the EU. If Facebook refuses to take action, we should.
  • An anti-capitalist look at tech’s trust problem.

    But tech appears to have no net positive uses whatsoever. Can it?

    This is somewhat disingenious: we have become accustomed to tech benefits, and the problem is more that its rate of benefit production has fallen while we’ve become more aware of its drawbacks. Still, close off the Internet and you’ll have a much worse popular revolt on your hands.
    Don’t get me wrong — I think the tech giants being taken down a notch is a good thing, but as technologists we have to be careful to define what tech we need to ditch: ads and their tracking mechanisms, the artificial stupidity that selects your Facebook/Google news — as well as, on the non-tech side, the inability to pay for services such as Facebook and Twitter.

    Tech’s challenge was never to remake capitalism all over again?—?only harder, crueller, meaner, even more harmful. It was to shift beyond it.

    I don’t buy this — at least, not entirely. Big tech and the neoliberal movement were born simultaneously in the early nineties, and early tech served as a shining example of neoliberalism while gladly accepting the money. I don’t think tech was ever meant to shift beyond capitalism — the only example I can think of is everything on the web being free of charge, and that was the worst mistake tech ever made, causing, among other things, ad tracking and fake news spread by Facebook’s artificial stupidity.
    Still, food for thought.
  • Remember Facebook Instant Articles that was going to revolutionise news content online? It turns out that more than half of the original 2015 partners have meanwhile abandoned it — and these are not the smallest names in newspaper publishing, either. Apparently it doesn’t work. Also, Facebooks’s announce algorithm change I mentioned in 34 is not going to help here.
  • Unilever is threatening to pull its ads from Facebook and Google (Guardian; NRC) because those companies do not remove posts that “create division in society and promote anger and hate.”
    Unilever is in fact not the first food/personal care multinational to do so: big competitor Procter & Gamble did the same about a year ago. Also in that last article: the tech giants have a trust problem right now, while trust in traditional journalism is increasing.
  • How the EU is exporting its data and privacy regulations to the rest of the world. It’s the EU that’s setting the standard here; not the US, which is more meh about regulations and privacy, especially under the current administration.
    Having sane leaders is a major competitive advantage right now.
    On the other hand, the EU regulations are more-or-less forced onto some countries, who could do with a little less neocolonial paternalism. On the gripping hand, the most important quoted example of such countries, South Africa, is not one that has a great trust in its own government, with Zuma about to resign. So maybe an enforced bit of regulation would be good for it nonetheless?
    Conundrums, conundrums.
  • According to Google, 1% of publishers will be affected by the upcoming selective Chrome ad blocker. To be honest I didn’t know Google was working on this, and I think it’s a good idea — especially in order to force internet advertisers to adapt or die.
  • An older game, but a rather good one, on the evolution of trust. Makes you play the game in order to understand trust/distrust strategies.
  • How to build a horse with various programming languages. JavaScript: the backbone came out angular, so the horse is paralyzed. Perfect summary.
  • Your users are irrational. Interesting read about how people can trick our fast intuitive brain into doing things without thinking, or, even more interesting, how to get our fast intuitive brain to start up our slow logical brain. And how all that applies to designing websites or apps.
  • Something that interests me as a conference organiser: Name badges, the unsung conference heroes. We did some thinking about name badges years ago (see the summary), but this article contains several interesting new ideas, notably adding interests to the badge in order to facilitate conversations.
  • Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).

Linkbait 35

Tue, 01/30/2018 - 5:02am

A short one; not much going on these days. (Or I’m just missing the good stuff.)

  • You’ve probably already heard, but Safari 11.1’s feature list looks good. Progressive web apps are now supported (evidence), but Max Firtman warns we’re not home safe yet. iOS PWA support is still sub-optimal in several respects.
  • Combining CSS Grids and CSS columns. Nice!
    It should be noted, though, that box-decoration-break: clone works on columns only in Firefox.
  • Nicolás Bevacqua’a A Guide to Modular Design Thinking presentation in annotated slide form. Essential reading to everyone who wants to know all about modular JavaScript. Also very interesting for thinking about whether modern JavaScript may be too modularised.
  • Simple trick to identify possibly dead code. Identify possibly dead code by CSS selector, add a unique background image to that selector, wait three months, see if there were any hits on that background image. If not, code is dead.
  • Paul Kinlan makes a list of challenges for web developers. It contains many well-known (platform quirks and compat problems) and less-well-known problems (developers don’t test on the hardware that their users run on and thus it feels “good enough”).
    Curiously, CSS is not mentioned even once, while I’m fairly certain it is a major hassle for JavaScripters who came from another programming language. Worth a mention, I’d say.
  • Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).

My first ALA article from 2000

Thu, 01/25/2018 - 4:41am

Today it’s A List Apart’s 20th birthday. 20th? Yup. Time flies when you’re having fun with browsers.

Anyway, after congratulating Zeldman I reminisced about the very first article I ever wrote for a site other than my own, back in January 2000. (I thought it was 1999, but I turned out to be wrong.) I knew it was no longer on the ALA site, but Zeldman filled me in on the reasons why, which I’d never heard before. The two of us agreed it was a pity, and how we’d love to reread it — especially since I still remember the first paragraph fondly.

Anyway. It took someone else to remind me the article might still exist in the Wayback Machine. Why didn’t I think of that myself? Probably because I’m too lazy busy.

Lo and behold: there it was: fear of style sheets. With good old Joe Stalin on the masthead image, exactly as I remembered. (Zeldman never explained why he picked Uncle Joe, so I still don’t know, and he’s probably forgotten.)

Money quote:

Rule 1) ANY browser should be able to access the content of the site.
Rule 2) Rule 1 does NOT imply that the site should look the same in each browser.

Did we learn anything in the next 18 years? Nope.

Is that surprising? Nope.

Have we become less afraid of style sheets? Nope. (Looking at you, JavaScript developers.)

Anyway, no real conclusion here; just fond memories and a surprisingly modern message if you ignore the browsers the article talks about.

Read it for yourself: Fear of style sheets 3: a new era.

Linkbait 34

Tue, 01/16/2018 - 1:36am

Linkbait! Get yer linkbait!

  • Weird story about how Indian users of the Jio feature phone discovered that, while they could not install WhatsApp on their phone, they could use browser testing service Browserling as a proxy. At first the proprietor tried to close the loophole, but later he decided to go with the flow.
  • Academic paper on JavaScript keystroke timing attacks. Note that, as far as I can see, it has nothing to do with Meltdown or Spectre; it’s just one of those other attacks that sub-millisecond timing allows.
    I hope that making performance.now() coarser will solve this problem as well.
  • Interesting CSS feature request from about a year ago: use counters in calc(). Something like element { margin-left: calc(100px + counter(item)); counter-increment: item; } Problem: counter(item) is a string, and we want a number, or a way to append a unit such as px.
    Still, interesting notion.
  • Brian Leroux feels Github stars create the wrong kind of incentive for impressionable devs, in reaction to this JavaScript Rising Stars report that is based on number of stars repositories acquired.
  • Brad Frost gets upset at Google’s latest robot creep. Can’t say I noticed any of this; possibly it’s US-only. In fact, I hope so.
  • Nice article about the Facebook news feed changes. Money quote:

    Journalism that is engineered to be viral, to be liked or picked by an algorithm is not journalism, it’s marketing.

  • Want more? This article declares the ad-based media site dead, mentions the Google/Facebook duopoly in ads, and proposes to yield that market to them.
    Interestingly, at the end the article looks toward Europe for the necessary innovation, a royalty model, that might save newsrooms and newspapers, while it rejects US “techno-utopianism.”
    More in general, since the EU has no stake in the US tech giants’ continuing operation, harsh but necessary actions are more likely to occur on this side of the ocean. See also the Google fines; and the Microsoft fines of many years ago.
  • Slightly related: a guide to open source financial support. It strikes me that the problems and solutions are roughly the same as for website monetisation, except that open source doesn’t have an ad-driven model (and probably won’t get one either). That bodes ill for open source financial support: it doesn’t work for websites, and it won’t work for open source, either.
    Unless, of course, news sites can work out their problems and their model proves relevant to open source as well.
  • And here’s an interesting bit of Facebook background. This November 2017 article claims a 25% decline in Facebook referrals to reputable news sources, while Google’s referrals grew. The article mentions tweaks to Facebook’s algorithms as a possible cause. Note the date; well before the current news feed discussion. No doubt Facebook was already experimenting back then, and no doubt they noticed the decline in referrals.
    This could be construed as evidence that Facebook is retreating from news — or, if the 25% decline was involuntary, is being pushed out by Google.
  • So let’s talk about Google’s news feeds. People are starting to get worried about AMP and its potential to become a closed silo. Worse, this silo would be created in the name of web performance. The obvious solution to the performance problem is not creating new silos, but ditching tools. But web developers aren’t ready for that jump yet — and the letter does not mention the core problem.
    Granted, the letter takes a nuanced standpoint, and does not attack AMP the fundamental idea, but rather the locking-in that Google sprinkled on top of it.
  • Last week I linked to this XSS attack article that uses npm as an attack vector.
    One reader claimed that the piece was actually satire. Because it was only one reader who said so I didn’t issue a correction, the more since I myself couldn’t tell. The story in itself is totally believable to me. Then again, the best satire is inherently believable.
    Satire? Or serious? You decide.
  • Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).

Linkbait 33

Tue, 01/09/2018 - 3:29am

For the first time in years.

  • Useful for newbies: the Spellbook of Modern Web Dev. Gives a metric shitload of links to important topics, and goes decidedly light on build tools, frameworks, and so on. It’s almost as if this was written to teach people how to be actual web developers instead of framework-copy-paste peons. Lovely!
  • Yet another article about Chrome turning into IE6, this time on The Verge. The article was met by a predictable level of ennui; as someone wrote, any browser nowadays can be the new IE6.
    Still, the point is not that Chrome is technically behind other browsers (it isn’t, to put it mildly), but that it’s approaching Microsoft’s old dominance in the web sphere. And that is a problem; the web is best off when no browser is dominant. So we’ll have to go through a new cycle of dominance and challenge.
  • In other browser news, UC, the third-largest mobile browser, is moving from WebKit to Chromium. Chromium 57, to be exact. Why? My personal guess: CSS Grids, combined with a general feeling that WebKit isn’t cutting the cake any more.
    Not only does this make UC somewhat more predictable in terms of support, it also makes Apple the only browser vendor still to use WebKit.
    It’s unclear whether UC Mini, the proxy browser, will follow this move to Chromium. My guess is that it won’t in the next few years — changing a proxy browsing system is a lot more difficult than changing a full, installable browser — see also Opera Mini, which still uses Presto.
  • A report, with bubble graphs, about the state of JavaScript around the world, with an accompanying summary article. Well, it’s really about frameworks, although “No Framework” is also mentioned, and ends up at about 20%, I’d say from the graphs.
    Also gives breakdown for a number of countries, which is interesting data, although I’m uncertain whether we should attack any meaning to the fact that in France React use is higher than average, while Angular 2 use is lower than average.
    Does not mention jQuery. I dislike a State of JavaScript report not mentioning one of the most important libraries.
  • OK, so jQuery is a library, and not a framework. Yawn. Besides, this semantic trick could be deployed solely because Angular, React, etc. numbers wouldn’t look so great if they’re compared to jQuery. Or I’m wrong and jQuery is going down. In any case, we can’t tell because the data is missing.
    Remy discussed jQuery at length, and includes a graph that shows jQuery so far ahead of other libraries (not frameworks!) that it’s not funny any more.
    I’d love to see a comparison between the frameworks and the libraries. The split appears artificial to me if your goal is to show which ones are popular and which ones aren’t.
  • Another useful data-driven article about how web bloat affects people with slow connections. It does, the problems are huge, and here’s some data to back that up.
    Not than anyone will care. The solution entails cutting down drastically on frameworks and other tools, and web developers aren’t yet ready for that.
  • An XSS attack aimed at gathering credit card numbers and related data by simply reading out form fields. Very easy to do if you can get your malicious script in place.
    In this case, the malicious script was spread via npm. Create an innocent-sounding module, convince others to include it as a dependency, add the malicious code, make sure the code only operates at night, when the QA people are asleep, and bingo! XSS attack succeeded.
    Web developers should stop their mindless copying. It’ll lead to problems like this.
  • Permissions on the web suck. It’s often unclear why you should give a certain permission, the interface is atrocious, and in general web developers (or marketing people) just add asking for permissions for no good reason other than that push notifications are hip.
  • A while ago I wrote about styling and scripting sliders. Recently, Ana Tudor cranked the volume up to 11 with an excellent article that, among other things, goes into how inspectors show (or don’t show) sliders, and the problems that gives. Worth a read if you’re using sliders.
  • The Mozilla Security Blog gives a good overview of the consequences of Meltdown and Spectre for JavaScript. In practice, SharedArrayBuffer will be disabled, and the resolution of performance.now() will be drastically reduced.
    Still, my question remains how much this will actually affect your average JavaScript-heavy site. To me, it seems that there won’t be much of an effect since both items are fairly niche and not in use in most sites.
    I asked on Twitter, but nobody seemed to be sure. Nobody pushed back against my theory that the practical effect is close to zero, so that’s what I’m going to assume for now.
    On the other hand, Tab Atkins warns that more areas of web development could be used as high-res timers, though, and that we’re not out of the woods yet.
  • Google gives in on AMP URLs. Pretty soon, AMP pages will be served from the publishers’ URLs, and not from google.com/amp.
    This is a bigger deal than you might think: might have effect on Facebook as well. Publishers are forced to go through AMP and Facebook because their own sites are so very bad, and because Facebook is where the audience is. BUT if they did nothing, they'd lose their own branding and news would become commoditised. Thus they want to retain some aspect of their identity. Google is now giving them that. Will Facebook follow?
  • Speaking of Facebook, here’s a good article on Facebook’s flawed business model. For Facebook itself it might be good to move away from an ad-driven revenue stream, but the shareholders won’t accept it, so it won’t happen. (Did I mention that shareholders are the most serious problem we have on earth right now?). The article closes with the idea that Zuckerberg might ignore shareholders anyway. I’d like to see that before I believe it.
  • Six months ago I wrote about woman speakers and attendees at the conferences I co-organised in Amsterdam. Turns out that two months later Jeremy replied to and disagreed with one of my statements. I apologise; I saw this only yesterday.
    I said that I did not believe in having 50% woman speakers at conferences, since the audience does not consist of 50% women. I did this partly in order to get people to think, and I wasn’t sure what the best percentage should be.
    Jeremy disagrees; his argument is that a line-up should be at least partly aspirational: how many women (or other non-white non-men) do we want to have in the audience. That, according to him, is the crux of the matter.
    That is a solid argument that I am sensitive to, but it still doesn’t tell us how many women there should be. But that’s a very difficult question, and neither Jeremy nor I have a pre-cooked answer for you.
    The absolute minimum of women speakers for the conference I co-organise is 2 per day, or 25%. In practice, we’re usually somewhat above that number. Good enough? Not good enough? I don’t know, but so far I’m pretty happy with how it turned out.
  • Have anything for the next Linkbait? Let me know.
©2003 - Present Akamai Design & Development.