Thanks for bringing the use of CSS3 syntax into discussion, this was one of
the things that put me a lot into thinking actualy :). From what i can tell,
all the features you mentioned can be achieved with CSS2 syntax too. Here is
how i'm imagining to make this work:
- selector inclusion with :alias, this one marks any selector that is only
a place holder for common style properties. This is alright by CSS2 syntax
too (a standard parser will return it), and all selectors that end with
:alias are actualy removed from the final CSS, their content beeing included
in other selectors. The inclusion by another selector will look like this :
content:url(".bgColor:alias"), this beeing the current solution, but not
100% sure about it yet.
- right-to-left support, this is achieved by using :rtl pseudo selector,
right? this one can get used from the beginning with another naming
strategy, like component selector name ending with "-rtl".
- skinning icons, all selectors names that define an icon, end with Icon or
-icon, right? so these can be easily identified when parsing, and they will
be removed from the final CSS, and the image url used to get the right icon
instance.
- abstracting out the html/styleClass implementation, maybe i didn't get
this right, but isn't the component making the decision which selector to
use depending on its state? it could end up looking like
af-inputText-disabled and af-inputText.
I hope this makes sense to you too :)
Regards,
Catalin
On 6/15/06, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
I'll start developing the @agent/@platform features very soon, like this
week/beginning of next week. I'll do the :lang/@locale after that, so I
can revisit the api later.
I'd like to give you a brief background as to why we use the css3 syntax
instead of using css2 that all browsers can interpret. The main reason
is to add features that are not in css2, like
* selector inclusions with the :alias,
* right-to-left support,
* skinning icons in the same skin file,
* the @agent/@platform features that I've mentioned, and
* the ability to abstract out the html/styleclass implementation.
It's arguable that abstracting out the html implementation may make the
skinning 'keys' more confusing to the users. For example,
af|inputText:disabled skins the af|inputText when it is in the disabled
mode. Another way we could have defined this would be to do this:
af|inputText.AFDisabledState.
- Jeanne
Catalin Kormos wrote:
> @Jeanne: i just want to say that i'll make sure your proposition will
> make
> it into the merged skinning approach, but my work won't be available
> sooner
> than the next two months, and more, considering that it will require
> integration work too after that, and probably Trinidad's users would
> want to
> benefit from such new cool feature as soon as possible. In my opinion
you
> could get to it with no problem, what do you think?
>
> Regards,
> Catalin
>
>
> On 6/15/06, Catalin Kormos <[EMAIL PROTECTED] > wrote:
>
>>
>> @Adam: Thanks, i'm glad to hear that!. The current functionality will
be
>> kept, for sure :)
>>
>> @Martin: Sure, i'll keep insync with them, Jeanne's work i'll be able
to
>> reuse i think, as i said the parsing approach will be changed, but
>> for her
>> proposition we need custom parsing anyway. I'll get in touch with her
>> and
>> try to figure this out.
>>
>> Regards,
>> Catalin
>>
>>
>> On 6/15/06, Martin Marinschek < [EMAIL PROTECTED]> wrote:
>> >
>> > Catalin,
>> >
>> > I'm +1 on any changes you want to do on the existing framework, but
>> keep
>> > insync with Trinidad's skinning developers (like Jeanne) so that
>> all of
>> > this
>> > is used for Trinidad as well - keep in mind that our ultimate goal
>> here
>> > is
>> > merging together the different approaches, laying the base for making
>> > the
>> > component sets compliant to each other. New features are great, but
>> only
>> > if
>> > they end up in both sides of the great divide.
>> >
>> > @Tobago developers: if anyone is interested - Catalin has looked
>> through
>> > the
>> > skinning approaches, and Trinidad's deemed him best for
>> implementing the
>> >
>> > skinning portion of Tomahawk. If anyone wants to help out with
getting
>> > this
>> > compliant with the Tobago skinning, this would be great!
>> >
>> > regards,
>> >
>> > Martin
>> >
>> > On 6/15/06, Adam Winer < [EMAIL PROTECTED]> wrote:
>> > >
>> > > Catalin,
>> > >
>> > > Sounds awesome! Looking forward to it. If there's a good
>> > > way to use less CSS 3 syntax but keep the functionality, I'm
>> > > all for it.
>> > >
>> > > -- Adam
>> > >
>> > >
>> > > On 6/14/06, Catalin Kormos <[EMAIL PROTECTED]> wrote:
>> > > > Hi Adam,
>> > > >
>> > > > Sorry if this was confusing, i certainly wouldn't want to write a
>> > pretty
>> > > new
>> > > > framework for skinning, and this to be used only by Tomahawk. As
>> > Martin
>> > > > mentioned we did compare existing approaches besides Trinidad's,
>> > like
>> > > the
>> > > > one from Tobago and I also took a look at Exadel Visual Component
>> > > Platform's
>> > > > skinning. As far as i know these are all the current approaches
>> for
>> > JSF
>> > > and
>> > > > Trinidad's is the one choosed to be based on, all the features it
>> > offers
>> > > are
>> > > > realy nice and there is room for more, like what Jeanne would
like
>> > to
>> > > > implement, right?
>> > > >
>> > > > The goal is to work on making the Trinidad's skinning framework
>> > become
>> > > the
>> > > > skinning framework for MyFaces. There are things to be changed
>> > though.
>> > > Like
>> > > > going all the way with CSS, and not use XSS for the base skins,
>> > allow
>> > > skins
>> > > > to extend each other and not just a base skin, and allow @import
>> > rules
>> > > to be
>> > > > used.
>> > > >
>> > > > The most important changes i was planning to do are related to
>> > parsing
>> > > and
>> > > > merging the CSS files. Right now, Trinidad uses CSS3 syntax for
>> > > component
>> > > > selectors, and has it's own way of parsing that syntax. What i
>> want
>> > to
>> > > do is
>> > > > use a standard CSS2 compliant parser (an implementation of SAC,
>> > > > http://www.w3.org/Style/CSS/SAC/ ), with minimal extensions, for
>> > example
>> > > to
>> > > > recognize @agent rules, and have an internal model based on DOM
>> > Level 2
>> > > > Style specifications (
>> > > > http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/ ). This
>> > could
>> > > > determine also changing the naming of the component selectors
>> to use
>> > > CSS2
>> > > > valid syntax from the beginning but would eliminate the
>> > transformation
>> > > of
>> > > > CSS3 syntax into CSS2 syntax that currently occurs.
>> > > >
>> > > > I would certainly appreciate your feedback on these plans, and
>> help
>> > to
>> > > find
>> > > > to the best approach for bringing Trinidad skinning framework
into
>> > the
>> > > > overall MyFaces world.
>> > > >
>> > > > Regards,
>> > > > Catalin
>> > > >
>> > > >
>> > > > On 6/14/06, Martin Marinschek < [EMAIL PROTECTED]>
>> wrote:
>> > > > >
>> > > > > Hi Adam,
>> > > > >
>> > > > > inspired means it will be based on the ADF Faces skinning
>> > framework.
>> > > We
>> > > > > evaluated Tobago's and Trinidad's thing, and we decided for the
>> > > Trinidad
>> > > > > way. Whatever extensions we write, will go to both Trinidad and
>> > > Tomahawk
>> > > > > (the definitive goal would be a common module we could both
base
>> > > upon).
>> > > > >
>> > > > > regards,
>> > > > >
>> > > > > Martin
>> > > > >
>> > > > > On 6/14/06, Adam Winer < [EMAIL PROTECTED]> wrote:
>> > > > > >
>> > > > > > Catalin,
>> > > > > >
>> > > > > > One quick comment: I don't see a reason to write a skinning
>> > > framework
>> > > > > > "inspired by" the Trinidad skinning. Trinidad is part of
>> > > MyFaces; why
>> > > > > > not work on taking the Trinidad skinning framework and
>> bringing
>> > it
>> > > into
>> > > > > > the overall MyFaces world?
>> > > > > >
>> > > > > > -- Adam
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On 6/14/06, Catalin Kormos < [EMAIL PROTECTED]> wrote:
>> > > > > > > Hi there,
>> > > > > > >
>> > > > > > > I just want to say that it sounds to me like a very good
>> > ideea,
>> > > having
>> > > > > > the
>> > > > > > > same skin take care of browsers incompatibilities for
>> example,
>> >
>> > > rather
>> > > > > > than
>> > > > > > > having different skins take care of that, with need of user
>> > > > > > intervention;
>> > > > > > > i'm working on the future skinning framework for MyFaces
(at
>> > least
>> > > i
>> > > > > > hope it
>> > > > > > > will become that), which is very much inspired by the
>> current
>> > > state of
>> > > > > > the
>> > > > > > > ADF Faces skinning. It's going to be done during the
>> Google's
>> > SoC
>> > > > > > program
>> > > > > > > btw. Would be ok if i take some inspiration from this
>> too? :)
>> > > > > > >
>> > > > > > > A concern of mine would be about the :lang pseudo selector.
>> > Maybe
>> > > this
>> > > > > > one i
>> > > > > > > didn't get quite right, but wouldn't this interfere with
the
>> > > standard
>> > > > > > usage
>> > > > > > > of the :lang pseudo selector, for styling components that
>> > renderer
>> > > > > their
>> > > > > > own
>> > > > > > > different "lang" attribute value, maybe on the same page?
>> this
>> > > might
>> > > > > not
>> > > > > > be
>> > > > > > > the case for ADF Faces components though.
>> > > > > > >
>> > > > > > > Regards,
>> > > > > > > Catalin
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > >
>> > > > > http://www.irian.at
>> > > > >
>> > > > > Your JSF powerhouse -
>> > > > > JSF Consulting, Development and
>> > > > > Courses in English and German
>> > > > >
>> > > > > Professional Support for Apache MyFaces
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> >
>> > http://www.irian.at
>> >
>> > Your JSF powerhouse -
>> > JSF Consulting, Development and
>> > Courses in English and German
>> >
>> > Professional Support for Apache MyFaces
>> >
>> >
>>
>
