W3C home > Mailing lists > Public > public-html@w3.org > May 2009

Re: Title of the HTML5 document

From: Sam Ruby <rubys@intertwingly.net>
Date: Mon, 25 May 2009 10:38:59 -0400
Message-ID: <4A1AAD83.7050505@intertwingly.net>
To: Anne van Kesteren <annevk@opera.com>
CC: Maciej Stachowiak <mjs@apple.com>, "public-html >> HTML WG" <public-html@w3.org>
Anne van Kesteren wrote:
> On Mon, 25 May 2009 14:54:39 +0200, Sam Ruby <rubys@intertwingly.net>
> wrote:
>> Maciej Stachowiak wrote:
>>> If you think there are contradictions that are problematic,
>>> should they not be addressed as technical issues in their own
>>> right, rather than playing games around with the title?
>> I do *NOT* like the characterization of "playing games".  Please
>> stop that.
> 
> I have to admit I share this feeling with Maciej. I.e. I definitely
> get the feeling the argument is not about the title, but rather the
> contents of the document.

The argument is about getting the title and contents to match.  Both "A 
vocabulary and associated APIs for HTML and XHTML" and "Uniform Browser 
Behavior for the Web" are misleading by omission.

>>> Note that neither Roy nor Larry suggested that "contradictions
>>> with other specifications" was a reason to change the title.
>>> Rather, they do not like the things the spec specifies or the
>>> manner in which it does so. The argument that the title should be
>>> changed because there are contradictions with other
>>> specifications was, I believe, first presented in your emails
>>> just now. At first glance, it does not seem to me that changing
>>> the title would make such contradictions any more or less of a
>>> problem, so I'm not sure why you are making this argument.
>> http://lists.w3.org/Archives/Public/public-html/2007Nov/0430.html
>> 
>> Roy stated that the title was "misleading", and continued with the
>>  observation that it contains sections which "reinterpret HTTP".
> 
> He also said "It is not HTML5 by any stretch of the imagination." and
> similar inflammatory remarks. Also, the chairs at that time decided
> it was ok to publish the document anyway so I think it was at least
> established that HTML 5 was an OK name to use. I.e. his objection was
> taken note of and a decision to continue with the chosen name was
> made.

It was agreed that HTML 5 was an OK name to use.

>> The issue is not with the <h1>.  Removing the subtitle would not
>> address the issue.
> 
> Roy's issue was with the <h1> as far as I can tell. The subtitle was
> added a little later because some thought HTML 5 was not clear about
> the status of XHTML:
> 
> http://lists.w3.org/Archives/Public/public-html/2008Jan/0096.html

The subtitle helps in some ways, but not others.

>> The current draft contains content sniffing for feeds.  If
>> accurately describes uniform browser behavior.  It reinterprets
>> HTTP.  It is not part of a vocabulary.  It is not part of
>> associated API.
> 
> It is planned to be splitted out and is a very minor part of the
> whole specification. It is also not specific to browsers as search
> engines, feed readers, etc. have to implement similar algorithms. I
> don't think everything needs to be called out in the title/subtitle.
> E.g. that rendering rules is defined is good, but there's no need to
> call that out there. Would it really help if we added to the subtitle
> that HTML5 deals with page load processing semantics as well? I'd be
> fine with adding something to that effect, but I've similar
> reservations to myakura:
> 
> "title of #html5, wording in html-desing- principles, i keep
> wondering such small changes would make people interpret these any
> differently" https://twitter.com/myakura/status/1909112035

Nobody has suggested that everything needs to be called out in the 
title/subtitle and abstract.  Merely that things that might be 
considered to be unexpected be so called out.

I also disagree that feed readers implement "similar" algorithms.  In 
most cases, the approach is more along the lines of: if you tell me it 
is a feed, I'll first try it as a feed (no matter what the MIME type may 
say), and if that fails, I'll try a limited amount of sniffing to see 
what the content really is.

>> If it weren't contentious, it wouldn't be an issue.  It is
>> contentious. One way to address it is to remove the section.
>> Another is to label it properly.
>> 
>> Removing accurate, but incomplete, labels does not address the
>> issue.
> 
> The section in question is clearly labeled, no? I.e. it notes what
> specifications it is in conflict with.

The section is labeled.  Now the section needs to be included in a 
specification whose title, subtitle, or abstract heralds that material.

- Sam Ruby
Received on Monday, 25 May 2009 14:39:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:37 GMT