W3C home > Mailing lists > Public > www-style@w3.org > January 2009

Re: unit expander

From: Josef Schmid <e9427749@student.tuwien.ac.at>
Date: Tue, 13 Jan 2009 21:38:00 +0100
Message-ID: <496CFBA8.60408@student.tuwien.ac.at>
To: www-style@w3.org
CC: Giovanni Campagna <scampa.giovanni@gmail.com>

Hi, Giovanni!

Giovanni Campagna schrieb:
> As I said before, you may introduce a chw(<string>,<simple selector>)
> function (which stands for char-width), or even a
> link-value(<property-name>,<simple-selector>) to avoid at all parsing
> issues.

----
The fun(...) form is more for programmers as for web developers.
Especially if nesting is needed, ala fun1(fun2(fun3(...),...)) .
----
For the string/char width the different possibilities in style are:
    some-property: 0.7width of "string"
    some-property: 0.7width-of "string"
    some-property: 0.7e"string"
    some-property: 0.7e("string")
    some-property: str("string",0.7)
All can be done.
So this is a matter of
* taste
* readability, teachability
* conceptual extension with can be used for other new things too,
   or fitting in what is here already.
* paradigms or ideologies (no value restricting keywords etc)
* ...


> But there are many other problems: [...]
> 2) linking properties between otherwise unrelated element can be difficult
> to implement (ie. needing for a complete DOM, for actual values elaborated,
> etc.)

You have remarked/quest in more detail earlier.
I hope i could provide answers to all your questions.

> For 2), instead, I'm not an implementor so I don't actually know how
> difficult it would be. I would wait for browser developers.
----

Back to the top.
link-value(<property-name>,<simple-selector>) looks more traditionally,
but introduce generic types.
Because the context type (=result) depend on the first parameter.
     T link-type(T,....)
So the parser must treat this special either look-ahead
behind link-value, or store the expected value type of the
property and check it later.
And it is more difficult if you have other such functions.

This is not needed for unit expander variant form 'from'.
E.g.:
Compare
   await-length-property: link-value(1em,:root)
with
   await-length-property: 1em from :root
And
   await-length-property: link-value(str("m",0.7),:root)
with
   some-property: 0.7width of "string" from :root

----
I like the 'from' proposal because it solves different use cases
a) access viewport widht & height form anywhere.
    e.g. height: 70% from :root
b) correlate lenghts with others:
    e.g. width: 100% from (table.above)
c) a more powerful alternative for the rem unit
    e.g. font-size: 1.2em from .my-reference-container
d) and likely others that doesn't come to my mind.

----
But of course, other solution are possible.
And maybe more narrow-minded proposals, are more welcome...


bye,
   Jos "tormentor of native-speakers" ef
Received on Tuesday, 13 January 2009 20:39:04 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:15 GMT