Percent of what? A proposal

"Toby Inkster" <usenet200605 (AT) tobyinkster (DOT) co.uk> wrote:

The <p> element does not inherit font-size, since it has its font-size
explicitly set.

I didn't say that it did inherit the font size --

Well, I would say you did.

it's 90% of the
font-size it *would* have inherited had no font-size property been
specified; hence it's 90% of the inherited font size.

So you are referring to "inherited font size", thereby implying that the
element inherits the font size.

This may sound like splitting hairs, but I really prefer using the CSS
terminology instead of terms that imply some imaginary inheritance in a
situation where inheritance certainly does not take place. Inheritance is
confusing enough as it is, and imaginary inheritance doesn't help.

On Wed, 17 May 2006 01:32:01 +0800 ironcorona <iron.corona (AT) gmail (DOT) com> wrote:

phil-news-nospam (AT) ipal (DOT) net wrote:

|> The natural expectation of "50%" would be "half bright". However, #808080
|> does not give you that. The value that will is somewhere around #c0c0c0
|> depending on your video monitor.
|
| No, this refers to a percentage of an 8 bit colour value; red, green and
| blue.
| http://www.w3.org/TR/CSS1#color-units

Nothing useful is in that document because it does not provide any example
with a percentage value between 0% and 100% exclusively. The question is
what do you get with 50%.

There is no way to specify 50% of a colour with CSS.

Good. And I hope there never is one unless it takes gamma correction into
consideration the proper way.

When you are creating a new color, using a
percentage is really no different than using absolute byte codes

Exactly. It simply refers to 50% of the number between 0 and 255 which,
as you know, is how you specify RGB colour values with CSS.

It's a convenient notation of how to encode color values. It is NOT an
actual percentage value of the intensity. It will NOT give the expected
results. CSS developers were misguided by allowing a percentage to ever
be used even for encoding a color value because is misleads. Percentages
are traditionally used for linear light values, where 50% would be half
gray. But #808080 is NOT half gray ... it's just a code .. not a linear
value.

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

phil-news-nospam (AT) ipal (DOT) net wrote:

|> "Vague"? OK, maybe I meant that %'s meaning is too dependent on the
|> context in which it is used,
|
| They have to be dependent on the context in which they're used. They
| are fractions of something. What they are fractions of dependents on
| what they are and on where they are in relation to something else.

And you have to know that in order to do the calculation correctly.

So you're saying it would be better to have 18 new values ALL of which
can only be used in certain contexts. Surely you'd have to be aware of
where it's appropriate to use each of the new values too. Which means
you have exactly the same problem but now you can choose from one of
eighteen different solutions.

|> Gamma correction: do some research if you don't know what it's about.
|> Check out http://www.geocities.com/therealbirdin/Standards/#sRGB where
|> I think I did a semi-decent job of explaining why it's important.
|
| Why are people giving me pointers to gamma correction? I never asked.
| The % value isn't to do with gamma it's simply to do with a percentage
| of an 8 bit number.

Which is a totally assinine way to calculate intensity values.

Why, semantically it's perfectly correct. It's like saying that a 50%
of a box of width:300px; is 150px. You don't need to be concerned about
the area. You don't need to be concerned about the position of the
moon. Everyone understands that 50% of the width value means the width
value divided by 2.

You would
know that if you understood gamma correction and how calculations that do
not take it into consideration affect chromaticity.

You would know if you understood the spec what it's actually a
percentage of. Every time you mention gamma it's still not about gamma.
You could just reply to EVERY post with the words "GAMMA GAMMA GAMMA"
and it still wouldn't be about gamma. It's not about gamma. How don't
you understand that.

This is why I asked my question of you in the first case. I want to see
if you genuinely understand color, and how gamma correction affects it.
I'll try the question in a different way: If your intention is to get a
gray value which is exactly half the intensity of the color #ffffff, what
will be the code you would expect to see as a result?

I wouldn't be. I never even think of the colour intensity. If I want a
gray value I'll go into paint, double-click gray, move the lum pointer
up and down until I get a colour I like, translate the rgb values into
hex and there it is.


--
Brian O'Connor (ironcorona)

