I’m the current editor of the Vision for W3C and helped get it across the line this year to reach #w3cAB (W3C Advisory Board @ab@w3c.social) consensus to publish as an official Group Note, the first official Note that the AB (Advisory Board) has ever published.
I’m very proud of this milestone, as I and a few others including many on the AB¹, have been working on it for a few years in various forms, and with the broader W3C Vision TF² (Task Force) for the past year.
W3C also recently announced the Vision for W3C in their news feed:
One of the key goals of this document was to capture the spirit of why we are at #W3C and our shared values & principles we use to guide our work & decisions at W3C.
If you work with any groups at W3C, anything from a Community Group (CG) to a Working Group (WG), I highly recommend you read this document from start to finish.
See what resonates with you, if there is anything that doesn’t sound right to you, or if you see anything missing that you feel exemplifies the best of what W3C is, please file an issue or a suggestion:
Check that list to see if your concerns or suggestions are already captured, and if so, add an upvote or comment accordingly.
Our goal is to eventually publish this document as an official W3C Statement, with the consensus of the entire #w3cAC (W3C Advisory Committee).
One key aspect which the Vision touches on but perhaps too briefly is what I see as the fundamental purpose of why we do the work we do at W3C, which in my opinion is:
To create & facilitate user-first interoperable standards that improve the web for humanity
“Interoperability: We verify the fitness of our specifications through open test suites and actual implementation experience, because we believe the purpose of standards is to enable independent interoperable implementations.”
These are both excellent, and yet, I think we can do better, with adding some sort of explicit statement between those two about that “We will” create & facilitate user-first interoperable standards that improve the web for humanity.
In the coming weeks I’ll be reflecting how we (the VisionTF) can incorporate that sort of imperative “We will” statement about interoperable standards into the Vision for W3C, as well as working with the AB and W3C Team on defining a succinct updated mission & purpose for W3C based on that sort of input and more.
In a related effort, I have also been leading the AB’s “3Is Priority Project³” (Interoperability and the Role of Independent Implementations), which is a pretty big project to define and clarify what each of those three Is mean, with respect to each other and Incubation, which is its own Priority Project⁴.
As part of the 3Is project, the first “I” I’ve been focusing on has unsurprisingly been “Interoperable”. As with other #OpenAB projects, our work on understanding interoperability, its aspects, and defining what do we mean by interoperable is published and iterated on the W3C’s public wiki:
This is still a work in progress, however it’s sufficiently structured to take a look if interoperability is something you care about or have opinions about.
In particular, if you know of definitions of interoperable or interoperability that resonate and make sense to you, or articles or blog posts about interoperability that explore various aspects, I am gathering such references so we can make sure the W3C’s definition of interoperable is both well-stated, and clearly reflects a broader industry understanding of interoperability.
New this week: the #IndieWeb community deployed a major modern update to the design, usability, and cross-device support of the https://indieweb.org/ home page and wiki in general! In brief:
* Updated MediaWiki install, updated themes, better mobile device support * New default theme: Vector (2022), the same as English Wikipedia * Lots of CSS fixes for content, sidebars, etc. * Home page content simplification and more pleasing design update
This was a community effort, with many people pitching in with major & minor contributions, spending weeks, days, hours, or a few minutes here and there helping out. From server work, to PHP coding, to HTML+CSS (re)coding, to testing variants of MediaWiki themes, browsers, and devices.
Huge thanks in particular to @PaulRobertLloyd.com (@paulrobertlloyd@mastodon.social) for both driving this design update (e.g. said project page) and doing the heavy lifting of debugging, patching, and testing the latest MediaWiki Vector theme, documenting before & after screenshots, and @AaronParecki.com (@aaronpk@aaronparecki.com@aaronpk) for all the server-side software updates, PHP/IndieAuth wrangling, and critical devops too.
Go try the new https://indieweb.org/ on any browser, on any device, and share your experience!
Implemented liking/favoriting of #Mastodon posts via Bridgy Fed on my site! (Actually of any post on any site that #BridgyFed can discover an #ActivityPub endpoint to send likes to.)
Tested it by liking @evanp.me (@evan@cosocial.ca@evanpro)’s reply¹ confirming that he received a notification from my prior post². I sent a #Webmention from my like post³ to Bridgy Fed, and it #federated the like to Evan’s server, which subsequently showed up in the "favourites" list of Evan’s post: