Can you have a hover effect on a TD in IE?

[madsgormlarsen]

I can not get hover effect on a TD to work in IE, it seams you can not
have
a hover on a td in IE?

I have treid this

body.section-2 td.current,
body.section-2 td.submenu,
body.section-2 td.bredtsubmenumellemrumhojre,
body.section-2 td.bredtsubmenumellemrumvenstre {
background-color: #ffc233;

}

body.section-2 td.submenucurrent {
background-color: #ffcc66;

}

body.section-2 td.submenu:hover {
background-color: #ffcc66;

}

and this

body.section-2 td.current,
body.section-2 td.submenu,
body.section-2 td.bredtsubmenumellemrumhojre,
body.section-2 td.bredtsubmenumellemrumvenstre {
background-color: #ffc233;

}

body.section-2 td.submenucurrent,
body.section-2 td.submenu:hover {
background-color: #ffcc66;

}

Which works in firefox, but not in IE.

Then I treid setting the hover effect on the link, like this.

a.submenulink:hover {
background-color: #ff0000;

}

But then the entire cell is not filled out.

Can you see a fix for this problem?

Se problem here http://madsgormlarsen.dk/andersen/
Mads

[Harlan Messinger]

ma************@gmail.com wrote:

I can not get hover effect on a TD to work in IE, it seams you can not
have
a hover on a td in IE?

Correct, :hover has no effect in IE with the sole exception of a:hover.
A serious deficiency.

[madsgormlarsen]

Thanks

Can one then somehow make it fill out the td cell?

Mads

[Harlan Messinger]

ma************@gmail.com wrote:

Thanks

Can one then somehow make it fill out the td cell?

Sorry, I missed where you asked that originally. If the link is the
entire content of the cell, then set display: block for the link. It
will then effectively take up the entire cell (except possibly for any
padding on the cell or margin on the link).

[Dr.Tube]

Hi Mads,

I can not get hover effect on a TD to work in IE, it seams you can not have a hover on a td in IE?
<snip>
Can you see a fix for this problem?

See Peterneds site:
http://www.xs4all.nl/~peterned/csshover.html
This might be what you're looking for...

--
Kind regards,
Xavier van Unen

[madsgormlarsen]

Thanks for the tip, but is there not a simpler solution? I have a
javascript that gives a hover effect on a tr, is there not something
like that for a td.

Mads

[Els]

ma************@gmail.com wrote:

Thanks for the tip, but is there not a simpler solution? I have a
javascript that gives a hover effect on a tr, is there not something
like that for a td.

Now I may be mistaken, but weren't you the person who after some
instructions understood how to quote when replying to a message?

--
Els http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -

[dingbat]

ma************@gmail.com wrote:

Thanks for the tip, but is there not a simpler solution?

Embed an <a> in it and set the <a>'s width to 100%
Then base all your CSS selectors around a:hover

Ugly, but gets the job done most of the time.

[madsgormlarsen]

It can be done like this,
http://activedeveloper.dk/artikler/d...?articleid=247 , with
javascript.

but woudl be nice if one could compensate fro margin and padding, and
just use css on a link.

Mads

[madsgormlarsen]

> Now I may be mistaken, but weren't you the person who after some

instructions understood how to quote when replying to a message?

Hi Els

Yes, I am guilty as charged, I am that surden someone, and I will
qoute, I promisse I will qoute. I feel ashamed of myself, I have been
sinful.

Where have you been, I have missed your participation in this
discussion. Hope you will enligtend me, on this problem.


Mads
tj 91 192

[madsgormlarsen]

Embed an <a> in it and set the <a>'s width to 100%
Then base all your CSS selectors around a:hover

Well, does not work in this case, acutally it seams to make the link
vider than the td! But in this case it is also a height problem, not a
width problem, the a:hover does not fill out the height of the TD. And
height 100% does not do anyting.

Mads

['sNiek]

ma************@gmail.com schreef:

Well, does not work in this case, acutally it seams to make the link
vider than the td! But in this case it is also a height problem, not a
width problem, the a:hover does not fill out the height of the TD. And
height 100% does not do anyting.

Add "display: block" to the style for the a-tag (you don't need the td
at all for adding layout to a page, but we all knew that right?)

--
Niek Emmen, Sitebuilder
Sebastian Webprojecten, http://www.sebastian.nl

[Els]

ma************@gmail.com wrote:

Now I may be mistaken, but weren't you the person who after some
instructions understood how to quote when replying to a message?
Hi Els

Yes, I am guilty as charged, I am that surden someone, and I will
qoute, I promisse I will qoute. I feel ashamed of myself, I have been
sinful.

Apology accepted. Now be a good boy from now on :-)
Where have you been, I have missed your participation in this
discussion. Hope you will enligtend me, on this problem.
The answer I would give, has already been given by others:
td a{
display:block;
width:100%;
}

If that still looks wider than the TD, you probably have to set some
margins and/or paddings to 0.
Mads
tj 91 192

What do those numbers stand for?

--
Els http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -

[madsgormlarsen]

Add "display: block" to the style for the a-tag (you don't need the td
at all for adding layout to a page, but we all knew that right?)

I have already added block, but there must be som margin padding which
gives a problem. I have treid to make a tabel-less css menu, but I
could not get it to work, and I have yet to find one that does.

compare these two tabel-less menu

www.eniro.dk/cimg/p.gif

http://labs.silverorange.com/images/...ate/about.html

to mine. I you scale them up, you will see that mine does a lot better.
Mads

[madsgormlarsen]

Apology accepted. Now be a good boy from now on :-)
As you can see, I am qouting wildly, so I am making amends.
The answer I would give, has already been given by others:
td a{
display:block;
width:100%;
}
If that still looks wider than the TD, you probably have to set some
margins and/or paddings to 0.

