Table cell width

[dorayme]

It was interesting how both methods produce the same result.

Yes, my point was that both methods produce similar results, I
was simply assuming it needed browsers to support the CSS
properly.

So you
feared the buttonize styling wouldn't work on another OS?

No, I had no fears about this at all. The intention of the URL

<http://dorayme.netweaver.com.au/buttonizedHorizList.html>

had nothing to do with OSs. That older browsers on Win did not
support inline-box is quite another matter, there are older Mac
browsers that did not either; you should see what the formerly
quite good browser Mac IE5 makes of the above: both menus appear
like DIVs down the page, not even the floated one works
horizontally.

It would probably need me to enrol you in a course on my sense of
humour to explain my quickly withdrawn remark about you and PCs
and Macs. Let's face it, you are an American and I am from a
planet light years from earth, there are some difficult gulfs.

Just in case you are interested, if you want to take this course,
which is twice weekly for 6 months, Tues and Thurs evenings 6 to
8pm, I would want payment in advance. I would deliver the
lectures with an American accent, you can have New York, Mid
Western, Californian, or Texan drawl, no extra charges for this,
part of the deal. I would appear as any of your favourite
American actors or actresses, including Donald Duck and Jessica
Rabbit (my preferences are towards the latter to test your
concentration). O, and btw, I accept $US, they are about on
parity with $Aust and especially when in big wads in plain brown
envelopes.

The only
failure was IE6, and it also as with the success of the inline-box vs
floating it failed the same way in IE6!

Actually, the inline-block does not work on IE7 either, at least
not in IE8 in compatibility mode.

I should add another way to skin the horizontal cat, just
display: inline... but this looks like a poor cousin and harder
work to adapt to my page (and keep the same look).

 

[Tim Streater]

Horizontal lists are not too hard to style and they behave pretty
well. And you can get pressed looks and all sorts of things. Not
sure they are *easier* than floated DIVs but I would be inclined
to use them instead, it is something that is more regularly done
(in navigation bars) and so there would be a lot more examples.

Here's what I ended up with:

<http://clothears.org.uk/temp/tabs-new.html>

which works quite satisfactorily. I've implemented this in my app and
saved more than 100 lines of JavaScript. Closed a few other loopholes at
the same time.

One thing I noticed while testing is that only Firefox seems to bother
giving the tabs fractional pixel widths. So as more tabs are added and
they shrink, the right-most edge of the right-most tab moves about
unless Firefox is used. Which is OK for testing but Safari is used in
production.

And don't imagine that, if this app ever got widespread use, there
wouldn't be *someone* with large numbers of tabs. Before I retired, I'd
get people coming to me and complaining that it took forever for their
Eudora to start when they rebooted their PC. Turned out they had 400 or
so emails open in tabs. Of course, each tab was by then a few pixels
wide and so it wasn't obvious that this was what they'd done. Much
clicking of the Close Tab button sorted them out.

 

[dorayme]

Here's what I ended up with:

<http://clothears.org.uk/temp/tabs-new.html>

which works quite satisfactorily. I've implemented this in my app and
saved more than 100 lines of JavaScript. Closed a few other loopholes at
the same time.

One thing I noticed while testing is that only Firefox seems to bother
giving the tabs fractional pixel widths. So as more tabs are added and
they shrink, the right-most edge of the right-most tab moves about
unless Firefox is used. Which is OK for testing but Safari is used in
production.

And don't imagine that, if this app ever got widespread use, there
wouldn't be *someone* with large numbers of tabs. Before I retired, I'd
get people coming to me and complaining that it took forever for their
Eudora to start when they rebooted their PC. Turned out they had 400 or
so emails open in tabs. Of course, each tab was by then a few pixels
wide and so it wasn't obvious that this was what they'd done. Much
clicking of the Close Tab button sorted them out.

Well, I have not got a full picture of what you are doing (it's
ok, it is probably not useful to explain) but I am a bit puzzled
as to why you want the tabs to shrink on a line rather than do
what floated list items usually do and that is wrap. Not even
sure of quite why you want to cut off the text so mu=ch, I could
understand allowing for a max em width to the list items but this
would get a few meaningful words in.

