Percent of what? A proposal

[VidTheKid]

THE PROBLEM
The % symbol is too vague when defining dimensions in CSS and HTML. It
can relate to an inherited value, a measure of the containing element
(which can differ between box models) or for background image
placement, the size of the element minus the size of the image.

A SOLUTION
There should be new %-like units defined in CSS to specify what the
measurement is a percentage of. These take the form of the % sign and
one or more letters:
%p - Percent of the similar measurement of the parent element, measured
"border to border." (Whether or not to count the border, I don't know.
But it should be standardized. Probably count the border on only one
side, but then what to do if the borders are asymmetrical?)
%u - Percent of the useable area inside the parent element. In other
words, the width of the parent element, minus the padding on each side.
%t - Percent of the total size of the parent element. In other words,
the width of the parent element, plus the margin on each side.
%s - Percent of the balance of the size of the element being defined
subtracted from the size of the parent element.
%su - Percent of the balance of the size of the element being defined
subtracted from the useable size of the parent element.
%pw - Percent of the width of the parent element, measured border to
border.
%uw - Percent of the useable width of the parent element.
%tw - Percent of the total width of the parent element.
%sw - Percent of the balance of the width of the element being defined
subtracted from the width of the parent element.
%suw - Percent of the balance of the width of the element being defined
subtracted from the useable width of the parent element.
%w - Percent of some width measurement of the parent element,
determined just like % but measuring horizontally regardless of what
property (such as height) is being defined.
%ph - Percent of the height of the parent element, measured border to
border.
%uh - Percent of the useable height of the parent element.
%th - Percent of the total height of the parent element.
%sh - Percent of the balance of the height of the element being defined
subtracted from the height of the parent element.
%suh - Percent of the balance of the height of the element being
defined subtracted from the useable height of the parent element.
%h - Percent of some height measurement of the parent element,
determined just like % but measuring vertically regardless of what
property (such as width) is being defined.
% - Still supported, with currently defined (or undefined) behavior.
(Mnemonics for all those letters are as follows: Height, Parent,
Subtracted, Total, Useable, Width. Width and height of the body
element, the html element, or its theoretical parent, should be
interpreted as the width and height of the document view area of the
browser window, or the physical print page. %i should probably also be
included to relate to inherited values, but I'm not sure how exactly to
define that.)

Additionally, new CSS properties should be defined to provide alternate
means of defining width and height of elements based on the intended
useable or total size:
useable-width - Defines the width of the element so that the space
inside the padding is as specified.
useable-height - Defines the height of the element so that the space
inside the padding is as specified.
total-width - Defines the width of the element so that the total
horizontal space consumed (including margins) is as specified.
total-height - Defines the height of the element so that the total
vertical space consumed (including margins) is as specified.
width - Still supported, with currently defined behavior.
height - Still supported, with currently defined behavior.

SOME USES
img#mainlogo {
width: 80%uw;
height: 45%uw;
margin: 50%suh 10%uw 1em 10%uw; }
defines that the img element with ID mainlogo (such as the main logo on
a web page) will scale with the width of the browser, but always stay
at a 16:9 aspect ratio. If the logo image is at the very top of the
page, it appears centered in the view when the user is scrolled to the
top. The margin between the image and following elements (such as h1)
scales with the user-selected font size.

div.datainput {
margin: 2px;
padding: .5em;
total-width: 50%u;
float: left; }
div.datainput input {
total-width: 100%u; }
defines div elements that can be used as columns, and input elements
that fill the useeable space within those columns. The gap between the
columns is a constant pixel value and the padding inside the columns
varies as the user changes the font size.

div.photo {
margin: .4em;
padding: .4em;
border: 1px solid;
useable-width: 200px;
float: left; }
defines a div element designed to contain an image known to be of width
200% (height not necessarily known) and some caption text. Margins and
padding scale with the user-selected font size.

