Re: how many px equal to 100% width?

Nik Coughlin wrote:

"mao" <kc.at.sinzon (AT) gmail (DOT) com> wrote in message
news:a4551f4c-c451-4095-9a3e-2a1c645e95fd (AT) i29g2000prf (DOT) googlegroups.com...

<snip>

if I want my CSS use px unit, what is the X value in the following
code to have the same result as the one using width:100%?
body {width: Xpx;}

There is no 1:1 ratio for converting from % to px. It depends on the
viewport size of your browser. It is different for different people,
depending on their screen resolution, whether their browser is maximised
or not, how much chrome/toolbars etc. there are in the browser and a
whole bunch of other things.

Agree. It is a "How many angels can dance on the head of a pin?" type
question. So as Jukka would bluntly say, "Stop wanting that".

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

In article <33c90$4763598e$40cba7c7$11097 (AT) NAXS (DOT) COM>,
"Jonathan N. Little" <lws4art (AT) centralva (DOT) net> wrote:

Nik Coughlin wrote:
"mao" <kc.at.sinzon (AT) gmail (DOT) com> wrote in message
news:a4551f4c-c451-4095-9a3e-2a1c645e95fd (AT) i29g2000prf (DOT) googlegroups.com...

snip

if I want my CSS use px unit, what is the X value in the following
code to have the same result as the one using width:100%?
body {width: Xpx;}

There is no 1:1 ratio for converting from % to px. It depends on the
viewport size of your browser. It is different for different people,
depending on their screen resolution, whether their browser is maximised
or not, how much chrome/toolbars etc. there are in the browser and a
whole bunch of other things.

Agree. It is a "How many angels can dance on the head of a pin?" type
question.

I think of a "head of the pin" type question as rather more where
there is a feint chance of an answer in a debate with rather ill
defined terms.

But in this case there is no sense to the question itself. In the
former, it is not a matter of simple conceptual confusion but
rather a mistaken assessment of determinacy. In the case of
thinking that there is an equivalence between % and px, it is a
total misconception, the debate cannot even begin.

--
dorayme

dorayme wrote:

I think of a "head of the pin" type question as rather more where
there is a feint chance of an answer in a debate with rather ill
defined terms.

If that is the case, then we can have an answer of sorts. You create a
DIV (or anything else that can be set invisible) and style it to have
width:100%

This "thing" will be exactly the width in pixels that the OP is after.

So, they just have to use a bit of JavaScript, to find precisely how
wide it is (*right now*, it will be different one mouse click/drag
later) and the job is done.

As with the original "42", they're *really* not going to like the answer.

I've used this technique precisely once. I was using coloured DIVs to
generate simple horizontal bar charts, and on modern displays an
accuracy of one tenth of a percent of the display may be too coarse, so
I needed something finer, and pixels seemed the right thing to use.

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

In article <476617fa$1 (AT) news (DOT) greennet.net>,
Steve Swift <Steve.J.Swift (AT) gmail (DOT) com> wrote:

dorayme wrote:
I think of a "head of the pin" type question as rather more where
there is a feint chance of an answer in a debate with rather ill
defined terms.

If that is the case, then we can have an answer of sorts. You create a
DIV (or anything else that can be set invisible) and style it to have
width:100%

A div is 100% by default.

(I notice now I misspelt a word. Never mind. I suppose no one
really wants to talk about angels on pins? I think this business
might have started in reference to a needle point in a context
where many things might be able to be in the same place and yet
be distinguishably different. Angels!)

--
dorayme

On 2007-12-16, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

In article <476617fa$1 (AT) news (DOT) greennet.net>,
Steve Swift <Steve.J.Swift (AT) gmail (DOT) com> wrote:

dorayme wrote:
I think of a "head of the pin" type question as rather more where
there is a feint chance of an answer in a debate with rather ill
defined terms.

If that is the case, then we can have an answer of sorts. You create a
DIV (or anything else that can be set invisible) and style it to have
width:100%

A div is 100% by default.

Not exactly. It's width: auto by default. The result of that is that its
"used" width will be the available width minus the total width of its
left and right margins, padding and borders.

But width: 100% makes its used width equal to the available width. So if
it has borders, padding and margins that add up to >0, it will overflow
its container, resulting in a greater used width than if its width had
been left as auto.

In article <slrnfmb54r.8aa.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:

On 2007-12-16, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:
In article <476617fa$1 (AT) news (DOT) greennet.net>,
Steve Swift <Steve.J.Swift (AT) gmail (DOT) com> wrote:

