Re: ready to publish "HTML5 differences from HTML4"?

On Jun 24, 2007, at 4:31 PM, Dan Connolly wrote:

> On Sun, 2007-06-24 at 14:02 -0500, Robert Burns wrote:
>> On Jun 23, 2007, at 1:31 PM, Dan Connolly wrote:
>>
>>>
>>> The differences document is nice and short; it has gotten
>>> a generally positive reaction.
>>
>> I think the positive reaction to the document is due to the fact that
>> we needed such a document to move the discussion along within the WG.
>> I don't think we're even close to a public release of that or any
>> document (maybe we'll be ready next month or August).
>
> We're already behind schedule for publishing something, strictly
> speaking. We were chartered 7 March; 3 months later is 7 June.
> Due to the fact that we weren't exactly firing on all cylinders
> on 7 March, a slip 'till the end of June or early July is
> somewhat straightforward; beyond that... I can ask for an exception
> to the heartbeat rule, but I would need to make a very good case.
>
> The heartbeat rule is
>  http://www.w3.org/2005/10/Process-20051014/groups.html#three-month- 
> rule
>
> It was cited from the "What should the HTML WG publish first?" survey,
> right at the top...
>
> "If you're not familiar with the process of Working Draft publication,
> see the list of W3C working drafts, section 7.4.1 First Public Working
> Draft of the Process document, and the heartbeat requirement."
>  -- http://www.w3.org/2002/09/wbs/40318/wd7/results
>
>
>>> I suggest this WG should publish it in its present form.
>>> http://dev.w3.org/cvsweb/~checkout~/html5/html4-differences/
>>> Overview.html
>>> $Revision: 1.22 $ of $Date: 2007/06/23 15:22:05 $
>>
>> I think to release that document now would be a big debacle. It would
>> create similar misunderstandings to those faced by XHTML2 when
>> everyone thought they couldn't have <img> elements in their documents
>> anymore (like HTML was going to become text only). Such
>> misconceptions will dominate the discourse about HTML5 and the public
>> will not recognize all of the positive contributions HTML5 makes.
>
> I see the risk; being quiet is not likely to help. Better to
> let the discussion start, I suggest.
>
>> Before we can publish this or the spec, we should wait for the
>> detailed review to come in over the next few weeks.
>
> I agree that publishing the spec should wait until the scheduled
> review completes, but only presuming this WG publishes something
> else to satisfy the heartbeat requirement first.

Would not publishing the design principles as a working draft satisfy  
the heartbeat requirement? I've seen little objections to that  
document and think it could be made ready for publication (at least  
as a working draft if not final) rather quickly.

>>  On the HTML4 /
>> HTML5 differences document, we need to:
>>
>> 1)  settle the issues already raised on the assistive technologies
>> features that are missing in HTML5.
>
> I think it's perhaps worthwhile to note issues that have gotten
> a lot of discussion. I intended to suggest text along those lines
> as soon as I saw Anne's draft. But that was 2 weeks ago, and
> I haven't managed to do it. And I'm not sure it will be easy
> to come to consensus on a description of the status of discussion.
> So I am content to just report, factually, which features are
> in the current editor's draft.
>
> The "status of this document" section will of course note that
> there are various open issues and that the WG hasn't made
> decisions on any of them.
>
> I hope you can accept publishing a document while these issues
> are still open. I don't see how we can meet the heartbeat
> requirement otherwise.

In general, I would certainly support publishing working drafts while  
issues are still open. However, on some of these issues I think it  
would be irresponsible to publish with such serious issues left  
outstanding. Again, I'm saying that these issues will dominate the  
discussion long after they're resolved by the WG. It will be hard to  
live down the misconception that "HTML5 is that new version that is  
less expressive than the old version" mentality. Better to make sure  
these mistakes are fixed before the first public working draft is  
published.

