center/shrink to fit redux.

N

Neredbojias

To further the education of mankind, mbstevens
That exercises nicely at all sorts of different sizes.

It's one way to make a list, -pseudo or otherwise, fit space more
efficiently, and I think it beats using tables. When "inline-block"
becomes a little more normalized, I'll probably be able to improve the
stability for browsers other than "the big 3" as well.

Thanks for the feedback.
 
M

mbstevens

Neredbojias said:
To further the education of mankind, mbstevens
<[email protected]> vouchsafed:





It's one way to make a list, -pseudo or otherwise, fit space more
efficiently, and I think it beats using tables. When "inline-block"
becomes a little more normalized, I'll probably be able to improve the
stability for browsers other than "the big 3" as well.

Thanks for the feedback.
There is an issue in Fox with "Top 40 Audio", which seems to
wrap after "Top 40" at any browser size, though.
 
M

mbstevens

dorayme said:
Actually, I better keep out of this. Seems easy enough to centre
a list? But there is obviously more going on.

Yes, tables were seeming to display centered <ul>s better than CSS for a
minute there. It wasn't so much just centering as doing it as well as
a table.
I am sure I caught
a glimpse of Hume in your mark up somewhere in the thread. Now he
is an enjoyable writer...

Then you may enjoy...
http://comp.uark.edu/~rlee/semiau98/humelink.html
http://www.philosophypages.com/ph/hume.htm
 
F

fred.haab

mbstevens said:
This seems to perform better than the CSS examples that fred.habb gave.
It should be no problem to take a test of the text length for server
side generated pages, too, and spit out corrected CSS with the page. He
mentioned generating the things with javascript, too, I believe. All I
can say is -- horrors!

That's because I'm the one asking how to do it a good way... those
examples were examples of why the margin: auto technique don't work
well... they weren't examples of a good way to do it.

And I did mention JavaScript... and I do agree it would be horrible,
and said as much (using JavaScript would be a worse solution,
basically).

Yes, "em" is a better unit of measurement in this case, and it's
certainly possible to have any PHP (for example) specify the correct
value on the fly... it'd still be nice to have something that works
intuitively. margin: auto is intuitive when you think about it, it's
just there should be some way to have the bounding box shrink to the
minimum size to contain the content.

I mean, that's why images work so well... the box size IS the image
size, so setting the margins to auto always perfectly centers the
image. Floating text reduces the bounding box to just fit the
content... so they really should include something like "float:
center", or "width: minimum" along with "margin: auto" would work.
 
M

mbstevens

Yes, "em" is a better unit of measurement in this case, and it's
certainly possible to have any PHP (for example) specify the correct
value on the fly... it'd still be nice to have something that works
intuitively.

I have to agree with that.
 
F

fred.haab

mbstevens said:
Yes, tables were seeming to display centered <ul>s better than CSS for a
minute there. It wasn't so much just centering as doing it as well as
a table.

To be honest, I still don't think the word "seeming" is appropriate...
the table method still works under all but the most bizarre
circumstances. I agree that using "em" and potentially calculating the
width on the fly (in the PHP) is a solution... but it's a lot more work
than just using a table to center the list.

Moreover, now your list items won't wrap at all... if they get wider,
you end up with a horizontal scroll bar, whereas the table would
wrap...

The thing is, in a list, you don't want to wrap when there's enough
whitespace to avoid it. Using a table, the table exapands in width up
to the maximum size before wrapping... but it does wrap if it has to.

So here's what happens with your latest solution (in a general case,
using some server side calculated data, whether it's PHP or some other
back end system).

