Technology doesn’t have to be terrible. Here’s an absolutely wonderful use of an e-ink display:
I made as much use of vanilla HTML and CSS as possible. I used a small amount of JavaScript but no framework or other libraries.
Those HTML web components I made for date inputs are very simple. All they do is slightly extend the behaviour of the existing input elements.
This would be the ideal use-case for the is attribute:
<input is="input-date-future" type="date">
Alas, Apple have gone on record to say that they will never ship support for customized built-in elements.
So instead we have to make HTML web components by wrapping existing elements in new custom elements:
<input-date-future>
<input type="date">
<input-date-future>
The end result is the same. Mostly.
Because there’s now an additional element in the DOM, there could be unexpected styling implications. Like, suppose the original element was direct child of a flex or grid container. Now that will no longer be true.
So something I’ve started doing with HTML web components like these is adding something like this inside the connectedCallback method:
connectedCallback() {
this.style.display = 'contents';
…
}
This tells the browser that, as far as styling is concerned, there’s nothing to see here. Move along.
Or you could (and probably should) do it in your stylesheet instead:
input-date-future {
display: contents;
}
Just to be clear, you should only use display: contents if your HTML web component is augmenting what’s within it. If you add any behaviours or styling to the custom element itself, then don’t add this style declaration.
It’s a bit of a hack to work around the lack of universal support for the is attribute, but it’ll do.
I had the opportunity to trim some code from The Session recently. That’s always a good feeling.
In this case, it was a progressive enhancement pattern that was no longer needed. Kind of like removing a polyfill.
There are a couple of places on the site where you can input a date. This is exactly what input type="date" is for. But when I was making the interface, the support for this type of input was patchy.
So instead the interface used three select dropdowns: one for days, one for months, and one for years. Then I did a bit of feature detection and if the browser supported input type="date", I replaced the three selects with one date input.
It was a little fiddly but it worked.
Fast forward to today and input type="date" is supported across the board. So I threw away the JavaScript and updated the HTML to use date inputs by default. Nice!
I was discussing date inputs recently when I was talking to students in Amsterdam:
They’re given a PDF inheritance-tax form and told to convert it for the web.
That form included dates. The dates were all in the past so the students wanted to be able to set a max value on the datepicker. Ideally that should be done on the server, but it would be nice if you could easily do it in the browser too.
Wouldn’t it be nice if you could specify past dates like this?
<input type="date" max="today">
Or for future dates:
<input type="date" min="today">
Alas, no such syntactic sugar exists in HTML so we need to use JavaScript.
This seems like an ideal use-case for HTML web components:
Instead of all-singing, all-dancing web components, it feels a lot more elegant to use web components to augment your existing markup with just enough extra behaviour.
In this case, it would be nice to augment an existing input type="date" element. Something like this:
<input-date-past>
<input type="date">
</input-date-past>
Here’s the JavaScript that does the augmentation:
customElements.define('input-date-past', class extends HTMLElement {
constructor() {
super();
}
connectedCallback() {
this.querySelector('input[type="date"]').setAttribute('max', new Date().toISOString().substring(0,10));
}
});
That’s it.
Here’s a CodePen where you can see it in action along with another HTML web component for future dates called, you guessed it, input-date-future.
Smart advice on future-proofing and backward-compatibility:
There isn’t a single, specific device, browser, and person we cater to when creating a web experience. Websites and web apps need to adapt to a near-infinite combination of these circumstances to be effective. This adaptability is a large part of what makes the web such a successful medium.
Consider doing the hard work to make it easy and never remove feature queries and @supports statements. This creates a robust approach that can gracefully adapt to the past, as well as the future.
This is something I bump against over and over again: so-called evergreen browsers that can’t actually be updated because of operating system limits.
From what I could gather, the version of Chrome was tied to ChromeOS which couldn’t be updated because of the hardware. No new ChromeOS meant no new Chrome which meant stuck at version 76.
But what about the iPad? I discovered that my Mom’s iPad was a 1st generation iPad Air. Apple stopped supporting that device in iOS 12, which means it was stuck with whatever version of Safari last shipped with iOS 12.
So I had two older browsers that couldn’t be updated. It was device obsolescence because you couldn’t install the latest browser.
Websites stop working and the only solution is to buy a whole new device.
Safari has been subjected to a lot of ire recently. Most of that ire has been aimed at the proposed changes to the navigation bar in Safari on iOS—moving it from a fixed top position to a floaty bottom position right over the content you’re trying to interact with.
Courage.
It remains to be seen whether this change will actually ship. That’s why it’s in beta—to gather all the web’s hot takes first.
But while this very visible change is dominating the discussion, invisible changes can be even more important. Or in the case of Safari, the lack of changes.
Compared to other browsers, Safari lags far behind when it comes to shipping features. I’m not necessarily talking about cutting-edge features either. These are often standards that have been out for years. This creates a gap—albeit an invisible one—between Safari and other browsers.
Jorge Arango has noticed this gap:
I use Safari as my primary browser on all my devices. I like how Safari integrates with the rest of the OS, its speed, and privacy features. But, alas, I increasingly have issues rendering websites and applications on Safari.
That’s the perspective of an end-user. Developers who have to deal with the gap in features are more, um, strident in their opinions. Perry Sun wrote For developers, Apple’s Safari is crap and outdated:
Don’t get me wrong, Safari is very good web browser, delivering fast performance and solid privacy features.
But at the same time, the lack of support for key web technologies and APIs has been both perplexing and annoying at the same time.
Alas, that post also indulges in speculation about Apple’s motives which always feels a bit too much like a conspiracy theory to me. Baldur Bjarnason has more to say on that topic in his post Kremlinology and the motivational fallacy when blogging about Apple. He also points to a good example of critiquing Safari without speculating about motives: Dave’s post One-offs and low-expectations with Safari, which documents all the annoying paper cuts inflicted by Safari’s “quirks.”
Another deep dive that avoids speculating about motives comes from Tim Perry: Safari isn’t protecting the web, it’s killing it. I don’t agree with everything in it. I think that Apple—and Mozilla’s—objections to some device APIs are informed by a real concern about privacy and security. But I agree with his point that it’s not enough to just object; you’ve got to offer an alternative vision too.
That same post has a litany of uncontroversial features that shipped in Safari looong after they shipped in other browsers:
Again: these are not contentious features shipping by only Chrome, they’re features with wide support and no clear objections, but Safari is still not shipping them until years later. They’re also not shiny irrelevant features that “bloat the web” in any sense: each example I’ve included above primarily improving core webpage UX and performance. Safari is slowing that down progress here.
But perhaps most damning of all is how Safari deals with bugs.
A recent release of Safari shipped with a really bad Local Storage bug. The bug was fixed within a day. Yay! But the fix won’t ship until …who knows?
This is because browser updates are tied to operating system updates. Yes, this is just like the 90s when Microsoft claimed that Internet Explorer was intrinsically linked to Windows (a tactic that didn’t work out too well for them in the subsequent court case).
I don’t get it. I’m pretty sure that other Apple products ship updates and fixes independentally of OS releases. I’m sure I’ve received software updates for Keynote, Garage Band, and other pieces of software made by Apple.
And yet, of all the applications that need a speedy update cycle—a user agent for the World Wide Web—Apple’s version is needlessly delayed by the release cycle of the entire operating system.
I don’t want to speculate on why this might be. I don’t know the technical details. But I suspect that the root cause might not be technical in nature. Apple have always tied their browser updates to OS releases. If Google’s cardinal sin is avoiding anything “Not Invented Here”, Apple’s downfall is “We’ve always done it this way.”
Evergreen browsers update in the background, usually at regular intervals. Firefox is an evergreen browser. Chrome is an evergreen browser. Edge is an evergreen browser.
Safari is not an evergreen browser.
That’s frustrating when it comes to new features. It’s unforgivable when it comes to bugs.
At least on Apple’s desktop computers, users have the choice to switch to a different browser. But on Apple’s mobile devices, users have no choice but to use Safari’s rendering engine, bugs and all.
As I wrote when I had to deal with one of Safari’s bugs:
I wish that Apple would allow other rendering engines to be installed on iOS devices. But if that’s a hell-freezing-over prospect, I wish that Safari updates weren’t tied to operating system updates.
This is very handy indeed! Quick one-line JavaScript helpers categorised by type.
And, no, you don’t need to npm install any of these. Try “vendoring” them instead (that’s copying and pasting to you and me).
Such an elegant idea!
Bookfeed.io is a simple tool that allows you to specify a list of authors, and generates an RSS feed with each author’s most recently released book.
Small pieces, loosely joined.
Personal website owners – what do you think about collecting all of the feeds you are producing in one way or the other on a
/feedspage?
Sounds like a good idea! I’ll get on that.
In some situations, a date picker is overkill:
I have relied on plain text inputs as date fields with custom validation for the site, typically using the same logic on the client and the server. For known dates — birthdays, holidays, anniversaries, etc — it has tested well.
An interesting look at the mortality causes for Internet Explorer 6 and Internet Explorer 8, and what they can tell us for the hoped-for death of Internet Explorer 11.
I disagree with the conclusion (that we should actively block IE11—barring any good security reasons, I don’t think that’s defensible), but I absolutely agree that we shouldn’t be shipping polyfills in production just for IE11. Give it your HTML. Give it your CSS. Withhold modern JavaScript. If you’re building with progressive enhancement (and you are, right?), then giving IE11 users a sub-par experience is absolutely fine …it’s certainly better than blocking them completely.
Jason contemplates his two decades of blog posts, some of which he now feels very differently about:
Tim Berners-Lee’s idea that cool URIs don’t change is almost part of my DNA at this point, so deleting them seems wrong. Approximately no one ever reads any post on this site that’s more than a few years old, but is that an argument for or against deleting them? (If a tree falls in the woods, etc…) Should I delete but leave a note they were deleted? Should I leave the original posts but append updates citing my current displeasure?
It’s browser updatin’ time! Firefox 65 just dropped. So did Chrome 72. Safari 12.1 is shipping with iOS 12.2.
It’s interesting to compare the release notes for each browser and see the different priorities reflected in them (this is another reason why browser diversity is A Good Thing).
A lot of the Firefox changes are updates to dev tools; they just keep getting better and better. In fact, I’m not sure “dev tools” is the right word for them. With their focus on layout, typography, and accessibility, “design tools” might be a better term.
Oh, and Firefox is shipping support for some CSS properties that really help with print style sheets, so I’m disproportionately pleased about that.
In Safari’s changes, I’m pleased to see that the datalist element is finally getting implemented. I’ve been a fan of that element for many years now. (Am I a dork for having favourite HTML elements? Or am I a dork for even having to ask that question?)
And, of course, it wouldn’t be a Safari release without a new made up meta tag. From the people who brought you such hits as viewport and apple-mobile-web-app-capable, comes …supported-color-schemes (Apple likes to make up meta tags almost as much as Google likes to make up rel values).
There’ll be a whole bunch of improvements in how progressive web apps will behave once they’ve been added to the home screen. We’ll finally get some state persistence if you navigate away from the window!
Updated the behavior of websites saved to the home screen on iOS to pause in the background instead of relaunching each time.
Maximiliano Firtman has a detailed list of the good, the bad, and the “not sure yet if good” for progressive web apps on iOS 12.2 beta. Thomas Steiner has also written up the progress of progressive web apps in iOS 12.2 beta. Both are published on Ev’s blog.
At first glance, the release notes for Chrome 72 are somewhat paltry. The big news doesn’t even seem to be listed there. Maximiliano Firtman again:
Chrome 72 for Android shipped the long-awaited Trusted Web Activity feature, which means we can now distribute PWAs in the Google Play Store!
Very interesting indeed! I’m not sure if I’m ready to face the Kafkaesque process of trying to add something to the Google Play Store just yet, but it’s great to know that I can. Combined with the improvements coming in iOS 12.2, these are exciting times for progressive web apps!
A terrific explanation of the aria-live attribute from Ire. If you’re doing anything with Ajax, this is vital knowledge.
I quite like this date-picking interface. It would be nice if browsers picked it up for input type="date".
A wonderful—and humorous—deep dive into all things time-related.
Building a calendar sucks. Like there’s really cool shit you can do, since every calendar out there today is basically straight outta 2005, but at the end of the day you’re stuck dealing with all of the edge cases that all your dork friends have warned you about since the dawn of time. (Like literally, the dawn of time is a separate edge case you have to account for as well.)
This also contains a well-deserved shout-out to ISO 8601:
ISO 8601 is one of my favorite standards and/or RFC out there. And yes, you should definitely have a favorite.
I do have a favourite RFC—ask me about it sometime over a beer.
This is a good walkthrough of the flow you’d need to implement if you want to notify users of an updated service worker.
Service workers, push notifications, and variable fonts are now shipping in Edge.
Squee! The next time there’s an update for OS X and iOS, Safari will magically have service worker support! Not only that, but Safari on iOS will start using the information in web app manifests for adding to home screen.
That’s an impressive turnaround.
I’m syndicating my notes to micro.blog now.