Re: "inline" elements in CSS2 box model, and "inline-block" in CSS3

On Thursday 18 October 2001 00:22, Tantek Celik wrote:
|   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 would not be putting all eggs in one basket here.
Stuart, your statement is pretty much valid when applied to Closed Source 
software.  If you have a lot of old products "in the field", it's really 
nightmare to upgrade them, and sometimes just not possible (requirements for 
increased memory, faster CPU, newer OS, etc.).
Besides, while browsers (which you probably refer to here under "products") 
are free at a moment (not counting Opera-no-ads), there is nothing that 
prevents vendors for charging for browsers in the future.
So, it can become very costly just because of upgrade licenses.

But this is really not an issues for Open-Sourced products, in particular, 
for Mozilla and Konqueror.
For example, I upgrade my KDE appx. every 2 months, 6 times per year, and 
download new Mozilla once per quarter (4 times per year)
Implicated costs are minimal - even with $1/per hour ISP charge here, it's 
less than $1 for Mozilla assuming avg. download speed of 10MB per hour (on 
dialup)

Latest statistics on http://apps.kde.com shows, that most [Open Source] users 
have in field "released withing last 1 year" products.
For example, for 35% of visitors accounted for Konqueror, appx. 10% use KDE 
2.1 [Konq 2.1] and 25% - KDE 2.2 [Konq 2.2]. Less than 1% have "other" 
version, and most likely it's Konq from KDE CVS, not old one.
So, majority of [KDE] users upgrade to latest-released product shortly, 
within 1-2 months after release ;-)
 
|   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

I agree.
Looking into the number of bugs reported to KDE team against *misrendered* 
IFRAME, IMG,  BUTTON, SELECT elements (_exactly_  these ones!), I started 
thinking that something is going wrong.
In fact, you can see <IMG src="myimg.jpg> on many pages, with *no* indication 
what should be "width" and "height". And CSS expects width and height to be 
defined in HTML.
So, size of these elements becomes very browser-specific.
In fact, Konqueror's default stylesheet has following fallback definitions
object {
        width: 50px;
        height: 50px;
}

embed {
        width: 50px;
        height: 50px;
}

while Mozilla:
-------------------------------------
object, embed, applet {
  -moz-user-focus: normal;
}

iframe {
  background-color: transparent ! important; /* (b=49779) */
  border: 2px inset;
  -moz-user-focus: normal;
}
Opera has nothing to say about OBJECT or IFRAME in stylesheet :-((

This problem is exactly very visible when somebody places such no-size IMG in 
table/cell, and cell "auto-resizes" on its own.

probably, specifying  { width: 50px;  height: 50px; } for elements which 
*resist* to tell something about their size is not the best solution, but 
still better than having such elem. not displayed at all, making all layout 
completely screwed and problem difficult to debug.
(if I remember correctly, HTML4 says nothing about default IFRAME or IMG 
size; that why we have 1x1 transparent GIFs used for layout so widely)

| 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...
|

My Best Regards,
-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/

Received on Thursday, 18 October 2001 03:20:11 UTC