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

From: Vadim Plessky <lucy-ples@mtu-net.ru>
Subject: Re: "inline" elements in CSS2 box model, and "inline-block" in
CSS3
Date: Thu, Oct 18, 2001, 3:32 AM

> I expect that Konqueror browser (http://www.konqueror.org), part of KDE
> project, will be fully compliant with CSS2 in 1 year time frame.

If you achieve that - I think Chris Wilson is supposed to buy everybody in
your company a beer or something.

Of course - does this mean you plan to implement all of aural style sheets
as well?  Are you going to support all the different media types?

> (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)

But the whole point of the CSS3 Modules is so that implementers can pick and
choose the modules which are appropriate for their implementations.  In
fact, it is expected that some modules will become recommendations long
before others, and even be implemented before others.

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

Ok, we'll talk again in a year then. ;-)

> Anyway, my goal is to speedup CSS adoption on the web, and promote W3C
> standards.

In this, we are in complete agreement.

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

On that page,

 http://htmltests.newmail.ru/

there is a directory listing with one subdirectory "css"

 http://htmltests.newmail.ru/css/

which is also a directory listing, but does not contain any files with the
word "Puzzle" in the name, nor does it contain any files from Feb. 2001.

Please feel free to send me exact URLs to test pages which you believe
demonstrates problems in IE5/Mac's CSS1 support.

I will stand by my statement that IE5/Mac supported all of CSS1 in March of
2000.  In addition, as I said before, all released software has bugs, and
certainly would believe it if you found a bug or two in our CSS1 support.
This does not contradict my statement that the support is there.

> I am in process of updating my CSS testing suite, but you can find copy of
> old tests at http://htmltests.enddeluxe.de

Is this the test you are referring to?

 http://htmltests.enddeluxe.de/CSS_blocks4_no_display-block.html

If so, I tried it out.  First I should note that you need to add a character
encoding to the page in order for it to validate fully.

 <http://validator.w3.org/check?uri=http://htmltests.enddeluxe.de/CSS_blocks
4_no_display-block.html>

says: "Warning: No Character Encoding detected!"

This is a relatively recent change to the w3c validator which now requires
character encodings whereas before it would validate pages without it.

I don't think this should affect the layout of the page however.

Also, note that this page uses invalid CSS:

 <http://jigsaw.w3.org/css-validator/validator?uri=http://htmltests.enddelux
e.de/CSS_blocks4_no_display-block.html>

Which appear to be mostly the result of the extended named colors that you
are using (the CSS validator doesn't have an option to validate using CSS3
drafts, e.g. the CSS3 Color draft).


However, even after all that - I seem to get the results that are expected
by the page - roughly speaking:


You should see below big numbers: 1, 2, 3, etc. in Red, Green and Blue
color. Light background
1  2  3
4  5  6
7  8  9

Dark background
1  2  3
4  5  6
7  8  9


With appropriate colors and backgrounds.

I don't see any problems.


> I know that Mac IE team *was* aware of this bug

Well, I can say that as the development lead for Tasman which is the
rendering engine we shipped in IE5/Mac, this is the first time I have seen
this page - so I am not certain who on the Mac IE team you contacted
regarding this supposed problem.

> I have no other feedback, though. May be, this bug was fixed in MacIE 5.1, if
> it's released.

As far as I can tell, it works fine in MacIE 5.0 (and MacIE 5.1 for that
matter - which did add a number of small rendering bug fixes).

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

Your best bet here would be the macie-talk list:

To subscribe send mail to MacIE-Talk-On@lists.boingo.com
To post send mail to MacIE-Talk@lists.boingo.com
To search the archives:
          <http://www.mail-archive.com/macie-talk%40lists.boingo.com/>

In addition, you may send _web_standards_ problem reports about either
IE/Mac or IE/Windows to:  wasp@microsoft.com

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

Yes, exactly.

> If you think that "portions of CSS2 itself are still broken", may be W3C
> should drop it from the list of web standards?

No - I personally think it should go back to CR, and then stay in CR until
it is fixed, and there is a test suite for it, and there are two or more
interoperable implementations of each feature.

Of course, that won't happen with CSS2, since it is already a REC.  Hence
perhaps the chance to do that with a CSS2.1.

> I see 2 possibilities here:
> 1) fix outstanding bugs in CSS2 specification, probably via errata

The CSS working group should do that, and are doing that.

 http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html

is updated fairly frequently, and as recently as a couple of weeks ago.

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

I think this is a good idea, but requires that we first find all the "bugs"
in CSS2 first.  I don't think we are yet finished finding the bugs.

> As about support for "all of CSS2", see my statement above.
> Konqueror will support all of CSS2.

Like I said, a lofty goal - I wish you luck.

And while you are attempting this goal, please point out problems you find
in CSS2 in this mailing list - that way the CSS working group can try to fix
them as soon as possible.

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

Ok, we'll speak again end of next year and see if this has come true. ;-)

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

Well, the spec _does_ say to treat margin-top:auto as margin-top:0 and
margin-bottom:auto as margin-bottom:0, so I am not sure why you would expect
vertical centering from that.

> it doesn't happen in any browser I know and tested - MS IE5, Mozilla,
> Konqueror, Opera.

And correctly so, according to the spec.

> I, personally, think that TABLEs are *evil*.

Maybe not evil, just abused.

> And everyone should avoid using tables, if possible.
> (with exception of database-centric applications, in particular, processing
> of big arrays of XML data)

A reasonable statement.

> So, display:table-cell is not a solution at all

Agreed.

> position: fixed - well, what
> will happen when you resize window?

That works fine, e.g.

body {position:fixed;left:0;right:0;bottom:0;top:0;margin:0;padding:0}

It simply resizes with the window.

> Besides, IIRC it takes element out of
> normal flow.

Yes, but everything inside still flows inside the element.

> You can achieve acceptable results with position: absolute, but it again
> takes element out of normal render flow.

Right - position:absolute does not solve the problem either.

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

Indeed.

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

If there was to be a CSS 2.1, we would have to be extremely diligent about
adding as few new features as possible.  It seems to me that display-role
and display-model (while I like the abstraction) would be too big of an
addition for a CSS 2.1.

One of the problems with CSS2 was that too much was crammed in it - kind of
like HTML 3.0.  I would hope that a CSS 2.1 would be _smaller_ than CSS2,
and avoid those mistakes.

> CSS3 "position" and "tables" proposals are not ready, but "box model" module
> seems quite good to me.

Really?  I thought there was a lot in the "box model" module which didn't
belong in it (e.g. linking and replaced content should be separated out).

> May be, it's in current state can be integrated into CSS 2.1?

Like I said, that may be too much to ask for a CSS 2.1.

...

> Thanks a lot for information on Microsoft's implementation of
> display:inline-block.
> I downloaded IE6 today, tested it a little bit, and result was quite good.
> I just want to express here that I am very impressed.

Thanks for your kind words.

> So I was really underestimating MS power giving 1 year for implementing this
> feature, it's already "here". :-)

(and a 1.5 years ago in IE5/Mac ;-)

> Have you, by any chance, implemented also display-role and display-model?

No, we have not.  Those are much bigger changes, and are still undergoing
some discussion, so we should wait until those features enter a CR draft
before implementing them.

Tantek

----------------------------------------------------------------------------
Raise your standards.                       http://www.microsoft.com/mac/ie/

Received on Thursday, 18 October 2001 14:35:38 UTC