I'll take a look. We should get approval from the community for @locale,
because this is a public API.
Could you send out another email with the subject set so people know
they should vote on the public API? Or you can wait until I review this
first.
+1 from me for @locale.
In XSS we had this syntax:
<styleSheet locales="en">
<styleSheet browsers="ie">
We converted the <styleSheet browsers..> syntax to @agent ie or @agent
ie, gecko, so I think we should convert the locales to @locale with
commas separating the locales. We should support the locales the same
way we do for xss, so the code change should be pretty simple, since we
already have the support for xss to follow.
The locale should be included for the hashcode in the css filename
(stylesheetdocumentid)
Jeanne
Marius Petoi wrote, On 12/9/2009 4:57 AM PT:
Hello,
I have added a patch that implements the support for skin selectors
depending on the locale
(https://issues.apache.org/jira/browse/TRINIDAD-1041). This is done in
the CSS using @locale rules. The syntax of the @locale rules is
similar to the syntax of the @agent and @platform rules:
@locale en-us, fr
{
/* skin selectors definitions go here */
}
The set of supported locales is afterwards stored in each
StyleSheetNode. I also implemented an example in the trinidad-demo.
There is a skin (localeDemo.css) which contains @locale rules.
Afterwards, the localeDemo.jspx page displays a textInput with a
different color, depending on the locale. In order to configure the
proper skin, a "LocaleDemoBean" is used, which is used for configuring
the proper skin-family (localeDemo), in the same way in which the
accessibility profile is configured for accessibilityProfileDemo.jspx.
Could you please have a look over the patch and see if this resolves
the issue.
Regards,
Marius
