Journal tags: date

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.

This is a little follow-up to my post about web components for date inputs.

If you try the demo on iOS it doesn’t work. There’s nothing stopping you selecting any date.

That’s nothing to do with the web components. It turns out that Safari on iOS doesn’t support min and max on date inputs. This is also true of any other browser on iOS because they’re all just Safari in a trenchcoat …for now.

I was surprised — input type="date" has been around for a long time now. I mean, it’s not the end of the world. You’d have to do validation on inputted dates on the server anyway, but it sure would be nice for the user experience of filling in forms.

Alas, it doesn’t look like this is something on the interop radar.

What really surprised me was looking at Can I Use. That shows Safari on iOS as fully supporting date inputs.

Maybe it’s just semantic nitpickery on my part but I would consider that the lack of support for the min and max attributes means that date inputs are partially supported.

Can I Use gets its data from here. I guess I need to study the governance rules and try to figure out how to submit a pull request to update the currently incorrect information.

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.

See the Pen Date input HTML web components by Jeremy Keith (@adactio) on CodePen.

In two of my recent talks—In And Out Of Style and Design Principles For The Web—I finish by looking at three different components:

1. a button,
2. a dropdown, and
3. a datepicker.

In each case you could use native HTML elements:

1. button,
2. select, and
3. input type="date".

Or you could use divs with a whole bunch of JavaScript and ARIA.

In the case of a datepicker, I totally understand why you’d go for writing your own JavaScript and ARIA. The native HTML element is quite restricted, especially when it comes to styling.

In the case of a dropdown, it’s less clear-cut. Personally, I’d use a select element. While it’s currently impossible to style the open state of a select element, you can style the closed state with relative ease. That’s good enough for me.

Still, I can understand why that wouldn’t be good enough for some cases. If pixel-perfect consistency across platforms is a priority, then you’re going to have to break out the JavaScript and ARIA.

Personally, I think chasing pixel-perfect consistency across platforms isn’t even desirable, but I get it. I too would like to have more control over styling select elements. That’s one of the reasons why the work being done by the Open UI group is so important.

But there’s one more component: a button.

Again, you could use the native button element, or you could use a div or a span and add your own JavaScript and ARIA.

Now, in this case, I must admit that I just don’t get it. Why wouldn’t you just use the native button element? It has no styling issues and the browser gives you all the interactivity and accessibility out of the box.

I’ve been trying to understand the mindset of a developer who wouldn’t use a native button element. The easy answer would be that they’re just bad people, and dismiss them. But that would probably be lazy and inaccurate. Nobody sets out to make a website with poor performance or poor accessibility. And yet, by choosing not to use the native HTML element, that’s what’s likely to happen.

I think I might have finally figured out what might be going on in the mind of such a developer. I think the issue is one of control.

When I hear that there’s a native HTML element—like button or select—that comes with built-in behaviours around interaction and accessibility, I think “Great! That’s less work for me. I can just let the browser deal with it.” In other words, I relinquish control to the browser (though not entirely—I still want the styling to be under my control as much as possible).

But I now understand that someone else might hear that there’s a native HTML element—like button or select—that comes with built-in behaviours around interaction and accessibility, and think “Uh-oh! What if there unexpected side-effects of these built-in behaviours that might bite me on the ass?” In other words, they don’t trust the browsers enough to relinquish control.

I get it. I don’t agree. But I get it.

If your background is in computer science, then the ability to precisely predict how a programme will behave is a virtue. Any potential side-effects that aren’t within your control are undesirable. The only way to ensure that an interface will behave exactly as you want is to write it entirely from scratch, even if that means using more JavaScript and ARIA than is necessary.

But I don’t think it’s a great mindset for the web. The web is filled with uncertainties—browsers, devices, networks. You can’t possibly account for all of the possible variations. On the web, you have to relinquish some control.

Still, I’m glad that I now have a bit more insight into why someone would choose to attempt to retain control by using div, JavaScript and ARIA. It’s not what I would do, but I think I understand the motivation a bit better now.

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.

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!

Aral recently released the videos from last September’s Update conference. You can watch the video of my talk if you like or, if video isn’t your bag, I’ve published a transcription of the talk.

It’s called One Web, Many Devices and I’m pretty happy with how it turned out. It’s a short talk—just under 17 minutes—but I think I made my point well, without any um-ing and ah-ing. At the time I described the talk like this:

I went in to the lion’s den to encourage the assembled creative minds to forego the walled garden of Apple’s app store in favour of the open web.