body {
font-size: 1.5%w; }
defines that text in a document should vary in size according to the
width of the browser window (which often depends on screen resolution).
User-selected font size may provide additional variance.

Clearly, the vagueries of % need to be fixed. In my opinion, this is a
good way to do that, and a logical extension of existing CSS syntax.

--
Vid the Kid

[phil-news-nospam]

On 14 May 2006 15:53:04 -0700 VidTheKid <vi*******@gmail.com> wrote:

| THE PROBLEM
| The % symbol is too vague when defining dimensions in CSS and HTML. It
| can relate to an inherited value, a measure of the containing element
| (which can differ between box models) or for background image
| placement, the size of the element minus the size of the image.
|
| A SOLUTION
| There should be new %-like units defined in CSS to specify what the
| measurement is a percentage of. These take the form of the % sign and
| one or more letters:

Looks like everything you suggested is based on the parent element.
Why not ALSO have some additiona modifiers to refer to some other
element besides the parent element, such as:

Nth parent up (0 = parent, 1 = grandparent, 2 = greatgrandparent).
Nth child under specified element Nth parent element
Ancestor with specified class, id, or element.

It would also be nice to have expressions for any size allowing to
add or subtract, and maybe even multiply and divide multiple sizes.
At least then you could combine relative and fixed amounts.

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

[ironcorona]

VidTheKid wrote:

The % symbol is too vague when defining dimensions in CSS and HTML. It
can relate to an inherited value, a measure of the containing element
(which can differ between box models) or for background image
placement, the size of the element minus the size of the image.
http://www.w3.org/TR/REC-CSS1#percentage-units

For block level elements it's a % of the content area of its parent
element. Margin, border and padding are % of the box's parent element.
For fonts it's a % of the default value. In RGB color units it's a %
of the 8 bits in the red, green and blue channel. There are others.

You can take the rule that a % is a % of either the default value or the
parent element's value.

I wouldn't consider this vague. If you were to read the spec you'll
find everything defined.

http://www.w3.org/Style/CSS/

On the other hand, it might be useful to be able to define the total
width/height of an element (including content, padding, border and
margin) as a % value.
Clearly, the vagueries of % need to be fixed. In my opinion, this is a
good way to do that, and a logical extension of existing CSS syntax.

Yarrrrrrrgh!

--
Brian O'Connor (ironcorona)

[phil-news-nospam]

On Mon, 15 May 2006 13:14:28 +0800 ironcorona <ir*********@gmail.com> wrote:

| For fonts it's a % of the default value. In RGB color units it's a %
| of the 8 bits in the red, green and blue channel. There are others.

With or without gamma correction?

What would you expect to get from 50% of #ffffff ?
#808080 ? #c0c0c0 ?
| You can take the rule that a % is a % of either the default value or the
| parent element's value.
|
| I wouldn't consider this vague. If you were to read the spec you'll
| find everything defined.
|
| http://www.w3.org/Style/CSS/

At the level he has specified an idea, it seems he has at least read some
of the document. So no need to tell him where it is unless you are just
trying to have an attitude with him. Sure, he might have read the thing
very well ... feel free to point out _where_ within the document to find
specific things.
| On the other hand, it might be useful to be able to define the total
| width/height of an element (including content, padding, border and
| margin) as a % value.

What does 10.3.3 say?

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

[David Dorward]

ph**************@ipal.net wrote:

| For fonts it's a % of the default value. In RGB color units it's a %
| of the 8 bits in the red, green and blue channel. There are others.

With or without gamma correction?

What would you expect to get from 50% of #ffffff ?
#808080 ? #c0c0c0 ?
It is always 50% of ff.
| On the other hand, it might be useful to be able to define the total
| width/height of an element (including content, padding, border and
| margin) as a % value.

What does 10.3.3 say?

It describes the constraints there are when the browser calculates the total
width of the element - it does't let you specify the total width.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

[ironcorona]

ph**************@ipal.net wrote:

