Re: [css-variables] a more "Classical" approach

W dniu 04.06.2014 17:13, François REMY pisze:
[---------------]
>>
>> what I'm trying to propose is something like "temporary style 
>> storage", which when used, is to be "joined" with "current main css", 
>> much like tables are joined in RDBMS.
>
> Not sure what you mean, but the current plan are to work on macros; I 
> don't see how your example is any different from what a macro 
> provides. Could you please detail how you propose is different from a 
> macro in a concrete example?

OK.

Macro example:
https://gcc.gnu.org/onlinedocs/cpp/Macro-Arguments.html

.. having a look at first example there, the processing is:
1. macro definition (apart from #define) consists of lest side (the 
introduces string), and right side (the replacement string).
2. macro-processor at the point when macro s to be expanden: takes 
left-hand side of definition, finds braces and arguments within them
3. macro-processor then searches the right-hand side looking for 
charachter-strings equal to charachter strings of argument names
4. macro-processor then takes current arguments (e.g where macro is 
called), and replaces charachter strings of arguments as found within 
right-hand side of macro definition, with current charachter-strings of 
macro arguments at the point where macro is invoked.
5. the resulting string replaces textual space originally ocupies by 
macro invocation string.

All string operations.

now the "CSS macros I'm thinking of", example:
$my-style, h1 {font-weight: bold; margin-left: 1ex; 
padding:3pt;border-radius:12pt}
p, $my-style {font-style:italic;border-color:green}
ul {border: $my-style }
$my-style {border-left:red}

Its intepretation:
1. I would imagine, that $variables procesing should be completted 
entirely, before CSS engine starts to use it (like in line with "ul" above).
2. so at the point when "ul" is styled, $my-style contains: 
{font-weight: bold; margin-left: 1ex; 
padding:3pt;border-radius:12pt;font-style:italic;border-color:green;border-left:red}
3. in the process of "ul" style calculation, any "border" components of 
the $my-style is selected and applied to "ul". In this example, it would 
be equivalent to: "ul {border-color:green;border-left:red}", no other 
content of $my-style should propagate to "ul" style, since only "border" 
attributes is selected there.

So the semantics of this is not "textual substitution", but "set 
product" instead. somilar (although not the same) as cascading.

[-----------------]
> - Custom Properties allow developers to add design meta-data to their 
> elements which they can read from JavaScript.
> - Custom Properties allow developrs to create/polyfill new css 
> properties, with the help of a companion script.
> - Custom Properties can be overriden at the element level, which 
> allows DOM-aware variables:
> --> example: you can define "primary-color" as red for your page, but 
> green in a specific widget; all components inside the widget will have 
> the usual styling but because the "primary-color" custom property will 
> be inherited to green, they will render differently inside or outside 
> of the widget.
>
> In addition, Custom Properties references (var(--property-name)) allow 
> to solve the usual variables refactoring problem faced in CSS. It is 
> kinda like a two-in-one. The only thing variables do not solve but 
> macro would is mixins.

I see.

Yet. Correctly if I'm wrong, but is there any web-design problem, that 
current javaScript cannot address withiout this additional support from 
CP? The above provided examples don't look like that.

[--------------------]
>
> This is why I think this example is confusing: if you read it too 
> fast, you may think Custom Properties allow conditions and statements, 
> which isn't true at all. They just allow to write any almost-arbritary 
> content, because CSS does not try to understand it.

Yes. I get it now :)

Still, all this does not convince me.

And my main objection is that I don't think that web-design with current 
javascript does need those CP features desperately; while I do think 
that we do need a tool to take "styling" to a higher level of 
abstraction. We need a "common style properties" (a style of styling a 
page) similar to those stored in properties-variables, which are 
*recognized* and *executed* by the CSS engine itself (e.g. ain't 
transparent to it). I'd say, that just like in earlier days, when style 
was separated from markup (e.g. from HTML), thus bringing higher level 
of abstraction on the pages (towards MCV Dave Kok mentions in a later 
post), and keeping in mind, that subsequently XTL didn't quite catch it 
(possibly to ambitious); so, a simple step towards that goal is 
necesary, while "a repository of styling-data for companion scripting" 
is not (IMHO).

-R

Received on Wednesday, 4 June 2014 16:16:52 UTC