It certainly got people talking. Addy Osmani wrote an op-ed piece in .net magazine after seeing the talk.

The somewhat contentious talk was followed by an even more contentious panel, which Amber described as Jeremy Keith vs. Everyone Else. The video of that panel has been published too. My favourite bit is around the five-minute mark where I nailed my colours to the mast.

Me: I’m not going to create something specifically for Windows Phone 7. I’m not going to create a specific Windows Phone 7 app. I’m not going to create a specific iPhone app or a specific Android app because I have as much interest in doing that as I do in creating a CD-ROM or a Laserdisc…

Aral: I don’t think that’s a valid analogy.

Me: Give it time.

But I am creating stuff that can be accessed on all those devices because an iPhone and Windows Phone 7 and Android—they all come with web browsers.

I was of course taking a deliberately extreme stance and, as I said at the time, the truthful answer to most of the questions raised during the panel discussion is “it depends” …but that would’ve made for a very dull panel.

Unfortunately the audio of the talks and panels from Update hasn’t been published—just videos. I’ve managed to extract an mp3 file of my talk which involved going to some dodgy warez sitez.

I wish conference organisers would export the audio of any talks that they’re publishing as video. Creating the sound file at that point is a simple one-click step. But once the videos are up online—be it on YouTube or Vimeo—it’s a lot, lot harder to get just the audio.

Not everyone wants to watch video. In fact, I bet there are plenty of people who listen to conference talks by opening the video in a separate tab so they can listen to it while they do something else. That’s one of the advantages of publishing conference audio: it allows people to catch up on talks without having to devote all their senses. I’ve written about this before:

Not that I have anything against the moving image; it’s just that television, film and video demand more from your senses. Lend me your ears! and your eyes. With your ears and eyes engaged, it’s pretty hard to do much else. So the default position for enjoying television is sitting down.

A purely audio channel demands only aural attention. That means that radio—and be extension, podcasts—can be enjoyed at the same time as other actions; walking around, working out at the gym. Perhaps it’s this symbiotic, rather than parasitic, arrangement that I find engaging.

When I was chatting with Jesse from SFF Audio he told me how he often puts video podcasts (vodcasts?) on to his iPod/iPhone but then listens to them with the device in his pocket. That’s quite a waste of bandwidth but if no separate audio is made available, the would-be listener is left with no choice.

So conference organisers: please, please take a second or two to export an audio file if you’re publishing a video. Thanks.

The Brighton Digital Festival kicked off with a one-two punch of geek conferences: dConstruct and Update.

Update was a labour of love from Aral who worked hard to put together an eclectic, slick event. It was mostly aimed at iOS developers but there was a lot of other stuff in there too, including a range of musical performances. Some speakers, like Matt Gemmell and Sarah, talked specifically about iOS design and development while others, like Cennydd, spoke of broader issues.

In my opinion the most important talk of the day was delivered by Anna who laid bare the state of Britain’s education system—and by extension, Britain’s future. She relentlessly hammered home her points, leaving me feeling shocked and angered at the paedophobic culture of our schools. But there was also hope: as long as there are young people of Anna’s calibre, the network—as wielded by digital natives—will interpret technological clampdowns as damage and route around them (see also Ben Hammersley’s amazing speech to the IACC).

I also spoke at Update. I went in to the lion’s den to encourage the assembled creative minds to forego the walled garden of Apple’s app store in favour of the open web. The prelude to delivering the talk was somewhat nerve-wracking…

The night before the conference, Aral arranged a lavish banquet at the Royal Pavilion. It was amazing. I’m ashamed to say that after a decade of living in Brighton it was my first time inside the building. But I wasn’t able to relax fully, knowing that I had this 18 minute potentially contentious talk to deliver the next morning.

When I got home, I decided I should do a run-through. I always feel like an idiot if I practice a talk by speaking to the wall but in this case I wanted to make sure that I crammed in all the points I wanted to make. I started up Keynote, opened my mouth and …bleaurgh! That’s a pretty good approximation of how legible I sounded. I realised that, although I knew in my mind what I wanted to say, when it came time to say it out loud, I just couldn’t articulate it. I tried for about an hour, with little success. I began to panic, envisioning my appearance at Update consisting of me repeating “Um, know what I mean? Right?”

The day of the event arrived. I was the second speaker. Aral introduced me. I walked on stage and opened my mouth…

And I didn’t screw it up. I made my case without any uhm-ing and ah-ing. I actually had a lot of fun.

