thin vs. 1px

[The Plankmeister]

If I set a border value to something like:

border : thin solid blue;

It will look perfect in all browsers except IE (No surprise there) where
'thin' borders are rendered 2 pixels wide. If I replace it with:

border : 1px solid blue;

It looks the same in all browsers. My question: Does one have advantages or
benefits over the other?
P.

[Brian]

The Plankmeister wrote:

border : thin solid blue;

border : 1px solid blue;

My question: Does one have advantages or
benefits over the other?

None that I can imagine. Use whichever one suits your design goals
better.

--
Brian
follow the directions in my address to email me

[Jukka K. Korpela]

"The Plankmeister" <pl************ ******@hotmail. com> wrote:

If I set a border value to something like:

border : thin solid blue;

It will look perfect in all browsers except IE (No surprise there)
where 'thin' borders are rendered 2 pixels wide.
It's perfect too, just differently perfect. :-)

It is up to anyone who writes a browser to decide what physical size
thin maps to.
If I replace it with:

border : 1px solid blue;

It looks the same in all browsers.
Well, with the usual caveats, yes. And this might be a problem in the
future.
My question: Does one have
advantages or benefits over the other?

In practice, what we currently get is what you have described, so the
practical choice is pretty clear. Make up your mind between 1px and
2px, and forget thin.

In the future, maybe people write browsers that implement the keyword
widths intelligently. For example, they could map thin to 1px in normal
situations but to something larger when the device is known to be very
high resolution (with small pixel size) or when the font size is very
large. A 1px border around some text in 60pt size looks pathetic.

On a more realistic path, you might consider using a width like
0.03em, which means that the width is scaled according to font size.
But there's a catch. Browsers may round it to zero. That's what Opera 7
does, for example, when the font size is 9px (which _some_ users might
select, for various reasons). And if you use a sufficiently large value
like 0.06em, then the border gets too thick when the font size is
large.

So I'm guess we're back with the choice between 1px and 2px.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[Barry Pearson]

Jukka K. Korpela wrote:
[snip]

In the future, maybe people write browsers that implement the keyword
widths intelligently. For example, they could map thin to 1px in
normal situations but to something larger when the device is known to
be very high resolution (with small pixel size) or when the font size
is very large. A 1px border around some text in 60pt size looks
pathetic.

[snip]

And, of course, the W3C recommendation is that the interpretation of "px"
itself should take into account such very high resolutions. (But I'm not aware
of browers that support this, or even where they would get their information
from to do so).

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Alan J. Flavell]

On Wed, 1 Oct 2003, Jukka K. Korpela wrote:

In the future, maybe people write browsers that implement the keyword
widths intelligently. For example, they could map thin to 1px in normal
situations but to something larger when the device is known to be very
high resolution (with small pixel size)

Would that be in addition to implementing CSS px units as they are
specified, or do we have to abandon that scheme (in much the way that
CSS2.1WD has told us to abandon font-size-adjust, say)? I note that
the CSS definition of the px unit is still present, in its somewhat
muddled formulation, in the CSS2.1 WD, the only substantive change is
to the reference dpi, but that was already on the errata.

cheers

[Tim]

Jukka K. Korpela wrote:

In the future, maybe people write browsers that implement the keyword
widths intelligently. For example, they could map thin to 1px in
normal situations but to something larger when the device is known to
be very high resolution (with small pixel size) or when the font size
is very large. A 1px border around some text in 60pt size looks
pathetic.

"Barry Pearson" <ne**@childsupp ortanalysis.co. uk> wrote:
And, of course, the W3C recommendation is that the interpretation of "px"
itself should take into account such very high resolutions. (But I'm not aware
of browsers that support this, or even where they would get their information
from to do so).

I would have thought that "px" dimensions would have to relate to
anything else that uses pixels on the page (e.g. pictures), so that you
can design non-textual things to go with images (for instance). If one
of them scales, then the other needs to, too.

But I think it's going to be quite some time before we get really high
resolution monitors (many times more than the current ones), that pixels
don't come into the equation, at all. Then, websites could use things
like "quarter-page-width" sized images, that scale nicely to suit, with
borders set to 10% of the image size, keeping them in proportion to each
other. Or scaling images to cover 10 lines of text height. And that
sort of thing.

--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.

[Barry Pearson]

Tim wrote:
[snip]

"Barry Pearson" <ne**@childsupp ortanalysis.co. uk> wrote:

And, of course, the W3C recommendation is that the interpretation of
"px" itself should take into account such very high resolutions.
(But I'm not aware of browsers that support this, or even where they
would get their information from to do so).
I would have thought that "px" dimensions would have to relate to
anything else that uses pixels on the page (e.g. pictures), so that
you can design non-textual things to go with images (for instance).
If one of them scales, then the other needs to, too.

I fully agree! See:

http://groups.google.c om/gr************* *************** ***@newsfep1-gui.server.ntli .net

