Tags: web

1682

sparkline

Tuesday, September 14th, 2021

BDConf & Mobilewood: 10-years later | Brad Frost

Brad reminisces about the scene ten years ago.

I’m not sure I’ll ever be a part of such an exciting moment in this field again. Of course technology continues to evolve, but the web landscape has settled down a bit. While I’m more than okay with that, I occasionally miss the electric, optimistic feeling of being on the cusp of something new and exciting.

Monday, September 13th, 2021

Stakeholders of styling

When I wrote about the new accent-color property in CSS, I pondered how much control a web developer should have over styling form controls:

Who are we to make that decision? Shouldn’t the user’s choice take primacy over our choices?

But then again, where do we draw the line? We’re allowed over-ride link colours. We’re allowed over-ride font choices.

Ultimately, I came down on the side of granting authors more control:

If developers don’t get a standardised way to customise native form controls, they’ll just recreate their own over-engineered versions.

This question of “who gets to decide?” used to be much more prevelant in the early days of the web. One way to think about this is that there are three stakeholders involved in the presentation of a web page:

  1. The author of the page. “Author” is spec-speak for designer or developer.
  2. The user.
  3. The browser, or user agent. A piece of software tries to balance the needs of both author and user. But, as the name implies, the user takes precedence.

These days we tend to think of web design a single-stakeholder undertaking. The author decides how something should be presented and then executes that decision using CSS.

But as Eric once said, every line of you CSS you write is a suggestion to the browser. That’s not how we think about CSS though. We think of CSS like a series of instructions rather than suggestions. Never mind respecting the user’s preferences; one of the first things we do is reset all the user agent’s styles.

In the early days of the web, more consideration was given to the idea of style suggestions rather than instructions. Heck, users could always over-ride any of your suggestions with their own user stylesheet. These days, users would need to install a browser extension to do the same thing.

The first proposal for CSS had a concept called “influence”:

h2.font.size = 20pt 40%

Here, the requested influence is reduced to 40%. If a style sheet later in the cascade also requests influence over h2.font.size, up to 60% can be granted. When the document is rendered, a weighted average of the two requests is calculated, and the final font size is determined.

I think the only remnant of “influence” left in CSS is accidental. It’s in the specificity of selectors …and the !important declaration.

I think it’s a shame that user stylesheets are no longer a thing. But I get why they were dropped from browsers. They date from a time when it was mostly nerds using the web, before “regular folks” came on board. I understand why it became a little-used feature, suitable for being dropped. But the principle of it still rankles slightly.

But in recent years there has been a slight return to the multi-stakeholder concept of styling websites. Thanks to prefers-reduced-motion and prefers-color-scheme, a responsible author can choose to bow to the wishes of the user.

I was reminded of this when I added a dark mode to my website:

Y’know, when I first heard about Apple adding dark mode to their OS—and also to CSS—I thought, “Oh, great, Apple are making shit up again!” But then I realised that, like user style sheets, this is one more reminder to designers and developers that they don’t get the last word—users do.

Thursday, September 9th, 2021

Chrome is the new Safari. And so are Edge and Firefox. – Hello my name is Niels Leenheer

You may not realise that all browsers on iOS are required to use the same rendering engine as Safari. On other platforms, this is not the case.

A terrific in-depth look at the frustrating state of the web on iOS.

So it’s not just one browser that falls behind. It’s all browsers on iOS. The whole web on iOS falls behind. And iOS has become so important that the entire web platform is being held back as a result.

And this damning assessment is mercifully free of conspiracy theories.

The Safari and Chrome team both want to make the web safer and work hard to improve the web. But they do have different views on what the web should be.

Google is focussing on improving the web by making it more capable.

Safari seems to focus on improving the web as it currently is.

Read the whole thing—it’s excellent!

There can only be one proper solution: Apple needs to open up their App Store to browsers with other rendering engines. Scrap rule 2.5.6 and allow other browsers on iOS and let them genuinely compete. Even though Apple has been forced to compromise on some App Store rules, I have little hope for this to happen.

Why We Create Progressive Web Apps: A Conversation with Jeremy Keith

This is a really nice write-up by Sydney of the chat we had on her podcast.

Meet the Self-Hosters, Taking Back the Internet One Server at a Time

Taking the indie web to the next level—self-hosting on your own hardware.

