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

On Fri, May 21, 2010 at 9:47 AM, Sam Ruby <rubys@intertwingly.net> wrote:
> 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.

That's the most specific rationale that covers those cases, though.
They are complex examples of markup that can be easily done badly (and
often are, on the web), but aren't important enough to justify a
dedicated element.

If we decided that there were more examples of similar complexity and
level of use, I'd support adding them in too.  I can use more specific
adjectives, if you would like, to try and describe it more precisely,
but that wouldn't substantially alter the width of the net cast by my
words.  Of, it it would help, I can remove some of the prevaricating
in my language and state things more forcefully.  This would similarly
merely be a change of voice, though, not of substance.


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

The lack of conformance requirements is a feature.  This is advice,
not requirement, and is meant merely to provide a baseline level of
advice that is sufficient to address the use-cases while offering up
acceptable accessibility.  I addressed this in my CP.

The deprecation issue mentioned in Shelley's CP is a non-sequitur.
There is no text regarding <dl> at all in this section of the spec.

Shelley's CP doesn't mention any interoperability issue.  She mentions
interoperability in passing, when discussing the deprecation issue,
but it's not brought up as anything wrong with the spec, and can't
really be interpreted as such either.


> 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.

All of the explanations would be identical.  "This case is moderately
complex, and is marked up in a variety of ways on the web currently,
many of which are less than ideal from an accessibility perspective.
The advice provided here is simple and easy to follow, while offering
acceptable accessibility as well."

In essence, this is not significantly different from the myriad markup
examples scattered throughout the spec illustrating good ways to use
various elements.  This section merely addresses certain cases that
are not specific to particular elements, but instead encompass a
mixture of several.

Shelley's CP alleges that authors would be better served by this
section instead providing a detailed argument for why elements
addressing these use-cases were not added to the spec.  I strenuously
disagree; if an author is trying to mark up a particular pattern and
is wondering why there's no element for it, a simple demonstration
showing that it can be achieved very easily with existing markup is an
ideal answer, as it addresses both their original question ("Why is
there no element for this?" "Because you can do it with normal markup
really easily.") and the inevitable follow-up ("Well, how do I mark it
up then?" "Like this.").

~TJ

Received on Friday, 21 May 2010 17:16:18 UTC