{display: inline-block } example, screenshot [Re: How is it possible to devise such a feeble system?]

On Wednesday 24 October 2001 23:39, Jesse McCarthy wrote:
|   Vadim Plessky <plessky@cnt.ru> wrote on 10/24/01 11:13:57 PM:
|   >ok, for inline-block check this example
|   >http://htmltests.newmail.ru/display-inline_block.html
|   >screenshot (MS IE6)
|   >http://htmltests.newmail.ru/display-inline_block-MSIE6.png
|   I get 404 errors on those URLs.  I don't have either of the browsers you
|   mention, so I could only make use of a screen shot (though I'm not
| certain I have anything that will display the PNG).

Sorry, I was too sleepy (2 o'clock in the night, when I found this wonderfull 
thread), correct URLs are: 
Screenshot (MS IE6)

As about PNG - MS IE, Mozilla, Konqueror, Opera are able to display it.
You can open it also with Adobe Photoshop or any decent image-editing program.
PNG (Portable Network Graphics) is a W3C standard/recommendation.

BTW: I recommend you to download and try MS IE6. It really worth upgrading 
from MS IE5.0 (which I had before)
DISCLOSURE: I am not employed by Microsoft, so it's not advertising.
In fact, I am running Linux with KDE 2.2.1, and Konqueror is my browser of 
choice ;-)

|   >|   I think what you were talking about, and this is just a guess
|   >| really, is having more than one block-level element on the same
|   >| horizontal "line".  If that's the case, why don't you float those
|   >| blocks to the left?
|   >
|   >but I need those blocks *in place*, not floated.
|   You'll have to excuse my denseness, but I'm not sure what you mean by
| "*in place*". ?

exactly where it's on screenshot.
making block 'float' you get it out of normal render-flow (word by word, one 
inline element after another, placement)
So, with 'inline-block' instead of 'inline' you have more freedom for 
formatting (width, height are respected, not ignored) while preserving line 
from line-break (if you define such element as 'block'). The rest of behavior 
of 'inline-block' element is exactly like for 'inline' element. 

As far as I can guess, putting 'inline-block' in LineText render-flow should 
increase calculated line-height (if line-height is not specified)?
Bert, what do you think about it, in respect of CSS3 Box Model?
<general description, funny>
To have something 'in place' is common sentence/word combination which means: 
"to get it here, and get it working"
Like, "to have e-commerce infrastructure in place" usually can be translated 
as "servers were setted up, contest developed, everything tested and working, 
people trained; now we are ready to proceed orders via web"
</general description, funny>

|   >You can align blocks (vertically/horizontally), incl. (?)
|   > 'inline-block'. You can't align LineText vertically, by definition.
|   > (only option I see is to use Padding, but you need to find a way to
|   > inherit container's block width/height values)
|   Sorry, I'm not sure what you mean by "LineText".


"The box model builds on the inline text model (see the CSS3 Text module 
[CSS3-text]), that describes how text is laid out on a line, including 
treatment of superscripts and bidirectional ("bidi") text."
Ref: http://www.w3.org/TR/css3-box
(in my other mail, I explained why I think that statement above is wrong, but 
we need it as a reference here)

|   >What I proposed to consider is adding possibility to have block elements
|   >inline, not breaking line.
|   Well, I'm not going to argue with you.  Honestly, I do not comprehend the
|   situation you are describing or the particular problem you are having,
| and I don't know what the advantages and ramifications of what you're
| proposing would be.

Think about modern Word Processor or Desktop Publishing program, which 
exports HTML from its native format.
Frankly speaking, all programs I know (MS Word 2000, Quark XPress, FreeHand, 
Adobe Illiustrator), with exception of KWord (http://www.koffice.org), do 
very bad job of exporting HTML.
So, my plan is: 
a) get 'inline-block' working in KHTML
b) add more layout features to KWord (in DTP mode)
c) use KWord for writing CSS tests inthe future (joke!..)
 re-write: "Use KWord for document processing, web publishing, and classical 
publishing tasks"

I think that it's right time now (or in 2002) to get rid of property file 
formats (.doc, .xls, .ppt, quark's, adobe's, macromedia's property formats), 
replace it with XML, use CSS and XSLT for rendering/formatting. Pictures 
should be either PNG (bitmap) or SVG (vector).
BTW: it's exactly what KWord does. It uses XML as internal document format, 
and exports it to XHTML or HTML with CSS2 formatting. Plus, everything is 
encoded in Unicode! ;-)
For screen rendering, KWord uses QT's (www.trolltech.com - QT library) Rich 
Text widget (engine).
Ohh, yes, have I mentioned that all this availble for free? ;-))


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

Received on Thursday, 25 October 2001 06:06:37 UTC