http://groups.google.c om/gr************* *************** ******@newsfep3-gui.server.ntli .net
But I think it's going to be quite some time before we get really high
resolution monitors (many times more than the current ones), that
pixels don't come into the equation, at all. Then, websites could
use things like "quarter-page-width" sized images, that scale nicely
to suit, with borders set to 10% of the image size, keeping them in
proportion to each other. Or scaling images to cover 10 lines of
text height. And that sort of thing.

We are already getting towards the stage where some monitors are approaching
2x the typical. That is enough to be a concern.

http://groups.google.c om/gr************* *************** ***@newsfep1-gui.server.ntli .net

http://groups.google.c om/gr************* *************** *********@newsf ep2-win.server.ntli .net

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Lauri Raittila]

In article <Xn************ *************** **@193.229.0.31 >, Jukka K.
Korpela wrote:

In the future, maybe people write browsers that implement the keyword
widths intelligently. For example, they could map thin to 1px in normal
situations but to something larger when the device is known to be very
high resolution (with small pixel size) or when the font size is very
large.

Or browser could have setting for setting values for keywords.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.

[Alan J. Flavell]

On Thu, 2 Oct 2003, Tim wrote:

"Barry Pearson" <ne**@childsupp ortanalysis.co. uk> wrote:

And, of course, the W3C recommendation is that the interpretation of "px"
itself should take into account such very high resolutions.
Indeed - and the viewing distance too ;-)
(But I'm not aware of browsers that support this, or even where
they would get their information from to do so).

I think the usual graphics APIs have ways of querying the nominal dpi
setting; the killer, though, is that only a keen specialist would
ever bother to find out how to calibrate their display so that the
resulting nominal value had any relation to reality.

(But, as for the intended viewing distance... [this space
intentionally left blank])
I would have thought that "px" dimensions would have to relate to
anything else that uses pixels on the page (e.g. pictures), so that you
can design non-textual things to go with images (for instance).
Indeed; I'm a bit tired of seeing poky little images on my 135dpi
display and getting told that they're perfectly big enough (on the
designer's ~ 65dpi system).
If one of them scales, then the other needs to, too.
Ideally, yes it does. A pity that most browsers make such a sow's ear
of re-sizing images.
But I think it's going to be quite some time before we get really high
resolution monitors (many times more than the current ones),

Hang on. In reality I've met resolutions from ~ 65dpi to ~ 150dpi,
and specialist displays can do better than that already.

That's linear ratios of well over 2, and since we're discussing
2-dimensional features it's not unfair to remark that it's a factor
of at least 5 in area.

Yet a linear factor of say 1.2 can make a quite perceptible difference
in size.

If you say there are technical obstacles to arbitrary resizing,
and especially of line-drawings, cartoon-ish material etc. then
I'd have to agree with you. Which is why I'm so baffled that it's
taken so long to get a viable scaleable vector graphics format on the
road.

But IMHO the problem does not go away merely by pointing to the
technical obstacles which exist to its resolution. I still want to be
able to size images in em units, in appropriate situations, and get
browsers to do something sensible in response.

[Tim]

"Alan J. Flavell" <fl*****@ph.gla .ac.uk> wrote:

I think the usual graphics APIs have ways of querying the nominal dpi
setting; the killer, though, is that only a keen specialist would
ever bother to find out how to calibrate their display so that the
resulting nominal value had any relation to reality.
I should think that knowing the DPI would depend on the graphics card
and the monitor. Not all monitors have their specifications (none of my
plug and play monitors are known to Windows, one is known to Linux, but
only by a large look-up chart created by Linux users).

(But, as for the intended viewing distance... [this space
intentionally left blank])
Yes, that's a good one. :-\ I find most people have their monitor far
too close (it hurts my eyes). I'm usually over a metre away from my
own, whether 14" or 17".
Tim wrote:

But I think it's going to be quite some time before we get really high
resolution monitors (many times more than the current ones),

Hang on. In reality I've met resolutions from ~ 65dpi to ~ 150dpi,
and specialist displays can do better than that already.
Mine's none too flash, nor are many of my friend's; and those that have
high resolution monitors use them display at a lower resolution because
the text gets too small (try using larger text in Windows, and it
doesn't enlarge the GUI around it proportionally, or at all).

I've yet to see anything with sufficiently high resolution, and enough
resources to back it, that we can use high resolution displays and work
with images created using many pixels where just one would have been
used before (e.g. nice smooth text, other anti-aliased images, high
resolution images where the monitor exceeds your own ability to pick
flaws with it, etc.).
If you say there are technical obstacles to arbitrary resizing,
and especially of line-drawings, cartoon-ish material etc. then
I'd have to agree with you. Which is why I'm so baffled that it's
taken so long to get a viable scaleable vector graphics format on the
road.

I think it's probably a similar situation to why scaleable fonts still
look so bad. You can't, easily, make small scaleable objects. They
turn into a mess, because there's not enough pixels to draw them nicely.
--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.