Tired of Big Tech monopolies, a community of hobbyists is taking their digital lives off the cloud and onto DIY hardware that they control.

Wednesday, September 8th, 2021

Decoded: The When, Why, and Why Not of Progressive Web Apps

I really enjoyed talking to Sydney Lai about progressive web apps, resilient web design, and all my other hobby horses.

Alas, there’s no transcript and I can’t find a direct link to the RSS feed or the individual audio file on the podcast website so it’s not huffduffable.

404PageFound – Active Vintage Websites, Old Webpages, and Web 1.0

Well, this is rather lovely! A collection of websites from the early days of the web that are still online.

All the HTML pages still work today …and they work in your web browser which didn’t even exist when these websites were built.

Tuesday, September 7th, 2021

Bruce Lawson’s personal site  : Briefing to the UK Competition and Markets Authority on Apple’s iOS browser monopoly and Progressive Web Apps

Following on from Stuart’s, here’s Bruce’s presentation to the CMA on Apple’s monopolistic practices and hostility to progressive web apps.

as days pass by — Talking to the Competition and Markets Authority about Apple

What I would like is that I can give users the best experience on the web, on the best mobile hardware. That best mobile hardware is Apple’s, but at the moment if I want to choose Apple hardware I have to choose a sub-par web experience. Nobody can fix this other than Apple, and there are a bunch of approaches that they could take — they could make Safari be a best-in-class experience for the web, or they could allow other people to collaborate on making the browser best-in-class, or they could stop blocking other browsers from their hardware. People have lots of opinions about which of these, or what else, could and should be done about this; I think pretty much everyone thinks that something should be done about it, though.

Using the platform

Elise Hein documents what it was like to build a website (or web app, if you prefer) the stackless way:

  • use custom elements (for modular HTML without frameworks)
  • use the in-browser package manager (for JavaScript packages without build tools)
  • match pages with files (to avoid routing and simplify architecture)
  • stick to standards (to avoid obsolescence and framework fatigue)

Her conclusions are similar to my own: ES6 modules mean you can kiss your bundler goodbye; web components are a mixed bag—it’s frustrating that Apple are refusing to allow native elements to be extended. Interestingly, Elise feels that a CSS preprocessor is still needed for her because she wants to be able to nest selectors …but even that’s on its way now!

Perhaps we might get to the stage where it isn’t an automatic default to assume you’ll need bundling, concatenation, transpiling, preprocessing, and all those other tasks that we’ve become dependent on build tools for.

I have a special disdain for beginner JavaScript tutorials that have you run create-react-app as the first step, and this exercise has only strengthened my conviction that every beginner programmer should get to grips with HTML, CSS and vanilla JS before delving into frameworks. Features native to the web are what all frameworks share, and knowing the platform makes for a stronger foundation in the face of change.

Sunday, September 5th, 2021

IndieWeb Events: Gardens and Streams II

September 25th, online:

We’ll discuss and brainstorm ideas related to wikis, commonplace books, digital gardens, zettelkasten, and note taking on personal websites and how they might interoperate or communicate with each other. This can include IndieWeb building blocks, user interfaces, functionalities, and everyones’ ideas surrounding these. Bring your thoughts, ideas, and let’s discuss and build.

Monday, August 30th, 2021

My love-hate affair with technology | Read the Tea Leaves

A very open and honest post by Nolan on trying to live with technology without sacrificing privacy.

Thursday, August 26th, 2021

Demystifying Public Speaking by Lara Callender Hogan

Lara’s superb book on public speaking is now available in its entirity for free as a web book!

And a very beautiful web book it is too! All it needs is a service worker so it works offline.

Monday, August 23rd, 2021

Friday, August 20th, 2021

Thank You For Reading - Jim Nielsen’s Blog

Your attentive kindness doesn’t get picked up by any analytical tool I’ve got other than my heart and my memory—however short lived.

Thursday, August 19th, 2021

Is Safari the new Internet Explorer?

The transcript from the latest episode of the HTTP 203 podcast is well worth perusing.

  • Internet Explorer halted development, no innovation. Would you say Safari is the new IE?
  • There was loads of stuff missing. Is Safari the new IE?
  • My early career was built on knowing the bugs in IE6 and how to solve them. Is Safari the new IE?
  • Internet Explorer 6, it had a really slow JavaScript engine, performance was bad in that browser. Is Safari the new IE?
  • Internet Explorer had a fairly cavalier attitude towards web standards. Is Safari the new IE?
  • Back in the day that we had almost no communication whatsoever. Is Safari the new IE?
  • Slow-release cycle. Is Safari the new IE?

