Catalin Kormos wrote:
> 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".
How is this better than :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.
This is what we are doing now.
>
> - 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.
This can get difficult when there are multiple states a component can be
in,
like disabled, readOnly, active, etc. The user can specify this with
pseudo-classes like this:
af|inputText:disabled:read-only:active. We render <input
class="af_inputText p_AFDisabled p_AFReadOnly p_Active">.
>
> I hope this makes sense to you too :)
I do not understand how using css2 syntax would help. You still need to
parse the skin css file and generate a new css file for the browser.
I understand that you can use a 3rd party parser, since 3rd party
parsers don't understand our :alias, :rtl
pseudo-classes, is that right?
We have a stand-alone parser that uses the batik jars. We considered
using that (and
donating it to Trinidad) instead of the skin parser that
is there now, but it has a few issues, so we couldn't. When those are
fixed, we can revisit whether it would be useful to have.
>
> 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
>> >> >
>> >> >
>> >>
>> >
>>
>>
>
