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, 6:50 PM

> |
> |   > (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.
>
> yes, it would be nice to see at least some modules implemented.
> But I expect that Microsoft will implement all modules, or I am wrong?

We will implement whatever modules are appropriate for the market.

> (otherwise, I don't know *who* will implement all modules)

Perhaps no one.  That's part of the point of modularization.  Different
modules for different markets etc.  No one company is expected to implement
all of them.  However, for each module, there should be at least one company
that implements it, or else the module should not have exited CR.

> |
> |   > 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.
>
> But I have heard that there is no CSS2 testing suite, and tests will be
> available only for CSS3 (when CSS3 is ready)
> CSS3 is not ready. No (official) tests for CSS2.

Yes, that is the present state of affairs.

> How do you suggest to fix CSS2 (or 2.1) in this case?

If there were to be a CSS2.1, there would need to be a CSS2.1 test suite.

> |   > 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.
>
> ok. But sometimes "problems with CSS2" are just problems of one
> implementation, it's hard to say wether CSS2 itself has something wrong.

Err on the side of pointing out too much, rather than pointing out too
little.  If you feel like something is wrong in CSS2, say so, and hopefully
the WG won't take it too personally ;-).

> By the way, is there any possibility to have some kind of web service when
> you provide URL and get back rendering from MacIE

That would certainly make an interesting web service.  I suppose you could
do that with any browser on any device as a _service_.  Sounds like a market
opportunity...

> (your "Talisman" engine)?

_Tasman_

as in the explorer who "discovered" Tasmania.

Or the name of the street where the rendering engine was created.

> As I mentioned, I don't have Mac, but it seems I need to check some tests
> with Mac IE. For example HR/DIV test I have is rendered wrong by IE6,

Presumably this is a _styled_ HR/DIV test?  Because if it isn't then it is
difficult to make that strong a statement as to how HR/DIV should be
rendered.

> but
> rendered correctly by MacIE5 (friend did screenshot for me). To be precise, I
> thought that it's rendered correctly until I did a fix for test (correction
> for CSS) and achieved *good* rendering by Konqueror and acceptable for
> Mozilla. And now have no idea - if I broken MacIE rendering or not...

Or all may be rendering it "correctly" as much as HTML4 permits.

> |   > 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.
>
> Yes, I found this clarification today in CSS2 errata.
> Why do I think that box should be rendered vertically with margin: auto?
> Because it's quite logical.

Frankly I always thought that using the "auto" value to achieve centering
was a gross hack, and not obvious at all - I can't count the number of times
I've had to explain the use of margin-left:auto;margin-right:auto as a
substitute for <center>.

> As far as I know, CSS has taken some good parts of DOM-JS manipulations and
> implemented it as CSS rules (HOVER, for example)

True.

> Ok, yes, I think that amrgin: auto is rather confusing.
> May be., there should be something like
> vertical-align: center
> and
> horizontal-align: center | left | right
> I am interested here in blocks.

Yes, or perhaps 'block-align'.

> Analyzing HTML generated by FTP packages (Quark, Adobe InDesign), I found
> that they use very easy approach - position everything in absolute
> coordinates.

Easy, but inflexible.  Positioning does not translate very well to different
resolutions, different devices.  Achieving proper "liquid" layouts is much
more challenging.

> Yes, you limit potential auditory in this case, limit potential usage of such
> HTML - but this works.
> Another approach - is to use tables everywhere.
> Well, this came from *old Netscape*, but unfortunately became very widely
> used practice. (do I need to tell here that this was the way how IBM has
> built Olympics.com site?)

Hmmm - was that the site that was sued for being inaccessible?

> There is only one way to *cure* both approaches - clean, reasonable layout
> based on block, inline-block and inline elements (SPAN, DIV in HTML)
> (I will be very grateful to you if you can explain *how* I can center box
> vertically, if margin: auto doesn't do the trick)

Like I said - there is no _good_ solution currently. (the combination of
position:fixed and display:table-cell not being a good solution).

> |   > 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.
> |
>
> No, I render to:
> http://htmltests.enddeluxe.de/CSS_blocks4_w3.html
> It was validated by validator correctly:
>
http://validator.w3.org/check?uri=http%3A%2F%2Fhtmltests.enddeluxe.de%2FCSS_
blocks4_w
> 3.html&charset=%28detect+automatically%29&doctype=Inline
>
> Document Type:
> XHTML 1.0 Transitional
> Root Namespace:
> http://www.w3.org/1999/xhtml

MacIE5 does not claim to support XHTML.
Thus this is an invalid test for MacIE5.

> |   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.
>
> Yes, that's exactly layout by MS IE.
> And Mozilla/Konqueror layout it as
> 1
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9
>
> Due to the fact that TD is { display: block }

Which, is specifically discussed in CSS1 as something which is not
necessarily supported for HTML, since CSS1 does not define table formatting.

> |   > 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.
>
> what a pity :-(
> Anyway, it would be nice to hear comments from you now.
>
> I understand that this example is somewhat "synthetic"

Worse, it still does not pass the CSS validator.

> |   > 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/>
>
> But are people *without* Mac accepted on this list?

Absolutely.

> I know that Mac community is rather closed...

Now that's a rather closed minded way to approach a community. ;-p

> |   In addition, you may send _web_standards_ problem reports about either
> |   IE/Mac or IE/Windows to:  wasp@microsoft.com
> |
>
> Thanks.
>
> P.S. May be, this Puzzle test shuld be re-written, in some way, to make it
> more clear and less confusing. And "close" to real life.

Indeed - it lacks a key feature of a good test, which is a proper prose
description of the expected results.

Tests should be valid (pass the HTML _and_ CSS validators), short, simple,
and either have the results be self-explanatory, or contain a simple prose
description of the expected results.

The CSS1 test suite is a good example, as are most of the tests on David
Baron[1] and Ian Hickson's[2] sites.

Regards,

Tantek

[1]
 http://www.people.fas.harvard.edu/~dbaron/css/test/results

[2]
 http://www.bath.ac.uk/%7Epy8ieh/cgi/listsuites.pl


----------------------------------------------------------------------------
Coding is not a crime.                                       http://eff.org/

Received on Sunday, 21 October 2001 04:11:18 UTC