inline-block: Are things really this bad?

[otto]

Any suggestions? I want a sequence of composite "blocks" (e.g. image
and caption representing a product category) to wrap like text as a
browser is made wider/narrower. Tables are not working well for this
application. Any fixed choice of column numbers is always the wrong
choice!

I looked up about CSS block flow , found "display:inline-block;" and
thought problem solved - till I tested in IE & FF. Nightmare!!! After
*much* fiddling I have managed some code that seems to "work" robustly
in FF & IE. (example at http://mtoto.org/bits/flow-test.html). - But it
doesnt validate 'cos I had to put a <div> inside a <span>! Tomorrow I
might try using <li> in place of the outer <span> to see if that at
least avoids the div-inside-span hack.

There must be an easier way to "in-line" arbitrary blocks! If you know
it please tell me.

[Spartanicus]

"otto" <ic*****@verycool.co.uk> wrote:

Any suggestions? I want a sequence of composite "blocks" (e.g. image
and caption representing a product category) to wrap like text as a
browser is made wider/narrower.

http://www.spartanicus.utvinternet.i...h_captions.htm

--
Spartanicus

[Sander Tekelenburg]

In article
<u2********************************@news.spartanic us.utvinternet.ie>,
Spartanicus <in*****@invalid.invalid> wrote:

[...]

http://www.spartanicus.utvinternet.i...h_captions.htm

2 comments:

- Yes, iCab 3 supports inline-block

- What makes you think iCab has anything to do with KHTML? iCab has its
very own rendering engine.

This is weird. Your site is the second I see today that says iCab is
KHTML based. <http://www.publish.com/article2/0,1895,1881400,00.asp> is
the other one. I wonder where that comes from. Some confusion due to
both of them passing Acid2 at more or less the same moment perhaps?

--
Sander Tekelenburg, <http://www.euronet.nl/%7Etekelenb/>

[Spartanicus]

Sander Tekelenburg <us**@domain.invalid> wrote:

- What makes you think iCab has anything to do with KHTML? iCab has its
very own rendering engine.

Odd mistake, I knew that.

--
Spartanicus

[otto]

Spartanicus wrote:

http://www.spartanicus.utvinternet.i...h_captions.htm

Thanks for that pointer and nicely written up too. Would that work for
arbitrary content though? I would welcome your criticism of my current
solution:-

http://mtoto.org/bits/flowing-galleries.html

'fraid I havent written it up but I have commented the html source it
if you have a moment to look.

[Spartanicus]

"otto" <ic*****@verycool.co.uk> wrote:

http://www.spartanicus.utvinternet.i...h_captions.htm
Thanks for that pointer and nicely written up too. Would that work for
arbitrary content though?

To get the caption width to match the images the size of the image needs
to be specified in the CSS. There is no realistic way around that.

Other potential problems are described in the article.
I would welcome your criticism of my current
solution:-

http://mtoto.org/bits/flowing-galleries.html

I don't see the point of bothering with inline-block unless the aim is
to center the image/caption combos (your demo left aligns for me).

--
Spartanicus

[otto]

Spartanicus wrote:

To get the caption width to match the images the size of the image needs
to be specified in the CSS. There is no realistic way around that.
I was really meaning: Would your CSS work for *any* type of element not
just different width pictures - a set of tables say?
I don't see the point of bothering with inline-block unless the aim is
to center the image/caption combos
How else? I am new to CSS but float: seemed very unpredictable unless
you pre-fix the height of all elements. And it can have unexpected
side-effects on following elements in my experience. In any case...
(your demo left aligns for me).

Only cos I chose the default to left align - thats the point. This CSS
is not just crafted for one gallery with one type of content (e.g.
pictures) in mind but to provide a common framework for *all* our
galleries *whatever the content*.

With the flick of a switch (aka CSS overide) a gallery can be centered
or right aligned. E.g. the little nested gallery is in fact center
aligned - it uses the exact same CSS classes as the main gallery.

[otto]

p.s. I beleive my solution top aligns properly (even in gecko).

[Spartanicus]

"otto" <ic*****@verycool.co.uk> wrote:

To get the caption width to match the images the size of the image needs
to be specified in the CSS. There is no realistic way around that.

I was really meaning: Would your CSS work for *any* type of element not
just different width pictures - a set of tables say?

Using tables instead of the images would produce hopelessly invalid
code.

To get tables to display inline there is the "inline-table" value for
the display property. Support for this value is even worse than for
"inline-block", despite the fact that inline-table is part of the CSS2.0
rec published in 1998.

I don't see the point of bothering with inline-block unless the aim is
to center the image/caption combos

How else? I am new to CSS but float: seemed very unpredictable unless
you pre-fix the height of all elements. And it can have unexpected
side-effects on following elements in my experience.

You're right actually, inline-block coding is the most appropriate way
to code this regardless of alignment.

--
Spartanicus

[otto]

thanx. The more I look into this CSS stuff the messier it all seems.
Surely the block containement & flow model is absolutely fundamental to
any layout styling framework?

What on earth is the need for a special "inline-table"? Why not just
allow any element to be inline or cause a break?

[Spartanicus]

"otto" <ic*****@verycool.co.uk> wrote:

What on earth is the need for a special "inline-table"?

Elements generated by display:inline-table participate in the CSS table
model, elements generated by display:inline-block do not.

--
Spartanicus

[Stan Brown]

Fri, 04 Nov 2005 16:14:13 GMT from Spartanicus
<in*****@invalid.invalid>:

"otto" <ic*****@verycool.co.uk> wrote:

http://www.spartanicus.utvinternet.i...h_captions.htm

Thanks for that pointer and nicely written up too. Would that work for
arbitrary content though?

To get the caption width to match the images the size of the image needs
to be specified in the CSS. There is no realistic way around that.

IMHO this is one of the very few times where inline styles make
sense:
<div class="captionedimage" style="width:218px"><img
width="218" ... ><p>caption</p></div>

If there's something wrong with the above, I hope someone will pick
holes in it.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you

[otto]

Anyone know why "display:inline-block" appears to work on a <span> but
not on a <div> in IE?

If I use <div> for the outer elements in my experiment (at
http://www.mtoto.org/bits/flowing-galleries.html) then IE behaves as if
they were display:block (i.e. they break the line) even though they are
explicitly inline-block. This has forced me to put a <span> illegally
around the <div>s (or other block elements) that I want to flow .

Surely this cant be right? I must have got the wrong end of the CSS
stick. How should one get arbitrary xhtml elements (logical tables for
example) to flow?

[otto]

Anyone know why "display:inline-block" appears to work on a <span> but
not on a <div> in IE?

If I use <div> for the outer elements in my experiment (at
http://www.mtoto.org/bits/flowing-galleries.html) then IE behaves as if
they were display:block (i.e. they break the line) even though they are
explicitly inline-block. This has forced me to put a <span> illegally
around the <div>s (or other block elements) that I want to flow .

Surely this cant be right? I must have got the wrong end of the CSS
stick. How should one get arbitrary xhtml elements (logical tables for
example) to flow?

[Spartanicus]

"otto" <ic*****@verycool.co.uk> wrote:

Anyone know why "display:inline-block" appears to work on a <span> but
not on a <div> in IE?

http://homepage.ntlworld.com/spartan...block_hack.htm

--
Spartanicus

[otto]

Spartanicus wrote:

"otto" <ic*****@verycool.co.uk> wrote:

Anyone know why "display:inline-block" appears to work on a <span> but
not on a <div> in IE?

http://homepage.ntlworld.com/spartan...block_hack.htm

Thanx - another neat article. Unfortunately I couldn't work out how to
make this hack coexist with FF (it has side-effects on formatting that
I didnt/couldnt predict or control).

For the time being I will stick to my own hack which I claim doesnt so
much rely on bugs (IE or FF) as mitigate them - at the expense of some
(xhtml-illegal) pollution of the html. At any rate it now behaves
exactly as I expect and gives me precise and predicatable control over
formatting in both IE and FF.