This sounds a lot like Do Not Track …but looking at the spec, the interesting part is the way that this is designed to work in combination with legal frameworks. That’s smart. I don’t think a purely technical solution is workable (as we saw with Do Not Track).
Tuesday, January 12th, 2021
Wednesday, January 6th, 2021
This is a very thoughtful and measured response to Alex’s post Platform Adjacency Theory.
Unlike Alex, the author doesn’t fire off cheap shots.
Also, I’m really intrigued by the idea of certificate authorities for hardware APIs.
Friday, December 18th, 2020
storage.estimate() in service workers to figure out how much gets pre-cached.
Monday, December 14th, 2020
I really enjoyed this trip down memory lane with Chris:
From the Web’s inception, an ancient to contemporary history of the Web.
Wednesday, December 2nd, 2020
There’s no browser support yet but that doesn’t mean we can’t start adding
prefers-reduced-data to our media queries today. I like the idea of switching between web fonts and system fonts.
Thursday, November 19th, 2020
Standardizing `select` And Beyond: The Past, Present And Future Of Native HTML Form Controls — Smashing Magazine
While a handful of form controls can be easily styled by CSS, like the button element, most form controls fall into a bucket of either requiring hacky CSS or are still unable to be styled at all by CSS.
Despite form controls no longer taking a style or technical dependency on the operating system and using modern rendering technology from the browser, developers are still unable to style some of the most used form control elements such as
select. The root of this problem lies in the way the specification was originally written for form controls back in 1995.
Stephanie goes back in time to tell the history of form controls on the web, and how that history has led to our current frustrations:
The current state of working with controls on the modern web is that countless developer hours are being lost to rewriting controls from scratch, as custom elements due to a lack of flexibility in customizability and extensibility of native form controls. This is a massive gap in the web platform and has been for years. Finally, something is being done about it.
Thursday, November 12th, 2020
Principles behind the design of web APIs:
- Put user needs first (Priority of Constituencies)
- It should be safe to visit a web page
- Trusted user interface should be trustworthy
- Ask users for meaningful consent when appropriate
- Support the full range of devices and platforms (Media Independence)
I should add these to my collection.
Wednesday, November 11th, 2020
This is a very handy table of elements from Steve of where
aria-label can be applied.
Like, for example, not on a
Tuesday, November 10th, 2020
I can see how this would be good to have fixed at the browser level.
Thursday, November 5th, 2020
Wednesday, October 28th, 2020
Portals and giant carousels
I posted something recently that I think might be categorised as a “shitpost”:
Most single page apps are just giant carousels.
Extreme, yes, but perhaps there’s a nugget of truth to it. And it seemed to resonate:
I’ve never actually seen anybody justify SPA transitions with actual business data. They generally don’t seem to increase sales, conversion, or retention.
For some reason, for SPAs, managers are all of a sudden allowed to make purely emotional arguments: “it feels snappier”
If businesses were run rationally, when somebody asks for an order of magnitude increase in project complexity, the onus would be on them to prove that it proportionally improves business results.
But I’ve never actually seen that happen in a software business.
A single page app architecture makes a lot of sense for interaction-heavy sites with lots of state to maintain, like twitter.com. But I’ve seen plenty of sites built as single page apps even though there’s little to no interactivity or state management. For some people, it’s the default way of building anything on the web, even a brochureware site.
It seems like there’s a consensus that single page apps may have long initial loading times, but then they have quick transitions between “pages” …just like a carousel really. But I don’t know if that consensus is based on reality. Whether you’re loading a page of HTML or loading a chunk of JSON, you’re still making a network request that will take time to resolve.
Leaving aside the fact that is literally what the browser cache takes of, I’ve seen some circular reasoning around this:
To be fair, in the past, the experience of going from page to page used to feel a little herky-jerky, even if the response times were quick. You’d get a flash of a white blank page between navigations. But that’s no longer the case. Browsers now perform something called “paint holding” which elimates the herky-jerkiness.
So now if your pages are a reasonable size, there’s no practical difference in user experience between full page refreshes and single page app updates. Navigate around The Session if you want to see paint holding in action. Switching to a single page app architecture wouldn’t improve the user experience one jot.
This is the problem that Jake set out to address in his proposal for navigation transitions a few years back:
Having to reimplement navigation for a simple transition is a bit much, often leading developers to use large frameworks where they could otherwise be avoided. This proposal provides a low-level way to create transitions while maintaining regular browser navigation.
I linked to Jake’s excellent proposal in my shitpost saying:
But then I added—and I almost didn’t—this:
Now you might be asking yourself what Paul said out loud:
Excuse my ignorance but… WTF are portals!?
Portals are a proposal from Google that would help their AMP use case (it would allow a web page to be pre-rendered, kind of like an iframe).
That was based on my reading of the proposal:
…show another page as an inset, and then activate it to perform a seamless transition to a new state, where the formerly-inset page becomes the top-level document.
It sounded like Google’s top stories carousel. And the proposal goes into a lot of detail around managing cross-origin requests. Again, that strikes me as something that would be more useful for a search engine than a single page app.
But Jake was not happy with my description. I didn’t intend to besmirch portals by mentioning Google AMP in the same sentence, but I can see how the transitive property of ickiness would apply. Because Google AMP is a nasty monopolistic project that harms the web and is an embarrassment to many open web advocates within Google, drawing any kind of comparison to AMP is kind of like Godwin’s Law for web stuff. I know that makes it sounds like I’m comparing Google AMP to Hitler, and just to be clear, I’m not (though I have myself been called a fascist by one of the lead engineers on AMP).
Clearly, emotions run high when Google AMP is involved. I regret summoning its demonic presence.
After chatting with Jake some more, I tried to find a better use case to describe portals. Reading the proposal, portals sound a lot like “spicy iframes”. So here’s a different use case that I ran past Jake: say you’re on a website that has an iframe embedded in it—like a YouTube video, for example. With portals, you’d have the ability to transition the iframe to a fully-fledged page smoothly.
But Jake told me that even though the proposal talks a lot about iframes and cross-origin security, portals are conceptually more like using
rel="prerender" …but then having scripting control over how the pre-rendered page becomes the current page.
Put like that, portals sound more like Jake’s original navigation transitions proposal. But I have to say, I never would’ve understood that use case just from reading the portals proposal. I get that the proposal is aimed more at implementators than authors, but in its current form, it doesn’t seem to address the use case of single page apps.
we haven’t seen interest from SPA folks in portals so far.
I’m not surprised! He goes on:
Maybe, they are happy / benefits aren’t clear yet.
From my own reading of the portals proposal, I think the benefits are definitely not clear. It’s almost like the opposite of Jake’s original proposal for navigation transitions. Whereas as that was grounded in user needs and real-world examples, the portals proposal seems to have jumped to the intricacies of implementation without covering the user needs.
I guess the web I want includes giant carousels.
Tuesday, October 20th, 2020
I’ve been like a dog with a bone the way I’ve been pushing for a declarative option for the Web Share API in the shape of
button type=“share”. It’s been an interesting window into the world of web standards.
The story so far…
- I blogged some half-formed thoughts.
- Then I opened an issue on the spec for the Web Share API.
- Meanwhile I wrote a polyfill, releasing the code and a test.
- I responded to pushback I was getting on the issue I filed.
- I also wrote up an explainer document so everything is gathered in one place.
- Finally I started soliciting feedback from people using the Web Share API in order to gather data.
That’s the situation currently. The general consensus seems to be that it’s probably too soon to be talking about implementation at this stage—the Web Share API itself is still pretty new—but gathering data to inform future work is good.
In planning for the next TPAC meeting (the big web standards gathering), Marcos summarised the situation like this:
Not blocking: but a proposal was made by @adactio to come up with a declarative solution, but at least two implementers have said that now is not the appropriate time to add such a thing to the spec (we need more implementation experience + and also to see how devs use the API) - but it would be great to see a proposal incubated at the WICG.
Like I said, I’m not expecting anything to happen anytime soon, but it would be really good to gather as much data as possible around existing usage of the Web Share API. If you’re using it, or you know anyone who’s using it, please, please, please take a moment to provide a quick description. And if you could help spread the word to get that issue in front of as many devs as possible, I’d be very grateful.
(Many thanks to everyone who’s already contributed to that issue—much appreciated!)
Monday, October 19th, 2020
Continuous partial browser support
That’s not what happened though. Developers used vendor-prefixed properties as though they were stable. Tutorials were published that basically said “Go ahead and use these vendor-prefixed properties and ship it!” There were even tools that would add the prefixes for you so you didn’t have to type them out for yourself.
Browsers weren’t completely blameless either. Long after features were standardised, they would only be supported in their prefixed form. Apple was and is the worst for this. To this day, if you want to use the
clip-path property in your CSS, you’ll need to duplicate your declaration with
-webkit-clip-path if you want to support Safari. It’s been like that for seven years and counting.
Like capitalism, vendor prefixes were one of those ideas that sounded great in theory but ended up being unworkable in practice.
Still, developers need some way to get their hands on experiment features. But we don’t want browsers to ship experimental features without some kind of safety mechanism.
- Developers are able to register for an experimental feature to be enabled on their origin for a fixed period of time measured in months. In exchange, they provide us their email address and agree to give feedback once the experiment ends.
- Usage of these experiments is constrained to remain below Chrome’s deprecation threshold (< 0.5% of all Chrome page loads) by a system which automatically disables the experiment on all origins if this threshold is exceeded.
I think it works pretty well. If you’re really interested in kicking the tyres on an experimental feature, you can opt in to the origin trial. But it’s very clear that you wouldn’t want to ship it to production.
You could ship something that’s behind an origin trial, but you’d have to make sure you’re putting safeguards in place. At the very least, you’d need to do feature detection. You certainly couldn’t use an experimental feature for anything mission critical …but you could use it as an enhancement.
And that is a pretty great way to think about all web features, experimental or otherwise. Don’t assume the feature will be supported. Use feature detection (or
@supports in the case of CSS). Try to use the feature as an enhancement rather than a dependency.
If you treat all browser features as though they’re behind an origin trial, then suddenly the landscape of browser support becomes more navigable. Instead of looking at the support table for something on caniuse.com and thinking, “I wish more browsers supported this feature so that I could use it!”, you can instead think “I’m going to use this feature today, but treat it as an experimental feature.”
You can also do it for well-established features like
geolocation. Instead of assuming that browser support is universal, it doesn’t hurt to take a more defensive approach. Assume nothing. Acknowledge and embrace unpredictability.
The debacle with vendor prefixes shows what happens if we treat experimental features as though they’re stable. So let’s flip that around. Let’s treat stable features as though they’re experimental. If you cultivate that mindset, your websites will be more robust and resilient.
Tuesday, October 13th, 2020
The unfair collusion between Google AMP and Google Search might just bite ‘em on the ass.
Thursday, October 8th, 2020
Tess calls for more precise language—like “site” and “origin”—when talking about browsers and resources:
When talking about web features with security or privacy impact, folks often talk about “first parties” and “third parties”. Everyone sort of knows what we mean when we use these terms, but it turns out that we often mean different things, and what we each think these terms mean usually doesn’t map cleanly onto the technical mechanisms browsers actually use to distinguish different actors for security or privacy purposes.
Monday, October 5th, 2020
The reason for a share button type
If you’re at all interested in what I wrote about a declarative Web Share API—and its sequel, a polyfill for button type=”share”—then you might be interested in an explainer document I’ve put together.
It’s a useful exercise for me to enumerate the reasoning for
button type=“share” in one place. If you have any feedback, feel free to fork it or create an issue.
The document is based on my initial blog posts and the discussion that followed in this issue on the repo for the Web Share API. In that thread I got some pushback from Marcos. There are three points he makes. I think that two of them lack merit, but the third one is actually spot on.
Apart from placing a button in the content, I’m not sure what the proposal offers over what (at least one) browser already provides? For instance, Safari UI already provides a share button by default on every page
But that is addressed in the explainer document for the Web Share API itself:
The browser UI may not always be available, e.g., when a web app has been installed as a standalone/fullscreen app.
That’s exactly what I wanted to address. Browser UI is not always available and as progressive web apps become more popular, authors will need to provide a way for users to share the current URL—something that previously was handled by browsers.
That use-case of sharing the current page leads nicely into the second bit of pushback:
The API is specialized… using it to share the same page is kinda pointless.
But again, the explainer document for the Web Share API directly contradicts this:
Sharing the page’s own URL (a very common case)…
Rather than being a difference of opinion, this is something that could be resolved with data. I’d really like to find out how people are currently using the Web Share API. How much of the current usage falls into the category of “share the current page”? I don’t know the best way to gather this data though. If you have any ideas, let me know. I’ve started an issue where you can share how you’re using the Web Share API. Or if you’re not using the Web Share API, but you know someone who is, please let them know.
Okay, so those first two bits of pushback directly contradict what’s in the explainer document for the Web Share API. The third bit of pushback is more philosophical and, I think, more interesting.
The Web Share API explainer document does a good job of explaining why a declarative solution is desirable:
That’s also my justification for having a declarative alternative: it would be easier for more people to use. I said:
At a fundamental level, declarative technologies have a lower barrier to entry than imperative technologies.
That’s demonstrably false and a common misconception: See OWL, XForms, SVG, or any XML+namespace spec. Even HTML is poorly understood, but it just happens to have extremely robust error recovery (giving the illusion of it being easy). However, that’s not a function of it being “declarative”.
He’s absolutely right.
I’ve been using the word “declarative” when I actually meant “robust in handling errors”.
I’ve been using “declarative” as a shorthand for “either HTML or CSS”, but really I should try to be more precise in my language. The word “declarative” covers a wide range of possible languages, and not all of them lower the barrier to entry. A declarative language with a brittle error-handling model is as daunting as an imperative language.
With that in mind,
button type=“share” is worth pursuing. Yes, it’s a declarative option for using the Web Share API, but more important, it’s a robust option for using the Web Share API.
I invite you to read the explainer document for a share button type and I welcome your feedback …especially if you’re currently using the Web Share API!
Thursday, October 1st, 2020
Employing the principle of least power for better digital preservation:
New frameworks and technologies spring up to try and cope with the speed of change. More and more ways to build and release things faster and cheaper becomes the norm. And, the more this happens, the more we deviate from standards: good ol’ HTML and CSS.
Wednesday, September 16th, 2020
A polyfill for button type=”share”
After writing about a declarative Web Share API here yesterday I thought I’d better share the idea (see what I did there?).
I opened an issue on the Github repo for the spec.
The polyfill also demonstrates how feature detection could work. Here’s the code.
This polyfill takes an Inception approach to feature detection. There are three nested levels:
- This browser supports
button type="share". Great! Don’t do anything. Otherwise proceed to level two.
- Use a
mailto:link to prefill an email with the page title as the subject and the URL in the body. Ya basic!
The idea is that, as long as you include the 20 lines of polyfill code, you could start using
button type="share" in your pages today.
I’ve made a test page on Codepen. I’m just using plain text in the button but you could use a nice image or SVG or combination. You can use the Codepen test page to observe two of the three possible behaviours browsers could exhibit:
- A browser supports
button type="share". Currently that’s none because I literally made this shit up yesterday.
- A browser supports neither
The polyfill doesn’t support Internet Explorer 11 or lower because it uses the DOM
closest() method. Feel free to fork and rewrite if you need to support old IE.