Anyway, I have really only come on to say to take note that
people using Zoom Text Only (see the Safari View menu for
example) might be seeing things you are not expecting at
different text size settings.

Me, I tend to avoid setting heights, in favour of overflow:
hidden on the immediate containers of the floats (so they 'see'
and enclose their children).

 

[Tim Streater]

Well, I have not got a full picture of what you are doing (it's
ok, it is probably not useful to explain) but I am a bit puzzled
as to why you want the tabs to shrink on a line rather than do
what floated list items usually do and that is wrap. Not even
sure of quite why you want to cut off the text so mu=ch, I could
understand allowing for a max em width to the list items but this
would get a few meaningful words in.

It's an incentive not to have too many tabs open.

Anyway, I have really only come on to say to take note that
people using Zoom Text Only (see the Safari View menu for
example) might be seeing things you are not expecting at
different text size settings.

On my to do list is to allow users to choose a font and point size,
amongst other things.

Me, I tend to avoid setting heights, in favour of overflow:
hidden on the immediate containers of the floats (so they 'see'
and enclose their children).

I did try setting that on the <ul> only to find it vanished the <li> if
there wasn't room.

 

[dorayme]

It's an incentive not to have too many tabs open.



On my to do list is to allow users to choose a font and point size,
amongst other things.

Well, maybe but should you bother, there are already many browser
controls and prefs for a user. Best to be able to accommodate
whatever a user throws at it by natural means, one such is
avoiding heights or at least using em units.

Not sure you are quite aware of what can be presented at the
moment to some viewers. Here is a screenshot (and it has nothing
to do with any particular browser though it happens to be Safari)

<http://dorayme.netweaver.com.au/justPics/disappearingText.png>

In your case, your heights are causing trouble. In the case of
the LI height you set, getting rid of it altogether would be my
instinct but you are a height-lover, I can tell, I can see
height-lovers from afar and I have nothing against them, they are
part of the human fabric, bless you. But if you specified in ems,
say

li {
....
height: 1.4em;
....
}

this would solve a problem. There would be other probs to solve
but this is a start. You might also set the same for the UL.

I did try setting that on the <ul> only to find it vanished the <li> if
there wasn't room.

That presumably would have been because of other constraints you
have.

If you remove heights on the UL and LI and just put the overflow
on the UL that starts to get things to fall into place. The
usefulness of overflow is often in respect to a secondary effect,
creating Block Formatting Context (BFC), it causes the container
whose children are floats to see them and enclose them, without
some mechanism like this, a container will be blind to what is
not in the flow. Anyway, I had a go at explaining this stuff at:

http://netweaver.com.au/floatHouse/

and esp.

http://netweaver.com.au/floatHouse/page8.php

If Ben C ever talks about this sort of thing, listen carefully,
he loves BFCs and knows all about them. I like them too and often
take them for little walks in the park. They are well behaved and
require no leads.

I see you are a bit fond of overflow: hidden; yourself, you have
it on BODY?

 

[Tim Streater]

! <g>

Well I wasn't completely serious. But I'm emulating Eudora 7.

Well, maybe but should you bother, there are already many browser
controls and prefs for a user. Best to be able to accommodate
whatever a user throws at it by natural means, one such is
avoiding heights or at least using em units.

Not sure you are quite aware of what can be presented at the
moment to some viewers. Here is a screenshot (and it has nothing
to do with any particular browser though it happens to be Safari)

<http://dorayme.netweaver.com.au/justPics/disappearingText.png>

Really? Why are the big + and - not appearing in those buttons then?
Only browser that did that to me was Opera (not that this invalidates
the point you are trying to make).

In your case, your heights are causing trouble. In the case of
the LI height you set, getting rid of it altogether would be my
instinct but you are a height-lover, I can tell, I can see
height-lovers from afar and I have nothing against them, they are
part of the human fabric, bless you. But if you specified in ems,
say

li {
...
height: 1.4em;
...
}

this would solve a problem. There would be other probs to solve
but this is a start. You might also set the same for the UL.