I thoroughly enjoyed addressing a roomful of Mac-heads by quoting Steve Jobs. “You don’t need permission to be awesome” he once said. That’s true on the web, not so much on the app store.

Naturally, there were some people who took umbrage with the message I was sending. The most common rebuttal was that I was being unrealistic, not considering the constraints of day-to-day work and budgets. To them, I would quote Steve Jobs once more:

Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes. The ones who see things differently. They’re not fond of rules. And they have no respect for the status quo.

In fact I finished up my talk with a slide of one of the Think Different posters; the one with John Lennon. I ended with a quote from Working Class Hero that I thought was a fitting summation of my feelings when I see talented creative people pouring their energy into unlinkable walled gardens:

You think you’re so clever and classless and free but you’re still fucking peasants as far as I can see.

(had I been writing my talk on an iOS device, I would no doubt have finished by saying “you’re still ducking peasants as far as I can see”.)

My talk was soon followed by a panel discussion about iOS vs. Android vs. Windows Phone 7 vs. the web vs. whatever else people are currently throwing their time and energy into. In fairly short order it turned into me vs. everyone else.

Now here’s the thing when it comes to any discussion about mobile or the web or anything else of any complexity: an honest discussion would result in every single question being answered with “it depends”. A more entertaining discussion, on the other hand, would consist of deliberately polarised opinions. We went for the more entertaining discussion.

The truth is that the whole “web vs. native” thing doesn’t interest me that much. I’m as interested in native iOS development as I am in native Windows development or native CD-ROM development. On a timescale measured in years, they are all fleeting, transient things. The web abides.

Get me going on universally-accessible websites vs. websites optimised for a single device or browser …then I will genuinely have extremely strong opinions that I will defend to the death.

Still, the debate at Update was good fun. The whole event was good fun. Nice work, Aral.

Update on Update: Amber Weinberg has written an overview of the day and my talk prompted Addy Osmani to write an op-ed in .net magazine.

I’m living inside Keynote these days. I’ve got a string of speaking engagements coming up and I’m freaking out about all of them.

The big one is the full-day dConstruct workshop I’ll be leading called Responsive Enhancement. I’ve been working on it solidly for the last month and I hope that it’s all going to come together this week. I’m quite excited about it. If anything, my concern is that there won’t be enough time in one day to cover all the things I want to geek about.

Lest you think that is a blatant plug to entice you to book a place on the workshop, that ship has sailed, my friend: the workshop sold out a while back. But you can still book a place on Scott’s jQuery Mobile workshop or Josh’s Mobile Design workshop. And remember, a workshop ticket gets you complementary access to the dConstruct conference (which sold out in a day).

Maker Faire Brighton will take place the day after dConstruct but I’ll probably be too busy making frantic last-minute preparations for Aral’s Update conference at the Brighton Dome two days later. I’ve been invited to deliver an 18 minute rant and permission has been granted for me to be as controversial as I wish. I’ll try not to disappoint. Tickets are still available if you want a piece of the action.

Later that week I’ll be up in London for the Adobe Expressive Web Tour. In this case, I haven’t explicitly asked permission to rant but I’m going to do so anyway. Hey, if you’re going to ask me to give a talk called “The State of the Web” in the same month that you dump Adobe Muse on the world, you’ve gotta expect some flak, right?

Then I’ll be flying out to Nashville for the Breaking Development conference which kicks off on September 12th. I’m feeling distinctly outclassed by the ludicrously smart line-up of talent that will be presenting there. And I’m supposed to open the show! gulp

Given that the title of my talk is There Is No Mobile Web, it may sound like I am once again courting controversy, but actually, I consider that to be a fairly uncontroversial viewpoint.

Much as I’m looking forward to the time in Tennessee, it’s a shame that I’ll have to duck out of town in the middle of the Brighton Digital Festival. I’ll miss out on BarCamp Brighton and Flash On The Beach.

Fortunately I will still be in town for Brainy Hacks on September 6th. It looks like Clare is putting together a great event: an evening of brainstorming design solutions for a non-profit:

Calling all creatives, strategists and planners - we need you to donate your brain to charity. We have a great brief from a not-for-profit organisation and you have two hours to solve it competing in teams of up to five to have your idea judged the best by our mega judges.

But if the time is going to pass pleasantly—with some food and drink to stir the creative juices—then a sponsor needs to step up and claim the glory. If you know of an appropriate organisation, get in touch with Clare.

Now, if you’ll excuse me, I need to get back to frantically putting slides together while I swirl deeper and deeper down into a pit of inadequacy-fuelled pseudocompetence.