Replying to a tweet from @briankardell
The spec is literally the reason why microformats2 didn’t end up using data-*
attributes. It isn’t “advice” in the spec; it is the spec. It specifies how data-*
attributes should and shouldn’t be used.
The spec is literally the reason why microformats2 didn’t end up using data-*
attributes. It isn’t “advice” in the spec; it is the spec. It specifies how data-*
attributes should and shouldn’t be used.
Or in the case of Facebook legitimising Breitbart…
Persuade your team to put commitment above alignment and trust it’ll end up being the alt-right decision.
Ba-doom tish!
What thread?
Yesterday I wrote about how much I’d like to see silent push for the web:
I’d really like silent push for the web—the ability to update a cache with fresh content as soon as it’s published; that would be nifty! At the same time, I understand the concerns. It feels more powerful than other permission-based APIs like notifications.
Today, John Holt Ripley responded on Twitter:
hi there, just read your blog post about Silent Push for acthe web, and wondering if Periodic Background Sync would cover a few of those use cases?
Periodic background sync looks very interesting indeed!
It’s not the same as silent push. As the name suggests, this is about your service worker waking up periodically and potentially fetching (and caching) fresh content from the network. So the service worker is polling rather than receiving a push. But I’ll take it! It’s definitely close enough for the kind of use-cases I’ve been thinking about.
Interestingly, periodic background sync also ties into the other part of what I was writing about: permissions. I mentioned that adding a site the home screen could be interpreted as a signal to potentially allow more permissions (or at least allow prompts for more permissions).
Well, Chromium has a document outlining metrics for attempting to gauge site engagement. There’s some good thinking in there.
If we want design to communicate, we need to communicate in the design process.
I might get that framed.
Tim ponders the hard work that goes into adding standards to browsers, giving us a system with remarkable longevity.
So much care and planning has gone into creating the web platform, to ensure that even as new features are added, they’re added in a way that doesn’t break the web for anyone using an older device or browser. Can you say the same for any framework out there?
His parting advice is perfect:
Use the platform until you can’t, then augment what’s missing. And when you augment, do so with care because the responsibility of ensuring the security, accessibility, and performance that the platform tries to give you by default now falls entirely on you.
It looks like modules could be a great way to serve modern JavaScript to modern browsers, and serve polyfills or older code to older browsers.
I would like to see it done without data-*
attributes.
(But this isn’t about what I would like—it’s about implementing standards correctly.)
HTML isn’t short of existing extension mechanisms: microdata, class
, etc.
…these attributes are not a generic extension mechanism for publicly-usable metadata.
Wondering if I know anyone on the Google search team I can chat to about this abuse of data-*
attributes:
https://developers.google.com/search/reference/robotsmetatag#data-nosnippet-attr
(this usage is explicitly forbidden in HTML).
Google’s pissing over HTML again, but for once, it’s not by making up rel
values:
A new way to help limit which part of a page is eligible to be shown as a snippet is the “
data-nosnippet
” HTML attribute onspan
,div
, andsection
elements.
This is a direct contradiction of how data-*
attributes are intended to be used:
…these attributes are intended for use by the site’s own scripts, and are not a generic extension mechanism for publicly-usable metadata.
Indeed it would! Thanks for that!
Happy 50th birthday, internet née ARPANET!
LO
“Talked to SRI Host to Host”
— IMP log, 1969-10-29 22:30, Charles S. Kline, Boelter Hall, UCLA