On Wed, 17 May 2006 10:46:37 +0800 ironcorona <iron.corona (AT) gmail (DOT) com> wrote:

phil-news-nospam (AT) ipal (DOT) net wrote:

|> "Vague"? OK, maybe I meant that %'s meaning is too dependent on the
|> context in which it is used,
|
| They have to be dependent on the context in which they're used. They
| are fractions of something. What they are fractions of dependents on
| what they are and on where they are in relation to something else.

And you have to know that in order to do the calculation correctly.

So you're saying it would be better to have 18 new values ALL of which
can only be used in certain contexts. Surely you'd have to be aware of
where it's appropriate to use each of the new values too. Which means
you have exactly the same problem but now you can choose from one of
eighteen different solutions.

What 18 values? The gamma curves for monitors? Did you make up "18"?

Two values need to be known. One is the default gamma that values which
already have the gamma correction applied used. For sources based on
PCs of "IBM compatibility" fame, that's about 2.2. The other value that
needs to be known is what the actual monitor in use has. The windowing
system should know that, and making available to the browser. Then the
browser will perform the correct calculations based on knowing these two
values. CSS's role is to not make the mistake of specifying that the
coded color values are assumed to be linear. If it were to make such a
mistake, we'd have browsers doing the calculations wrong, more meseed up
colors, and more hacks of people trying a variet of different non-standard
ways to compensate for such a mistake.

