W3C home > Mailing lists > Public > public-html@w3.org > August 2010

Re: ISSUE-89 idioms - Chairs Solicit Alternate Proposals or Counter-Proposals

From: Sam Ruby <rubys@intertwingly.net>
Date: Wed, 04 Aug 2010 13:02:44 -0400
Message-ID: <4C599D34.4030102@intertwingly.net>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, "public-html@w3.org WG" <public-html@w3.org>
On 06/04/2010 07:48 AM, Sam Ruby wrote:
> Tab: incorporating these suggests would address my previous feedback on
> this proposal.

At this time, the chairs are formally requesting that you update your 
change proposal.  Please complete this within the next week.

> - Sam Ruby

- Sam Ruby

> On 06/04/2010 07:12 AM, Smylers wrote:
>> Tab Atkins Jr. writes:
>>
>>> Issue 89 Counter Proposal
>>> =========================
>>
>> Hi Tab. Thanks for preparing this. A few suggestions below:
>>
>>> Rationale
>>> ---------
>>> Some types of content are common enough on the web to be significant,
>>> and complex enough to not have a simple, obvious way to mark them up,
>>> but do not offer enough benefit to directly address their use-cases by
>>> adding to HTML.
>>
>> That makes it sound a bit negative, giving the impression that these
>> scenarios are in a worse position than if they had dedicated HTML
>> elements. I'm not sure that is the case and am wondering if something
>> along the lines of the following may be better:
>>
>> The HTML language should cater for all types of content that are
>> common enough on the web to be significant, otherwise it is doing a
>> disservice to producers of any types which it omits.
>>
>> In creating the HTML5 spec we considered all of these types, and
>> ensured the language caters for them. Some types of content have
>> specific elements; others share elements. In all cases we should state
>> how to mark up these significant types of content, for the benefit of
>> authors who wish to publish such types.
>>
>> (Whether such descriptions are with the definitions of particular
>> elements or in a separate section of idioms -- or a mixture of the two
>> -- is a purely editorial matter that doesn't effect the total
>> information conveyed to authors.)
>>
>>> Negative Effects
>>> ----------------
>>> By including such authoring advice in the html specification, we open
>>> ourselves to the possibility of "baking in" advice that may be later
>>> superseded by new best practices.
>>
>> However if it's later decided that, say, the best way of marking up
>> tagclouds is with a specific<tagcloud> element then the HTML spec would
>> need updating anyway, to introduce such an element.
>>
>> And on the 'separate document' point:
>>
>> Tab Atkins Jr. writes:
>>
>>> On Fri, May 21, 2010 at 7:16 AM, Julian Reschke
>>> <julian.reschke@gmx.de> wrote:
>>>
>>>> separating the normative spec from authoring advice seems to be the
>>>> better approach; in particular it allows documents to be published
>>>> and progressed independently.
>>>
>>> If someone were to work on a HTML Markup Cookbook spec that contained
>>> more than just the handful of examples currently in the html spec, I'd
>>> support that and recommend removing this section from html itself.
>>
>> I wouldn't. It doesn't make sense for an author wanting to know how to
>> mark up X in HTML5 has to look in one of two different places, depending
>> on whether X has a specific element or is marked up by combining more
>> basic elements -- that's begging the question.
>>
>> Consider an author wishing to mark up the transcript of a conversation.
>> HTML5 provides a way to do this. We considered a specific<dialog>
>> element, but decided instead on<p> (in combination with<b> and other
>> elements). That the decision doesn't involve adding any new elements to
>> HTML5 is not a good reason not to document to authors how HTML5 should
>> be used to do this.
>>
>> Especially since HTML4 said to use<dl> for transcripts. An author
>> familiar with HTML4 and looking for the equivalent in HTML5 will not be
>> helped by no mention of how to do this in HTML5.
>>
>> Smylers
>
>
Received on Wednesday, 4 August 2010 17:03:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 4 August 2010 17:03:17 GMT