dorayme wrote:
I think of a "head of the pin" type question as rather more where
there is a feint chance of an answer in a debate with rather ill
defined terms.

If that is the case, then we can have an answer of sorts. You create a
DIV (or anything else that can be set invisible) and style it to have
width:100%

A div is 100% by default.

Not exactly. It's width: auto by default. The result of that is that its
"used" width will be the available width minus the total width of its
left and right margins, padding and borders.

But width: 100% makes its used width equal to the available width. So if
it has borders, padding and margins that add up to >0, it will overflow
its container, resulting in a greater used width than if its width had
been left as auto.

Thanks for this. I needed the reminder about the complexities.

Frankly, there are quite a few surprises in the issue when
checking different browsers:

<http://netweaver.com.au/alt/divAuto_...vAuto_v_100per
cent.html>

or

http://tinyurl.com/335cmx

iCab is different in that the scrollbars disappear after the
window is open more than 800px or so?

MacIE leaves a right padding after the right scroll is completed.

Most other modern Mac browsers behave similarly, Opera, FF,
Camino, Safari. All end with the black right border *on full
scroll*

I shall have to study more closely how the browsers calculate
where to place the right float after complete right scrolling
occurs. Before any scrolling and no matter how wide the browser
window, the right ruler floats to far right flush, that is easier
to understand.

And need to look mor closely why the right padding does not also
appear *on full right scroll* along with the border.

Shoot first and ask questions later has some redeeming features
but it is Monday morning and I won't expand on this now. (No need
to sigh in relief so loudly <g>)

--
dorayme

On 2007-12-17, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:
[...]

Frankly, there are quite a few surprises in the issue when
checking different browsers:

http://netweaver.com.au/alt/divAuto_...vAuto_v_100per
cent.html

or

http://tinyurl.com/335cmx

iCab is different in that the scrollbars disappear after the
window is open more than 800px or so?

Maybe it's not reflowing when the viewport gets wider or something?

MacIE leaves a right padding after the right scroll is completed.

A padding on body? That's just wrong as you've set padding on body to 0.

Most other modern Mac browsers behave similarly, Opera, FF,
Camino, Safari. All end with the black right border *on full
scroll*

That's what they should all be doing.

I shall have to study more closely how the browsers calculate
where to place the right float after complete right scrolling
occurs. Before any scrolling and no matter how wide the browser
window, the right ruler floats to far right flush, that is easier
to understand.

Yes, and its position relative to the root element doesn't change just
because you scroll. In other words, it stays where it is relative to
your graph-paper style background, and should therefore move left
relative to your monitor as you scroll the viewport right.

A right float goes as far to the right _of its container_ as it can. Its
container is body, and body has auto width, so its used outer margin
width is the width of the viewport and no wider. That's the container
the float is floating inside.

The fact that a sibling element, div class="demo", overflows body has no
affect at all on the width of body, the width available to rightMarker,
and therefore its positioning.

To get that effect (which people have asked for a couple of times) you
have to give body a shrink-to-fit width so it becomes wide enough for
its contents. Otherwise it is just wide enough to claim all the space
available, regardless of how much or how little width its contents might
prefer.

For normal flow the used width of an element depends _only on its
container_ and not on its contents. Height is the other way round. It
depends on the contents and not on the container.

If you think of writing a paragraph of text on a sheet of paper by hand
with a pen, in the normal fashion, and then, when you've finished,
drawing a box around the text, the situation is exactly the same. The
box's width comes only from the width of the paper, and was known before
you wrote a single word. But its height could only be determined after
you'd put in all the contents.

That's just how normal-flow auto widths and heights work in CSS-- the
system gets extended a bit for all the other things besides text that
might be in there, but the way it all flows is fundamentally the same:
Width greedy and first, height conservative and afterwards.

And need to look mor closely why the right padding does not also
appear *on full right scroll* along with the border.

Which right padding? Div class="demo" has all its padding in place as
far as I can see.

In article <slrnfmccfd.kb3.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:

On 2007-12-17, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:
[...]
Frankly, there are quite a few surprises in the issue when
checking different browsers:

http://netweaver.com.au/alt/divAuto_...vAuto_v_100per
cent.html

or

http://tinyurl.com/335cmx

iCab is different in that the scrollbars disappear after the
window is open more than 800px or so?

Maybe it's not reflowing when the viewport gets wider or something?

It is sure doing something! I might let the maker of iCab know.
It may be a bug if the specs are clear about this matter.

MacIE leaves a right padding after the right scroll is completed.

A padding on body? That's just wrong as you've set padding on body to 0.