>>  From the discussions that have
>> occurred so far, I would say the overwhelming consensus is that these
>> features should NOT be dropped in HTML5.
>
> "overwhelming consensus" is a contradiction in terms, in W3C process.
> In W3C process, if one person objects, there is not consensus. There
> is no level of support sufficient to be called "consensus" as long
> as objections remain.

I have not really seen serious objections to including the assistive  
technology semantics. Perhaps they occurred before I arrived, but  
I've tried to diligently read everything that's passed since I joined  
the working group.

> It might be correct to say "the overwhelming majority of opinion"
> or some such, but that would be based on a lack of information;
> most WG members have not given their opinion. Perhaps
> "the overwhelming argument that has been presented" is accurate.

Is not "given an opinion" the same as "not given their opinion". My  
understanding of WG rules was that an active objection needs to be  
registered and a passive silence would not be counted as an objection.

> Evidently, the editors are not convinced. Or perhaps they haven't
> gotten around to reading all the relevant arguments. I hope
> the editors respond to this issue in due course in a way that
> results in consensus. Otherwise, we'll escalate to the whole
> WG and make a formal decision. I'm not sure what priority
> to give to that task, but I hope I can put it at a lower
> priority than a decision to make our first publication.
> Otherwise, we run into the heartbeat requirement and the
> risk that this WG gets closed altogether.
>
>
>>  If we decide to publish the
>> differences document without settling these AT issues, we need to (at
>> the very least) explain what alternative mechanisms authors will use
>> in HTML5 for the features from HTML4 that HTML5 no longer supports
>>
>> 2) provide detailed explanations for the semantic changes in elements
>> such as <ht>, <i>, <b>, <strong>, and <small>.
>
> Feel free to suggest any specific changes you want.
>
> <rant>
> Saying "we need X" as though we're a bunch
> of customers who can demand service annoys me. We are the working
> group. If we want work done, the most constructive thing is
> to do it.
> </rant>

I'm not clear on how to do it. Perhaps I haven't read the materials  
sufficiently, but isn't it appropriate to air the necessary changes  
here on the email list. Others have also added this to the wiki. What  
else should we members of the working group do? I'm not trying to be  
facetious here, I honestly thought that airing things here on the  
email list was the way we move the process forward to meet our  
deadlines. If there's more I should be doing I'd be happy to.

>>  In my view, the change
>> in semantics means we do not maintain the html namespace. After all,
>> a namespace is a promise that the names used in the space will always
>> mean the same thing. New names may be added. Other names may be
>> deprecated. But the names, once introduced, will always have the same
>> meaning.
>
> I'm not so sure. The TAG looked into that and found otherwise:
>
> "As a general rule, resources on the web can and do change. In the
> absence of an explicit statement, one cannot infer that a namespace is
> immutable."
>  -- http://www.w3.org/2001/tag/doc/namespaceState.html

Certainly a namespace is not immutable. I never meant to suggest  
otherwise. However, that's not the same thing as saying that  the  
names within a namespace can simply change their meaning from one  
document to the next. To me that would be saying there is no  
namespace at all. Yes there are names used to designate certain  
ideas. However, its not a namespace because those names can designate  
one idea in one place and an entirely different idea in another  
place. In our situation, a named element may designate one idea in  
one html document and an entirely different idea in another html  
document. That would mean the absence of a namespace. Namespaces are  
mutable in the sense that names may be added and they may be  
deprecated or taken away. However, even when taking names away one  
would expect the namespace to keep track of what was taken away and  
not add the same name back years later that means something else.

There's nothing in <http://www.w3.org/2001/tag/doc/ 
namespaceState.html> that would lead me to think otherwise. That  
document's purpose is to determine "whether or not adding new names  
to a (published) namespace is a sound practice.". That's not an  
endorsement for dropping any consistency in name / semantics over time.

Again, I think the design principles document should suffice for the  
heartbeat rule and there was significant support for publishing that  
(and little discussion objecting to its current state).

Take care,
Rob

Received on Sunday, 24 June 2007 22:14:35 UTC