- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 10 Apr 2007 11:16:12 +0000 (UTC)
- To: Henrik Dvergsdal <henrik.dvergsdal@hibo.no>
- Cc: public-html@w3.org
On Tue, 10 Apr 2007, Henrik Dvergsdal wrote: > > 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. The "undocumented, unspecified, frozen set of bugs" to which I referred was the hypothetical set of bugs that a versioned browser with no further updates would introduce; I didn't mean to imply anything about my preferred development model for the specification. (Incidentally, feel free to call me "Ian" or "Hixie". Also, it's considerd good practice in W3C mailing lists to cite the actual e-mail in question using an e-mail to the archives, so that others can read quotes in context.) My personal preference, and also the model that the WHATWG has been using, is to balance compatibility with existing content, good logical consistent design, the needs of authors, and the needs of all the various implementors when creating the specification. It's not a matter of trying to specify exactly what one particular browser does, nor is it a matter of ignoring the legacy content, nor is it a matter of considering author needs paramount, or any other extreme. It's a matter of careful design, research, and judgemental calls, all based on the design principles which Maciej and others have written up in the wiki: http://esw.w3.org/topic/HTML/ProposedDesignPrinciples Some features do not need to be implemented by browser vendors, like <blackface>, and could and should be forgotten and not mentioned in the specification. Others, like <marquee> or <font>, need to be specified since they are required to browse the Web and interoperability is desired for those features, but they do not need to be allowed (i.e. while browsers have to support them, authors musn't use them). > 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). By "change behaviour" in the above quote I refer to changes from currently implemented behaviour for features that are widely used. As an extreme example, we couldn't make <tr> tags in HTML into comment syntax -- <tr> has to introduce a table row. I see no reason to freeze the specification, nor do I think that we should rely exclusively on implementations to create new features (though naturally implementation feedback is critical to the specification design process). I do not believe I have ever proposed such a radical design methodology; the text quoted above doesn't mean to imply this. > 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. There should not be any "automatically" about it, certainly. However, if a feature implemented by a browser becomes widely used, it is in our interests to study it and consider whether we should specify it (thus encouraging interoperability when others browser implement it as well). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 10 April 2007 11:16:19 UTC