On Mon, 15 May 2006 13:14:28 +0800 ironcorona <ir*********@gmail.com> wrote:

| For fonts it's a % of the default value. In RGB color units it's a %
| of the 8 bits in the red, green and blue channel. There are others.

With or without gamma correction?
I have no idea what gamma correction does but I think you're nitpicking.
It is the same as using numerical RGB values or using the combination
of three octets in the hex units.
What would you expect to get from 50% of #ffffff ?
#808080 ? #c0c0c0 ?
Note that I said "In RGB color units it's a % of the 8 bits in the red,
green and blue channel"

it would look something like {color: rgb(50%,50%,50%)} which translates
to {color: rgb(128, 128, 128)} OR {color:#808080;}
| You can take the rule that a % is a % of either the default value or the
| parent element's value.
|
| I wouldn't consider this vague. If you were to read the spec you'll
| find everything defined.
|
| http://www.w3.org/Style/CSS/

At the level he has specified an idea, it seems he has at least read some
of the document. So no need to tell him where it is unless you are just
trying to have an attitude with him. Sure, he might have read the thing
very well ... feel free to point out _where_ within the document to find
specific things.
You think? Then why does he say that the % value is "vague".
| On the other hand, it might be useful to be able to define the total
| width/height of an element (including content, padding, border and
| margin) as a % value.

What does 10.3.3 say?

It refers to the containing block. If you, for instance, have the below

<div class="container">
<div class="insert"></div>
</div>

<style type="text/css">
..insert {width:100%; padding:10%; margin:10%; border:10%;}
</style>

Then the insert box would push its way out of the container box because
there's no way to specify the total width of the element (including
content, padding, border and margin) as a % value.

--
Brian O'Connor (ironcorona)

[phil-news-nospam]

On Mon, 15 May 2006 07:26:06 +0100 David Dorward <do*****@yahoo.com> wrote:
| ph**************@ipal.net wrote:
|
|> | For fonts it's a % of the default value. In RGB color units it's a %
|> | of the 8 bits in the red, green and blue channel. There are others.
|>
|> With or without gamma correction?
|>
|> What would you expect to get from 50% of #ffffff ?
|> #808080 ? #c0c0c0 ?
|
| It is always 50% of ff.

You're evading the question. Is that 50% to be applied to the gamma
corrected value, or the linear value?

With 50%, are you expecting a 50% gray level that would be equivalent in
total light output as interleaving white lines and black lines seen at a
distance?

--
-----------------------------------------------------------------------------
| 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]

On Mon, 15 May 2006 15:05:02 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@ipal.net wrote:
|> On Mon, 15 May 2006 13:14:28 +0800 ironcorona <ir*********@gmail.com> wrote:
|>
|> | For fonts it's a % of the default value. In RGB color units it's a %
|> | of the 8 bits in the red, green and blue channel. There are others.
|>
|> With or without gamma correction?
|
| I have no idea what gamma correction does but I think you're nitpicking.
| It is the same as using numerical RGB values or using the combination
| of three octets in the hex units.

