[whatwg] A New Way Forward for HTML5
msporny at digitalbazaar.com
Thu Jul 23 21:46:54 PDT 2009
Tab Atkins Jr. wrote:
> A few comments as I see them (these all happen to be disagreements,
> but that's because it's easiest to get up the urge to write about
> things that I disagree with):
If all that is written about is what you disagree with, what you support
and agree with will never be known. :)
> "Problem: Disregarding Input from the Accessibility Community"
> ARIA is *going* to be in HTML5. Ian has made this clear. He's just
> waiting for them to resolve some unanswered Last Call comments so the
> spec can proceed to the next stability level. How can this possibly
> be construed as ignoring them?
See John Foliot's comment further down this thread. He expresses the
frustration with WHAT WG (from the Accessibility community's viewpoint)
better than I ever could.
I do not mean to present the problem as one-sided or easily summarized
-- just highlighting that what is being asserted in WHAT WG is not how
those outside of WHAT WG see the situation. I've outlined what I think
could be done to resolve the issue.
If there is no issue and we implement what I've outlined, then the
Accessibility community and I have wasted our time. If there is an
issue, the actions that I've outlined resolve that issue, then we've
> "Problem: Partial Distributed Extensibility"
> We had partial distributed extensibility. We called it "The Browser
Look at the title - "Problem: Partial Distributed Extensibility" -- I'm
not advocating partial distributed extensibility.
> For a mass-consumption medium like html, we need a centralized
> authority *so changes take time before they spread*. It produces a
> barrier to entry that weeds out all but the most desired additions to
> the language.
It also slows the rate of innovation and needlessly restricts the
language - but hey, we're both talking in broad generalizations, so this
method of argumentation isn't really going to get us anywhere. :)
> If they become relatively established despite the
> language not allowing them, that's the best argument possible for
> allowing them in the next version.
It's also sends the message that people should break the standard if
they really want a new feature. Again - broad generalizations leading to
Did you read this? It was linked to in the set of proposals I wrote:
It discusses the separation of concepts between language extensibility
(which isn't always desirable), and data extensibility (which is very
> "Problem: Specification Ambiguity"
> Dropping an email to the list is *not* a difficult thing. It's
It is incredibly intimidating for those that have never done it before.
Even more intimidating is getting a response from somebody you think is
smarter than you are listing all of the reasons you are wrong.
Writing a comment on a blog or web page is far less intimidating - we
should make it as easy as possible for people to give feedback. This is
currently not the case.
> And with a halfway decent modern mail client those "600 to
> 1,200 very technical e-mails a month" drop to a relatively small
> number of grouped conversations that can be tracked or ignored at
I think you mis-judge how scary receiving 600-1,200 emails from a single
mailing list is for most regular web developers and designers (read:
people who don't live and breathe this stuff, like we do).
> That being said, inline spec comments sound interesting. Can you
> expand on this?
Sure... all of the details aren't worked out yet, but the goal is to
make submitting feedback on the specification as easy as submitting a
comment on a YouTube video. Hopefully, we'll have better luck with the
quality of the comments, instead of "OMG! I love <marquee>!!1!".
How does this sound?
* We might want to have a message when somebody views the spec
(hover-right?) that says that they can leave a comment by right-clicking
on a section of the document and requesting a change.
* The HTML5 spec would contain the SCM revision number/hash in the
document somewhere. The change box would find the closest id="#whatever"
and note the revision and id as a unique identifier. The person would
fill the bug/request information out and click Ok.
* The request would be stored to a public database, perhaps with
different methods of notifications when issues come in. If it is
somewhat successful, we might want to tie it into a more permanent bug
We could use the same system to help people submit examples of how each
element could/should be used (like the PHP UserNotes):
> Are these meant to be private and only shown to Ian?
They should be public so that everyone can see the feedback, and perhaps
respond to it.
> Shown to everything who views the spec (optionally, of course)?
That could certainly be a feature that is supported in the future.
> Sent to the mailing list?
We might want to batch reports, or send one e-mail per instance. This is
where having a distributed SCM might come in handy - it would allow
people to make changes to the spec (small typo fixes, etc.) and send
patches to Ian for integration.
> "Problem: A Kitchen Sink Specification"
> Ian recently implemented a way to hide or highlight the UA guidelines
> that confuse so many more casual readers. Does this help? (I know it
> helps me. ^_^)
If I knew it existed it might have helped a bit. Even now that I know it
exists, I can't figure out how to activate it. How do I hide the "UA
I explain more about this issue in the previous e-mail back to David
Baron on why microsections might be a better approach for building these
more targeted documents.
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Released - Browser-based P2P Commerce
More information about the whatwg