[whatwg] A New Way Forward for HTML5

[Manu Sporny]

Tab Atkins Jr. wrote:
>> http://html5.digitalbazaar.com/a-new-way-forward/
> 
> 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
made progress.

> "Problem: Partial Distributed Extensibility"
> We had partial distributed extensibility.  We called it "The Browser
> Wars". 

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
permathreads. :)

Did you read this? It was linked to in the set of proposals I wrote:

http://intertwingly.net/blog/2009/04/08/HTML-Reunification

It discusses the separation of concepts between language extensibility
(which isn't always desirable), and data extensibility (which is very
desirable).

> "Problem: Specification Ambiguity"
> Dropping an email to the list is *not* a difficult thing. It's
> trivial.

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
> will.

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
tracker.

We could use the same system to help people submit examples of how each
element could/should be used (like the PHP UserNotes):

http://www.php.net/manual/en/function.curl-getinfo.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
Requirements" for:

http://www.whatwg.org/specs/web-apps/current-work/#the-progress-element

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

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Released - Browser-based P2P Commerce
http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/