I think you better learn what gamma correction does. Maybe the standards
people need to learn, too. Most of the graphics people, especially those
working with correct color values and working with video, know it.
|> What would you expect to get from 50% of #ffffff ?
|> #808080 ? #c0c0c0 ?
|
| Note that I said "In RGB color units it's a % of the 8 bits in the red,
| green and blue channel"
|
| it would look something like {color: rgb(50%,50%,50%)} which translates
| to {color: rgb(128, 128, 128)} OR {color:#808080;}

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.

Create a big box consisting of alternating horizontal lines 2px in height,
These will alternate between white (#ffffff) and black (#000000). Make
that box half the width of the page and position it on the left. Now make
another box and fill it with a solid gray color. Stand back at a distance
and judge the brightness of each box. Change the numeric value of the gray
box until it is just the same overall total brightness of the box that has
the alternating white and black lines. When you get that, then you will
know what your monitor needs for half brightness. This value can also tell
you the approximate gamma value for your monitor.

Google or Wiki for "gamma correction" for more info. Gamma correction is
the calculation of values to be used to make up for the gamma curve of the
CRT monitor phosphors.

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

[David Dorward]

ph**************@ipal.net wrote:

|> With or without gamma correction?
|>
|> What would you expect to get from 50% of #ffffff ?
|> #808080 ? #c0c0c0 ?
|
| It is always 50% of ff.

You're evading the question.

The question makes no sense. You don't get "50% of #ffffff" you
get "rgb(50%,50%,50%)" which is (to zero decimal places) the same
as "rgb(128,128,128)" or "#7f7f7f".

THEN gamma correction is applied, as per
http://www.w3.org/TR/CSS2/colors.html#gamma-correction

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

[ironcorona]

ph**************@ipal.net wrote:

On Mon, 15 May 2006 15:05:02 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@ipal.net wrote:
|> On Mon, 15 May 2006 13:14:28 +0800 ironcorona <ir*********@gmail.com> wrote:
|>
|> | For fonts it's a % of the default value. In RGB color units it's a %
|> | of the 8 bits in the red, green and blue channel. There are others.
|>
|> With or without gamma correction?
|
| I have no idea what gamma correction does but I think you're nitpicking.
| It is the same as using numerical RGB values or using the combination
| of three octets in the hex units.

I think you better learn what gamma correction does. Maybe the standards
people need to learn, too. Most of the graphics people, especially those
working with correct color values and working with video, know it.
From what I've been reading there's currently no way to set the gamma
values with CSS.
|> What would you expect to get from 50% of #ffffff ?
|> #808080 ? #c0c0c0 ?
|
| Note that I said "In RGB color units it's a % of the 8 bits in the red,
| green and blue channel"
|
| it would look something like {color: rgb(50%,50%,50%)} which translates
| to {color: rgb(128, 128, 128)} OR {color:#808080;}

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

--
Brian O'Connor (ironcorona)

[Jim Moe]

VidTheKid wrote:

THE PROBLEM
The % symbol is too vague when defining dimensions in CSS and HTML. It
can relate to an inherited value, a measure of the containing element
(which can differ between box models) or for background image
placement, the size of the element minus the size of the image.

Why present this here? We can do nothing about it.
See <http://www.w3.org/Style/CSS/members.php3>.

--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)

[Neredbojias]

To further the education of mankind, ironcorona <ir*********@gmail.com>
vouchsafed:

On the other hand, it might be useful to be able to define the total
width/height of an element (including content, padding, border and
margin) as a % value.

No! That would take all the fun out of css.

--
Neredbojias
Infinity has its limits.

[VidTheKid]

Referring to nth parent up: I suppose this could be done by
introducing a decimal digit among the letters after the % sign, up to
some perhaps arbitrary limit like 3 or 9. As far as explicitly
combining (via arithmatic) multiple other values to define dimensions,
that's a much bigger step than I think CSS can easily make. That would
make it perhaps function more like a sequential instruction language
rather than an asyncrhonous list of formatting rules. If you're going
to go in that direction, you might as well introduce variables and
branching. Javascript already provides this advanced functionality.

"Vague"? OK, maybe I meant that %'s meaning is too dependent on the
context in which it is used, and that meaning isn't always what the
author wants. (Take a look at the other thread where someone wanted a
text input element to fill the useable space inside a table cell with
padding while using doctype:strict.)

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.

--
Vid the Kid

[ironcorona]

VidTheKid wrote:

First of all:
http://www.safalra.com/special/googlegroupsreply/

Referring to nth parent up: I suppose this could be done by
introducing a decimal digit among the letters after the % sign, up to
some perhaps arbitrary limit like 3 or 9. As far as explicitly
combining (via arithmatic) multiple other values to define dimensions,
that's a much bigger step than I think CSS can easily make. That would
make it perhaps function more like a sequential instruction language
rather than an asyncrhonous list of formatting rules. If you're going
to go in that direction, you might as well introduce variables and
branching. Javascript already provides this advanced functionality.

"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 that meaning isn't always what the
author wants.
We all have to follow the same rules or else you get browser wars.

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.

--
Brian O'Connor (ironcorona)

[VidTheKid]

ironcorona wrote:

VidTheKid wrote:

First of all:
http://www.safalra.com/special/googlegroupsreply/
I know how to do proper replies on Google Groups. It just wasn't
convenient in this case because I was responding to multiple people.

"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.

Yes, but why does that "something else" have to be essentially guessed
based on context? Why can't it be specified directly by the stylesheet
author?
We all have to follow the same rules or else you get browser wars.

True. But that won't stop me from trying to get those same rules
improved. This proposal was intended as a change to the official CSS
specifications, not rogue browser implementaion.

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.

Someone made a reference to a percent of a color, someone else asked if
that included gamma correction, someone asked what gamma correction was
(or at least stated that they did not know -- equivalent in my mind),
and I was helping with an answer.

--
Vid the Kid

[Toby Inkster]

ironcorona wrote:

For fonts it's a % of the default value.

Actually, it's a percentage of the *inherited* value.

i.e.

<html>
<title>Example</title>
<div style="font-size:90%">
<p style="font-size:90%">
I am not 90% of the default font size; I am 81%.
</p>
</div>
</html>

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

[Toby Inkster]

VidTheKid wrote:

a logical extension of existing CSS syntax

Seems over-complicated to me. Percentages seem to work fairly well already.
What I *would* like to see is some basic maths support in CSS.

e.g.

<div id="nav">...</div>
<div id="main">...</div>

#nav {
float: left;
padding: 0.5em;
margin: 0 0.5em;
width: 180px;
}

#main {
float: left;
padding: 0.5em;
margin: 0 0.5em;
width: 100% - (180px + 4em);
}

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