Assuming 2.2 for the gamma value of the coded colors is relatively safe.
Color values from the Macintosh world might not be so safe. What CSS
could do is provide a means to specify, broadly, or specifically, what
gamma value applies to the coded color values in a given .CSS file.
It probably should default to 2.2. But it provies a means for the
developer that uses other gamma values (assuming the developer even
understands what this is ... apparently way too many don't) to say
what they are. You could read the PNG image format specs to see how
they handle this (GIF didn't handle it at all).

Armed with the two values (which might be the same) the browser can then
correctly perform percentage of color type calculations by first converting
all values to linear using the source gamma value, then converting to gamma
corrected values again using the system display gamma value.

BTW, if there are no percentages of colors being applied, and if the source
gamma and display gamma are the same, no conversion calculations are needed.

|> Gamma correction: do some research if you don't know what it's about.
|> Check out http://www.geocities.com/therealbirdin/Standards/#sRGB where
|> I think I did a semi-decent job of explaining why it's important.
|
| Why are people giving me pointers to gamma correction? I never asked.
| The % value isn't to do with gamma it's simply to do with a percentage
| of an 8 bit number.

Which is a totally assinine way to calculate intensity values.

Why, semantically it's perfectly correct. It's like saying that a 50%
of a box of width:300px; is 150px. You don't need to be concerned about
the area. You don't need to be concerned about the position of the
moon. Everyone understands that 50% of the width value means the width
value divided by 2.

You need to be concerned with gamma correction if you want to do the color
calculations correctly. Ignore gamma and you could be doing it wrong.

You would
know that if you understood gamma correction and how calculations that do
not take it into consideration affect chromaticity.

You would know if you understood the spec what it's actually a
percentage of. Every time you mention gamma it's still not about gamma.
You could just reply to EVERY post with the words "GAMMA GAMMA GAMMA"
and it still wouldn't be about gamma. It's not about gamma. How don't
you understand that.

You are so ignorant about how video works it's shameful.

This is why I asked my question of you in the first case. I want to see
if you genuinely understand color, and how gamma correction affects it.
I'll try the question in a different way: If your intention is to get a
gray value which is exactly half the intensity of the color #ffffff, what
will be the code you would expect to see as a result?

I wouldn't be. I never even think of the colour intensity. If I want a
gray value I'll go into paint, double-click gray, move the lum pointer
up and down until I get a colour I like, translate the rgb values into
hex and there it is.

If you use a WYSIWYG color selector, you can get what you want. But if
you want to take percentages of those colors, you need to apply that in
the linear value domain, NOT in the coded value domain that you see in
expressions like "#ffffff". Do the calculations for me and see what you
get ... your source gamma is 2.2, your display gamma is 2.45, you want a
50% intensity of #ffffff, what do you get? I'll bet you either won't, or
can't, do this calculation yourself, correctly.

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

On Wed, 17 May 2006 22:28:27 +0100 Toby Inkster <usenet200605 (AT) tobyinkster (DOT) co.uk> wrote:

phil-news-nospam wrote:
ironcorona <iron.corona (AT) gmail (DOT) com> wrote:

| So you're saying it would be better to have 18 new values ALL of which
| can only be used in certain contexts.

What 18 values? The gamma curves for monitors? Did you make up "18"?

Go back and read the OP. 18.

Did. No 18.

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

phil-news-nospam (AT) ipal (DOT) net wrote:

On Wed, 17 May 2006 22:28:27 +0100 Toby Inkster <usenet200605 (AT) tobyinkster (DOT) co.uk> wrote:
| phil-news-nospam wrote:
|> ironcorona <iron.corona (AT) gmail (DOT) com> wrote:
|
|> | So you're saying it would be better to have 18 new values ALL of which
|> | can only be used in certain contexts.
|
|> What 18 values? The gamma curves for monitors? Did you make up "18"?
|
| Go back and read the OP. 18.

Did. No 18.

Count them

01 - %p
02 - %u
03 - %t
04 - %s
05 - %su
06 - %pw
07 - %uw
08 - %tw
09 - %sw
10 - %suw
11 - %w
12 - %ph
13 - %uh
14 - %th
15 - %sh
16 - %suh
17 - %h
18 - %


--
Brian O'Connor (ironcorona)

phil-news-nospam (AT) ipal (DOT) net wrote:

On Wed, 17 May 2006 10:46:37 +0800 ironcorona <iron.corona (AT) gmail (DOT) com> wrote:
| phil-news-nospam (AT) ipal (DOT) net wrote:
|
|> |> "Vague"? OK, maybe I meant that %'s meaning is too dependent on the
|> |> context in which it is used,
|> |
|> | They have to be dependent on the context in which they're used. They
|> | are fractions of something. What they are fractions of dependents on
|> | what they are and on where they are in relation to something else.
|
|> And you have to know that in order to do the calculation correctly.
|
| So you're saying it would be better to have 18 new values ALL of which
| can only be used in certain contexts. Surely you'd have to be aware of
| where it's appropriate to use each of the new values too. Which means
| you have exactly the same problem but now you can choose from one of
| eighteen different solutions.

What 18 values? The gamma curves for monitors? Did you make up "18"?

Why are you so obsessed about gamma? You keep going on and on and on
and on and on and on. What's with that? If you read the above quote
you can see the context in which I replied.

Two values need to be known. One is the default gamma that values which
already have the gamma correction applied used. For sources based on
PCs of "IBM compatibility" fame, that's about 2.2. The other value that
needs to be known is what the actual monitor in use has. The windowing
system should know that, and making available to the browser. Then the
browser will perform the correct calculations based on knowing these two
values. CSS's role is to not make the mistake of specifying that the
coded color values are assumed to be linear. If it were to make such a
mistake, we'd have browsers doing the calculations wrong, more meseed up
colors, and more hacks of people trying a variet of different non-standard
ways to compensate for such a mistake.

Assuming 2.2 for the gamma value of the coded colors is relatively safe.
Color values from the Macintosh world might not be so safe. What CSS
could do is provide a means to specify, broadly, or specifically, what
gamma value applies to the coded color values in a given .CSS file.
It probably should default to 2.2. But it provies a means for the
developer that uses other gamma values (assuming the developer even
understands what this is ... apparently way too many don't) to say
what they are. You could read the PNG image format specs to see how
they handle this (GIF didn't handle it at all).

Armed with the two values (which might be the same) the browser can then
correctly perform percentage of color type calculations by first converting
all values to linear using the source gamma value, then converting to gamma
corrected values again using the system display gamma value.

BTW, if there are no percentages of colors being applied, and if the source
gamma and display gamma are the same, no conversion calculations are needed.


|> |> Gamma correction: do some research if you don't know what it's about.
|> |> Check out http://www.geocities.com/therealbirdin/Standards/#sRGB where
|> |> I think I did a semi-decent job of explaining why it's important.
|> |
|> | Why are people giving me pointers to gamma correction? I never asked.
|> | The % value isn't to do with gamma it's simply to do with a percentage
|> | of an 8 bit number.
|
|> Which is a totally assinine way to calculate intensity values.
|
| Why, semantically it's perfectly correct. It's like saying that a 50%
| of a box of width:300px; is 150px. You don't need to be concerned about
| the area. You don't need to be concerned about the position of the
| moon. Everyone understands that 50% of the width value means the width
| value divided by 2.

You need to be concerned with gamma correction if you want to do the color
calculations correctly. Ignore gamma and you could be doing it wrong.

I can't effect the gamma adjustment. There's nothing I can do.
Apparently the

|> You would
|> know that if you understood gamma correction and how calculations that do
|> not take it into consideration affect chromaticity.
|
| You would know if you understood the spec what it's actually a
| percentage of. Every time you mention gamma it's still not about gamma.
| You could just reply to EVERY post with the words "GAMMA GAMMA GAMMA"
| and it still wouldn't be about gamma. It's not about gamma. How don't
| you understand that.

You are so ignorant about how video works it's shameful.

How about you go fuck yourself. Shameful is robbing a bank, shameful is
hurting people. Not knowing about how video works is unimportant.

|> This is why I asked my question of you in the first case. I want to see
|> if you genuinely understand color, and how gamma correction affects it.
|> I'll try the question in a different way: If your intention is to get a
|> gray value which is exactly half the intensity of the color #ffffff, what
|> will be the code you would expect to see as a result?
|
| I wouldn't be. I never even think of the colour intensity. If I want a
| gray value I'll go into paint, double-click gray, move the lum pointer
| up and down until I get a colour I like, translate the rgb values into
| hex and there it is.

If you use a WYSIWYG color selector, you can get what you want. But if
you want to take percentages of those colors,

WE'RE NOT TALKING ABOUT A PERCENTAGE OF A COLOUR. NOBODY WAS TALKING
ABOUT A PERCENTAGE OF A COLOUR UNTIL YOU BROUGHT IT UP FOR NO REASON.

you need to apply that in
the linear value domain, NOT in the coded value domain that you see in
expressions like "#ffffff". Do the calculations for me and see what you
get ... your source gamma is 2.2, your display gamma is 2.45, you want a
50% intensity of #ffffff, what do you get? I'll bet you either won't, or
can't, do this calculation yourself, correctly.

I explained that I know nothing about gamma. Why are you going on and
on and on and on and on and on and on and on and on and on and on and on
and on and on and on and on and on and on and on and on and on and on
and on and on and on and on and on and on and on and on and on and on
and on and on?

And if you're going to start personal attacks (as above) you can just go
fuck off right now.


--
Brian O'Connor (ironcorona)

ironcorona wrote:

phil-news-nospam (AT) ipal (DOT) net wrote:
On Wed, 17 May 2006 22:28:27 +0100 Toby Inkster <usenet200605 (AT) tobyinkster (DOT) co.uk> wrote:
| phil-news-nospam wrote:
|> ironcorona <iron.corona (AT) gmail (DOT) com> wrote:
|
|> | So you're saying it would be better to have 18 new values ALL of which
|> | can only be used in certain contexts.
|
|> What 18 values? The gamma curves for monitors? Did you make up "18"?
|
| Go back and read the OP. 18.

Did. No 18.

Count them

01 - %p
02 - %u
03 - %t
04 - %s
05 - %su
06 - %pw
07 - %uw
08 - %tw
09 - %sw
10 - %suw
11 - %w
12 - %ph
13 - %uh
14 - %th
15 - %sh
16 - %suh
17 - %h
18 - %

Each of these were intended to specify some linear measurement as a
percentage of some other linear measurement, which is not necessarily
measured in the same direction. The intent was to give the stylesheet
author the ability to override the default behavior of a simple % when
that default behavior is not what they want, and slightly expand the
options, specifically, the subtracted forms (currently this is the
default behavior for background image placement, which I propose to
make available to all elements) and specifying one dimension as a
percent of the other so that aspect ratios may be constant while actual
size is variable. NONE of these relate to color.

Specifying color as a percent of another color value really only makes
sense if you then ADD it to a percent of another color value. Since
mathematical expressions aren't currently supported in CSS rules,
there's no point in attempting to do this. Specifying colors by
triplets of percentages was made part of the standard, I assume, to
provide a more "user-friendly" alternative to hexadecimal or the 0-255
range in decimal. How gamma correction factors into that is an issue
of some importance, but I think that's better discussed in another
thread (maybe even on another newsgroup).

Anyway, the whole point here is that my original post dealt with % as a
factor of some other linear dimensional value, and has no relevance to
color or gamma correction.

--
Vid the Kid

VidTheKid wrote:

ironcorona wrote:
phil-news-nospam (AT) ipal (DOT) net wrote:
On Wed, 17 May 2006 22:28:27 +0100 Toby Inkster <usenet200605 (AT) tobyinkster (DOT) co.uk> wrote:
| phil-news-nospam wrote:
|> ironcorona <iron.corona (AT) gmail (DOT) com> wrote:
|
|> | So you're saying it would be better to have 18 new values ALL of which
|> | can only be used in certain contexts.
|
|> What 18 values? The gamma curves for monitors? Did you make up "18"?
|
| Go back and read the OP. 18.

Did. No 18.
Count them

01 - %p
02 - %u
03 - %t
04 - %s
05 - %su
06 - %pw
07 - %uw
08 - %tw
09 - %sw
10 - %suw
11 - %w
12 - %ph
13 - %uh
14 - %th
15 - %sh
16 - %suh
17 - %h
18 - %

Anyway, the whole point here is that my original post dealt with % as a
factor of some other linear dimensional value, and has no relevance to
color or gamma correction.

Yeah, I get that. It started with me defining what % values mean. In
terms of making them non-vague. The other stuff is a by-product of
someone arguing an irrelevant point.

I assume though that you're asking for comments on the OP. I'll be more
constructive if that's the case.


--
Brian O'Connor (ironcorona)

On Thu, 18 May 2006 10:33:34 +0800 ironcorona <iron.corona (AT) gmail (DOT) com> wrote:

phil-news-nospam (AT) ipal (DOT) net wrote:
On Wed, 17 May 2006 22:28:27 +0100 Toby Inkster <usenet200605 (AT) tobyinkster (DOT) co.uk> wrote:
| phil-news-nospam wrote:
|> ironcorona <iron.corona (AT) gmail (DOT) com> wrote:
|
|> | So you're saying it would be better to have 18 new values ALL of which
|> | can only be used in certain contexts.
|
|> What 18 values? The gamma curves for monitors? Did you make up "18"?
|
| Go back and read the OP. 18.

Did. No 18.

Count them

01 - %p
02 - %u
03 - %t
04 - %s
05 - %su
06 - %pw
07 - %uw
08 - %tw
09 - %sw
10 - %suw
11 - %w
12 - %ph
13 - %uh
14 - %th
15 - %sh
16 - %suh
17 - %h
18 - %

These were the original proportions of GEOMETRIC values that were proposed.
You then introduced the idea of taking a propotion of a CODED COLOR VALUE,
e.g. "50% of #ffffff". Gamma is applicable to the color values. It has
nothing to do with the geometric proportions. The fact that VidTheKid also
has correct and useful information about color gamma was a coincidence, but
also tells me he has a good grasp of a lot of the concepts of graphics.

I don't know whether CSS expressions like rgb(50%.50%,50%) deal with gamma
one way (a linear expression converted to gamma corrected values) or the
other (just a shorthand way to express a gamma corrected value) because I
haven't dwelled on that part of CSS, yet (and have not needed to because I
know the impact of expressing pre-corrected values like "#c0c0c0"). But,
you cannot possibly know how CSS is doing it because you clearly do not
even understand what gamma correction is to begin with. Any discussion of
gamma here, or in a CSS document, would obviously fly right over your head.
If you want to ever deal with color correctly, this is an area you need to
go learn (a lot) more about.

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------