- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 21 May 2010 10:15:22 -0700
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: Maciej Stachowiak <mjs@apple.com>, "public-html@w3.org WG" <public-html@w3.org>
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