Can a div's width expand to fit content's width?

On 2008-04-09, Dave Rado <dave.rado (AT) dsl (DOT) pipex.com> wrote:

Hi Ben

On 9 Apr, 21:43, Ben C <spams... (AT) spam (DOT) eggs> wrote:

You need a shrink-to-fit container, which means a float or display:
table, table-cell or inline-block.

Most of those don't work in IE and inline-block doesn't in Firefox 2.

It looks like you also want the box centered in which case float is out.

See

http://netweaver.com.au/alt/shrinkTo...ingShrinkToFit....

which has a possible workaround for IE.

Yes, floats are out of the question because as you say, it needs to be
horizontally centred. It bugs me that W3C don't think the ability to
centre floats is worthwhile - it makes them seem rather out of touch,
to me.

More useful would be if you could set width: greedy or width:
shrink-to-fit on any block-level element.

Then you wouldn't have to use float or table-cell etc. just for the
shrink-to-fit side-effect and then have to work around the effect so to
speak.

I think something like this has been proposed for CSS 3.

But centre floats would be interesting-- presumably you'd interrupt each
line either side of the float.

I've got it working using tables, now - by making a table's background
colour provide the drop-shadow and then offsetting a div within the
table. It works great, but it uses two single-cell tables, one to
provide the drop-shadow with a dynamic width, with an offset div
inside that, and then a second single-celled table within that div to
provide the vertical centring. Bit clunky but it works (see my mock-up
at http://tinyurl.com/5k8hdy).

Re. the workaround you linked to for the fact that IE doesn't support
display: table, I'm not sure whether it can be made to work in this
context - part of my problem is that I don't really understand the
workaround. See my failed attempt to get it working at
http://tinyurl.com/6kvjtn , which works in Firefox but not in IE.

Can you see any way to tweak the code in my mock-up at
http://tinyurl.com/6kvjtn so that the banner looks the same as the
mock-up at http://tinyurl.com/5k8hdy in all browsers?

I don't know anything about IE so can't help you with that.

On 2008-04-10, Dave Rado <dave.rado (AT) dsl (DOT) pipex.com> wrote:
[...]

Why does Dreamweaver give you an xhtml transitional doctype by default
then?

Does it actually generate valid xhtml?

On 10 Apr, 21:39, Ben C <spams... (AT) spam (DOT) eggs> wrote:

On 2008-04-10, Dave Rado <dave.r... (AT) dsl (DOT) pipex.com> wrote:
[...]

Why does Dreamweaver give you an xhtml transitional doctype by default
then?

Does it actually generate valid xhtml?

Yes.

Dave

Hi Jonathan

On 10 Apr, 19:11, "Jonathan N. Little" <lws4... (AT) central (DOT) net> wrote:

Well since they are most likely being incorrectly served as text/html,
yes. Also since most likely your pages are semi-xhtml a little parsing
with sed could fix them in a flash. I am sure someone here knows of an
xhtml stripping utility...

At the very least don't perpetuate your mistake by continuing to create
your new pages as xhtml...

I still don't understand what problems it will cause me that are
serious enough to justify changing back.

Dave

Dave Rado wrote:

Hi Jonathan

On 10 Apr, 19:11, "Jonathan N. Little" <lws4... (AT) central (DOT) net> wrote:

Well since they are most likely being incorrectly served as text/html,
yes. Also since most likely your pages are semi-xhtml a little parsing
with sed could fix them in a flash. I am sure someone here knows of an
xhtml stripping utility...

At the very least don't perpetuate your mistake by continuing to create
your new pages as xhtml...

I still don't understand what problems it will cause me that are
serious enough to justify changing back.

Okay, if you do xhtml *correctly* here is why. Point any version of IE
to this page...

http://www.fingerlakesbmw.org/test/xhtml.php
XHTML Properly Served


--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

In article
<e6537cfd-8743-42e3-90ac-a3d82fd40ba8 (AT) p39g2000prm (DOT) googlegroups.com>,
Dave Rado <dave.rado (AT) dsl (DOT) pipex.com> wrote:

On 10 Apr, 16:16, "Jonathan N. Little" <lws4... (AT) central (DOT) net> wrote:

Any reason why you are using XHTML? Bet not...

See for example:
http://www.w3schools.com/xhtml/xhtml_why.asp

You might like to read:

<http://www.spartanicus.utvinternet.ie/no-xhtml.htm>

--
dorayme

On 11 Apr, 02:41, dorayme <doraymeRidT... (AT) optusnet (DOT) com.au> wrote:

You might like to read:

http://www.spartanicus.utvinternet.ie/no-xhtml.htm

Another good read is:
http://www.webdevout.net/articles/beware-of-xhtml

Okay my development site has now all been converted to valid html
4.01.

Thanks all.

Dave

Dave Rado wrote:

On 11 Apr, 02:41, dorayme <doraymeRidT... (AT) optusnet (DOT) com.au> wrote:

You might like to read:

http://www.spartanicus.utvinternet.ie/no-xhtml.htm

Another good read is:
http://www.webdevout.net/articles/beware-of-xhtml

Okay my development site has now all been converted to valid html
4.01.

Thanks all.

Not that we put a gun to your head...well we kind'a did...but you will
find it is a smart move in both the short and long term. I don't think
xhtml is going anywhere anytime soon, if at all.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

On Apr 10, 8:35 pm, Dave Rado <dave.r... (AT) dsl (DOT) pipex.com> wrote:

Floats don't meet my requirement for reasons discussed earlier in the
thread (the boxes have to be shrink-to-fit *and* centred). I've got it
working using tables though.

AFIAK you cannot reliably do it by CSS alone because of different
quirks on different browsers. It also very difficult to do because of
official by very silly treatment of overflow:auto. It is being taken
as kind of overflow:remainder, so "take all space what rest" while it
should be, as the name implies, "take exactly how much space you need
to accommodate the current content but not a pixel more".

I would stay with one cell table to keep things cross-browser
compatible and reliable.