Tuesday, August 17th, 2021

Letters to a Young Technologist

A handsome web book that’s a collection of thoughtful articles on technology, culture, and society by Jasmine Wang, Saffron Huang, and other young technologists:

Letters to a Young Technologist is a collection of essays addressed to young technologists, written by a group of young technologists.

SafarIE

I was moaning about Safari recently. Specifically I was moaning about the ridiculous way that browser updates are tied to operating system updates.

But I felt bad bashing Safari. It felt like a pile-on. That’s because a lot of people have been venting their frustrations with Safari recently:

I think it’s good that people share their frustrations with browsers openly, although I agree with Baldur Bjarnason that’s good to avoid Kremlinology and the motivational fallacy when blogging about Apple.

It’s also not helpful to make claims like “Safari is the new Internet Explorer!” Unless, that is, you can back up the claim.

On a recent episode of the HTTP 203 podcast, Jake and Surma set out to test the claim that Safari is the new IE. They did it by examining Safari according to a number of different measurements and comparing it to the olden days of Internet Explorer. The result is a really fascinating trip down memory lane along with a very nuanced and even-handed critique of Safari.

And the verdict? Well, you’ll just to have to listen to the podcast episode.

If you’d rather read the transcript, tough luck. That’s a real shame because, like I said, it’s an excellent and measured assessment. I’d love to add it to the links section of my site, but I can’t do that in good conscience while it’s inaccessible to the Deaf community.

When I started the Clearleft podcast, it was a no-brainer to have transcripts of every episode. Not only does it make the content more widely available, but it also makes it easier for people to copy and paste choice quotes.

Still, I get it. A small plucky little operation like Google isn’t going to have the deep pockets of a massive corporation like Clearleft. But if Jake and Surma were to open up a tip jar, I’d throw some money in to get HTTP 203 transcribed (I recommend getting Tina Pham to do it—she’s great!).

I apologise for my note of sarcasm there. But I share because I care. It really is an excellent discussion; one that everyone should be able to access.

Update: the bug with that episode of the HTTP 203 podcast has been fixed. Here’s the transcript! And all future episodes will have transcripts too:

Monday, August 9th, 2021

Turning 30 · Matthias Ott – User Experience Designer

I have no idea what the web will look like in another 30 years. But I am sure that we will look back at the first 30 years of the Web like we look back at the silent era in cinema today: as the formative years of a medium that was about to evolve to even higher heights.

The Web has always been about what each and every one of us contributes. And contributing is easier and more important than ever. So let’s not leave the future of the Web to big tech alone. Inclusiveness, accessibility, performance, security, usability, decentralization, openness – in almost all areas, the Web is far from done.

Sunday, August 8th, 2021

Browsers

I mentioned recently that there might be quite a difference in tone between my links and my journal here on my website:

’Sfunny, when I look back at older journal entries they’re often written out of frustration, usually when something in the dev world is bugging me. But when I look back at all the links I’ve bookmarked the vibe is much more enthusiastic, like I’m excitedly pointing at something and saying “Check this out!” I feel like sentiment analyses of those two sections of my site would yield two different results.

My journal entries have been even more specifically negative of late. I’ve been bitchin’ and moanin’ about web browsers. But at least I’m an equal-opportunities bitcher and moaner.

I wish my journal weren’t so negative, but my mithering behaviour has been been encouraged. On more than one occasion, someone I know at a browser company has taken me aside to let me know that I should blog about any complaints I might have with their browser. It sounds counterintuitive, I know. But these blog posts can give engineers some ammunition to get those issues prioritised and fixed.

So my message to you is this: if there’s something about a web browser that you’re not happy with (or, indeed, if there’s something you’re really happy with), take the time to write it down and publish it.

Publish it on your website. You could post your gripes on Twitter but whinging on Jack’s website is just pissing in the wind. And I suspect you also might put a bit more thought into a blog post on your own site.

I know it’s a cliché to say that browser makers want to hear from developers—and I’m often cynical about it myself—but they really do want to know what we think. Share your thoughts. I’ll probably end up linking to what you write.