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

On Wednesday 17 October 2001 22:53, Tantek Celik wrote:
|   From: Vadim Plessky <lucy-ples@mtu-net.ru>
|   Subject: Re: "inline" elements in CSS2 box model, and "inline-block" in
| CSS3 Date: Wed, Oct 17, 2001, 7:26 PM
|
|   > On Wednesday 17 October 2001 11:28, Bjoern Hoehrmann wrote:
|   > |   * Vadim Plessky wrote:
|   > |   >Therefor, I would like to propose to include (*backport* from
|   > |   > CSS3) { display: inline-block; } in CSS2 specifications.
|   > |   >It should speedup adoption of "inline-block" by 2-4 years, as
|   > |   > manufacturers of mainstream browsers, realistically speaking,
|   > |   >can add support for it within 1 year.
|   > |
|   > |   Why does this property need to be defined in CSS Level 2 in order
|   > | to be supported? Adding new features through errata is in general not
|   > | a good idea.
|   >
|   > As it's pretty well known, there is none browser on our planet
|   > supporting CSS1. (I mean, *all* of CSS1, without any bugs)
|
|   You could just shorten that statement to:
|    "there is none[sic] browser on our planet without any bugs"

well, your statement is much stronger than mine.
It affects also HTML, XML, JS/ECMAscript and DOM bugs.
I was speaking only about CSS, so it narrows scope
I think that CSS specification is pretty well defined (comparing to other 
ones, HTML in particular), so chances are pretty high that you can eliminate 
CSS bugs (but still have DOM or JS bugs)

I expect that Konqueror browser (http://www.konqueror.org), part of KDE 
project, will be fully compliant with CSS2 in 1 year time frame.
(that's why it's so important *what* is in CSS2 specification now; I doubt it 
will have CSS3 support, as some parts or CSS3 are not ready)
It depends, of course, on corporate support for this Open Source project.
If Konqueror gets at least 2-3 paid developers this or next year, I am pretty 
much confident in this statement.
|
|   So I don't really see your point.
|

It's a pity, than. I hope my statement above clarifies a little bit my 
position.
Anyway, my goal is to speedup CSS adoption on the web, and promote W3C 
standards.

|   > And CSS1 was introduced ...yehh, in 1996.
|
|   And IE5/Mac supported all of CSS1 ... in March of 2000 (over 1.5 yrs
| ago).

Unfortunately, this is not correct. Please do not see this as a flaimball, 
but IE5/Mac is not CSS1 compliant.
Ref: my http://htmltests.newmail.ru page, "Puzzle" test, from Feb. 2001
I am in process of updating my CSS testing suite, but you can find copy of 
old tests at http://htmltests.enddeluxe.de or search Google for cached copy.
Also, I can send you this test off-list as attachement.
I know that Mac IE team *was* aware of this bug, and looked through this page.
I have no other feedback, though. May be, this bug was fixed in MacIE 5.1, if 
it's released.
It may be that I will find new bugs in MacIE CSS implementation. As I 
mentioned above, I am in process of re-writing CSS tests, making them more 
*precise* and *visual*. If you can provide me e-mail address for 
communicating with MacIE team, I would be more than happy to track down bugs 
in MacIE.
Macintosh hardware is pretty expensive, I can't afford to buy Mac just for 
testing purposes. 
|
|   > So it seems none will support [all] CSS2 until early 2005 or late
|   > 2004...
|
|   Why should any browser support all of CSS2, when portions of CSS2 itself
| are still broken?  I don't think any browser will ever support "all of
| CSS2".

That's was also my point. Some parts of CSS2 need fixing.
If you think that "portions of CSS2 itself are still broken", may be W3C 
should drop it from the list of web standards?
I see 2 possibilities here:
1) fix outstanding bugs in CSS2 specification, probably via errata
or
2) announce CSS 2.1, "free of bugs"
Than browser manufacturers would be claiming conformance with CSS 2.1 (and 
note at the same time that they do not support CSS2)

As about support for "all of CSS2", see my statement above.
Konqueror will support all of CSS2.
Most likely, Konqueror/Embedded (Konq/E) will support it too ;-)
So, all Compaq iPAQs with Linux and Konq/E installed will have fully 
W3C-compliant CSS2 implementation latest end of next year. :-))

|
|   > I have no idea on Microsoft position on this, though.
|
|   Well, since it wasn't obvious:
|
|   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.

Thanks a lot for your information. I don't Mac here, but it's good motivation 
for me to download and test IE6.
|
|   > BTW: this construction, "inline-block", is quite important for correct
|   > layouting.
|
|   Strongly agreed.

Thanks!
|
|   > Current CSS2 layout definition for "vertical" block placement is badly
|   > defined and misleading.
|
|   Well, I'm not sure if I would make that strong a statement.
|
|   But I will say that it is "insufficient" - for example, for _easily_
|   achieving vertically centering effects without relying on position:fixed
| and display:table-cell hackery.

that's what I was referencing to, for example.
I expect that defining DIV { margin: auto } will position DIV block in the 
center not only horizontally, but vertically as well. 
it doesn't happen in any browser I know and tested - MS IE5, Mozilla, 
Konqueror, Opera.

I, personally, think that TABLEs are *evil*. And everyone should avoid using 
tables, if possible.
(with exception of database-centric applications, in particular, processing 
of big arrays of XML data)
So, display:table-cell is not a solution at all, position: fixed - well, what 
will happen when you resize window? Besides, IIRC it takes element out of 
normal flow.
You can achieve acceptable results with position: absolute, but it again 
takes element out of normal render flow.
|
|   > Adding "inline-block" will clarify this (a little bit :-) and make 
|   > confusion smaller.
|
|   Agreed.
|
|   > In particular, HTML export filter from word processors should benefit
|   > greatly from writing blocks as "inline-block", instead of writing
|   > unnecessary tables.
|
|   Agreed.

thanks, thanks again.
|
|   However, I don't think this should be a change to CSS2, as it is very
| much an addition.
|
|   Should, however, there be a CSS2.1 (which removed the bad/unimplemented
|   bits, and added a few simple improvements), I would be in favor of adding
|   "display:inline-block".

well, it seems a good proposal.
It would be interesting to hear what other CSS2 editors and W3C CSS board 
think about it.
If it's agreed to make CSS 2.1, more parts of CSS3 display model 
(diaplay-role, display-model) can be integrated into CSS 2.1?

CSS3 "positiong" and "tables" proposals are not ready, but "box model" module 
seems quite good to me.
May be, it's in current state can be integrated into CSS 2.1?

Commenting on CSS3 "box model": it seems it needs more integration with UI 
module.
Latest discussion on Scrollbars shows that current Box Model doesn't cover 
them. It's easy to see that Title Bar elements and Window Decorations are not 
covered as well.
 I guess it's a right time now to understand what these parts of UI need to 
add to CSS descriptions, and necessary elements can be added to Box Model.
|
|   Regards,
|
|   Tantek
|
|  
| ...........................................................................
| Tantek Çelik                                          tantekc@microsoft.com
| W3C CSS wg representative, HTML wg alternate rep     tantek@cs.stanford.edu
| Tasman Development                                    Microsoft Corporation

-- 

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 02:29:13 UTC