[Jukka K. Korpela]

"Toby Inkster" <us**********@tobyinkster.co.uk> wrote:

For fonts it's a % of the default value.
Actually, it's a percentage of the *inherited* value.

Technically it isn't. It's a percentage of the parent element's font size;
see
http://www.w3.org/TR/REC-CSS2/fonts....ont-size-props
(More exactly, it is relative to the parent element's _computed_ font-size
value, though the specs aren't crystal clear on this. Thus, if the parent
element has font-size: 11.5pt and no such font size for the font is
available in an implementation, leading to the use of the closest size such
as 12pt, percentages would relate to the "computed value" of 11.5pt and not
the "actual value" 12pt.)
<div style="font-size:90%">
<p style="font-size:90%">
I am not 90% of the default font size; I am 81%.
</p>
</div>

The computed size is indeed 81% of the font size of the parent of the <div>,
but inheritance plays no role here. The <p> element does not inherit
font-size, since it has its font-size explicitly set.

[Toby Inkster]

Jukka K. Korpela 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 -- 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.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

[phil-news-nospam]

On Mon, 15 May 2006 18:53:47 +0100 David Dorward <do*****@yahoo.com> wrote:
| ph**************@ipal.net wrote:
|
|> |> With or without gamma correction?
|> |>
|> |> What would you expect to get from 50% of #ffffff ?
|> |> #808080 ? #c0c0c0 ?
|> |
|> | It is always 50% of ff.
|>
|> You're evading the question.
|
| The question makes no sense. You don't get "50% of #ffffff" you
| get "rgb(50%,50%,50%)" which is (to zero decimal places) the same
| as "rgb(128,128,128)" or "#7f7f7f".
|
| THEN gamma correction is applied, as per
| http://www.w3.org/TR/CSS2/colors.html#gamma-correction

That does not specify what this _proposed_ idea does. But it does suggest
that the application of proportions will be applied to the _already_
corrected color value, which is wrong _regardless_ of what CSS documents
say. If it is applied after gamma correction, then it is not a proportion
of intensity ... it is instead a tool that will just produce more bad
colors on the net.

