Tags: browser



[css-exclusions] Status of the exclusions spec #3308

Remember when I said that if we want to see CSS exclusions implemented in browsers, we need to make some noise?

Well, Rachel is taking names, so if you’ve got a use-case, let her know.

CSS and Network Performance – CSS Wizardry

Harry takes a look at the performance implications of loading CSS. To be clear, this is not about the performance of CSS selectors or ordering (which really doesn’t make any difference at this point), but rather it’s about the different ways of getting rid of as much render-blocking CSS as possible.

…a good rule of thumb to remember is that your page will only render as quickly as your slowest stylesheet.

Editorial Layouts, Floats, and CSS Grid | Rob Weychert

I remember a couple of years back when Jen came to visit Clearleft to chat to us about CSS grid, this use-case that Rob describes here came up almost immediately.

But despair not—Rachel points to a potential solution. I saw potential solution, because if we want to see this implemented in browsers, we need to make some noise.

Phil Nash and Jeremy Keith Save the Safari Video Playback Day

I love this example of paying it forward:

So We Got Tracked Anyway

Even using a strict cookie policy won’t help when Facebook and Google are using TLS to fingerprint users. Time to get more paranoid:

HTTPS session identifiers can be disabled in Mozilla products manually by setting ‘security.ssl.disablesessionidentifiers’ in about:config.

The Way We Talk About CSS

A very thoughtful post by Rachel…

There is frequently talk about how developers whose main area of expertise is CSS feel that their skills are underrated. I do not think we help our cause by talking about CSS as this whacky, quirky language. CSS is unlike anything else, because it exists to serve an environment that is unlike anything else. However we can start to understand it as a designed language, with much consistency. It has codified rules and we can develop ways to explain and teach it, just as we can teach our teams to use Bootstrap, or the latest JavaScript framework.

Designing With Code

How mucking about in HTML and CSS can lead to some happy accidents.

‘Sfunny, people often mention the constraints and limitations of “designing in the browser”, but don’t recognise that every tool—including Sketch and Photoshop—comes with constraints and limitations. It’s just that those are constraints and limitations that we’ve internalised; we no longer even realise they’re there.

Thinking about permissions on the web | Sally Lait

Sally takes a long hard look at permissions on the web. It’s a fascinating topic because of all the parties involved—browsers, developers, and users.

In order to do permissions well, I think there are two key areas to think about - what’s actually being requested, and how it’s being requested.

Is a site being intrusive with what they can potentially learn about me (say, wanting my precise location when it’s unnecessary)? Or is it being intrusive in terms of how they interact with me (popping up a lot of notifications and preventing me from quickly completing my intended task)? If one of those angles doesn’t work well, then regardless of whether the other is acceptable to someone, they’re likely to start opting out and harbouring negative feelings.

DasSur.ma – The 9am rush hour

Why JavaScript is a real performance bottleneck:

Rush hour. The worst time of day to travel. For many it’s not possible to travel at any other time of day because they need to get to work by 9am.

This is exactly what a lot of web code looks like today: everything runs on a single thread, the main thread, and the traffic is bad. In fact, it’s even more extreme than that: there’s one lane all from the city center to the outskirts, and quite literally everyone is on the road, even if they don’t need to be at the office by 9am.

The State of Fieldset Interoperability - Bocoup

The long-standing difficulties of styling fieldset and legend are finally getting addressed …although I’m a little shocked that the solution involves extending -webkit-appearance. I think that, at this point, we should be trying to get rid of vendor prefixes from the web once and for all, not adding to them. Still, needs must, I suppose.

Removing jQuery from GitHub.com frontend | GitHub Engineering

You really don’t need jQuery any more …and that’s thanks to jQuery.

Here, the Github team talk through their process of swapping out jQuery for vanilla JavaScript, as well as their forays into web components (or at least the custom elements bit).

“Killing the URL” | CSS-Tricks

URLs are the single greatest feature of the web.

881410 - Incorrect transforms when stripping subdomains

The latest version of Chrome is removing seams by messing with the display of the URL.

This is a bug.

The mysterious case of missing URLs and Google’s AMP | sonniesedge.co.uk

My reaction to that somewhat sensentionalist Wired article was much the same as Charlie’s—seeing it on the same day at the latest AMP sneakiness has me worried.

The hiding of URLs fits perfectly with AMPs preferred method of making sites fast, which is to host them directly on Google’s servers, and to serve them from a Google domain. Hiding the URL from the user then makes a Google AMP site indistinguishable from an ordinary site.

As well as sharing Charlie’s concern, I also share her hope:

I really hope that the people who are part of Google can stop something awful like this from happening.

The Font Loading Checklist—zachleat.com

This checklist came in very handy during a performance-related workshop I was running today (I may have said the sentence “Always ask yourself What Would Zach Do?”).

  1. Start Important Font Downloads Earlier (Start a Web Font load)
  2. Prioritize Readable Text (Behavior while a Web Font is loading)
  3. Make Fonts Smaller (Reduce Web Font load time)
  4. Reduce Movement during Page Load (Behavior after a Web Font has loaded)

The first two are really straightforward to implement (with rel="preload" and font-display). The second two take more work (with subsetting and the font loading API).

Google Wants to Kill the URL | WIRED

Change will be controversial whatever form it takes. But it’s important we do something, because everyone is unsatisfied by URLs. They kind of suck.

Citation very fucking needed.

I’m trying very hard to give Google the benefit of the doubt here, but coming as it does on top of all the AMP shit they’re pulling, it sure seems like Google are trying to remake the web in their image.

Oh, and if you want to talk about URLs confusing people, AMP is a great example.

The Ecological Impact of Browser Diversity | CSS-Tricks

This is a terrific spot-on piece by Rachel. I firmly believe that healthy competition and diversity in the browser market is vital for the health of the web (which is why I’m always saddened and frustrated to hear web developers wish for a single monocultural rendering engine).

Changing Our Approach to Anti-tracking - Future Releases

This is excellent news from Mozilla. Firefox is going to make it easier to block vampiric privacy-leeching and performance-draining third-party scripts and trackers.

In the physical world, users wouldn’t expect hundreds of vendors to follow them from store to store, spying on the products they look at or purchase. Users have the same expectations of privacy on the web, and yet in reality, they are tracked wherever they go.

The power of progressive enhancement – No Divide – Medium

The beauty of this approach is that the site doesn’t ever appear broken and the user won’t even be aware that they are getting the ‘default’ experience. With progressive enhancement, every user has their own experience of the site, rather than an experience that the designers and developers demand of them.

A case study in applying progressive enhancement to all aspects of a site.

Progressive enhancement isn’t necessarily more work and it certainly isn’t a non-JavaScript fallback, it’s a change in how we think about our projects. A complete mindset change is required here and it starts by remembering that you don’t build websites for yourself, you build them for others.

Let’s serve everyone good-looking content

A terrific piece by Hidde, about CSS grid, but also about a much bigger question:

I don’t think we owe it to any users to make it all exactly the same. Therefore we can get away with keeping fallbacks very simple. My hypothesis: users don’t mind, they’ve come for the content.

If users don’t mind, that leaves us with team members, bosses and clients. In my ideal world we should convince each other, and with that I mean visual designers, product owners, brand people, developers, that it is ok for our lay-out not to look the same everywhere. Because serving good-looking content everywhere is more important than same grids everywhere.