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

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

From: Sam Ruby <rubys@intertwingly.net>
Date: Fri, 21 May 2010 12:47:40 -0400
Message-ID: <4BF6B92C.8030805@intertwingly.net>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: Maciej Stachowiak <mjs@apple.com>, "public-html@w3.org WG" <public-html@w3.org>
On 05/20/2010 02:58 PM, Tab Atkins Jr. wrote:
> Issue 89 Counter Proposal
> =========================

I've recorded the counter proposal in the issue-status page, but I 
encourage you to consider improving the rationale.

> Summary
> -------
> There is no problem, and no change should be made.
>
> 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.  We can offer useful advice to authors in the HTML
> spec, promoting particular patterns for these types of content that
> are at least good enough.  This has the potential to reduce author
> confusion for very little cost, and helps to ensure that complex
> content is marked up in a way that is widely usable, such as for
> accessibility purposes.

This rationale is extremely generic.  "Some types of content ... can 
offer useful advice... potential to reduce author confusion".  That 
could pretty much justify any addition to the spec.

By contrast, the original proposal that this proposal attempts to 
counter alleges specific problems, ranging from lack of conformance 
requirements, deprecation, interoperability, etc.

Consider adding an explanation as to why you believe that the specific 
advice offered is useful and provide rationale as to why this specific 
advice would reduce author confusion.

> Details
> -------
> No change.
>
> Positive Effects
> ----------------
> Authors receive good advice on how to mark up certain relatively
> complex types of content, thus increasing the chance that said markup
> is well-designed and as widely accessible as possible.  By spreading
> this advice in a relatively official document such as the html spec,
> we increase its chance of being picked up by other tutorial and
> teaching sites, rather than those sites coming up with their own
> potentially inferior and conflicting advice.
>
> 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, the impact of this is
> relatively small.  The advice given in the html spec is at least "good
> enough"; if better advice comes along in the future, the degree to
> which it is better is likely to be fairly small.
>
> Additionally, this section is guidance, not normative requirements for
> authors.  If specific guidelines, perhaps mandated by law in
> particular contexts, contradict the advice given here, the author may
> follow those guidelines without fear of making their markup invalid.
>
> Finally, the advice given by this section can always be superseded,
> either informally by new best-practices that become commonly accepted,
> or more formally via the "Applicable Specifications" clause.  The w3c
> may, for example, publish at some later date a more comprehensive
> markup-best-practices document that covers the limited cases given in
> the spec and further cases as well, without any significant conflict.
>
> ~TJ
>

- Sam Ruby
Received on Friday, 21 May 2010 16:48:07 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:02 UTC