--
-----------------------------------------------------------------------------
| 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]

On Tue, 16 May 2006 02:38:42 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@ipal.net wrote:
|> On Mon, 15 May 2006 15:05:02 +0800 ironcorona <ir*********@gmail.com> wrote:
|> | ph**************@ipal.net wrote:
|> |> On Mon, 15 May 2006 13:14:28 +0800 ironcorona <ir*********@gmail.com> wrote:
|> |>
|> |> | For fonts it's a % of the default value. In RGB color units it's a %
|> |> | of the 8 bits in the red, green and blue channel. There are others.
|> |>
|> |> With or without gamma correction?
|> |
|> | I have no idea what gamma correction does but I think you're nitpicking.
|> | It is the same as using numerical RGB values or using the combination
|> | of three octets in the hex units.
|>
|> I think you better learn what gamma correction does. Maybe the standards
|> people need to learn, too. Most of the graphics people, especially those
|> working with correct color values and working with video, know it.
|
| From what I've been reading there's currently no way to set the gamma
| values with CSS.

You don't need to. The browser should acquire it from the display system.
|> |> What would you expect to get from 50% of #ffffff ?
|> |> #808080 ? #c0c0c0 ?
|> |
|> | Note that I said "In RGB color units it's a % of the 8 bits in the red,
|> | green and blue channel"
|> |
|> | it would look something like {color: rgb(50%,50%,50%)} which translates
|> | to {color: rgb(128, 128, 128)} OR {color:#808080;}
|>
|> 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%. When you are creating a new color, using a
percentage is really no different than using absolute byte codes, other
than for the scale they operate in. But even CSS1 doesn't say for sure
how they are expecting this to be handled. They are just leaving it up
to the browser to figure it out. Maybe it will do it right.

The issue is when you apply the percentage to an already codified color
value. You have to know whether than color code is already gamma corrected
or not. Nothing in CSS1 or CSS2 says this, because nothing in them has
any feature to do a percentage _modification_ of an _existing_ color code.
Remember, this was a _proposed_ feature addition. You do not need to know
whether the existing color code is already gamma corrected in the case of
creating a new color because you aren't dealing with an existing color.

You can create a new color with rgb(50%,50%,50%) or #808080. You might not
get what you _think_ you would get. But that is an entirely different issue
than taking 50% of some color already codified. The example of #ffffff does
not expose the issue directly. An example of "50% of #ffcc99", however,
would, because if not done in consideration of gamma correction will cause
a chroma shift of that color. That color may have been acquired from some
other source that expected a specified chroma value and this would be making
changes in the chroma, not just the intensity, unless the browser applies
the reverse of the gamma correction to the coded value (using the gamma
value it thinks the monitor is using, maybe acquired from the video driver),
performs the linear intesity calulation, then re-corrects for gamma.

My question is whether this will be specified as part of how the browser
should handle taking a percentage of an already coded color.

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

[ironcorona]

ph**************@ipal.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.
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.

--
Brian O'Connor (ironcorona)

[phil-news-nospam]

On 15 May 2006 16:33:45 -0700 VidTheKid <vi*******@gmail.com> wrote:
| Referring to nth parent up: I suppose this could be done by
| introducing a decimal digit among the letters after the % sign, up to
| some perhaps arbitrary limit like 3 or 9. As far as explicitly
| combining (via arithmatic) multiple other values to define dimensions,
| that's a much bigger step than I think CSS can easily make. That would
| make it perhaps function more like a sequential instruction language
| rather than an asyncrhonous list of formatting rules. If you're going
| to go in that direction, you might as well introduce variables and
| branching. Javascript already provides this advanced functionality.
|
| "Vague"? OK, maybe I meant that %'s meaning is too dependent on the
| context in which it is used, and that meaning isn't always what the
| author wants. (Take a look at the other thread where someone wanted a
| text input element to fill the useable space inside a table cell with
| padding while using doctype:strict.)
|
| 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.

Yes, I think you did a decent job for the given audience.

There is a different issue in producing one's own color value and taking
some percentage of existing color values. If they are already corrected
for the gamma curve, they need to be translated "back" (they might never
have been there to begin with given the common practices of coding colors
to get what looks nice) to linear, calculated, then translated back to
gamma corrected. One catch with this is it introduces a new effect where
a finite set of colors may end up becoming a smaller finite set of colors.
When taking 50% of a value, that's not going to be a problem. But if the
intent is to up the brightness like 200%, then not only are the top ends
clipped, but also fewer colors in the range below clipping are used, and
this can introduce some striping effects similar to digitizing with too
few bits (I get around this by generating images with a lot more bits of
coding than just 8 bits when I know post generation calculations are going
to be done).

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

[Jukka K. Korpela]

"Toby Inkster" <us**********@tobyinkster.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.

[phil-news-nospam]

On Tue, 16 May 2006 12:53:37 +0800 ironcorona <ir*********@gmail.com> wrote:
| VidTheKid wrote:
|
| First of all:
| http://www.safalra.com/special/googlegroupsreply/
|
|> Referring to nth parent up: I suppose this could be done by
|> introducing a decimal digit among the letters after the % sign, up to
|> some perhaps arbitrary limit like 3 or 9. As far as explicitly
|> combining (via arithmatic) multiple other values to define dimensions,
|> that's a much bigger step than I think CSS can easily make. That would
|> make it perhaps function more like a sequential instruction language
|> rather than an asyncrhonous list of formatting rules. If you're going
|> to go in that direction, you might as well introduce variables and
|> branching. Javascript already provides this advanced functionality.
|>
|> "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.
It's NOT just a simple multiplication if the value involved is already
gamma corrected.
|> and that meaning isn't always what the
|> author wants.
|
| We all have to follow the same rules or else you get browser wars.

And the rules need to be made correct the first time, else we have legacy
standards brokenness that ends up creating lots of problems until about
10 years after someone finally decides to fix the standards. So the best
time to make a proposal right is before it gets adopted.
|> 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. You would
know that if you understood gamma correction and how calculations that do
not take it into consideration affect chromaticity. Using a percentage as
a way to express a pre-corrected color value it one thing. But using a
percentage to adjust an already gamma corrected value is entirely another.
It's already common practice to express color values numerically in their
pre-corrected form. Usually this is not much of an issue because people
generally just pick some color that looks nice, rather than intentionally
trying to (and making sure they) get a specific emission proportion.

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?

--
-----------------------------------------------------------------------------
| 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]

