Notices by Tantek Çelik (tantek.com@fed.brid.gy)

🎂 Congrats @microformats.org on 20 years! #microformats20

Even after 20 years, people keep discovering new ways of using #microformats:
* @artlung.com: "WML, WAP, & Microformats Demo!" (https://lab.artlung.com/wml/faux)
> Because WML elements may have the class attribute
Originally posted 2025-06-18: https://xoxo.zone/@artlung/114705990062730513

That adds to the list of languages with working microformats examples:
* HTML — modern, unversioned as well as every version since HTML4
* HTML3 — see https://microformats.org/wiki/html3
* SVG — see https://microformats.org/wiki/svg
* XHTML — every version, 1.0, 1.1, 2.0
and now also:
* WML — https://microformats.org/wiki/wml

Literally any HTML-like or XML-like language that has a space-separated class attribute can work with microformats.

In constrast, every alternative to microformats (most now defunct) required adding new attributes, or worse, entirely new elements, which meant revising every language one at a time (or use of fragile XML Namespaces), resulting in supporting only 1-2 languages at most (HTML and XHTML) in practice, and nothing else.

Re-using the "class" attribute based on the existing footpath that web designers made for encoding additional semantics into their HTML, and the similarly extensible "rel" attribute, was one of the best design decisions in any extension format ever.

After 20 years, microformats continue to serve as another example of “loosely joined” approaches being more adaptable, reliable, resilient, and longer lasting than “tightly coupled”.

More microformats 20th anniversary posts from the #indieweb personal sites (via https://stream.indieweb.org/)
* @manton.org: "It’s the 20th anniversary of the launch of microforrmats.org!" (https://www.manton.org/2025/06/20/its-the-th-anniversary-of.html)
* ... hashtag your post #microformats or #microformats20 and #federate (using #Mastodon or any compatible #fediverse server etc.) or webmention this post!

#20thAnniversary #smallPieces #looselyJoined

Previously, previously, previously:
* https://tantek.com/2024/173/t1/years-posse-microformats-beyond
* https://tantek.com/2023/171/t1/anniversaries-microformats-posse
* https://tantek.com/2019/171/t1/happy-14th-microformats-org

I’m happy to announce that something I and others have worked on very hard for the past few years has been published by the W3C Advisory Board (AB) and sent to the W3C Advisory Committee (AC) for a vote to make it official:

Vision for W3C: https://www.w3.org/TR/2025/NOTE-w3c-vision-20250402/

Official announcement: https://www.w3.org/news/2025/proposal-to-endorse-vision-for-w3c-as-a-w3c-statement/

If your company is a W3C Member¹, please ask your Advisory Committee Representative² to vote to support publication of the Vision for W3C as an official W3C Statement:

https://www.w3.org/wbs/33280/Vision2025/ (W3C Member-only link)

Thank you for your support.

#W3CVision #Vision #VisionForW3C #W3C (@w3c@w3c.social) #W3CAB (@ab@w3c.social)

¹ https://www.w3.org/membership/list/
² https://www.w3.org/Member/ACList (W3C Member-only link)

Ten years ago today I coined the shorthand “js;dr” for “JavaScript required; Didn’t Read”

* https://tantek.com/2015/069/t1/js-dr-javascript-required-dead

in reference to (primarily content) pages that were empty (or nearly so) without scripts.

Since then js;dr found its way into a book:

Page 88 of “Inclusive Design Patterns” by @heydonworks.com (@[email protected])


and stickers!



At the time I made the claim that:

“in 10 years nothing you built today that depends on JS for the content will be available, visible, or archived anywhere on the web.”

I’ve seen and documented many such sites, built with a hard dependency on scripting, that end up dead and unarchived. Many of these have been documented on the IndieWeb’s js;dr page:

* https://indieweb.org/js;dr

I have to ask though: does anyone remember building a site 10 years ago (Internet Archive citation) with a Javascript library/framework dependency to display content, that still works today?

E.g. using one of the popular libraries/frameworks used to build such sites back then like AngularJS (discontinued 2022), Backbone.js, Ember.js, or even React which was still quite new at the time.

The one almost exception I found was Facebook, e.g. this Smashing Magazine post on Facebook barely renders some content and all commentary is missing, in the earliest (2019) version saved on the Internet Archive:
* https://web.archive.org/web/20191123225253/https://www.facebook.com/smashmag/posts/10153198367332490

You can extract the direct Facebook link if you want to try viewing it in the present.


Regarding those libraries/frameworks themselves, I wrote:

“All your fancy front-end-JS-required frameworks are dead to history, a mere evolutionary blip in web app development practices. Perhaps they provided interesting ephemeral prototypes, nothing more.”

Of all those listed above, only React has grown since, likely at the expense of the others.

However instead of fewer such libraries and frameworks today, it seems we have many more (though it feels like their average hypespan is getting shorter with each iteration).

Since I wrote “js;dr”, the web has only become more fragile, with ever more dependencies on scripting just to display text content. The irony here is that Javascript, like XML, has draconian parsing rules. One syntax error and the whole script is thrown out.

This means it’s far too easy for any such JS-dependent site to break, in one or more browsers, whenever browsers change, or Javascript changes, or both.

You wouldn’t build a site today (or 20 years ago) that depends on fragile draconian XML parsing, so why build a site that depends on fragile draconian Javascript parsing?


I’ll repeat my claim from ten years ago, slightly amended, and shortened:


In 5 years nothing you (personally, not a publicly traded company) build today that depends on Javascript in the browser to display content will be available, visible, or archived anywhere on the web.


There’s a lot more to unpack about what we’ve collectively lost in the past ten years of fragile scripting-dependent site-deaths, and why web developers are choosing to build more fragile websites than they did 10 or certainly 20 years ago.


For now I’ll leave you with a few positive encouragements:


Practice Progressive Enhancement.

Build first and foremost with forgiving technologies, declarative technologies, and forward and backward compatible coding techniques.

All content should be readable without scripting.

Links, buttons, text fields, and any other interactive HTML elements should all work without scripting.

Scripts are great for providing an enhanced user experience, or additional functionality such as offline support.

Then make sure to test your pages and sites without scripts, to make sure they still work.


If it's worth building on the web, it's worth building it robustly, and building it to last.

20 years and two weeks ago, I came up with undohtml.css and unknowingly invented the mechanism of CSS Resets (AKA reboot or reset style sheets¹) which spawned numerous variants, many still in broad use on the web today.

https://tantek.com/log/2004/09.html#d06t2354

A one sentence problem description, and a short paragraph describing my problem-solving, actions, license, link to less than 300 bytes of code (not counting comments), and a few future thoughts.

The rest of that blog post was about “debug scaffolding”, the part I thought was more interesting at the time.

Eric Meyer (@meyerweb.com @meyerweb@mastodon.social) followed up ~10 days afterwards with his thinking and improvements:
* https://meyerweb.com/eric/thoughts/2004/09/15/emreallyem-undoing-htmlcss/
where he mentioned “resetting” in passing, but not actually calling it a "reset".

~2.5 years later Eric published “Reset Styles” with further reasoning and improvements:
* http://meyerweb.com/eric/thoughts/2007/04/12/reset-styles/
describing them as: “reset” or “baseline” set of styles.

Subsequently he iterated in several more blog posts:
* http://meyerweb.com/eric/thoughts/2007/04/14/reworked-reset/
* http://meyerweb.com/eric/thoughts/2007/04/18/reset-reasoning/ — this is Eric’s first post where he explicitly calls them “reset styles”, which I believe is the origin of the eventual phrase “CSS Reset” and “reset style sheets”
* http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/ (yes a Matrix: Reloaded reference)

~6 months later Eric published his evergreen resource “CSS Tools: Reset CSS”
* https://meyerweb.com/eric/tools/css/reset/
which, as you see within the URL: “css/reset”, is perhaps where the phrase “CSS Reset” comes from, and it’s also the label (link text) he gives that page in his UI about-page² and the first content link in his 404 page³.

My technology invention takeaways from all this:

1. if you find yourself repeatedly solving the same (especially annoying) problem, create a re-usable solution that works for you
2. write up your problem statement / use-case in only one sentence
3. publish your solution (on your personal site⁴), name it something short, with only a short paragraph description, and re-use/remix friendly license (like Creative Commons)

And things not to worry about (that may get in your way to publishing):

1. perfecting or making your solution “big enough” or “the right size”. does it solve your problem? then it’s already the right size.
2. coming up with the perfect name. instead, name it what it does. someone might come up with a better name weeks, months, or years later. let them run with it!
3. waiting to blog multiple things. I could have blogged undohtml.css by itself, probably should have, and instead lumped it into a blog post with another CSS thing I came up with.

Further reading and resources for CSS Resets:

* More history: https://css-tricks.com/reboot-resets-reasoning/
* Large collection: https://perishablepress.com/a-killer-collection-of-global-css-reset-styles/

References:

¹ https://en.wikipedia.org/wiki/Reset_style_sheet
² https://meyerweb.com/ui/about.html
³ https://meyerweb.com/404
⁴ https://indieweb.org/

#undoHTML #undoHTMLCSS #reset #CSSreset #resetstyles #webdesign #technology #invention #indieweb

✏️ I want the Read Write Suggest-Edit Accept-Edit Update Web.

The consumer Infinite Scroll Web leaves us feeling empty.

Too few of us participate in the Read Write Web, whether with personal sites or Wikipedia.

A week ago when we wrapped up #IndieWebCamp Portland and I was reading Kevin Marks (@kevinmarks@indieweb.social) live-tooting of the demos¹, I noticed a few errors, typos or miscaptures, and pointed them out in-person.

Kevin was able to quickly edit his toots and update them for anyone reading, thanks to #Mastodon’s post editing feature and its support of #ActivityPub Updates. But this shouldn’t require being in the same room, whether IRL or chat.

We should be able to suggest edits to each other’s posts, as easily as we can reply and add a comment.

13 years ago I wrote²:

 “The Read Write Web is no longer sufficient. I want the Read Fork Write Merge Web.”

Now I want the Read Write Suggest-Edit Accept-Edit Update Web.

The ↪ Reply button is fairly ubiquitous in modern post user interfaces (UIs).

Why not also a ✏️ Suggest Edit button, to craft a fix for a typo, grammar, or other minor error, and send the author for their review, and acceptance or rejection? Perhaps viewable only by the suggester and the author, to avoid "performative" suggested edits.

If the author’s posts provide revision histories, when a suggested edit is accepted, a post’s history could show the contributor of the edit.

Instead of asking Kevin in-person, what if I could have posted special "Suggested Edit" responses in reply to his toots, for which he would receive special notifications, and could choose to one-click accept and update (or further edit) his toots?

To enable such UIs and interactions across servers and implementations, we may need a new type of response³, perhaps with a special property (or more) to convey the edits being suggested.

There is documentation of this and similar use-cases, prior art / UIs, as well as some brainstorming on the #IndieWeb wiki:
* https://indieweb.org/edit

Our interaction after IndieWebCamp has inspired me to take another look at how can we design and prototype solutions to this problem.

For now, if you host your blog and posts as static files on GitHub (or equivalent), you could add a button like this to your posts alongside Like, Reply, Repost buttons:

✏️ Suggest Edit

and link it to an edit URL for the static file for the post.

I don’t use GitHub static files myself for posts, but here’s an example of such an edit link for one of my projects:

https://tantek.com/github/cassis/edit/main/README.md

This will start the process of creating a “pull request”, GitHub’s jargon⁴ for a “suggested edit”.

After completing GitHub’s ceremony of entering multiple text fields (summary & description), and multiple clicks to create said “pull request”, it’ll be sent to the author to review. Presuming the author likes the suggested edit, they can perform the other half of GitHub’s jargon-filled ceremonies to “Merge” or “Squash & Merge”, “Delete fork”, etc. to accept the edit.

It’s an awkward interaction⁵, however useful for at least prototyping a ✏️ Suggest Edit button on sites that store their posts as files in GitHub. Certainly worthy of experimenting with and gathering experience to design and build even better interactions.

We can start with the shortest path to getting something working, then learn, iterate, improve, repeat.

#readWriteWeb #editableWeb #suggestEdit #acceptEdit

References:

¹ https://indieweb.social/@kevinmarks/113025295600067213
² https://tantek.com/2011/174/t1/read-fork-write-merge-web-osb11
³ https://indieweb.org/responses
⁴ The phrase “pull request” was derived from the git command: “git request-pull” according to https://www.reddit.com/r/git/comments/nvahcp/comment/h12hzj7/
⁵ “edits” in GitHub require taking far more steps, and navigating far more jargon, then say, Wikipedia pages, which come down to “Edit” and “Save”. We should aspire to Wikipedia’s simplicity, not GitHub’s ceremonies.

This is post 20 of #100PostsOfIndieWeb. #100Posts

← https://tantek.com/2024/242/t1/indiewebcamp-portland
→ https://tantek.com/2024/246/t1/adventures-indieweb-activitypub-bridgy-fed

People over protocols over platforms.


inspired by today’s #indieweb #fediverse #ActivityPub #decentralized #socialMedia lunch meetup at #XOXO #XOXOConf (@xoxo@xoxo.zone)

This is post 16 of #100PostsOfIndieWeb. #100Posts

← https://tantek.com/2024/173/t1/years-posse-microformats-adoption
→ https://tantek.com/2024/238/t1/indiewebcamp-portland

All setup here at IndieWebCamp Portland!

https://events.indieweb.org/2024/08/indiewebcamp-portland-2024-8bucXDlLqR0k

Good crowd of participants from #XOXO #XOXOConf (@xoxofest.com @xoxo@xoxo.zone @xoxo) here to work on their personal website(s), domains, or other independent social media setups!

As encouraged by Andy Baio (@waxy.org @andybaio@xoxo.zone @waxpancake)

“Every one of you should have a home on the web not controlled by a billionaire.”

If you’re in #Portland and want help, encouragement, or camaraderie in getting setup or doing more with your personal site, come on by! We’ll be having a mix of discussion sessions and create/hack sessions.

Personal site and hack demos at 16:00 PDT!

#indieweb #fediverse #ActivityPub #decentralized #socialMedia

This is post 17 of #100PostsOfIndieWeb. #100Posts

← https://tantek.com/2024/237/t1/people-over-protocols-platforms
→ 🔮

Good W3C SocialCG telcon yesterday morning.

Minutes: https://www.w3.org/wiki/SocialCG/2024-08-02

Appreciate working with @evan@cosocial.ca @dmitriz@mastodon.mit.edu @TallTed@mastodon.social @snarfed.org Lisa a @AaronNGray@fosstodon.org @bobwyman@mastodon.social @by_caballero@mastodon.social @j12t@j12t.social @steve@social.technoetic.com @thisismissem@hachyderm.io

#W3C #SocialCG #20240802 #2024_215 #ActivityPub #ActivityStreams #relAuthor