I can now have
adactio.comon speed dial for search — a valid use case indeed.
😊
Funnily enough, I tend to use tags more often than my own site search. I type adactio.com/tags/… followed by whatever I think past me would’ve used. So my browser’s address bar is kind of a sitesearch interface already.
I’ve already add the search element to thesession.org, but while browser support is still rolling out, I’m being extra verbose:
<search role="search">
...
</search>Brought to you by the department of redunancy department.
I’ll remove the ARIA role once browsers are all on board. As Scott says:
Please be aware that this element landing in the HTML spec today does not mean it is available in browsers today. Issues have been filed to implement the search element in the major browsers, including the necessary accessibility mappings. Keep this in mind before you get all super excited and willy nilly add this new element to your pages.
How browser fingerprinting works and what you can do about it (if you use Firefox).
Check out the demo that Rich has put together to go with Amelia’s proposed syntax.
So much ink spilled supposedly explaining what “the web platform” is …when the truth is you can just swap in the “the web” every time that phrase is used here or anywhere else.
Anyway, the gist of this piece is: the web is good, actually.
Hear, hear!
If you have even a passing knowledge of CSS, I encourage you to experiment with its possibilities.
All twelve are out, and all twelve are excellent deep dives into exciting web technologies landing in browsers now.
But you can’t have a web app without a web-app-compatible browser, and you can’t get a web-app-compatible browser in Apple’s App Store. The only browsers permitted in the App Store are those based on WebKit, the browser engine behind Safari. This means that every browser on iOS, from Firefox to Edge to Chrome, is just a reskinned version of Safari.
Frameworks come and go. They are transient. Web standards, on the other hand, are the reason the Web is good now and it will become even better in the future.
Reminder:
emandremwork with the user’s font size;pxcompletely overrides it.
Here’s a remarkably in-depth timeline of the web’s finest programming language, from before it existed to today’s thriving ecosystem. And the timeline is repsonsive too—lovely!
A good ol’ rant by Vasilis on our design tools for the web.
I think this might be the most excited I’ve been in quite some time about an update to browser support, which probably says a lot about my priorities:
Support for the
avoidvalue of the CSS fragmentation propertiesbreak-before,break-after, andbreak-insidewhen printing.
Finally!
I’ve smelt the same change in the wind that Chris describes here—there’s finally a reckoning happening in the world of JavaScript frameworks and single page apps.
Stuart writes up the process up making a mobile game as a web app—not a native app. The Wordle effect reverberates.
It’s a web app. Works for everyone. And I thought it would be useful to explain why it is, why I think that’s the way to do things, and some of the interesting parts of building an app for everyone to play which is delivered over the web rather than via app stores and downloads.
This is an archive of the very earliest Web browsers — the true pioneers, the Old Gods, the Ancients:
WorldWideWeb, LineMode, Viola, Erwise, Midas, TkWWW, Samba, Lynx, w3, FineWWW
A terrific tour of just some of the fantastic ways you can use :has() in CSS.
The section on using it with sibling selectors blew my mind:
How often have you wanted to adjust the margins on a headline based on the element following it? Now it’s easy. This code allows us to select any h2 with a p immediately after it.
h2:has(+ p) { margin-bottom: 0; }Amazing.
Adrian brings an excellent historical perspective to the horrifying behaviour of Facebook’s in-app browsers:
Somewhere along the way, despite a reasonably strong anti-framing culture, framing moved from being a huge no-no to a huge shrug. In a web context, it’s maligned; in a native app context, it’s totally ignored.
Yup, frames are back—but this time they’re in native apps—with all their shocking security implications:
The more I think about it, the more I cannot believe webviews with unfettered JavaScript access to third-party websites ever became a legitimate, accepted technology. It’s bad for users, and it’s bad for websites.
By the way, this also explains that when you try browsing the web in an actual web browser on your mobile device, every second website shoves a banner in your face saying “download our app.” Browsers offer users some protection. In-app webviews offer users nothing but exploitation.
I really, really enjoyed this deep dive into practical HTML semantics. Sit back and enjoy!