W3C home > Mailing lists > Public > www-style@w3.org > June 2014

Re: It's time for contextual positioning

From: Rafał Pietrak <rafal@ztk-rp.eu>
Date: Wed, 11 Jun 2014 08:36:49 +0200
Message-ID: <5397F901.7040707@ztk-rp.eu>
To: www-style@w3.org
W dniu 10.06.2014 22:18, Tab Atkins Jr. pisze:
>>> position:contextual;
>>> context:#elementID
>> I strongly agree that something like this is necessary! However, I'd 
>> like to consider it as part of a general overhaul and sanification of 
>> absolute positioning, rather than jumping straight into a custom 
>> solution. ~TJ 

So if further consideration is due, I'd like to file a small comment here.

1. "in the spirit" of "cascading", the element referred to by "context:" 
in that example, should not require being an ID. I would think it should 
be just any selector CSS recognizes. possibly, a selector string just 
like jquery uses.

2. I would think, that being able to referre (by "context:" token) to 
other elements in order to "suck in" some styles from referred element 
should not be refrained to just position attributes.

So I'd vote to device a generic syntax for such "referring to" cases. 
And gravitating towards (along my earlier expressed desire for 
$variables, with the above requirements in mind), I'm thinking of 
"syntax excape code" at the attribute value level.

If I'm not mistaken, the @ character does not have any special meaning 
at the attribute value level, so the syntax could be:

nav.menu {width:100%}
.menu ul { position: absolute @ "nav.menu"; bottom:0;left:100%}
h2 {font-color: @ ".title h1"}

meaning, that the "@" character would mean "take the value from elements 
seleced as followes", and that excape characted bares that meaning only 
when encountered at places, where one would expect "end-of-value" 
character: ";" or "}", or right after attribute name collon.

if "@" is already taken, I can see other suitable candidates: "^", or 
"/", or a doublet: /" ... "/ (here " is part of the doublet).

Naturally, this could create closed loops of referrencies, so I'd 
sugest, that this extention would define a "two pass" processing. First 
pass only registers "referreal requests", and calculates all the styles 
as if those where not there (treating "@...;" just like a comment). And 
the seocnd pass takes and  processes only the "@" "adjustments", using 
only values calculated during the first pass. A Makefile style 
dependency tree, build during the second pass, could be "more intuitive" 
for web designers .... but it also could be more error prone, so despite 
me desire to have, I would opt for a simpler standard.

Received on Wednesday, 11 June 2014 06:37:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:43 UTC