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. 9 6902
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
"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/
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/
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
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**@childsupportanalysis.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.
Tim wrote:
[snip] "Barry Pearson" <ne**@childsupportanalysis.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.com/gr*******************************@newsfep1-gui.server.ntli.net
http://groups.google.com/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.com/gr*******************************@newsfep1-gui.server.ntli.net
http://groups.google.com/gr*************************************@newsfep2-win.server.ntli.net
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
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.
On Thu, 2 Oct 2003, Tim wrote: "Barry Pearson" <ne**@childsupportanalysis.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.
"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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: DiggidyMack69 |
last post by:
Hello folks,
I have a jsp using the thin oracle drivers. I need to add a query for
a large table (70 something columns...I'didn't build it) due the high
number of columns and some things that are...
|
by: Ramachandran Pramod |
last post by:
HI Group,
I have installed WAS 5.0 in my machine recently and would like to
configure Oracle JDBC thin driver. I tried it with the admin console,
with the following parametners
JDBC...
|
by: Mark Carter |
last post by:
Suppose I wanted to combine a thin client written in VB6 with a server
on a remote machine. Since this is the python group, assume for now
that it could be written in python (although VB6 would be...
|
by: Harish |
last post by:
Hi,
Why is "jdbc:oracle:thin" called a thin driver?
Thanks in advance.
Harish.
|
by: ak |
last post by:
Hi all
I figured I would ask here if somebody
done something similar to this since I am
new to .NET :
I need to implement a thin client; it is involves
communicating with a database and...
|
by: Ramesh |
last post by:
Hi
Can somebody suggest some ways of communication
between jdbc and ms-access without the odbc way.
I heard that it can be done through thin drivers.
What are those thin drivers.
Are they...
|
by: Russ |
last post by:
Hello,
I have an application that consists of both thin client portions and
fat client portions.
One such view consists of a fat client treeview on the left, and a
thin client asp.net webapp...
|
by: Michael |
last post by:
Hi,
i've heard from someone that i can make my whole VB.NET
application to be run on a web browser and this is call
thin client? Only problem is that i need to install .net
framework on all PCs...
|
by: 99m |
last post by:
Can anyone recommend to me a thin PHP framework? By thin, I mean that I
don't want a massive amount of code, dependencies, or large learning
curve. I'm also not thrilled about introducing XSLT into...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
| |