- From: Robert Burns <rob@robburns.com>
- Date: Thu, 23 Aug 2007 17:30:58 -0500
- To: Dan Connolly <connolly@w3.org>
- Cc: John Foliot <foliot@wats.ca>, w3c-wai-ig@w3.org, wai-xtech@w3.org, whatwg@whatwg.org, public-html@w3.org
Hi Dan, I'm glad to see you bring these issues to the list They are pressing issues and I think even these issues of conveying a 'bad image' can have detrimental effects down the road on the adoption of our deliverables. We want to make sure that HTMl5 is taken seriously by both authors and developers. On Aug 23, 2007, at 3:52 PM, Dan Connolly wrote: > On Thu, 2007-08-23 at 12:14 -0700, John Foliot wrote: >> Dan Connolly wrote: >>> >>> I sympathize with your frustration, but I ask that you remain >>> patient. >> >> Dan, >> >> Thank you for your prompt response. While patience is indeed a >> virtue, my >> (our?) patience is being sorely tested, as while the official word >> is that >> we're nowhere near deciding anything, current editors and >> contributors are >> going ahead and making "pronouncements" that lead many to believe >> that much >> of HTML5 is 'fait accomplis'. As someone once said to me, you >> can't suck >> and blow at the same time. >> >> To whit: >> * Is Anne ("Standards Suck") van Kesteren out of place to be >> announcing that >> HTML5 has dropped <input usemap>? >> [http://annevankesteren.nl/2007/08/input-usemap] > > Evidently; i.e. perception is reality, and I'm getting complaints > about this weblog entry. > > Anne, you and I have certainly talked about the connotations and > denotations of "dropped". > > Something like "the editors are evidently inclined to drop > <input usemap>; it will be interesting to see whether any new > arguments come up" perhaps wouldn't have generated as many complaints. However even that language conflicts with your earlier post on the state off the WG where you said: > But keep in mind that we have, so far, made *no* design > decisions. We haven't decided that HTML 5 will have a p element. > Before we address subtle issues like the table headers issue, Any edits to the draft so far are just that edits to a draft. Really they are proposals of the editor to the WG. These are hardly different than the proposals on the wiki, except those are proposals from one or more WG members who are not editors. > How about updating your weblog entry with something like that, Anne? > >> * Is Lachlan Hunt definitive when stating, "HTML5 now defines the >> usemap >> attribute as a Hashed ID Reference, not a URI, and can only >> reference maps >> within the same document." >> [https://bugzilla.mozilla.org/show_bug.cgi?id=189643], as well as >> "HTML5 >> currently will not be including the usemap attribute on input >> elements." >> [https://bugzilla.mozilla.org/show_bug.cgi?id=392994] > > He seems to be accurately quoting from current editor's drafts. > That seems like a useful way to get feedback from the > mozilla development community, no? It does not at all seem to be a quote from an editors draft to me. Lachlan neglects to mention that it's a draft. He states it an way that makes it sound authoritative on the verge of final recommendation status. He links to document fragments in the draft that skip right past the disclaimers about the document status. Now we can pretend that developers read every word of a specification before writing a single line of code, but I think we should instead admit that's avery rare developer. You may think that developers know better, but since these are diverse open source communities, they have the same vulnerability to be swayed by such rhetoric as most any community. Bugs have even been closed as wontfix due largely to confusion created by pronouncements like Lachlan's. (I don't mean to single out Lachlan here; he is not the only one. This is just one example.) > It seems to me that in the bugzilla context, it's reasonably well > known that HTML 5 is a moving target. The Mozilla foundation > is reasonably well represented in this working group; I'm interested > to get confirmation as to whether this is business-as-usual > or something counter to norms there. I would say it is very counter to norms. Sure you'll see it quite often relating to HTML5 and WebForms 2.0, but I cannot recall any other cases where you see these types of pronouncements. CSS 2.1 might often get quoted as a if its a final recommendation, but at least that has first reached a candidate recommendation status on a few occasions . Also the mozilla foundation may be well represented here, but Mozilla is a large project and largely a de-centered community of developers. Unless the Mozilla members of our group are going to spend an inordinate amount of time trying to counter these claims, they will have detrimental effects in the Mozilla community. It's best to just not make such claims in the first place. >> * Is From Maciej Stachowiak correct when he states, "This feature is >> underspecified in HTML4, and not implemented by IE. It is also >> likely to be >> dropped in HTML5 and may be removed from Mozilla and Opera as a >> result." >> [http://bugs.webkit.org/show_bug.cgi?id=15032] > > I accept "underspecified" and "likely to be dropped" as his opinion, > and as far as I know he's correct that it's not implemented by IE. However, I think the concern is not over the "underspecified in HTML 4" as the "likely to be dropped in HTML5". By what basis could anyone make such an estimation when as you yourself said: we should all "keep in mind that we have, so far, made *no* design decisions. We haven't decided that HTML 5 will have a p element." Making such a claim at this stage seems on par with claiming HTML5 will address the issues surrounding area 51; though to those outside the WG, it doesn't sound so absurd. It sounds more persuasive than that. Yet we have a forms taskforce that has barely just convened. We have made not a single design decision. Rather, a few members of the WG, including one editor, have proposed dropping use of image maps by input elements, based on either 1) a misunderstanding of the HTML 4.01 recommendation (not hard to do because it is ambiguous on the issue) or 2) another premature consideration of the WebForms 2.0 draft regarding the <input usemap> feature; or 3) another fair reading of HTML 4.01, but a reading that should still be open to WG discussion. Either way, it is clearly an issue that will (and needs to) get a much more thorough consideration by the WG. >> These types of pronouncements *do* tend to send mixed messages, >> don't you >> agree? > > Yes. > > That's an accurate reflection of the constituencies in the working > group: there are a variety of opinions. We could have chartered > the working group to keep its discussions member-confidential until > we reached consensus, but I don't think that would be better. There's a bid difference between not making the WG discussions confidential and going further to have WG members making pronouncements in public that misrepresent where the WG stands right now. If all of those pronouncements ended with: "But keep in mind that we have, so far, made *no* design decisions. We haven't decided that HTML 5 will have a p element.", then I don't think anyone would be raising these concerns. >> If these authors/HTML 5 contributors can be categorically making >> these kinds of statements, then is it not unreasonable to expect >> something >> like, "Based upon current feedback, the headers attribute will be >> preserved >> in HTML5" (attribute to whom you wish)? > > What I get from Al Gilman's 6 June message is that something that > provides the functionality of the headers attribute is needed. > He doesn't argue that the headers attribute is the only acceptable > solution. > http://lists.w3.org/Archives/Public/public-html/2007Jun/0145.html > > I have seen a fair amount of test data fly by and I have > seen a lot of discussion of use cases. I have not digested it all yet. I agree with your assessment of Al Gilman's message. And I think there have been a lot of fruitful discussion surrounding table data/ header cell associations that could lead to some excellent solutions. However, the issue being raised is not specifically about header cells (as i understand it). It''s a broader issue regarding the disjoint between deliberations and reviews of the WG and the editing that's happening to the draft. Not long ago you said you've seen WGs work well with either 1) the editor making edits introducing proposed changes to the draft for subsequent WG discussion or 2) the discussion taking place first followed by edits to the draft reflecting the WG's views . However, in this WG there's a third approach we're seeing that is hard to imagine working well. We have edits to the draft that neither reflect discussions occurring in the WG, nor do these edits serve as a catalyst to initiate discussions that appear to have any influence over future edits. That to me suggests a gradual widening of the separation between the views expressed in the WG and the views penned into the draft. That's a problem for the WG. There should be some gradual process approaching editor/WG unity instead. Take care, Rob
Received on Thursday, 23 August 2007 22:31:59 UTC