- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 10 Apr 2007 03:53:18 -0700
- To: Henrik Dvergsdal <henrik.dvergsdal@hibo.no>
- Cc: public-html@w3.org
On Apr 10, 2007, at 3:17 AM, Henrik Dvergsdal wrote: > > On 10. apr. 2007, at 11.36, Maciej Stachowiak wrote: >> I could give my personal opinion on these points if you are >> curious but I don't think it is relevant to the question of >> adopting HTML5. And I certainly would not be speaking for everyone >> who signed the letter. > > On 10. apr. 2007, at 11.39, Dao Gottwald wrote: >> I don't follow your reasoning. Using HTML5 as a /starting point/ >> doesn't mean that any resolution of the WHATWG is set in stone. > > OK. I get your point, but there seems to be a common vision here > and I think it will be useful to get a sense the whole picture. It > would at least help putting the decision into perspective. > > So what is your *personal* opinion on this then? Do you think this > seems like a good strategy: I don't think anyone is proposing exactly this strategy except you. Maybe you should get opinions from the people you quoted, to see if you accurately presented their point of view. I don't think you did. But since you asked, here are my personal opinions, speaking only for myself. > 1. We start with HTML5 in its current state. Obviously, I agree. > 2. We add all that's necessary to define "exactly how to handle the > web as it is today" (Hunt). This means all components that are > being used in current web pages, including, for instance, elements > like <blink>, <blackface> and <marquee> and all the "undocumented, > unspecified, frozen set of bugs" (Hickson) that people rely on out > there. Not exactly. The elements that would have to be specified are ones that current web content depends on to a significant degree. To address the ones you mentioned: <marquee> would have to be included, it is supported at least by IE, Mozilla and Safari and is apparently used extensively on various Asian-language sites. <blink> is not supported by IE and there doesn't seem to be significant content depending on it - supporting it with actual blinking would be more likely to break content. <blackface> is a proprietary tag only supported by MSNTV in their variant of XHTML for walled garden content. It is not relevant to the web. Given these examples, I assume this was meant to be some kind of reductio ad absurdum. But I think we can distinguish unappealing but needed features, like <marquee>, from unneeded (and possibly counterproductive) ones like <blink> or <blackface>. I think there is considerable flexibility on what exactly to include, for such implementation-only elements. > 3. We organize the standard into sets of "recommended", "right" > components, and sets of forbidden, "wrong" components: > > This "effectively means that we discourage people from using the > elements (it's forbidden, the elements don't event exist as far as > authors are concerned), but "require" user agents to support them > so they don't lose market share, render the web and such" (van > Kesteren, offlist). Using terms like "right" and "wrong" makes this needlessly moralistic. I would instead say that there is one set of elements and attributes that are allowed in conforming documents, and strict superset of this that must be supported by conforming user agents. One could take this as an application of the IETF principle of "be lenient in what you accept and strict in what you send". It's not a moral issue, just a case of features that are needed for compatibility but that would not be recommended as good practices for new content. Again, by using such a moralizing tone, I assume you meant to make this proposition sound foolish. > 4. We then freeze the standard and let evolve in two ways only: (1) > by bug fixing and (2) by incorporating new components once they are > actually being used - "we cannot afford to change behavior, nor can > we afford to remove features from browsers once they are > used" (Hickson). I don't agree with this. Changes should include: - Correcting errors - Adjusting to match what is interoperably implemented, even that contradicts what past spec versions said - Adding new elements/attributes/APIs in a compatible way - Possibly moving things from being conforming for documents to just being things that implementations must support, if there is a good reason to remove them from conformance I don't think new features would have to actually be used before they can get in the spec, but obviously things that are used would be candidates. There is also the W3C requirement of two interoperable implementations to become a full REC, so in that sense, any spec feature would have to at least be implemented before it is final. > This means that if, for instance, Microsoft implements some new > element in IE and people start using it, it will automatically be > included in the standard and all the others will have to follow. If indeed lots of people use it, then other browsers will have to follow anyway, so better to have a spec than require us to reverse engineer IE and each other. Anyway, if your proposal was meant to be an exercise in sarcasm, I hope you will make your point more directly. Regards, Maciej
Received on Tuesday, 10 April 2007 10:53:37 UTC