- From: Tantek Celik <tantek@cs.stanford.edu>
- Date: Wed, 17 Oct 2001 17:22:38 -0700
- To: Stuart Ballard <sballard@NetReach.Net>
- CC: Vadim Plessky <lucy-ples@mtu-net.ru>, Bjoern Hoehrmann <derhoermi@gmx.net>, "www-style@w3.org" <www-style@w3.org>, "css2-editors@w3.org" <css2-editors@w3.org>
From: Stuart Ballard <sballard@NetReach.Net> Subject: Re: "inline" elements in CSS2 box model, and "inline-block" in CSS3 Date: Wed, Oct 17, 2001, 4:24 PM > Tantek Celik wrote: >> >> a. we publicly introduced 'inline-block' over two years ago >> in the 16 Sep 1999 UI for CSS WD: >> >> http://www.w3.org/TR/1999/WD-css3-userint-19990916#display >> >> b. we implemented display:inline-block in IE5/Mac and IE6/Windows. > > Eek! I thought that w3c policy was that anything introduced in a WD was > recommended not to be implemented in a released product, because of the > risk that a later version of the specification would change the meaning > and break products that were already "in the field". I don't know where that policy is written down - but yes, that's about right is my understanding. I believe that it is/was expected that things in last call WDs were fair game from the perspective of needing implementation experience etc. - which I think has now moved to "CR". In this case, the notion of "inline-block" formatting existed even before CSS1 - one might say that it was a fairly obvious omission (just look at how CSS1 bends over backwards to talk about replaced elements without really defining what that means). Essentially, how the default/defacto layout of IFRAME, IMG, TEXTAREA, BUTTON, SELECT lists, and several other HTML tags have already well constrained how "inline-block" works to the point of not only providing enough to be able to implement it, but for it to be very silly for CSS to do anything other than specify what already exists. Now, as far as getting this "well known/understood" concept of "inline-block" into a REC - that's another matter... > I believe that Mozilla implemented a pre-final version of the "opacity" > property under the name -moz-opacity for this very reason. I don't think > they were aware of anything specific that was going to change, but since > opacity has never been in a final specification, its spec shouldn't be > limited by released browsers. In this case, 'opacity' is a fairly new concept to the web, and so it was appropriate to prefix a prototype implementation. > (I'm sure that Mozilla is also guilty of this in some other areas, so > I'm not picking on any particular vendor here) And certainly they wouldn't be the only vendor guilty of this, even if they were. Tantek
Received on Wednesday, 17 October 2001 20:20:32 UTC