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

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
-- 
http://twitter.com/Smylers2

Received on Friday, 4 June 2010 11:12:44 UTC