So many folks spend time on their CSS and their UX/UI but still come up with URLs that are at best, comically long, and at worst, user hostile.
Domains registered with punycode names (and then given TLS certificates) are worryingly indistinguishable from their ASCII counterparts.
Can you spot the difference between the URLs https://adactio.com and https://аdаctіо.com?
The largest complaint by far is that the URLs for AMP links differ from the canonical URLs for the same content, making sharing difficult. The current URLs are a mess.
This is something that the Google gang are aware of, and they say they’re working on a fix. But this post points out some other misgivings with AMP, like its governance policy:
This keeps the AMP HTML specification squarely in the hands of Google, who will be able to take it in any direction that they see fit without input from the community at large. This guise of openness is perhaps even worse than the Apple News Format, which at the very least does not pretend to be an open standard.
A really clear introduction to the pieces of a URL by Vera, who is setting out on her career as a front-end developer.
Some more food for thought, following on from Shaun’s post about HTML as the foundation of web development:
Jonathan takes a look at the physical web. Like me, he’s excited by the possibilities. Although he says:
Sadly, my mind quickly devolved into the annoyance of numerous notifications, like popup windows and other distracting adverts, vying for my attention.
This is a common worry with the physical web, but it’s unfounded. All a beacon does is broadcast a URL. You have to actively look for the URLs being broadcast—they can’t send notifications.
It all just feels like QR codes. They’ll be all over the place and most of them won’t be very useful.
I understand this concern, but whereas QR codes are completely opaque to humans, at least URLs can—and should—be human-readable …so, unlike QR codes, a URL can give you some idea of what awaits.
Another dive into the archives of the www-talk mailing list. This time there are some gems about the origins of the
input element, triggered by the old
From the ARPANET to the internet, this is a great history of the Domain Name System:
Root DNS servers operate in safes, inside locked cages. A clock sits on the safe to ensure the camera feed hasn’t been looped. Particularly given how slow DNSSEC implementation has been, an attack on one of those servers could allow an attacker to redirect all of the Internet traffic for a portion of Internet users. This, of course, makes for the most fantastic heist movie to have never been made.
Issue 596729 - chromium - Do not show the app banner unless the Manifest has a display set to standalone or fullscreen - Monorail
I am shocked and disgusted by this arbitrary decision by the Chrome team. If your Progressive Web App doesn’t set its manifest to obscure its URL, you get punished by missing out on the add to home screen prompt.
I’ve been poking around at Google’s information on “instant apps” since they announced it at Google I/O. My initial impressions mirror Peter’s.
Either they allow access to more device APIs (which could be a massive security hole) or else they’re more or less websites.
Ah, how I wish that this were published at a long-lived URL:
The one part of the web that I believe is truly genius, and that keeps standing the test of time, is the URI. The Web gave us a way to point to anything, forever. Everything else about the web has changed and grown to encyclopedic lengths, but URIs have been killing it for decades.
And yet the numbers show we’re hell-bent on screwing all that up with link-shorteners, moving URIs without redirection, and so forth. As always happens in technology we’ve taken a simple idea and found expedient ways to add fragility and complexity to it.
Making web apps? Care about SEO? Here’s Google’s advice:
Use feature detection & progressive enhancement techniques to make your content available to all users.
How the Web Works: A Primer for Newcomers to Web Development (or anyone, really) by Preethi Kasireddy
This is a great reminder of the fundamental nuts’n’bolts of the internet and the World Wide Web: clients, servers, URLs, DNS, HTTP, TCP/IP, packet switching, and all the other building blocks we sometimes take for granted.
This is part one of a four-part series:
- A Primer for Newcomers to Web Development (or anyone, really)
- Client-Server Model & the Structure of a Web Application
- HTTP & REST
- Stay tuned…
I really like Alex’s framing of best-of-breed progressively enhanced websites as “progressive apps” (although Bruce has some other ideas about the naming).
It’s a shame that the add-to-homescreen part isn’t standardised yet though.
This is a really good point from Tim Berners-Lee: there’s no good reason why switching to TLS should require a change of URLs from http:// to https://