It might solve *that* problem, but could create others. Does the window
resize event go off when users change the text size themselves? Without
that, not sure how I could adjust the sizes of other items.

That presumably would have been because of other constraints you
have.

Oh doubtless.

I see you are a bit fond of overflow: hidden; yourself, you have
it on BODY?

I just tried taking this off in my app (not the testbed I posted a link
to). Nasty inappropriate scrollbars appeared.

You know, it might be easier if I just emailed you a .dmg.

 

[dorayme]

....

Really? Why are the big + and - not appearing in those buttons then?
Only browser that did that to me was Opera (not that this invalidates
the point you are trying to make).

Screenshot *was* from Safari, it looks like a character problem,
that is JK's department really. + would do me fine. Even
typing + on my pages using my server would get it. Either. But
not your

It might solve *that* problem, but could create others. Does the window
resize event go off when users change the text size themselves? Without
that, not sure how I could adjust the sizes of other items.

All I know is that the viewport generally does not change and
should not change when a user changes his or her text size in the
View menu, that should be left to the manual control of the user.
But, just a thought, are you aware of the difference between Zoom
Text Only and Zoom in some of these modern browsers like FF and
Safari?

Sorry to keep mentioning my writings but I did them to save
future typing (I am on a court order to help on usenet for the
rest of my natural life for crimes committed in my youth but I am
allowed to make it as easy as possible for myself - at least, so
the the judge said) I have an unfinished thing on this stuff at:

<http://dorayme.netweaver.com.au/differentEyesights/textSpill.html

Oh doubtless.


I just tried taking this off in my app (not the testbed I posted a link
to). Nasty inappropriate scrollbars appeared.

Well, that's another thing, setting widths on elements can be
fraught. You set 100% on UL and LI. Now this is the width of the
content area. Where are poor margins, paddings, borders to go? In
the modern non-quirks box model they are outside the content area
and often outside the viewport, hence the scrollbars.

Scrollbars are the sentinels of respect for individual citizens
of the HTML world. They look out for margins and paddings and
borders and give them a way to participate in the life of the
page. It is a foundational kindness towards them and I, at least,
get a lump in my throat thinking about it.

Many elements are by default (not counting borders, margins,
paddings) 100% of their container's *content* area (your BODY has
no borders or margins and likely no paddings). It is often not
necessary to give widths to elements that will stretch the whole
way anyway, auto widthwise.

Try removing all your overflows, except the one needed to let the
UL see its floated list items; so one on UL is needed. Remove the
widths of 100% from your UL and LI.

 

[Tim Streater]

Screenshot *was* from Safari, it looks like a character problem,
that is JK's department really. + would do me fine. Even
typing + on my pages using my server would get it. Either. But
not your

Odd that. I looked here:

<http://www.utf8-chartable.de/unicode-utf8-table.pl>

for a nice fat plus and minus signs, found them, and copied in the
values. Worked for me in iCab, Safari, Firefox, Chrome - but not Opera.

All I know is that the viewport generally does not change and
should not change when a user changes his or her text size in the
View menu, that should be left to the manual control of the user.
But, just a thought, are you aware of the difference between Zoom
Text Only and Zoom in some of these modern browsers like FF and
Safari?

Sorry to keep mentioning my writings but I did them to save
future typing (I am on a court order to help on usenet for the
rest of my natural life for crimes committed in my youth but I am
allowed to make it as easy as possible for myself - at least, so
the the judge said) I have an unfinished thing on this stuff at:

<http://dorayme.netweaver.com.au/differentEyesights/textSpill.html>

Yes, that's quite nice. Still, I'm not going to fiddle too much just yet
as I only have myself to please. There are still some height-related
bodges that I have to fix yet before it'll be be possible for Mr Hiram Q
Walrustitty to be let loose on it.

Well, that's another thing, setting widths on elements can be
fraught. You set 100% on UL and LI. Now this is the width of the
content area. Where are poor margins, paddings, borders to go? In
the modern non-quirks box model they are outside the content area
and often outside the viewport, hence the scrollbars.

Scrollbars are the sentinels of respect for individual citizens
of the HTML world. They look out for margins and paddings and
borders and give them a way to participate in the life of the
page. It is a foundational kindness towards them and I, at least,
get a lump in my throat thinking about it.