1. Get the results of some query (let's say five things).
2. Find the length of the longest line.
3. Set the style width to that length in EM.
4. Create the list markup.

However, if one of those lines happens to be very long, then you are
going to be stuck with horizontal scrolling instead of wrapping.

So you might try something like:

2.5 if the length is larger than some reasonable maximum, then use the
reasonable maximum.

Well, that's great... but what is the reasonable maximum? It depends
on the users window and font sizes! But your back-end scripting has no
idea about those values.

Moreover, not only doesn't it work in a general case, you're doing all
this extra work simply to avoid using "table" for presentation because
someone else decided it was bad, and you'll be ridiculed on
alt.html.critique because, regardless of how good your page looks, even
when resized and font-zoomed for the visually impaired, people will
mock you because you used a table for presentation.

So I agree with the philosophy to avoid using markup for presentation,
but when you can simplify things (and look, in this case it's a simple
one row, one column table, pretty hard to mess up) and have it work
right EVERY TIME, and know that it will be supported in the future
(unlike other markup that has been obsoleted by CSS presentation), then
I'm failing to see the problem.

Now, like I've been saying, ideally someone can show me a generic,
always works solution that is less cumbersome than tables... but I
simply haven't seen that yet. I want to see it, I really do. I don't
want to be a troll that just opened this debate to complain about it, I
want to see the "right" way that always works.

In other words, you see how UL works with no other presentation or
markup:
..
..
..
<body>
<ul>
<li>Item one.</li>
<li>item two.</li>
</ul>
</body>
</html>

All I want, if this list is less than the maximum width of the window,
that it be centered. Othewise, it should behave exactly as the list
shown above does when the user makes the window really small (in this
case it doesn't matter, but add a longer list item), or makes the font
big, or a combination of both...

The table handles it quite nicely with very little work.

Again, I'm not talking about a million of these on a page, I'm talking
about presentation (is there an alt.css newsgroup? I suppose I should
try there). It's a simple concept to have something like this centered
on the page and have it work for arbitrary cases of amount of text,
window size, and font size.

And no one has answered my lazy question, so just to ask again, if
anybody knows...

Is there anything the w3c is doing to address this? "Float: center"
would probably put the use of tables as presentation to an end rather
quickly.
 
M

mbstevens

Well, that's great... but what is the reasonable maximum?

With the method I presented a good maximum is not hard to find except
for pathologically odd text or window size. Under those circumstances
the rendering is not as pretty, but is easy to use and accessible, and
would render on hand held devices and specialized devices in a way that
would not confuse any of them.

simply to avoid using "table" for presentation because
someone else decided it was bad, and you'll be ridiculed on
alt.html.critique because,
regardless of how good your page looks, even
when resized and font-zoomed for the visually impaired, people will
mock you because you used a table for presentation.

That is misrepresentation of the worst sort.

Some of us actually see the _value_ of semantic markup.
There is now a huge increase in the number of devices and handhelds, and
many are confused by non-semantic markup.

It is no huge sin to use a table as you want to. We just have a way
that is better because it will display usably and accessibly (if not
prettily) everywhere and under all circumstances.
I want to see it, I really do. I don't
want to be a troll

That's the second time you've written that.
Methinks the gent protestith too much.
Perhaps you should stop misrepresenting others' motivations before
making the claim again?
 
D

dorayme

mbstevens said:
Yes, tables were seeming to display centered <ul>s better than CSS for a
minute there. It wasn't so much just centering as doing it as well as
a table.


Then you may enjoy...
http://comp.uark.edu/~rlee/semiau98/humelink.html
http://www.philosophypages.com/ph/hume.htm

Ah, yes... so that was the discussion... I should pay more
attention. Thanks for the links. What words can describe the
background colour of the first link above? No, better not say...
Is there a way to _easily_ ie. tactically use one's own
stylesheet when browsing. Probably not.
 
M

mbstevens

dorayme said:
What words can describe the
background colour of the first link above?

Acid green. Chartreuse. The color boxers see after a right to the temple.
No, better not say...
Is there a way to _easily_ ie. tactically use one's own
stylesheet when browsing. Probably not.
It is one ugly page.
 
F

fred.haab

mbstevens said:
With the method I presented a good maximum is not hard to find except
for pathologically odd text or window size. Under those circumstances
the rendering is not as pretty, but is easy to use and accessible, and
would render on hand held devices and specialized devices in a way that
would not confuse any of them.

It's not hard to find if you do scripting (either client or server
side). Why should you have to do that? Besides, I've experimented
with your method, the longest line had 56 characters on it... the ideal
"em" width was less than 20. So what's the formula? #characters/3?
That doesn't sound right... it might have something to do with the fact
that em doesn't even represent the current font size, it represents the
parent font size!

And I don't think the case has to be pathological, either... all you
need is a simple case where the one line is nearly the size of a large
window... and then shrink the window from, say, 1280 to 800... unless
you pick your maximum to fit within 800, at which point you might have
wrapped lines even though you have a lot of white space.

What you've given me is fine - I'll probably use it the way it is to
avoid using a table for markup, but it is NOT as good for presentation,
in this case, as a table would be.
That is misrepresentation of the worst sort.

Maybe. I probably shouldn't have said it, but after seeing people
ripping other sites that look quite good to your casual observer just
because it had a table was pissing me off...
Some of us actually see the _value_ of semantic markup.

I see it, it just isn't working ideally for presentation in this case.
That's the second time you've written that.
Methinks the gent protestith too much.
Perhaps you should stop misrepresenting others' motivations before
making the claim again?

No, I keep saying that because, on another group, I had a problem that
turned out to be an IE flaw (unbeknownst to me at the time), and was
promptly accused of being a troll against MS... so yes, I feel the need
to say it when I complain about something, especially in this case
where it seems like I'm beating a dead horse...

But the fact is that no one has presented a generic alternative that
works as well. That's OK, in the specific cases I'm using, I just
think it's a CSS flaw... a presentation layer that let's you ideally
center some things and not others.

One thing that bothers me was you use of words... that tables
"seemingly" rendered a special case better... but, WHEW!!! Turns out it
wasn't the case!

But, actually, it was. CSS has flaws, that's the bottom line... some
people jump to it's defense like it can do no wrong, but it's not
perfect. Using tables certainly isn't perfect - but it solves an
immediate problem (as I see it).
 
M

mbstevens

What you've given me is fine - I'll probably use it the way it is to
avoid using a table for markup, but it is NOT as good for presentation,
in this case, as a table would be.

Through your entire post you've completely ignored all the things I've
been saying about cross-device compatibility.

Which is really more important: usability/accessibility or prettiness?
 
M

mbstevens

it might have something to do with the fact
that em doesn't even represent the current font size, it represents the
parent font size!

No:
"The 'em' unit is equal to the computed value of the 'font-size'
property of the element on which it is used. The exception is when 'em'
occurs in the value of the 'font-size' property itself, in which case it
refers to the font size of the parent element. "

http://www.w3.org/TR/CSS21/syndata.html

I happened to set width (not font size) for the ul in the demo page. It
could just as well have been set for the li elements. Whatever you set
it for is set for the element, not the parent.
that element.
 
F

fred.haab

mbstevens said:
Through your entire post you've completely ignored all the things I've
been saying about cross-device compatibility.

I'm not ignoring it, I just don't think, in this case, it's that
important.
Which is really more important: usability/accessibility or prettiness?

It depends on your target audience, doesn't it?

If I were developing a public website now, I wouldn't use a table in
this case.

The table I used to center the UL in the example was extremely
simple... I wouldn't have some nested tables five levels deep to get
pixel perfect layout - it's one simple table that shouldn't confuse any
UA.

Even Lynx would do just fine with it.
 
N

Neredbojias

To further the education of mankind, mbstevens
There is an issue in Fox with "Top 40 Audio", which seems to
wrap after "Top 40" at any browser size, though.

Hmm, I'll have to check it out. Thanks for the heads-up.

I'm not completely "sold" on this system but was looking into making
'lists' more 'flexible' in html-design terms. It would be a semi-cinch
with javascript, but that's javascript. Ideally, a list would split-off
vertically, feeding equalized list-sections to the right (-or left),
filling available space. My pseudo-list-type flows horizontally, which
isn't always desirable. Anyway, it's just a test of css and its
capabilities.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,778
Messages
2,569,605
Members
45,238
Latest member
Top CryptoPodcasts

Latest Threads

Top