- From: Sam Ruby <rubys@intertwingly.net>
- Date: Wed, 04 Aug 2010 13:02:44 -0400
- To: "Tab Atkins Jr." <jackalmage@gmail.com>, "public-html@w3.org WG" <public-html@w3.org>
On 06/04/2010 07:48 AM, Sam Ruby wrote: > Tab: incorporating these suggests would address my previous feedback on > this proposal. At this time, the chairs are formally requesting that you update your change proposal. Please complete this within the next week. > - Sam Ruby - 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 Wednesday, 4 August 2010 17:03:16 UTC