Many elements are by default (not counting borders, margins,
paddings) 100% of their container's *content* area (your BODY has
no borders or margins and likely no paddings). It is often not
necessary to give widths to elements that will stretch the whole
way anyway, auto widthwise.

Try removing all your overflows, except the one needed to let the
UL see its floated list items; so one on UL is needed. Remove the
widths of 100% from your UL and LI.

Right, that helped - thanks. I removed the overflow on the body and the
100% on the ul. Result: nothing (visible) happened, which is the desired
outcome.

 

[dorayme]

Odd that. I looked here:

<http://www.utf8-chartable.de/unicode-utf8-table.pl>

for a nice fat plus and minus signs, found them, and copied in the
values. Worked for me in iCab, Safari, Firefox, Chrome - but not Opera.

Well, nothing seems to induce it to appear on my machine using
your . Here are the things that work for me:

<http://dorayme.netweaver.com.au/charTest.html>

You better get feedback from others on this in case there is a
problem at my end, mysterious or otherwise. btw, yours does not
work on my Windows XP in VirtualBox either but my url lloks very
similar in IE8 to my Safari.

Yes, that's quite nice. Still, I'm not going to fiddle too much just yet
as I only have myself to please. There are still some height-related
bodges that I have to fix yet before it'll be be possible for Mr Hiram Q
Walrustitty to be let loose on it.

OK, all I can tell you about this is that I generally use heights
only *as a last resort* (when I have not figured a way to not use
height at all) in order to build my confidence that Wallrustitty
will have a pleasant enough experience. And then, usually in ems!

 

[Jukka K. Korpela]

Screenshot *was* from Safari, it looks like a character problem,
that is JK's department really.+ would do me fine. Even
typing + on my pages using my server would get it. Either. But
not your

Sorry, I've spent too much time in my virtual life outside Usenet lately
and had missed this part of the thread.

This discussion seems to be about

http://clothears.org.uk/temp/tabs-new.html

and specifically about the characters in the two buttons. I have no
difficulty in seeing them on Firefox. On IE, they appear as small
rectangles, which is the usual symptom of lack of a glyph for a
character. This isn't primarily a browser problem, though. IE is just
less capable of going thru all the fonts installed in the system.

The characters used are U+2795 and U+2796, HEAVY PLUS SIGN and HEAVY
MINUS SIGN. They are Dingbat characters, which means that they don't
have much semantics - in particular, their Unicode properties say that
they are "other symbols", not mathematical symbols. But that's not the
point; it's sometimes OK to use Dingbats.