On Wed, 17 May 2006 01:32:01 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@ipal.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/ |
-----------------------------------------------------------------------------

[Neredbojias]

To further the education of mankind, Toby Inkster
<us**********@tobyinkster.co.uk> vouchsafed:

Seems over-complicated to me. Percentages seem to work fairly well
already. What I *would* like to see is some basic maths support in
CSS. #main {
float: left;
padding: 0.5em;
margin: 0 0.5em;
width: 100% - (180px + 4em);
}

_That_ would be one giant step forward. However, you can do it via php
now.
--
Neredbojias
Infinity has its limits.

[ironcorona]

ph**************@ipal.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)

[Toby Inkster]

Neredbojias wrote:

Toby Inkster vouchsafed:

#main {
float: left;
padding: 0.5em;
margin: 0 0.5em;
width: 100% - (180px + 4em);
}

_That_ would be one giant step forward. However, you can do it via php
now.

You can do maths via PHP for sure. e.g.

#main {
float: left;
padding: 0.5em;
margin: 0 0.5em;
width: <?php echo (4+2+5); ?>em;
}

But PHP wouldn't be any use for the earlier example because only the
client knows the "conversion factors" required to be able to mix units.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

[Neredbojias]

To further the education of mankind, Toby Inkster <usenet200605
@tobyinkster.co.uk> vouchsafed:

