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

Tab: incorporating these suggests would address my previous feedback on 
this proposal.

- 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 Friday, 4 June 2010 11:49:16 UTC