Ian Hickson wrote:
On Fri, 20 Feb 2009, Sam Ruby wrote:
Ian Hickson wrote:
On Thu, 19 Feb 2009, Sam Ruby wrote:
For starters, there is an interesting gap between 100% and 50.000001%.
I wasn't specifically meaning 50%; there are as you say a number of
ways of achieving "consensus" without achieving "unanimous consensus",
ranging from
everyone-except-people-who-disagree-with-everything-on-principle down
all the ways past 50% to a mere plurality. If our goal is to aim for
one of these levels, it would be helpful to know which level we are
aiming for since it would affect the way one would approach the goal
of publishing a last call draft.
At the IETF, there is a mantra of "rough consensus and running code". As
I read your proposed milestones, I see Last Call first preceding running
code in a number of instances. Am I misreading this?
No, that's correct. The W3C model is that running code is only expected
after entering the CR phase. That we have any code at all at this very
early stage (in W3C terms) is actually quite unusual.
Equally unusual: "The HTML5 work isn’t using the traditional W3C
approach, and will never use a consensus approach so long as I am editor"[1]
Frankly, we are in uncharted territory. Without continuously assessing
consensus (the traditional W3C approach) and without code to anchor us
(like I see done elsewhere), frankly this spec is adrift.
There are still other processes that I'm aware of. When I was the
convener (roughly corresponds to W3C chair) of the ECMA CLI spec (better
known as the spec for the foundation of the .Net CLR or Mono), we had a
grueling schedule of meeting every six weeks or so face to face going
over a chapter or so a meeting.
I'm flexible. I'm quite willing to give you (or any other editor, for
that matter) quite a bit of latitude. But I will be equally straight up
about my assessment of the prospects. I believe I've been consistent on
this matter. I believe I was brought in to fix this issue. And it is
my belief that we can get through this, otherwise I wouldn't be here.
Your end date (2022) is clearly not an issue, but at this point in time
I do strongly believe that some of the interim milestones need to be
reexamined.
It would be helpful if we had a firm idea of how we want to approach the
problem of section 1.5.4 sooner rather than later, if we are to not slip
past October. This is not an issue that where implementors "vote with
your feet". What bar are you looking for?
My understanding is that the status with that section is that Larry and
Lachy were going to try to explain what was wrong with the section, so
that it could be improved. Is this not the case?
If it turns out that this is one of only a few things that need to change
to dramatically increase the level of consensus from certain quarters,
then it's certainly an area that will change. On the other hand, if the
people objecting to this section also object to most of the rest of the
document, then changing it wouldn't gain us much. Does that make sense?
Regarding the question in the last paragraph: not to me.
Larry has simply asked that the section be removed. Suggesting that his
requests are not to be considered until he expresses any and all
potentially unrelated objections is not, in my opinion, a particularly
effective way to manage a queue of issues. This looks like an easy
issue to me, but if you want to defer it to 3Q that's you choice. I'll
just point out that the implications of such a cavalier approach to
issue management are pretty clear to me.
As always, I'll be brutally honest here: if there are other specs that
have editors that appear to manage their input queues of requests better
and therefore show a greater chance of completing in a reasonable
time-frame, I'll apportion my time accordingly.
For the record, I also don't believe that Rob's approach will be a
cakewalk. Just to give one example: I fully expect him to also run
smack into an objection by the likes of Roy Fielding. Roy is tough to
work with because he invariably is right. But I have worked with Roy
before, and if we have dealt with or deferred all other issues, I'm
confident that we can work through these issues too.
And if your choice is to focus further down the road, you will be
amongst the beneficiaries of having these issues behind you. Should you
decide to switch directions and focus more near term for the moment, or
to entertain the TAG-preferred approach of layered specifications, I'll
help with that too.
For the near term the low hanging fruit is as follows: [...] for you
to consider Rob's approach to @summary, @profile, and @alt.
Could you elaborate on this? I'm not sure what approach you mean.
Rob's statements on this matter:
https://bugzilla.mozilla.org/show_bug.cgi?id=478665#c3
http://lists.w3.org/Archives/Public/public-html/2009Feb/0128.html
Related example from the same editor:
http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1.1
As a concrete example, let's explore "summary". To the extent that I
understand it, your position is that the summary attribute is
non-conforming, and people who wish it to be so must provide a what
appears to be an unspecified amount of supporting data if they wish this
to be changed.
My read is that Rob would simply say that summary is a part of the
grammar and would prepare an even-toned cautionary note directed at
consumers. Others would be welcome to draft alternative wordings for
the cautionary note for consideration.
My approach is that I want to improve accessibility, and I think that the
document conformance rules are one of several tools we have at our
disposal to help people spend their time on the right things that improve
accessibility. There has been new data recently collected that puts into
question the current state of the spec regarding summary="", which I look
forward to examining in detail, so this may not be a good example to
study. Better examples might be axis="" or longdesc="", which are also
absent in HTML5 yet present in HTML4 and which theoretically were supposed
to improve accessibility. Including longdesc="" is demonstrably a waste of
time, because so few pages use it correctly that users are almost
certainly never going to try to use the feature. Thus, HTML5 makes it non-
conforming, leading authors to spend more time worrying about other things
(like alt=""), which actually do help accessibility.
The approach of just ducking controversy doesn't improve accessibility.
Time out. If I felt the "no consensus, no code" approach was viable in
anything approximating a reasonable timeframe, we wouldn't be having
this discussion. We are exploring a potential "next step", not a "final
destination".
If I wasn't clear on that, I apologize.
I'm not saying "never". I'm saying that "not all at once" approaches
look more viable at this point in time. If you think that @summary is
top of the list of issues that HTML4.next should address first and
foremost, then by all means propose something else to defer until
HTML4.next.next.
I do happen to have an opinion on the subject (I'd say that other
battles are more important to me), but I'm not the one doing the work.
It
attempts to put an immediate spec-writing and working-group benefit
(namely, being able to move forward without objections) ahead of the user.
This, IMHO, is unacceptable (and is counter to our design principles). It
also doesn't actually work, because it won't get any more consensus -- it
will just move the objections from one group of people to another.
You also mentioned profile="" and alt="". I don't understand how the
approach you describe would extend to those two attributes. In the case of
profile="", just allowing it with the spec saying "here be dragons" misses
the point entirely, which is that putting it in the spec leads other spec
authors to think that the feature is something they can rely on, whereas
in practice that isn't the case (virtually nobody actually uses it, even
when they should). With alt="", as far as I can tell the spec is closer to
taking the approach you describe than the people complaining want -- the
controversy is actually that the spec doesn't take a stance that's tough
_enough_, quite the opposite of the problem with the other two attributes.
Again "next step" vs "final destination". A spec that is no worse than
HTML 4 is in this one aspect might be a useful baby step given the other
issues that we have to deal with. And in the case of alt, the right
baby step might very well be to continue to make it required
unconditionally.
Pick your battles.
Just to be clear, I'm not telling you or Rob or Mike what order to do
things, or what to work on. But I will be by each of your sides and
play an active role in assessing consensus throughout the process.
- Sam Ruby
[1] http://intertwingly.net/blog/2008/11/20/Half-Full#c1227317561