It is leaving what I imagined it should have, see below. But then
I need to think this thing though. Thanks for stuff you posted
which I have snipped...

I need to look more closely at why the right padding does not also
appear *on full right scroll* along with the border.

Which right padding? Div class="demo" has all its padding in place as
far as I can see.

This is what I am seeing in Safari:

http://netweaver.com.au/alt/pics/view_in_Safari.png

div.demo has a right-padding of 50px. In Mac IE, this padding is
visible on full right scrolling or so it appears to me. Perhaps
the makers of Mac IE had the same misconception I have?

http://netweaver.com.au/alt/pics/view_in_macIE.png

--
dorayme

On 2007-12-17, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

In article <slrnfmccfd.kb3.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:

On 2007-12-17, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:
[...]
Frankly, there are quite a few surprises in the issue when
checking different browsers:

http://netweaver.com.au/alt/divAuto_...vAuto_v_100per
cent.html

or

http://tinyurl.com/335cmx
[...]
This is what I am seeing in Safari:

http://netweaver.com.au/alt/pics/view_in_Safari.png

div.demo has a right-padding of 50px. In Mac IE, this padding is
visible on full right scrolling or so it appears to me. Perhaps
the makers of Mac IE had the same misconception I have?

http://netweaver.com.au/alt/pics/view_in_macIE.png

The gap between the black border and the right of the viewport looks
like not padding but the 50px right margin. Change margin to 60px and
leave padding at 50, and I expect that gap will be 60px not 50px.

What you have here is an overconstrained situation. You've set the whole
lot: margin, border, padding and width, and it all adds up to more than
the space available.

According to the rules (CSS 2.1 10.3.3) the browser is therefore
supposed to disregard what you've set for right margin, and use instead
whatever value solves the equation:

margin + padding + borders + width = available width

Mac IE is getting this wrong-- it's giving you less of something else
instead, perhaps of width.

Suppose the available with is 600, then we've got:

50 + 50 + 50 + 50 + 50 + mr + 600 = 600
pl pr bl br ml mr width available

pl means "padding left" etc.

Therefore the "used" value of mr (margin-right) has to be -250. In other
words, you actually get a right margin of -250px even though you asked
for one of 50px. The browser tries to give you what you ask for, but
where that isn't logically possible, it has to make the specified
compromises.

(Note that if direction were rtl, it would be the left margin that ended
up as -250).

MacIE appears to be drawing this right margin as +50px. That's wrong
according to today's specifications.

In article <slrnfmdvdg.kb3.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:

On 2007-12-17, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:
In article <slrnfmccfd.kb3.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:

On 2007-12-17, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:
[...]
Frankly, there are quite a few surprises in the issue when
checking different browsers:

http://netweaver.com.au/alt/divAuto_...vAuto_v_100per
cent.html

or

http://tinyurl.com/335cmx
[...]
This is what I am seeing in Safari:

http://netweaver.com.au/alt/pics/view_in_Safari.png

div.demo has a right-padding of 50px. In Mac IE, this padding is
visible on full right scrolling or so it appears to me. Perhaps
the makers of Mac IE had the same misconception I have?

http://netweaver.com.au/alt/pics/view_in_macIE.png

The gap between the black border and the right of the viewport looks
like not padding but the 50px right margin.

Yes, sorry, margin! Was not examining it closely enough or
attending. I have altered the markup a bit so more is clearer - I
just put in loads more text!

http://tinyurl.com/335cmx

What you have here is an overconstrained situation. You've set the whole
lot: margin, border, padding and width, and it all adds up to more than
the space available.

According to the rules (CSS 2.1 10.3.3) the browser is therefore
supposed to disregard what you've set for right margin, and use instead
whatever value solves the equation:

margin + padding + borders + width = available width

Mac IE is getting this wrong-- it's giving you less of something else
instead, perhaps of width.

Suppose the available with is 600, then we've got:

50 + 50 + 50 + 50 + 50 + mr + 600 = 600
pl pr bl br ml mr width available

pl means "padding left" etc.

Therefore the "used" value of mr (margin-right) has to be -250. In other
words, you actually get a right margin of -250px even though you asked
for one of 50px. The browser tries to give you what you ask for, but
where that isn't logically possible, it has to make the specified
compromises.

(Note that if direction were rtl, it would be the left margin that ended
up as -250).

MacIE appears to be drawing this right margin as +50px. That's wrong
according to today's specifications.

Thanks for this. It is much clearer now. Depending on the
direction, the browser leaves a last dimension to make the sum
good. In this case it is the poor mug right margin that gets the
unworldly but mathematically understandable treatment.

--
dorayme