Neredbojias wrote:

Toby Inkster vouchsafed:

#main {
float: left;
padding: 0.5em;
margin: 0 0.5em;
width: 100% - (180px + 4em);
}

_That_ would be one giant step forward. However, you can do it via php
now.

You can do maths via PHP for sure. e.g.

#main {
float: left;
padding: 0.5em;
margin: 0 0.5em;
width: <?php echo (4+2+5); ?>em;
}

But PHP wouldn't be any use for the earlier example because only the
client knows the "conversion factors" required to be able to mix units.

Yes, that's a good point. I realized after I posted that it would hardly
be dynamic. Maths of this sort would be a boon to css, indeed.

--
Neredbojias
Infinity has its limits.

[phil-news-nospam]

On Wed, 17 May 2006 10:46:37 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@ipal.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/ |
-----------------------------------------------------------------------------

[Toby Inkster]

phil-news-nospam wrote:

ironcorona <ir*********@gmail.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.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

[phil-news-nospam]

On Wed, 17 May 2006 22:28:27 +0100 Toby Inkster <us**********@tobyinkster.co.uk> wrote:
| phil-news-nospam wrote:
|> ironcorona <ir*********@gmail.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/ |
-----------------------------------------------------------------------------

[ironcorona]

ph**************@ipal.net wrote:

On Wed, 17 May 2006 22:28:27 +0100 Toby Inkster <us**********@tobyinkster.co.uk> wrote:
| phil-news-nospam wrote:
|> ironcorona <ir*********@gmail.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)

[ironcorona]

ph**************@ipal.net wrote:

On Wed, 17 May 2006 10:46:37 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@ipal.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)

[VidTheKid]

ironcorona wrote:

ph**************@ipal.net wrote:

On Wed, 17 May 2006 22:28:27 +0100 Toby Inkster <us**********@tobyinkster.co.uk> wrote:
| phil-news-nospam wrote:
|> ironcorona <ir*********@gmail.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

[ironcorona]

VidTheKid wrote:

ironcorona wrote:

ph**************@ipal.net wrote:

On Wed, 17 May 2006 22:28:27 +0100 Toby Inkster <us**********@tobyinkster.co.uk> wrote:
| phil-news-nospam wrote:
|> ironcorona <ir*********@gmail.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)

[phil-news-nospam]

On Thu, 18 May 2006 10:33:34 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@ipal.net wrote:
|> On Wed, 17 May 2006 22:28:27 +0100 Toby Inkster <us**********@tobyinkster.co.uk> wrote:
|> | phil-news-nospam wrote:
|> |> ironcorona <ir*********@gmail.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/ |
-----------------------------------------------------------------------------

[ironcorona]

ph**************@ipal.net wrote:

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".

The exact quote from me in <44********@quokka.wn.com.au>:

"% of the 8 bits in the red, green and blue channel"

note "%" and "8 bits"

50% of #ffffff is an idea that you first mentioned in
<e4********@news2.newsguy.com>

I never said that % equals a percentage of a colour. This too is an
idea that you came up with.

--
Brian O'Connor (ironcorona)

[phil-news-nospam]

On Fri, 19 May 2006 02:06:32 +0800 ironcorona <ir*********@gmail.com> wrote:
| ph**************@ipal.net wrote:
|
|> 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".
|
| The exact quote from me in <44********@quokka.wn.com.au>:
|
| "% of the 8 bits in the red, green and blue channel"
|
| note "%" and "8 bits"
|
| 50% of #ffffff is an idea that you first mentioned in
| <e4********@news2.newsguy.com>
|
| I never said that % equals a percentage of a colour. This too is an
| idea that you came up with.

What do you think "8 bits in the red, green and blue channel" is? Linear?

Stay away from any kind of color/intensity calculations. You can't handle
them.

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