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

On Thursday 18 October 2001 18:08, 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: 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.

Hello Tantek!

KDE is not a company. It's a an open-source project, not owned by any company 
(and it doesn't have Management Board where some *members* can vote or make 
some decision, like GNOME project has)
Sorry for this slightly off-topic information, but I think it had to be 
clarified.  
|
|   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?

There is some ongoing work with implementing text-to-speach engine, I am not 
very familiar with its progress. And this project is out of KDE scope. As 
soon as this engine works, necessary mappings can be implemented in KHTML. I 
do not expect this to come during next 6 months, but most likely we will have 
it in 1 year time frame.
A lot, of course, depends on IBM position with Linux & OpenSource software.
IBM has very good portfolio of technologies, some of them are already going 
to open-source (JFS, for example, integrated into Linux kernel)
 There is a growing interest on Embedded market in Konqueror/Embedded.
Several companies already developing kiosk-like applications based on KHTML 
and Konq/E, and it also works on PDAs.
@media print was implemented recently, hooks for "presentation" media are 
ready as well.
Don't know about braile machine - probably, none of KDE developers have such 
one.
Now, we need to see these applications going out of these "houses", and some 
return from them will follow.
|
|   > (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?
(otherwise, I don't know *who* will implement all modules)

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

Yep! :-)
Actually, Konqueror is not even 1 year old - official launch of it was on 
Oct.23, 2000.
And I hope that 2-year old product will be pretty stable, fast and 
standard-compliant.

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

yes, I have found in it some answers to my questions, which were not 
answered after reading CSS3 and CSS2 specs.

|
|   > 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.
How do you suggest to fix CSS2 (or 2.1) in this case?

|
|   > 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.
I, personally, prefer practical approach.
You have some web design goal. You understand what should be layout and how 
you want to achieve it. Start  implementing it - and find (CSS) problem, or 
some DOM issue.

By the way, is there any possibility to have some kind of web service when 
you provide URL and get back rendering from MacIE (your "Talisman" engine)?
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, 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...

|   > 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.
As far as I know, CSS has taken some good parts of DOM-JS manipulations and 
implemented it as CSS rules (HOVER, for example)
It's possible to place box vertically calculating position from 
(document.width - width)/2 and (document.height - height)/2 (or 
window.height, however you like)
But isn't it stupid to use JS just for this?

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.
Analyzing HTML generated by FTP packages (Quark, Adobe InDesign), I found 
that they use very easy approach - position everything in absolute 
coordinates.
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?)
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)
 
|
|   > it doesn't happen in any browser I know and tested - MS IE5, Mozilla,
|   > Konqueror, Opera.
|
|   And correctly so, according to the spec.

according to errata - yes. Frankly speaking, it was not clear from CSS2 and 
CSS3 specs at all.
|
|   > 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.

But can you have position:fixed and "relative" to some lement, at the same 
time?
|
|   > Besides, IIRC it takes element out of
|   > normal flow.
|
|   Yes, but everything inside still flows inside the element.

It would be nice to see PostScript translation (for printing) for such 
elements ;-)
I was printing from MS IE last time couple of years ago, but IIRC it always 
had problems with printing of *non-standard* elements.
May be, it was fixed in current versions.
But I think using of "position" should be very careful - not everything 
possible on screen can be implemented on printer.

[...]
|   > 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).

well, if we speak about redundancy and completeness, a lot of CSS2/CSS3 
should be changed.
One of drawbacks that it still tries to keep compatibility with HTML4.
Another minus is that some GUI issues are not addressed very well.
To have *good* model (and some language which can describe this model), you 
need to define set of axioms - first. Make several propositions/theorems (and 
proove them) - second.  And proove that you haven't missed something ;-)
Easy, isn't it?
As a building blocks for CSS, we can think of different display: elements, 
and *role* which they play.
But, in my opinion, number of those elements should be reduced.
For example, can't ruby content be *generated* (and be layouted in form of 
inline/block/inline-block elements)?
I have to admit that I don't know Japaneese and never seen Ruby-like printed 
materials, but looking into specs it seems to me artificial.
You can use XML to store Ruby content, and layout it vis *standard* CSS 
methods with some code generator.
|
|   > 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.
|
ok
|   ...
|   > 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 ;-)

yes, it's very impressive!
It's a pity that Apple stopped OEM MacOS licensing, and we will not see Mac 
clones anymore. I would like to have such machine at reasonable price, just 
for MacIE testing purposes. :-)
Wether people like it or not, but Mac became a niche computer, and Apple - 
niche-oriented company. And, in some aspect, Apple is now US-only company. 
Their market share here, for example, is less than 0.5%, and the only market 
they still can sell is high-end DTP.
Such a pity :-( 
They could do much better. But there are not enough good managers in the 
world.
...
|
|   Tantek
|- Raise your standards.                      
| http://www.microsoft.com/mac/ie/

-- 

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 17:46:02 UTC