I will try that, but it looks a lot wider, and it the problem is the
height. The javascript works, but it does not really work no well with
the rest of my setup (meaning - colour coding set by body tag and css)

tj 91 192

What do those numbers stand for?

Well I figured no one would notice, it was just a quick note for
myself. But it is the car number of someone that went in and took my
neigbours lawn mover! - just in case they were steellling it. I let you
know if it was a grand theft lawn mobile :-)

['sNiek]

ma************@gmail.com schreef:

compare these two tabel-less menu

www.eniro.dk/cimg/p.gif
I asume you meant http://www.eniro.dk

http://labs.silverorange.com/images/...ate/about.html

to mine. I you scale them up, you will see that mine does a lot better.

Take a look at how the menu is built, it uses <ul> an <li> for the tabs.
You've got a perfect combination of html and css when you use that
(handheld-pc's and such will display the menu s an unordered list, which
is excellent).

Look at a page I made like:
http://www.bredeschooltilburg.nl/ind...=12&d=72&p=351

that's a similar method.

--
Niek Emmen, Sitebuilder
Sebastian Webprojecten, http://www.sebastian.nl

[madsgormlarsen]

I asume you meant http://www.eniro.dk
Well, no is was a total miss I meant

http://kalsey.com/2003/05/css_tabs_with_submenus/
Take a look at how the menu is built, it uses <ul> an <li> for the tabs.
You've got a perfect combination of html and css when you use that
(handheld-pc's and such will display the menu s an unordered list, which
is excellent).

Yes, that is indeed excellent, but you need to control the elements as
best as possible, and at the same time make the solution scalable. None
of the tabel-less solution I have seen can do that. I found myself
being rather disapointed in css, because it so dependent on the
browser, so from my experience table control is still better. Now it is
all fine about telephones and so forth, but how about OLD browsers -
what if you have a sight were there is a good chance of a win98 user
with a old browser stopping by, what will give the best result in such
a situation? Especially when were a taking about a menu, something like
a long list based on ul and li is not really better than a table? But
be asured I treid, could not get it to work. I am definatly not saying
your wrong, but I just don´t think css i quite there yet.

Mads

['sNiek]

ma************@gmail.com schreef:

I found myself
being rather disapointed in css, because it so dependent on the
browser, so from my experience table control is still better.
Hang in there, I bet your first experiences with plain old HTML were
even worse, mine were!
It's a learning-curve you have to take, and then there's sun, light,
beauty, bottles of beer that never empty...
sorry it's almost weekend :-)
Now it is
all fine about telephones and so forth, but how about OLD browsers -
what if you have a sight were there is a good chance of a win98 user
with a old browser stopping by, what will give the best result in such
a situation? Especially when were a taking about a menu, something like
a long list based on ul and li is not really better than a table?
Users with old browser still see the <UL>-formatted list, so they can
read the page. You can't expect that drivers with cars from the 1920's
can keep up on the freeway!
But
be asured I treid, could not get it to work. I am definatly not saying
your wrong, but I just don´t think css i quite there yet.

As said, hang in there!

--
Niek Emmen, Sitebuilder
Sebastian Webprojecten, http://www.sebastian.nl

[madsgormlarsen]

Hang in there, I bet your first experiences with plain old HTML were
even worse, mine were!
It's a learning-curve you have to take, and then there's sun, light,
beauty, bottles of beer that never empty...
sorry it's almost weekend :-)

Well, I would be more optimistic if I could find an exsample that
works. The two exsamples I have given are tabel-less, and based
totattly on css, but none of them scale very well. All css based
menu´s I have seen either dont scale at all, or they totally screw up
the design as soon as you doo. - (or they are very simple and without
submenus)

You can try your own menu, if you scale it once, then the menu divides
in to two rather confusing lines. Compare that to mine, you can make it
as big as you want, scales perfecly to any size. Yes, there is a good
reason to want to make tabel less menu, but to me, being able to scale
is a major part of the advantage of text based menus.

Mads

['sNiek]

ma************@gmail.com schreef:

Hang in there, I bet your first experiences with plain old HTML were
even worse, mine were!
It's a learning-curve you have to take, and then there's sun, light,
beauty, bottles of beer that never empty...
sorry it's almost weekend :-)

Well, I would be more optimistic if I could find an exsample that
works. The two exsamples I have given are tabel-less, and based
totattly on css, but none of them scale very well. All css based
menu´s I have seen either dont scale at all, or they totally screw up
the design as soon as you doo. - (or they are very simple and without
submenus)

It depends on how the width of the div's are defined, if you use
percentages, the site will scale allright.

You still can put the construction od the site in one table, as I did in
my example (http://www.bredeschooltilburg.nl/ind...=12&d=72&p=351)
That's a good way to start, if you make the cell containing the UL-based
menu liquid (I used exact measures) the site will scale pretty good.

Remember: you don't build a CSS-only site, you use CSS to define the
layout of tags like div, h1, h2, h3, p, img and td as well.

You can try your own menu, if you scale it once, then the menu divides
in to two rather confusing lines.

? Don't know what you mean. But hey that could be the
never-empty-bottle-off-beer working :-)

--
Niek

[madsgormlarsen]

>

http://labs.silverorange.com/images/...ate/about.html

to mine. I you scale them up, you will see that mine does a lot better.

Actually this is the best one I have seen, (
http://labs.silverorange.com/archive.../updatedsimple) is
scalable, to a large extent. But I endede up having some trouble -
acually almost the exact same problems I have now with my table version
- This was the trouble I had, and could not find a solution for. I
wrote about the trouble on silverorange.com/ .

"I have altered the css a litle, to give a darker color to the selected
subject in the submenu. I have gotten it work like I want in firefox,
but unfortunaly it does not work in IE. Also it does not work when you
enlarge the text a little. Any suggestions on how to do this?"

Which I could show you, but just dont have a version of my site at that
stage.

Mads

[madsgormlarsen]

You can try your own menu, if you scale it once, then the menu divides
in to two rather confusing lines.

? Don't know what you mean. But hey that could be the
never-empty-bottle-off-beer working :-)

More likely it is my bad english that gives some confusement, go to
text size in your browser, and enlarge the text, as a person with a bad
vision would do, then go to my site and try the the same.

Mads

[madsgormlarsen]

Se problem here http://madsgormlarsen.dk/andersen/

Mads

['sNiek]

ma************@gmail.com schreef:

You can try your own menu, if you scale it once, then the menu divides
in to two rather confusing lines.
? Don't know what you mean. But hey that could be the
never-empty-bottle-off-beer working :-)

More likely it is my bad english that gives some confusement,'

That's allright, my English isn't that good either.
go to
text size in your browser, and enlarge the text, as a person with a bad
vision would do, then go to my site and try the the same.

You mean that the link-text is placed on two lines like:

*normal mode*
This is the link

*enlarged mode*
This is
the link

That's not such a big problem, is it? As long as people with bad vision
can read it, it's fine.
My wife has 55% vision, she doesn't complain about stuff like this,
putting font-size in px is a big problem for her, saw that you did that
right.

Cheers.
--
Niek

[madsgormlarsen]

> That's not such a big problem, is it? As long as people with bad vision

can read it, it's fine.
My wife has 55% vision, she doesn't complain about stuff like this,
putting font-size in px is a big problem for her, saw that you did that
right.

She can use firefox, it does not respect px, and will enlarge the text
even if in px. But all the same, I would refer it to work in IE aswell.
Cheers

[madsgormlarsen]

Add "display: block" to the style for the a-tag (you don't need the td
at all for adding layout to a page, but we all knew that right?)

There is a discussion about that here
http://groups.google.com/group/comp....ed71b1b8c5784a

The guy named mason pretty much sums up my view on the point.

CAH

['sNiek]

ma************@gmail.com schreef:

She can use firefox, it does not respect px, and will enlarge the text
even if in px

Or any other browser than IE, but she's a very stubborn lady :-)
--
Niek

[Alan J. Flavell]

On Sat, 13 Aug 2005, 'sNiek wrote:

ma************@gmail.com schreef:

She can use firefox, it does not respect px, and will enlarge the text
even if in px

Or any other browser than IE, but she's a very stubborn lady :-)

If she won't toss IE in favour of a web-compatible browser (which
would be my invariable advice), then she should visit IE's menu:

Tools> Internet Options> Accessibility

, where she will find, inter alia:

[ ] Ignore font styles specified on web pages

[ ] Ignore font sizes specified on web pages
If she's more ambitious, she could also try

[ ] Format document using my style sheet [C:\mystyle.css ]
(to the best of my understanding, turning this option on in MesSIE
also has the effect of completely disabling the author style sheet.)

Hope this helps, tot ziens

['sNiek]

Alan J. Flavell schreef:

If she won't toss IE in favour of a web-compatible browser (which
would be my invariable advice), then she should visit IE's menu:
I know, but like I said, she's very stubborn (I can't convince her even
though I'm a sitebuilder)

Tools> Internet Options> Accessibility

, where she will find, inter alia:

[ ] Ignore font styles specified on web pages

[ ] Ignore font sizes specified on web pages
Oh yes, but that would really fuck up the layout, and that really is a
pitty: doesn't give a nice surfing experience


If she's more ambitious, she could also try

[ ] Format document using my style sheet [C:\mystyle.css ]
(to the best of my understanding, turning this option on in MesSIE
also has the effect of completely disabling the author style sheet.)
That would really mess things up, for some people it would be a great
help though, but then again: there better software for that. My wife
isn't that handicapped.
@work she has a 21 inch screen with 800x600 display, strange experience
watching that.

Hope this helps, tot ziens

Houdoe en bedankt :-)

--
Niek

[Alan J. Flavell]

On Sat, 13 Aug 2005, 'sNiek wrote:

Alan J. Flavell schreef: [...]

(to the best of my understanding, turning this option on in MesSIE
also has the effect of completely disabling the author style
sheet.)

That would really mess things up,

It would wreck the author's layout, certainly; but if we're talking
about a properly-made web page (where all substantive content is in
the HTML part, and the CSS stylesheet is a genuine presentation
proposal), I think it's fair to say that when the presentation
proposal is proving actively harmful to a particular user, then
overruling the presentation in favour of accessing the substantive
content is a user action which is entirely within the spirit of the
WWW.
for some people it would be a great help though, but then again:
there better software for that. My wife isn't that handicapped.

OK, it won't suit everybody: it was only an in-principle suggestion,
which anyone is free to take or not, according to their circumstances.

As it happens, I've had two unsolicited emails "out of the blue",
thanking me for mentioning on a web page that IE's font size override
is not on the font menu, but on the accessibility menu. I rarely get
so many as two unsolicited personal emails about any individual point
which I mention on a web page, so I came to the conclusion that this
is something about which folks are very likely unaware until it's
pointed out, and therefore worth mentioning whenever the occasion
arises. It might prove useful to someone else who's reading this
(although I stand by my personal view that IE is fit for nothing more
than running Microsoft Update, and for web browsing I'd use a web
browser instead. A pity that some commercial "web" sites prove to be
proprietary pages that don't work with a web browser, but only with
MessSIE).

all the best

['sNiek]

Alan J. Flavell schreef:

I think it's fair to say that when the presentation
proposal is proving actively harmful to a particular user, then
overruling the presentation in favour of accessing the substantive
content is a user action which is entirely within the spirit of the
WWW.

Can't diaagree with that.

for some people it would be a great help though, but then again:
there better software for that. My wife isn't that handicapped.

OK, it won't suit everybody: it was only an in-principle suggestion,
which anyone is free to take or not, according to their circumstances.

As it happens, I've had two unsolicited emails "out of the blue",
thanking me for mentioning on a web page that IE's font size override
is not on the font menu, but on the accessibility menu.

On occasion I get e-mails from visitors that they can't read the webpage
because the font size is about 2px small, I have to point out that they
have to restore the settings in the font-menu. Because of MSIE we have
to use bleeding em´s to have scalable type in MSIE.

--
Niek

[Alan J. Flavell]

On Sat, 13 Aug 2005, 'sNiek wrote:

On occasion I get e-mails from visitors that they can't read the
webpage because the font size is about 2px small, I have to point
out that they have to restore the settings in the font-menu. Because
of MSIE we have to use bleeding em´s to have scalable type in MSIE.

Huh? em units (or percent, which is in effect the same thing, and
allegedly provokes fewer bugs in MesSIE), are my preferred choice of
unit without the slightest reference to MesSIE. Readers are expected
to configure their browser so that their 1.0em size is their own
comfortable choice for reading body text. Any reader who complains
that 1.0em is the wrong size gets told they haven't properly adjusted
their browser.

What other units could make any kind of sense - for display on a
device whose characteristics you don't know, which almost certainly
isn't calibrated against a physical size - and for use by a reader
whose eyesight is unknown to you? There's no other units in CSS which
make any kind of sense, honestly.

(Sure, the reader also needs a defence mechanism against those idiot
deezyners who try to set body text way down below 0.8em. Thank
goodness for Mozilla's minimum font size configuration option).

['sNiek]

Alan J. Flavell schreef:

What other units could make any kind of sense - for display on a
device whose characteristics you don't know, which almost certainly
isn't calibrated against a physical size - and for use by a reader
whose eyesight is unknown to you? There's no other units in CSS which
make any kind of sense, honestly.

I honestly would prefer px or pt, it´s the designers job to present the
webpage in a readable format. Indeed, there are designers who use a very
small font-size: shoot them (or send them an e-mail)!

There are enough possibilities to adjust the font-size in good, valid
browsers, so why wouldn't a designer/webbuilder use px's to present
their design? If it results in readable text, it's just fine.

And btw, I find it a horror to put the text in the right em's to
translate the photoshop-manufactered design to html/css.

Cheers,
--
Niek

[Beauregard T. Shagnasty]

'sNiek wrote:

There are enough possibilities to adjust the font-size in good,
valid browsers, so why wouldn't a designer/webbuilder use px's to
present their design? If it results in readable text, it's just
fine.

I'm an old guy with really poor vision, and only have Internet
Explorer. My text size is set to Largest so I can at least try to read
the sites I go to. Unfortunately, yours is set in stone at 10px and I
can't increase it or read it, so I'll just go somewhere else.

Actually, that's not true (except the old guy part), but it will point
out to you what will happen with a goodly portion of the surfing public.

--
-bts
-This space intentionally left blank.

[Alan J. Flavell]

On Sat, 13 Aug 2005, 'sNiek wrote:

Alan J. Flavell schreef:

What other units could make any kind of sense - for display on a
device whose characteristics you don't know, which almost
certainly isn't calibrated gainst a physical size - and for use by
a reader whose eyesight is unknown to you? There's no other units
in CSS which make any kind of sense, honestly.
I honestly would prefer px or pt,

But even if those made any sense in the situation that you've quoted,
the fact is that they aren't implemented to specification by browsers.
The same nominal pt size of text string comes out at completely
different physical sizes on my laptop, on my old desk PC+CRT, and on
my new desk PC + panel. According to the CSS specification, the
physical sizes of the string have to be identical. It makes no sense
to specify things in units that don't work - even if they made any
sense in relation to the other criteria which I mentioned, which I say
that they do not. A similar argument applies to CSS px units.
(Don't confuse them with physical pixels).
it´s the designers job to present the webpage in a readable format.
It's the designer's job to communicate some substantive content to
their readers: in the course of that, they make some presentation
proposals that make reasonable sense in some range(s) of presentation
situation. It's also the designer's job IMNSHO to arrange matters so
that their design does not fall into a snivelling heap when user
requirements fall outside of - maybe way outside of - the author's
plans for presentation situation. So-called "flexible design".
There are enough possibilities to adjust the font-size in good,
valid browsers,

There ought not to be: pt (or mm or inch etc.) sizes are absolute
physical quantities. If they were properly implemented, then there
would be no way of modifying them - one could put a ruler on the
display, and know exactly what the size of the text would be, with no
prevarication. If the ruler says that the size is not what it ought
to be, then the size specification in pt units *isn't working*.

In a correct CSS implementation, the only option would be to disable
the author's size specification entirely.

The CSS px unit is different, but it's still defined in physical
terms, irrespective of the reader's eyesight. CSS px units, if they
were implemented as defined, might be useful for a collective viewing
situation, e.g a lecture room, where the same display (projected)
inevitably has to be viewed by everyone present, and obviously if the
room is larger then the projected display has to be larger, which is
just how the CSS spec says that px units have to work. But for
individual viewing, CSS px units make no more sense than pt units,
since they take no account of the reader's eyesight. Again, if the
browser permits the user to adjust the display size for px units, then
it's no longer in conformance with the specification, i.e this size
unit is no longer working. In this sense the MSIE implementation of
px units is correct, except that it's only correct for one specific
display dpi and viewing distance.

But, in any case, as I already said, neither the absolute length units
(pt etc.), nor the CSS px units, actually work to specification in a
web context.

I don't see the point of specifying units which are not only something
that I don't want in theory, but aren't even implemented to
specification in practice. The em unit is just what I want: 1.0em is
meant to be the *reader's* choice of comfortably readable body text,
and that's jusst what I want to use as my basis for text size, and
it's just how I want to set my browser for reading pages from others.

Ho hum.

['sNiek]

Alan J. Flavell schreef:

In this sense the MSIE implementation of
px units is correct, except that it's only correct for one specific
display dpi and viewing distance.
Say what? MSIE is correct? Sounds ironic :-)
But, in any case, as I already said, neither the absolute length units
(pt etc.), nor the CSS px units, actually work to specification in a
web context.
Wow, you really got me thinking up here. I think you convinced me, in
the nearby future their will be 150dpi screens and then the px-sizes
will mess up.
Good that I'm using em's allready.
I don't see the point of specifying units which are not only something
that I don't want in theory, but aren't even implemented to
specification in practice. The em unit is just what I want: 1.0em is
meant to be the *reader's* choice of comfortably readable body text,
and that's jusst what I want to use as my basis for text size, and
it's just how I want to set my browser for reading pages from others.

Ho hum.

i stand corrected, nice post!

--
Niek

['sNiek]

Beauregard T. Shagnasty schreef:

'sNiek wrote:

There are enough possibilities to adjust the font-size in good,
valid browsers, so why wouldn't a designer/webbuilder use px's to
present their design? If it results in readable text, it's just
fine.

I'm an old guy with really poor vision, and only have Internet Explorer.
My text size is set to Largest so I can at least try to read the sites I
go to. Unfortunately, yours is set in stone at 10px and I can't increase
it or read it, so I'll just go somewhere else.

Actually, that's not true (except the old guy part), but it will point
out to you what will happen with a goodly portion of the surfing public.

I didn't say I was using px's: it's just that it is not so easy to
translate a "11px font with 14px leading"in photoshop to em's that are
just as big and with the right leading.

Cheers.

--
Niek

[Tim]

On Sat, 13 Aug 2005 20:14:44 +0200, 'sNiek sent:

in the nearby future their will be 150dpi screens and then the px-sizes
will mess up.

I'm sure there already are. I've got a quite old 130 dpi screen, and
another 76 dpi screen, and various ones between which I've not assessed.

Pixel or point based text sizing doesn't work as expected, by anybody
(author or viewer), across all of them. On one, I have to specify 16 as
the minimum readable size, on another it's 24 (in whatever unit Mozilla
Firefox is using for the minimum font size - pixels, I think).

Change the DPI parameter in the browser (telling it what you think your
screen is capable of) usually changes the size of the text. Which makes
sense, though rarely works in a user-friendly manner. It'd be easier to
deal with if the font sizes were specified in a non-DPI-dependent manner,
and adjusting your DPI merely adjusted the resolution (quality). Then I
could set my preferred text size, on all my computers, as 14 pt (for
instance), set the DPI as was true for the monitor, and get consistency
across everything, without a lot of mucking about.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please destroy some files yourself.

[Spartanicus]

Tim <ti*@mail.localhost.invalid> wrote:

I've got a quite old 130 dpi screen
If it's a CRT then you are deluding yourself. The maximum resolution of
a CRT is limited by the dot pitch of the tube.
Change the DPI parameter in the browser (telling it what you think your
screen is capable of) usually changes the size of the text.

If by that you are referring to the "Display resolution" in Mozilla,
changing that setting does not change the text size here.

--
Spartanicus

[Alan J. Flavell]

On Sun, 14 Aug 2005, Tim wrote:

On Sat, 13 Aug 2005 20:14:44 +0200, 'sNiek sent:

in the nearby future their will be 150dpi screens and then the
px-sizes will mess up.
I'm sure there already are.

There sure are, and IBM sell LCD displays with a resolution somewhat
over 200dpi, though they're still hair-curlingly expensive.
I've got a quite old 130 dpi screen,
When I measured the settings on my old PC+CRT display (a 19-inch
professional iiyama display), it was set to about 135 increments per
inch. Admittedly this was somewhat higher than the the CRT was
physically capable of - but it otherwise served me well (provided that
I used Mozilla's minimum font size setting to defend myself from the
kind of deezyner who tried to set microfonts on me).
Change the DPI parameter in the browser (telling it what you think
your screen is capable of) usually changes the size of the text.

This depends not only on the browser but also on the OS, or, to be
more exact, on the display system. X Windows is quite different from
MS Windows in this regard, for example; and (for all that I know about
Macs, which I'm afraid is rather little) Macintoshes are probably
different again.

But be sure to review what the CSS specification says about its
definition of the CSS px unit. I think you'll agree that if there are
any browsing systems which really implement that unit as specified,
they are very few and far between in practice.

best regards.

[Tim]

On Sun, 14 Aug 2005 09:14:35 +0100, Alan J. Flavell sent:

But be sure to review what the CSS specification says about its
definition of the CSS px unit.

I did, some time ago, and probably, initially, came away with as much
understanding as all of those who implemented it very badly. After a
while, I came to the conclusion that is wasn't practically usable with the
current crop of browsers and wannabes.

My experiments convinced me that about the only place I'll use px units is
a bit of padding between text content and a border on a box. Just enough
so that they don't touch. I'd tried using ems, but then I always ended up
with different vertical and horizontal space (more padding above than
beside, which just looked bad). But something like 5 pixels was enough to
make some separation between text and the border.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please destroy some files yourself.

[Tim]

Tim <ti*@mail.localhost.invalid> wrote:

I've got a quite old 130 dpi screen

Spartanicus sent:

If it's a CRT then you are deluding yourself. The maximum resolution of
a CRT is limited by the dot pitch of the tube.
And you think that some aren't capable of it?

DPI rather depends on a point of view, too. Whether you mean you can
clearly distinguish every single pixel, and use them with single pixel
drawings to produce images that all of their fine detail can be seen.

Or that such tiny pixels can reasonably be used to draw the shape of a
more complex figure.

e.g. How smooth the curves are drawn around a letter O.

Which is more to do with how many pixels per inch the display card outputs
than the phosphor dots on the CRT, though it's not a completely clear cut
thing, where your usable resolution is somewhere between the two figures.

But, if you have a genuine monochrome monitor, they're certainly *very*
high resolution.

Change the DPI parameter in the browser (telling it what you think your
screen is capable of) usually changes the size of the text.

If by that you are referring to the "Display resolution" in Mozilla,
changing that setting does not change the text size here.

Did here, with Mozilla Firefox (1.0.6). Though I used mixed OSs, here,
and I can't recall if it was Windows or Linux that did that, or both, and
I don't care to repeat the experiment at the moment.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please destroy some files yourself.

[Spartanicus]

Tim <ti*@mail.localhost.invalid> wrote:

I've got a quite old 130 dpi screen

If it's a CRT then you are deluding yourself. The maximum resolution of
a CRT is limited by the dot pitch of the tube.

And you think that some aren't capable of it?

Do the math.
DPI rather depends on a point of view, too. Whether you mean you can
clearly distinguish every single pixel, and use them with single pixel
drawings to produce images that all of their fine detail can be seen.

Or that such tiny pixels can reasonably be used to draw the shape of a
more complex figure.

e.g. How smooth the curves are drawn around a letter O.
The argument isn't meant to justify not to respect a user's font
setting, only to inject realism in your 130PPI monitor claim.
Which is more to do with how many pixels per inch the display card outputs
than the phosphor dots on the CRT, though it's not a completely clear cut
thing, where your usable resolution is somewhere between the two figures.
No they are 2 different parameters, screen area and resolution (the
screen area setting is very often mislabeled as "resolution").
But, if you have a genuine monochrome monitor, they're certainly *very*
high resolution.

If like me you've worked on monochrome monitors with a non operative
vertical and horizontal deflection (rare), you'd know that this produces
a light spot with a much larger diameter than that which is directly
bombarded with electrons. The light radiates outwards. This combined
with the fact that the electron beam itself has a limited focus makes
the resolution of monochrome monitors little better than colour CRTs.

--
Spartanicus

[Tim]

Tim:

I've got a quite old 130 dpi screen
Spartanicus:
If it's a CRT then you are deluding yourself. The maximum resolution of
a CRT is limited by the dot pitch of the tube.

Tim:
And you think that some aren't capable of it?
Spartanicus:

Do the math.
Tell me, how many DPI on a high definition CRT projection set spanning
something like 9 feet across the screen... And that's just one example of
where making assumptions of what can't be done falls rather flat on its
face.
DPI rather depends on a point of view, too. Whether you mean you can
clearly distinguish every single pixel, and use them with single pixel
drawings to produce images that all of their fine detail can be seen.

Or that such tiny pixels can reasonably be used to draw the shape of a
more complex figure.

e.g. How smooth the curves are drawn around a letter O. The argument isn't meant to justify not to respect a user's font
setting, only to inject realism in your 130PPI monitor claim.
You're complaining about projecting realism into a claim?

Can you see every tiny dot that could possibly be visible in a 1200 DPI
printout? No. But you certainly get a better printout than in a 600 DPI
printout. Because x many dots per inch were used to render the drawing.
Which is more to do with how many pixels per inch the display card
outputs than the phosphor dots on the CRT, though it's not a completely
clear cut thing, where your usable resolution is somewhere between the
two figures. No they are 2 different parameters, screen area and resolution (the
screen area setting is very often mislabeled as "resolution").
Resolution is an all encompassing term that covers how well you *resolve*
an image, as an end result. It's not just how many dots, it's how well
it's perceived. You've got video bandwidth, number of outputted pixels,
pixel definition of the display device, focus, all in combination.
There's no one thing that determines the maximum resolution.
But, if you have a genuine monochrome monitor, they're certainly *very*
high resolution.

If like me you've worked on monochrome monitors with a non operative
vertical and horizontal deflection (rare), you'd know that this produces
a light spot with a much larger diameter than that which is directly
bombarded with electrons.
Not an argument. That has nothing to do with the normal operation of
the set. Shut down scanning and you, now, subject one point of the screen
to a lot more electron stimulation than it'd normally get, *and* you'll
get bleed. In normal operation, the beam illumination size is much
smaller.
This combined with the fact that the electron beam itself has a limited
focus makes the resolution of monochrome monitors little better than
colour CRTs.

You obviously haven't used very high definition monitors. Monochrome
CRTs are far superior to colour CRTs, usually by a factor of 3:1 at
minimum. The focus is *much* sharper and you have tiny particles of
phosphor paint randomly distributed over the inside of the tube, rather
than the large colour pixels and the shadow mask scanned by a fat blob
that typically can only illuminate the minimum of one colour dot at a time
(i.e. one colour phosphor is illuminated as a whole, rather than different
illuminations along all of its whole dimensions), and often illuminations
a colour phosphor dot and its neighbours at the same time.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please destroy some files yourself.

[madsgormlarsen]

OTP

How many anarchy-list subscribers to does it take to change
a light bulb?

1,666

1 person to notice that the hard drive light is burned out on Jack's
computer.

13 people to make generalizations about how changing society would mean
that in the future, problems like the burned-out bulbs
wouldn't exist.

1 person to re-open the debate about how light bulbs are made from
animal materials and thus are unanarchistic. This person also
would say that guns should be banned because they can be used to shoot
small cuddly animals.

1 former small-town politician to regale the list on his hunting
experiences and how guns and light bulbs are good things.

1 son of a CIA-agent to say that greenhouse warming doesn't exist and
that the burned-out bulb has no environmental effect. He will
cite an article from a LaRouchite paper he found in his college's
student cafeteria. This person then sends 145 messages with
press accounts about lightbulbs in police cars that he may have
destroyed.

1 person to send out flame bait about the light bulb issue.

130 people who respond to the flame bait and quote previous messages in
their entirety, with only a one line addition appended.
These posts will all include sig lines longer than the responses.

6 people to propose that a FAQ on the Proper Anarchist Way to Change
Light Bulbs be written.

560 people to send requests on how to find "The Lightbulb Cookbook."

670 to send unsubscribe messages saying that the traffic about
lightbulbs is too much.

45 drunken students to post weird ramblings with no relation to any of
the threads.

1 rosaphilia to post 65 KB forwarded messages about conspiracy theories
and light bulbs.

19 spammers to send messages about products entirely unrelated to
lightbulbs, anarchy, guns, or police cars.

3 A-infos posts to inform the world on the lightbulb debate.

16 folks who send messages quoting great anarchist lightbulb thinkers
out of context.

18 immature boys to make accusations that other list members do weird
sexual things with lightbulbs.

2 people to send out emails about punk benefit shows in Ohio that will
raise money for the new light bulb.

1 wise guy/gal to start a flame thread if organizing around the
lightbulb situation is an example of "lifestylism."

356 to post follow-up to the lifestylism debate, asserting that the
lightbulb is important to revolutionary politics.

20 newbies to crosspost the entire thread to 15 other lists, including
6
secret, members-only ones, and 45 newsgroups including
alt.talk.lightbulb, alt.revolution.change.lightbulb,
alt.politics.chomsky, alt.worship.trotsky, soc.guns.fuzzy,
alt.conspiracy.westinghouse, and alt.libertarian.scientology.

1 person to ponder the origins of the black lightbulb and its various
meanings through history.

65 anarchos to discuss how they were first introduced to the anarchist
way of lightbulb changin'.

4 frustrated anarchists to urge that we get anarchists "organized" on
this issue.

89 people to discuss whether or not anarchists should change the
lightbulb like they do at McDonalds.

222 well-read anti-authoritarians to suggest book titles for further
reading on this important topic.

3 anarchist librarians to make sure that all the debate about the
lighbulb situation is archived and properly indexed, so that future
scholars can look back and ponder what all the commotion was about.

1 list-maintainer to go out to the electronics store to buy a new bulb.
and of course:

3 luddite neo-primitivists to fashion a raft out of junk, float across
the Atlantic, locate Jack's computer, and smash the new bulb to pieces.
Note: The numbers don't add up to the answer given above because math
is
relative. Those who maintain that mathematics gives
exact answers are pretentious, elitist academic wankers.

[Spartanicus]

Tim <ti*@mail.localhost.invalid> wrote:

Tell me, how many DPI on a high definition CRT projection set spanning
something like 9 feet across the screen... And that's just one example of
where making assumptions of what can't be done falls rather flat on its
face.
Now you are turning to farcical examples. You know full well that your
claim pertained to a colour CRT monitor with a mask and phosphor, not a
projection unit.

The argument isn't meant to justify not to respect a user's font
setting, only to inject realism in your 130PPI monitor claim.

You're complaining about projecting realism into a claim?

Not complaining, just correcting your claim.
Can you see every tiny dot that could possibly be visible in a 1200 DPI
printout?

Possibly, but that's not the issue, the issue is if it's being output
and thereby available. Which is not the case on a CRT monitor driven
beyond the output capacity of the CRT.

Which is more to do with how many pixels per inch the display card
outputs than the phosphor dots on the CRT, though it's not a completely
clear cut thing, where your usable resolution is somewhere between the
two figures.

No they are 2 different parameters, screen area and resolution (the
screen area setting is very often mislabeled as "resolution").

Resolution is an all encompassing term that covers how well you *resolve*
an image, as an end result. It's not just how many dots, it's how well
it's perceived. You've got video bandwidth, number of outputted pixels,
pixel definition of the display device, focus, all in combination.
There's no one thing that determines the maximum resolution.

Video bandwidth and focus can pose an additional constraint on the
maximum output resolution, but the absolute limit is determined by the
mask and phosphor dots of the CRT.

But, if you have a genuine monochrome monitor, they're certainly *very*
high resolution.

If like me you've worked on monochrome monitors with a non operative
vertical and horizontal deflection (rare), you'd know that this produces
a light spot with a much larger diameter than that which is directly
bombarded with electrons.

Not an argument. That has nothing to do with the normal operation of
the set. Shut down scanning and you, now, subject one point of the screen
to a lot more electron stimulation than it'd normally get, *and* you'll
get bleed.

Disabling the deflection is no different than what happens in a given
moment in time during fully saturated video.
This combined with the fact that the electron beam itself has a limited
focus makes the resolution of monochrome monitors little better than
colour CRTs.

You obviously haven't used very high definition monitors. Monochrome
CRTs are far superior to colour CRTs, usually by a factor of 3:1 at
minimum. The focus is *much* sharper and you have tiny particles of
phosphor paint randomly distributed over the inside of the tube

On the atomic level they are particles, for practical purposes it's a
homogeneous layer. Both bleed and focus limitations of the beam are a
reality that severely limit the imagined output resolution of monochrome
CRTs.

--
Spartanicus

[Tim]

Tim <ti*@mail.localhost.invalid> wrote:

Tell me, how many DPI on a high definition CRT projection set spanning
something like 9 feet across the screen... And that's just one example
of where making assumptions of what can't be done falls rather flat on
its face.
Spartanicus sent

Now you are turning to farcical examples.
No, that's a real situation. I'm point out that you can't unilaterally
declare all CRTs incapable of very high resolutions.
You know full well that your claim pertained to a colour CRT monitor
with a mask and phosphor, not a projection unit.
I don't deny that, but I also refute your notion that it's not capable of
the DPI that it is.

Can you see every tiny dot that could possibly be visible in a 1200 DPI
printout? Possibly, but that's not the issue, the issue is if it's being output
and thereby available. Which is not the case on a CRT monitor driven
beyond the output capacity of the CRT.
It's exactly the same situation. If a display driven as if it's 130 DPI
renders much better than if it's treated as though it were 100 DPI, then
it's resolution is better than 100 DPI. If it produces the results that
were desired, then it is the top resolution that you determine it to be.

We have the same situation with broadcast television, though we use the
terms "lines" to measure display resolution, and we talk about the number
of lines across the entire screen (much easier to quantify than an inch).
If you can determine that 900 finely drawn vertical lines, across the
screen, can be distinguished as being lines rather than a grey blob, the
monitor is a 900 line resolution monitor.

A similar technique being used with the DPI of the monitor. That being
the maximum resolution that can be used to define a picture.

e.g. If you were to progressively display imagery on a screen at 100 DPI,
200 DPI, and so on, up until the point that you could no longer determine
any difference between the pictures, the last highest DPI figure would be
the DPI of the screen.
Video bandwidth and focus can pose an additional constraint on the
maximum output resolution, but the absolute limit is determined by the
mask and phosphor dots of the CRT.
That depends on the situation. Not all CRTs work that way.

But, if you have a genuine monochrome monitor, they're certainly
*very* high resolution. If like me you've worked on monochrome monitors with a non operative
vertical and horizontal deflection (rare), you'd know that this
produces a light spot with a much larger diameter than that which is
directly bombarded with electrons. Not an argument. That has nothing to do with the normal operation of
the set. Shut down scanning and you, now, subject one point of the
screen to a lot more electron stimulation than it'd normally get, *and*
you'll get bleed. Disabling the deflection is no different than what happens in a given
moment in time during fully saturated video.
Very wrong! Disabling the deflection is EXTREMELY different. It's
obvious you don't know much about how CRTs work on the electronics level.
Disable the scan, and you'll burn the tube, if you continued to emit
electrons at one point on the tube at the same intensity as if it were
still scanning. Before that, though, you'll most definitely draw a blob
(with no scan) where a dot would have been drawn while scanning.

This combined with the fact that the electron beam itself has a
limited focus makes the resolution of monochrome monitors little
better than colour CRTs.

You obviously haven't used very high definition monitors. Monochrome
CRTs are far superior to colour CRTs, usually by a factor of 3:1 at
minimum. The focus is *much* sharper and you have tiny particles of
phosphor paint randomly distributed over the inside of the tube

On the atomic level they are particles, for practical purposes it's a
homogeneous layer. Both bleed and focus limitations of the beam are a
reality that severely limit the imagined output resolution of monochrome
CRTs.

While such limits are a limit of the resolution. A monochrome set can,
and does, have greater focus, and smaller illuminated dot size potential
than colour CRTs. By a significant order of magnitude.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please destroy some files yourself.

[Spartanicus]

Tim <ti*@mail.localhost.invalid> wrote:

You know full well that your claim pertained to a colour CRT monitor
with a mask and phosphor, not a projection unit.
I don't deny that, but I also refute your notion that it's not capable of
the DPI that it is.

Which is not 130PPI.

I'll do the math for you: professional grade Trinitron monitors have a
0.24mm dot pitch which equates to a maximum resolution of ~118PPI. If
you are thinking about claiming that some monitors have a 0.21mm dot
pitch, note that this is a false marketing inspired claim based on the
horizontal plane only, based on a *mask* pitch measurement, and/or based
on the finest grain present (CRTs commonly have a different DP in the
center than on the outer edges).

Normal high quality monitors like your old clunker in the back of the
shed are more likely to have a 0.27mm or worse dot pitch, a 0.27mm DP
equates to ~105PPI maximum resolution.

Disabling the deflection is no different than what happens in a given
moment in time during fully saturated video.

Very wrong! Disabling the deflection is EXTREMELY different. It's
obvious you don't know much about how CRTs work on the electronics level.

My degree in electronics, being old enough to have grown up in the CRT
age and many years of experience working with and on CRT displays
suggests differently.
Disable the scan, and you'll burn the tube

Which is due not to the excitation at a given moment, but due to
prolonged excitation. With deflection enabled a given spot is only
subjected to excitation for a fraction of the time.

--
Spartanicus

[Spartanicus]

Spartanicus <in*****@invalid.invalid> wrote:

I'll do the math for you: professional grade Trinitron monitors have a
0.24mm dot pitch which equates to a maximum resolution of ~118PPI.

Clearly my math isn't what it used to be (blame my old age :-)

Revised figures:
0.24mm dot pitch = ~105PPI
0.27mm dot pitch = ~94PPI

--
Spartanicus

[Christoph Päper]

Spartanicus:

0.24mm dot pitch which equates to a maximum resolution of ~118PPI.

Clearly my math isn't what it used to be (blame my old age :-)

Let's (also) blame English units in general and "DPI"/"PPI" in particular.