The problem is that the characters are very new, introduced in Unicode
version 6.0. According to
http://www.fileformat.info/info/unicode/char/2795/fontsupport.htm
the Symbola font is the only font that contains them. But that's
slightly outdated information: Quivira has got them, too. But this means
that the characters exist only in fairly exotic fonts that one has to
find, download, and install separately (I don't think any sofware has
them bundled in, but there might be some specialized software with such
special fonts). Moreover, if you wanted IE to display them, you would
need to set font-family: Symbola, Quivira in CSS for the elements
containing them (such as the button elements and <span> elements where
you'd wrap them into in text).

A much more reasonable approach is to use the normal PLUS SIGN "+" and
the MINUS SIGN U+2212 (which you can write as &minus; if you need to).
The minus sign works in almost all browsing situations these days. You
can use CSS to set their font face, font size, and font weight. This is
somewhat problematic in practice, since these characters don't bold well
(their bold versions aren't much more bold than normal versions), and
increasing font size has various side effects (on line height and on the
meaning of the em unit). But these are still more manageable than the
problems with special characters.

P.S. It is never necessary or useful to use + for "+" in HTML,
unless your "+" key is broken or something.

 

[dorayme]

Sorry, I've spent too much time in my virtual life outside Usenet lately
and had missed this part of the thread.

Life away computers generally can be surprisingly distracting.

This discussion seems to be about

http://clothears.org.uk/temp/tabs-new.html
....


The problem is that the characters are very new, introduced in Unicode
version 6.0. According to
http://www.fileformat.info/info/unicode/char/2795/fontsupport.htm
the Symbola font is the only font that contains them. But that's
slightly outdated information: Quivira has got them, too. But this means
that the characters exist only in fairly exotic fonts that one has to
find, download, and install separately (I don't think any sofware has
them bundled in, but there might be some specialized software with such
special fonts).

So, there it is, the nub of the problem. Thanks. Tim will send
the cigar.

A much more reasonable approach is to use the normal PLUS SIGN "+" and
the MINUS SIGN U+2212 (which you can write as &minus; if you need to).
The minus sign works in almost all browsing situations these days. You
can use CSS to set their font face, font size, and font weight. This is
somewhat problematic in practice, since these characters don't bold well
(their bold versions aren't much more bold than normal versions), and
increasing font size has various side effects (on line height and on the
meaning of the em unit). But these are still more manageable than the
problems with special characters.

P.S. It is never necessary or useful to use + for "+" in HTML,
unless your "+" key is broken or something.

I made a table yesterday for Tim to show what I was seeing and
some of the different possible ways for a heavier looking plus:

<http://dorayme.netweaver.com.au/charTest.html>

I mention because I am reminded that the bolding - you mention
about this above -in WinIE (on my VirtualBox) is not as prominent
as on my Mac browsers; I recall having to actually compare the
bolded and unbolded on the same page to notice that IE was in
fact applying bold.

 

[Jukka K. Korpela]

I am reminded that the bolding - you mention
about this above -in WinIE (on my VirtualBox) is not as prominent
as on my Mac browsers; I recall having to actually compare the
bolded and unbolded on the same page to notice that IE was in
fact applying bold.

Testing MINUS SIGN in Times New Roman in 16px size on Win 7 with
ClearType enabled, I was unable to see any difference between normal and
bold. But this was just my old yes. When I grabbed it and studied the
pixels I found out that they are both 1px high, 10px wide, but the first
and last pixels slightly differ in color. This might result in different
visual impression to a person with a very good eyesight or a good
imagination.

The PLUS SIGN is clearly different, since its vertical part is 2px as
normal, 3px as bold. But the horizontal parts are identical.

This wouldn't have surprised me if I had remembered that bolding, as a
typographic device, was designed for serif fonts and to increase
contrasts in addition to making some lines thicker. Vertical lines get
thicker, horizontal lines don't, or they get thicker to a lesser degree.

When one needs operators like these as prominent symbols, it might be
best to use images. It's not an ideal solution, but characters have
their limitations.

Another approach is to use the characters but declare, in CSS, a list of
fonts that contain them as rather bold, such as Arial Black. It might be
difficult, though, to construct a list that produces sufficiently bold
glyphs across environments.

 

[Tim Streater]

So, there it is, the nub of the problem. Thanks. Tim will send
the cigar.

Don't smoke, sorry. I smirk from time to time, but that's another story.

 

[Tim Streater]

When one needs operators like these as prominent symbols, it might be
best to use images. It's not an ideal solution, but characters have
their limitations.

True. Then I can get them to look exactly as I desire.

 

[dorayme]

True. Then I can get them to look exactly as I desire.

To you, yes, I hope Hiram Q Walrustitty has images on in his
browser.

Seriously, in your case, the pluses and minuses have a bit of
natural meaning (plus to add a tab and minus to take it off) and
ordinary keyboard pluses and the one JK mentions for minus should
surely be sufficient and reliable.

 

[Jukka K. Korpela]

Seriously, in your case, the pluses and minuses have a bit of
natural meaning (plus to add a tab and minus to take it off) and
ordinary keyboard pluses and the one JK mentions for minus should
surely be sufficient and reliable.

Except for their visual appearance, and this might be rather relevant. I
don't see anything particularly wrong with using

<img alt="+" src="plus.png" class="pm">

together with a CSS rule that tries to make the "+" character (when
used) bold via font selection.

The possibility that the image is not rendered for some reason is not
serious in this case, provided that an appropriate alt attribute is used
- the rendering just falls back to using the "+" character.

 

[dorayme]

Except for their visual appearance, and this might be rather relevant. I
don't see anything particularly wrong with using

<img alt="+" src="plus.png" class="pm">

Or alt="add a tab" ...

I agree, nothing *really* wrong. I was just thinking that for
something so simple, the + on the keyboard, with some bold
styling looks fine for Tim's purpose.

together with a CSS rule that tries to make the "+" character (when
used) bold via font selection.

The possibility that the image is not rendered for some reason is not
serious in this case, provided that an appropriate alt attribute is used
- the rendering just falls back to using the "+" character.

In the case of some browsers, like my Safari, it does not render
the alt in lieu of the image when the image is unavailable. You
get a question mark in a small blue rectangle. FF does it
sensibly imo, it simply shows the + or whatever alt text is
there. If I recall, what FF does is beyond the call of duty, it
not being insisted up on in any of the specifications. Perhaps
some browsers have options as to how to handle alt text, I can't
see any on Safari. Hopefully all the browsers cater for screen
readers and let them read the alt text, but that is a different
matter.

 

[Jukka K. Korpela]

Or alt="add a tab" ...

Or alt="+" title="add a tab", because assistive software may give the
user optional access to information in title attributes. Besides, they
typically appear on mouseover and may act as useful explanations to
people using common graphic browsers.

I agree, nothing *really* wrong. I was just thinking that for
something so simple, the + on the keyboard, with some bold
styling looks fine for Tim's purpose.

Yes, but bolding something as simple as "+", not to mention the minus
sign, is not simple at all!

In the case of some browsers, like my Safari, it does not render
the alt in lieu of the image when the image is unavailable. You
get a question mark in a small blue rectangle.

I'm shocked. Yes, I can see that on my Safari (on Win 7), too. That's
worse than what early IE versions did: they showed an icon of a broken
image _and_ the alt text (in a tiny font).

FF does it
sensibly imo, it simply shows the + or whatever alt text is
there. If I recall, what FF does is beyond the call of duty, it
not being insisted up on in any of the specifications.

It does the right thing. The specifications do not require any specific
rendering, but they do say:
"Several non-textual elements (IMG, AREA, APPLET, and INPUT) let authors
specify alternate text to serve as content when the element cannot be
rendered normally."
http://www.w3.org/TR/html401/struct/objects.html#adef-alt

Authors of Safari may have (mis)read the somewhat obscure text before
that: "For user agents that cannot display images, forms, or applets,
this [alt] attribute specifies alternate text." Despite the poor
wording, the idea has always been that the alt attribute text is treated
as the content (hence, rendered) whenever the image is not displayed,
for whatever reason.

So should we get back the money we paid for Safari? Seriously, this is a
browser bug (or misbehavior) and not something authors can reasonably
cater for, any more than we can prepare for some browsers suddenly
starting to stop displaying the letter "z" for some unknown reason.

But in fact, Safari shows the title attribute value on mouseover, so
there's an additional reason to use alt="+" title="add a tab" in this case.

Perhaps
some browsers have options as to how to handle alt text,
Yes.

I can't see any on Safari.

Neither can I.

 

[dorayme]

2012-01-12 14:08, dorayme wrote:
....

Yes, but bolding something as simple as "+", not to mention the minus
sign, is not simple at all!

Obviously it depends on the level of perfection wanted. But I am
used to having maintained an old Ford XY for decades and making
do with whatever and this has cured me of many previously
youthful hopes of perfection in earthly matters.

I'm shocked. Yes, I can see that on my Safari (on Win 7), too. That's
worse than what early IE versions did: they showed an icon of a broken
image _and_ the alt text (in a tiny font).

My iCab and Chrome as well as Safari just show a broken icon.
Adding a title attribute, as you mention, is a good idea to
compensate for broken or poorly designed browsers. Between the
alt and the title, something should get through.

....

 

[Jukka K. Korpela]

My iCab and Chrome as well as Safari just show a broken icon.

Oh my. So Chrome is seriously broken, too. And if I change its settings
by telling it not to show any images, it draws an empty bordered
rectangle corresponding to each image, without any alt text.

Please tell me this is a bad dream.