Blake, I like this proposal a lot. It is easy to understand and it's much more compact.
.AFTestBackgroundColor:alias {color: -tr-property-ref(".AFTestForegroundColor:alias", "background-color")}

I should point out that this is different than our other special CSS syntaxes where the property name is a special property name (-tr-rule-ref, -tr-inhibit).
-tr-rule-ref:selector(".AFDefaultFont:alias");
-tr-inhibit: color;

In your syntax it's the property value that is a new syntax. It is a little different, but I agree that it makes sense.

The alternative is what we discussed in the email thread earlier:
.AFTestForegroundColor:alias {color: red;}
.AFTestBackgroundColor:alias {
  -tr-include-property: property(selector=".AFTestForegroundColor:alias",propertyName="color", localPropertyName="background-color")
}


or something similar to the above, but more compact:
/* set background-color to the same value as the color property in .AFTestForegroundColor:alias */
-tr-property-ref:property(background-color: .AFDefaultForegroundColor:alias color;};

(this is similar to border: black 1px solid, but order matters here.)

or should we continue to use -tr-rule-ref, but instead of -tr-rule-ref:selector() we would have -tr-rule-ref:property()

something like:
/* set background-color to the same value as the color property in .AFTestForegroundColor:alias */
-tr-rule-ref:property(background-color: include(".AFTestForegroundColor:alias", "color");};

I'm not sure the best syntax part within the () above.

Anyway, I'm just throwing out ideas. I like Blake's suggestion the best, though I can see using -tr-rule-ref:property since we already have a -tr-rule-ref:selector.

Jeanne



Blake Sullivan wrote, On 4/1/2010 9:23 PM PT:
Sorry for only looking at the proposals now.  I'm thinking that the following syntax for setting individual properties would be more like setting a property value and also more compact:


.AFTestForegroundColor:alias {color: Red;}
  
// sets the color property equal to the background-color property of the selector
// ".AFTestForegroundColor:alias"
.AFTestBackgroundColor:alias {color: -tr-property-ref(".AFTestForegroundColor:alias", "background-color")}
// sets the background-color property of the command button to the background color
// of the selector "AFTestBackgroundColor:alias".
af|commandButton {background-color : -tr-property-ref("AFTestBackgroundColor:alias")}

The command button style definition shows the more compact form where the source property name isn't specified.  In this case, it is assumed to be the same as the destination property name.  So, the above is equivalent to:

af|commandButton {
  background-color : -tr-property-ref("AFTestBackgroundColor:alias", "background-color:") }

What do you guys think?  With only one or two properties, I don't think that skin authors will be confused about the order.

-- Blake Sullivan


Marius Petoi said the following On 2/3/2010 11:17 PM PT:
Ok Jeanne. Thank you!

One more question, in order to transform the XSS files in CSS files, in
base-desktop.xss there are some styles which are mode-dependent. Should we
add @mode in the CSS? Or do you have any other idea?

Marius

On Thu, Feb 4, 2010 at 7:17 AM, Jeanne Waldman <jeanne.wald...@oracle.com>wrote:

  
 Hi,

I looked into the performance issues and they have nothing to do with the
new features we have been adding recently, so we are ok to add patches.
I'll add this to my todo list, but if anyone else has some time in the next
couple of days, feel free to review the patch.

Jeanne

Jeanne Waldman wrote, On 1/21/2010 11:51 AM PT:

Ok. Our performance team has noticed the Skinning Framework is using more
memory than not that long ago, so I want to look into that before we add
anymore patches.
Jeanne

Marius Petoi wrote, On 1/19/2010 1:23 AM PT:

Hi Jeanne,

The new patch is ready.

Marius

On Tue, Jan 19, 2010 at 8:58 AM, Marius Petoi <marius.pe...@codebeat.ro>wrote:

    
Ok. Then I shall adapt dealing with the aliases and I shall inform you
when the new patch is ready.

Marius


