Tags: browsers

507

sparkline

All you need to know about hyphenation in CSS | Clagnut by Richard Rutter

Everything you need to know about hyphenation on the web today, from Rich’s galaxy brain.

Hyphenation is a perfect example of progressive enhancement, so you can start applying the above now if you think your readers will benefit from it – support among browsers will only increase.

I Used The Web For A Day On Internet Explorer 8 — Smashing Magazine

A fascinating look at the web today with IE8. And it’s worth remembering who might be experiencing the web like this:

Whoever they are, you can bet they’re not using an old browser just to annoy you. Nobody deliberately chooses a worse browsing experience.

The article also outlines two possible coping strategies:

  1. Polyfilling Strive for feature parity for all by filling in the missing browser functionality.
  2. Progressive Enhancement Start from a core experience, then use feature detection to layer on functionality.

Take a wild guess as to which strategy I support.

There’s a bigger point made at the end of all this:

IE8 is today’s scapegoat. Tomorrow it’ll be IE9, next year it’ll be Safari, a year later it might be Chrome. You can swap IE8 out for ‘old browser of choice’. The point is, there will always be some divide between what browsers developers build for, and what browsers people are using. We should stop scoffing at that and start investing in robust, inclusive engineering solutions. The side effects of these strategies tend to pay dividends in terms of accessibility, performance and network resilience, so there’s a bigger picture at play here.

Chromium Blog: Chrome Lite Pages - For a faster, leaner loading experience

My first reaction to this was nervousness. Of all the companies to trust with intercepting and rerouting page requests, Google aren’t exactly squeeky clean, what with that whole surveillance business model of theirs.

Still, this ultimately seems to be a move to improve the end user experience, and I’m glad to see this clarification:

Lite pages are only triggered for extremely slow sites, so we encourage developers to measure how well their pages are currently performing over slow networks.

Lite pages as a badge of shame (much like AMP in my eyes).

First Web browser revived during hackathon - YouTube

This is the lovely little film about our WorldWideWeb hack project. It was shown yesterday at CERN during the Web@30 celebrations. That was quite a special moment.

First Web browser revived during hackathon

WorldWideWeb coverage

Remy’s keeping a list of hyperlinks to stories covering our recent hack week at CERN.

AddyOsmani.com - JavaScript Loading Priorities in Chrome

A table showing how browsers prioritise a) the loading of JavaScript and b) the execution of JavaScript.

nexus-project / nexus-browser · GitLab

Here’s the source code for the WorldWideWeb project we did at CERN.

WWW: Where’s the Writable Web?

Prompted by our time at CERN, Remy ponders why web browsers (quite quickly) diverged from the original vision of being read/write software.

WorldWideWeb, 30 years on – Dan Q

This is a lovely write-up of the WorldWideWeb hack week at CERN:

The Web is a success story in open standards, natural and by-design progressive enhancement, and the future-proof archivability of human-readable code.

FOREVERYONE.NET

I linked to this a while back but now this great half hour documentary by Jessica Yu is ready and you can watch the whole thing online: Tim Berners-Lee, the birth of the web, and where the web has gone since.

In the scenes describing the early web, there’s footage of the recreated Line Mode Browser—how cool is that‽

Recreating the First Web Browser at CERN | U.S. Mission to International Organizations in Geneva

The US Mission to the UN in Geneva came by to visit us during our hackweek at CERN.

“Our hope is that over the next few days we are going to recreate the experience of what it would be like using that browser, but doing it in a way that anyone using a modern web browser can experience,” explains team member Jeremy Keith. The aim is to “give people the feeling of what it would have been like, in terms of how it looked, how it felt, the fonts, the rendering, the windows, how you navigated from link to link.”

Recreating the first web browser at CERN | Flickr

Photos from earlier this week:

In a small room in CERN’s Data Center, an international group of nine developers is taking a plunge back in time to the beginnings of the World Wide Web. Their aim is to enable the whole world to experience what the web looked like viewed within the very first browser developed by Tim Berners-Lee.

Recreating the First Web Browser at CERN

Public Affairs Office on Instagram

A little teaser from U.S. MIssion at the U.N. in Geneva:

This year marks the 30th Anniversary of the birth of the #WorldWideWeb. A team of #webdevelopers are working to make it possible for the public to experience the #FirstWebBrowser as it looked on #TimBernersLees’s computer @CERN…

A Simpler Web: I Concur

Tales of over-engineering, as experienced by Bridget. This resonates with me, and I think she’s right when she says that these things go in cycles. The pendulum always ends up swinging the other way eventually.

CSS Remedy

This is a really interesting approach that isn’t quite a CSS reset or a normalisation. Instead, it’s an experiment to reimagine what a default browser stylesheet would be like if it were created today, without concerns about backwards compatibility:

Applies basic styling to form elements and controls, getting you started with custom styling. We want to find the balance between providing a base for implementing a custom design, and allowing OS-level control over how form inputs work (like how a number pad works on iOS).

Provides a very lightweight starter file, with generic visual styling that you will want to replace. This isn’t as robust or opinionated as a starter-theme or framework. We’ve leaned toward specifying less, so you have less to override. (We haven’t defined any font families, for example.)

You can contribute by adding issues.

Limiting JavaScript? - TimKadlec.com

Following on from that proposal for a browser feature that I linked to yesterday, Tim thinks through all the permutations and possibilities of user agents allowing users to throttle resources:

If a limit does get enforced (it’s important to remember this is still a big if right now), as long as it’s handled with care I can see it being an excellent thing for the web that prioritizes users, while still giving developers the ability to take control of the situation themselves.

194028 – Add limits to the amount of JavaScript that can be loaded by a website

Now this is a feature request I can get behind!

A user must provide permission to enable geolocation, or notifications, or camera access, so why not also require permission for megabytes of JavaScript that will block the main thread?

Without limits, there is no incentive for a JavaScript developer to keep their codebase small and dependencies minimal. It’s easy to add another framework, and that framework adds another framework, and the next thing you know you’re loading tens of megabytes of data just to display a couple hundred kilobytes of content.

I’m serious about this. It’s is an excellent proposal for WebKit, similar to the never-slow mode proposed by Alex for Chromium.

No More Google

A list of alternatives to Google’s products.