relative dimension values.

As stated in CSS 2,
Box model/Width:
"The percentage is calculated with respect to the width of the generated
box's containing block."

This makes percentable values completely useless.

If we will change this definition to:
"The percentage is calculated with respect to the width of the generated
box's containing block *minus widths of all fixed elements in the line*".

Illustration:
Lets say we have three blocks placed inline with widths 25%, 100px and 75%:

---25%--->|<---fixed:100px--->|<----------75%--------->|

Actual first and third block widths will be calculated from
ContainerContentWidth-100px weighted by their percentable values.

Using proposed alghorithm it is possible to mix fixed and "spring" content
without any tables.
Same approach should apply to heights.

Another illustration:
<P>Here is first input element <INPUT width=100px> and <SPAN
class=bigfont>here</SPAN> is another: <INPUT width=100%></P>
If we will use new schema then last input element will occupy the rest of
the line.
Layout like this cannot be implemented even with <table> because of base
line issues.

I've implemented this alghorithm in my experimental rendering engine.
Implementation is pretty simple and do not increase comlexity of layout
alghorithms significantly.
If anybody want to take a look just drop me message.

Andrew Fedoniouk.
http://TerraInformatica.com

PS: Does anybody know where is the best place to publish proposals like
this?

Andrew Fedoniouk wrote:

As stated in CSS 2,

Did you miss comp.infosystems.www.authoring.stylesheets?

Box model/Width:
"The percentage is calculated with respect to the width of the generated
box's containing block."

This makes percentable values completely useless.

In your opinion. I find them quite useful.

If we will change this definition to:
"The percentage is calculated with respect to the width of the generated
box's containing block *minus widths of all fixed elements in the line*".

Yeah! Break backwards compatibility! Woo!

Illustration:
Lets say we have three blocks placed inline

If they are blocks, then they are almost certainly not inline. (Unless you
are using the supported-only-by-Opera display: inline-block.

with widths 25%, 100px and 75%:
|<---25%--->|<---fixed:100px--->|<----------75%--------->|

What about floats?

If that first element is floated, is it supposed to be part of that "line"?
How is the UA supposed to tell?

Using proposed alghorithm it is possible to mix fixed and "spring" content
without any tables.

Gosh, and here I was thinking that you could do that with display: table-*
all this time.

PS: Does anybody know where is the best place to publish proposals like
this?

http://lists.w3.org/Archives/Public/www-style/

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>

If we will change this definition to:
"The percentage is calculated with respect to the width of the generated
box's containing block *minus widths of all fixed elements in the
line*".

Yeah! Break backwards compatibility! Woo!

It is enough to introduce %% size unit for that and let % stay as is.

If they are blocks, then they are almost certainly not inline. (Unless you
are using the supported-only-by-Opera display: inline-block.

inline-blocks are already in W3C recomendations.
Browsers which are not implementiong this cannot be treated
as conformant browsers. Right?

with widths 25%, 100px and 75%:
|<---25%--->|<---fixed:100px--->|<----------75%--------->|

What about floats?

If that first element is floated, is it supposed to be part of that
"line"?
How is the UA supposed to tell?

I cannot see any problems with floats here.
See the behavior of text line with text-align: justify in this case.
You may think that each whitespace in the line is given percentable width
value.

Gosh, and here I was thinking that you could do that with display: table-*
all this time.

Yep, very clever - to regret <TABLE> as a layout instrument and to invent
table-* styles.

http://lists.w3.org/Archives/Public/www-style/

Thanks a lot,

Andrew Fedoniouk.
http://terrainformatica.com

Andrew Fedoniouk wrote:

Yep, very clever - to regret <TABLE> as a layout instrument and to invent
table-* styles.

That would be because <table> says something about the data, while table-*
styles simply describe how it should be laid out.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>

"Andrew Fedoniouk" <news (AT) terrainformatica (DOT) com> wrote

Yep, very clever - to regret <TABLE> as a layout instrument and to invent
table-* styles.

For the same reason that it's better to use CSS properties instead of FONT
tags, ALIGN attributes, BGCOLOR attributes; instead of using BLOCKQUOTE to
indent paragraphs that aren't quotes; and so on. The only reason not to
right now is lack of support.

"David Dorward" <dorward (AT) yahoo (DOT) com> wrote:

That would be because <table> says something about the data, while table-*
styles simply describe how it should be laid out.

Did you try to use them practically? I suspect no.
table-* styles do not help in most cases: no colspan/rowspan, no
percentable/weighted width/height (similar to old <table> model).

Andrew Fedoniouk.
http://terrainformatica.com