On Mon, Jan 18, 2010 at 11:16 PM, Jeanne Waldman <
jeanne.wald...@oracle.com> wrote:

      
I'm fine with your syntax. I think it is clearer as well. I was just
giving an alternative option if people wanted to vote on it.

Marius Petoi wrote, On 1/15/2010 12:05 AM PT:

Yes, 'name' is an alias...I introduced it because I saw it was done this
way in the XSS. I will remove it. Are you saying I should change the syntax?
I personally think it is clearer this way.

Marius

On Fri, Jan 15, 2010 at 1:45 AM, Jeanne Waldman <
jeanne.wald...@oracle.com> wrote:

        
What is 'name'? Is that an alias? We distinguished between selector and
name in XSS but we don't in the CSS format. We still do in the code, but the
person working with the css shouldn't know the difference.

Yes, the con of my suggestion is that order matters and the user needs
to know what the order means .I can see them not knowing is color what I'm
setting or is color what I'm retrieving? That is what I think the con is for
the CSS syntax like *padding: 0px 2px 3px 4px*


Regarding your link, I haven't had time to look at that yet.

Jeanne

Marius Petoi wrote, On 1/12/2010 11:46 PM PT:

Hi Jeanne,

Thank you for the answer! Like in the situation of -tr-rule-ref, the
list of properties is comma separated. I don't understand what you mean by
camel-case...The name of the new property can be whatever the user wishes
for. Afterwards, it will be treated like all the other properties in the
CSS. Regarding the new syntax you suggested, first of all, we may have a
selector or a name, in which case "selector" is replaced with "name". Also,
another problem is the order in which they appear; with this syntax it can
be any order.

How about
http://markmail.org/search/?q=skinning%20list%3Aorg.apache.myfaces.dev#query:skinning%20list%3Aorg.apache.myfaces.dev%20order%3Adate-backward+page:3+mid:3au5ilvrrpbxopgx+state:results? Did you have the time to look over it too?

Regards,
Marius

On Tue, Jan 12, 2010 at 11:58 PM, Jeanne Waldman <
jeanne.wald...@oracle.com> wrote:

          
 Another idea for the syntax comes from the rgb color syntax -
color: rgb(100%, 0%, 0%)

You could use this syntax, and not specify what each of the properties is for:-tr-include-property:
property("af|foo", "color", "background-color")
or
property(af|foo, color, background-color)

I like this because it's shorter, but I don't like it since they will have to look up which is which, something I have to do when I use the border: 0px 3px 2px 1px syntax - which is right, left, top, bottom.


Jeanne




Jeanne Waldman wrote, On 1/12/2010 10:21 AM PT:

Hi,
Thanks for this patch.
I will have to look at the CSS spec to see if this syntax conforms to
other CSS syntaxes. This is what I usually do when I try to come up with a
new skinning api.
Like, is the comma standard, or should it be space-separated? Is the
camel-case standard, or should it be '-'s.
I think it looks good, but I'll have to look at it closer before I
vote.

Jeanne

Marius Petoi wrote, On 1/11/2010 4:52 AM PT:

Is there anyone who has already reviewed this or added them on his/her
TODO list? Thank you in advance!

Marius

On Fri, Jan 8, 2010 at 11:35 AM, Marius Petoi <
marius.pe...@codebeat.ro> wrote:

            
Hello,

I created a new JIRA task for this issue (
https://issues.apache.org/jira/browse/TRINIDAD-1680) and I added a
patch for it.

I introduced a new -tr property: "-tr-include-property". The syntax of
this is:

     -tr-include-property:
property(selector="af|foo",propertyName="color",
localPropertyName="background-color")

In SkinStyleSheetParserUtils, when the selectors are parsed, similar
to the -tr-rule-ref, I introduced a list of includedProperties. The rules
defined with -tr-include-property are parsed and the list of
includedProperties is filled up. In the end, when the StyleNode is created,
this list is passed to the constructor.

I also introduced the new feature in the documentation.

Is the syntax of the new rule ok? And if so, please have a look over
the patch and tell me whether I should modify anything.

Regards,
Marius

              
            

  

Reply via email to