Questions about After 5/WebSpecs

q.md

Questions

what we are talking about: after 5

The goal of this document is to propose a small set of basic principles for the organisation of the HTML project after 5.0.

Questions asked here will be answered in an article on http://html5doctor.com

question: One of the key points is HTML will be forkable. The forking of specs has caused much consternation in standards orgs. How are the issues related to forking going to be fixed?

How will the editors reconcile the HTML design principles (priority of constituencies, a11y, &c) with those of the Extensible Web Manifesto?

Blue Stratos, or Old Spice?

what's in it for 'Joe developer'?

who can actively participate?

@brucelawson Penhaligon Juniper Sling :)

PS: if you don't have a github account you can jot down your questions on this etherpad

Is the intent to have the spec on GitHub? If so, I wonder if this would reduce the barrier for contribution. I am sure a lot of people would rather deal with GitHub issues than mailing lists

Slightly of topic perhaps but I'd be surprised if any developers really knew what html 5 really was.. is there any high level visual that says? for example are Web components part of it? webgl? pointer events? css grid? etc

The W3C has previously been described as "the organization that has been trying to kill and/or replace html since the day it was founded", and as having "a long history of fucking up HTML by going off into la-la land for a few years while the world evolves without them".

The current HTMLWG had no choice but to (eventually) move on from the former, and has since put all its energies into the latter.

Why should we expect any different this time?

Gists are a poor way to communicate I'd put this stuff in a repo, you never get notified of comments on Gists...

@briandipalma sorry may be unclear, we are just gathering questions to be answered for a future article on http://html5doctor.com

I'd like to see a future version able to handle more common interactions that are currently only achievable using Javascript. Elements like the new input types have already started this process by allowing things like a default date picker for dates.

Possible examples...

1. Simple show/hide/toggle (possibly using an attribute in a tag to trigger an action on another tag with matching ID)
2. Accordions (expand/collapse one element in a series of elements, maybe using attributes and ID's)

The end result would have a few advantages:

• less reliance on Javascript for basic UI functions
• less page weight
• faster development for both web and HTML5 apps

Just a few thoughts!

Why is the future seen as using a modularity model similar to CSS when the entirety of HTML5 will make it to rec before the vast majority of CSS level 3 specs do, despite the fact that CSS level 3 started first?

where do implementers fit in to this?