You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@myfaces.apache.org by Martin Marinschek <ma...@gmail.com> on 2006/06/15 07:03:04 UTC

Re: [Proposal] skinning platform, agent, and language features

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 <aw...@gmail.com> 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 <ca...@gmail.com> 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 <ma...@gmail.com> 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 <aw...@gmail.com> 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 <ca...@gmail.com> 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

Re: [Proposal] skinning platform, agent, and language features

Posted by Jeanne Waldman <je...@oracle.com>.

I have another comment to add to my email.

Look at the css spec definition for pseudo-elements and pseudo-classes 
below:

    * Pseudo-elements create abstractions about the document tree beyond
      those specified by the document language. For instance, document
      languages do not offer mechanisms to access the first letter or
      first line of an element's content. CSS pseudo-elements allow
      style sheet designers to refer to this otherwise inaccessible
      information. Pseudo-elements may also provide style sheet
      designers a way to assign style to content that does not exist in
      the source document (e.g., the :before and :after
      <generate.html#before-after-content> pseudo-elements give access
      to generated content).
    * Pseudo-classes classify elements on characteristics other than
      their name, attributes or content; in principle characteristics
      that cannot be deduced from the document tree. Pseudo-classes may
      be dynamic, in the sense that an element may acquire or lose a
      pseudo-class while a user interacts with the document. The
      exception is ':first-child' <#first-child>, which /can/ be deduced
      from the document tree

Think about the Trinidad components as html components. Just like a html 
component can have pieces -- first letter, first line, a Trinidad 
component can have pieces ::label, ::content.
We base the skinning keys around the concept of components and 
pseudo-classes and pseudo-elements.
This works well with icons. Icons are usually a piece of a component, 
like selectInputColor::launch-icon. It's not a style class.

The user is skinning a component, and we give them the pieces of the 
component that they can skin via the skinning keys.

If we turn our skinning key format from the way it is in Trinidad to a 
style-class-centric format, we lose the component-ness of the api.

Jeanne



Jeanne Waldman wrote:

>
>
> Catalin Kormos wrote:
>
>> IMO, it's not just the 3rd party parsers use advantage, another 
>> advantage
>> would be that most of the class selectors the skinner provides would 
>> end up
>> as they were specified in the final CSS. After all, most components will
>> just define a list of class selectors that can be used to customize 
>> their
>> appearence, right? or how do you see this generaly?
>
>
> True.
>
>>
>> In case of a component that can be in more than one state at one 
>> time, that
>> component will still need to let the user customize each state's style
>> separately, as far as i can tell, and then it will renderer the
>> corresponding class selectors in its class attribute, right? (some 
>> helper
>> class could take care of determining the right selectors).
>
>
> I would simply let the user use the composite style classes, like
> af_inputText.AFDisabled.AFSomeOtherState
> so that we don't have to document all the possible combination of states.
> Let's say there are 5 states a component can be in. That's a lot of 
> combinations.
>
>>
>> About the :hover issue, if we take <af:inputText disabled='true'/>, with
>> CSS2 only, the skinner could have at his disposal a class selector
>> ".af-inputText-disabled" and in case he wants to change that style on 
>> mouse
>> over, he could add the following selector 
>> ".af-inputText-disabled:hover" to
>> the skin, and have both selectors rendered as they were specified by 
>> him, no
>> transformation needed. (this works for most browsers, at least IE and 
>> Opera
>> won't know about this for anything else than links, but there are 
>> solutions
>> to make them work as expected for any html element). The final html code
>> would look like <input type="text" disabled='true'
>> class="af-inputText-disabled"/>
>>
>> With DHTML, the user could have two class selectors, one for disabled 
>> and
>> one for disabled:hover, .af-inputText-disabled and
>> .af-inputText-disabled-hover, and the mouse over is detected with JS 
>> which
>> could interchange the selector in the class attribute.
>>
> Overall, I don't have a problem with simply documenting the style 
> classes that
> we output, instead of putting it in a css-3 format. However, the idea 
> when we
> came up with the css-3 format is that we don't want to document our 
> css style
> classes, because those can change, and we don't want people to rely on 
> those,
> and I think if we documented our css style classes, they would be more
> inclined to rely on them.
> Instead we document an 'api' -- the css-3 skinning keys, which is an
> abstraction of the styleclasses . We can then map these
> to the actual style classes if we want or the html implementation,
> like, af|processTrain::step can map to .af_processTrain A{}.
> Then the html implementation can change to something else, and behind 
> the scenes
> we can change the mapping, and the user won't have to change his 
> skinning definitions.
>
>> Looking forward to your comments.
>>
>> Regards,
>> Catalin
>>
>> On 6/21/06, Jeanne Waldman <je...@oracle.com> wrote:
>>
>>>
>>> So are you saying the benefit of css2-syntax instead of css-3 syntax is
>>> that we can use a 3rd party parser, and that is it?
>>> The namespace is in css-3 syntax, but really that is it, right?
>>>
>>> As far as the 'states', it is possible for a component to be in more
>>> than one state at a time.
>>> Currently, we do not have a component like this, but I can see that it
>>> is possible.
>>> Like, how about if we add a state called "hover" to inputText, and the
>>> end user wants special styling
>>> when the inputText component is disabled and the user hovers over 
>>> it. As
>>> the component
>>> writer, you could write code to detect when the mouse hovers over the
>>> inputText, and you would
>>> add a styleclass of "p_AFHover", so the html would look like:
>>> <input class="af_inputText p_AFHover p_AFDisabled"/> and when the user
>>> moves the mouse
>>> away, you'd take off the hover style class using DHTML and it would be:
>>> <input class="af_inputText p_AFDisabled">
>>>
>>> You would document for the skinners the 'states' like this:
>>> :disabled - This pseudo-class is used to style the inputText when it is
>>> disabled <af:inputText disabled='true'/>
>>> :hover - This pseudo-class is used when the user hovers over the 
>>> component
>>>
>>> And in the skin .css file the skinner can say, hey, I want the
>>> background of the inputText to turn pink when
>>> the user hovers over when it is disabled. He'd then write the following
>>> skin definition:
>>>
>>> af|inputText::content:disabled:hover {background-color:pink}
>>>
>>> The code parses this file and creates a style class definition like 
>>> this:
>>>
>>> .af_inputText.p_AFDisabled.p_Hover {background-color:pink}
>>>
>>> What do you think of that? :)
>>>
>>> - Jeanne
>>>
>>> Catalin Kormos wrote:
>>>
>>> > I don't want to say that css2 syntax would help, just trying to 
>>> figure
>>> > out
>>> > if it can be possible to provide the same feature using css2 syntax.
>>> > Parsing
>>> > and generating a new css file for the browser must be done in this 
>>> case
>>> > also, and merging child skin's css file with parent skin's css 
>>> file. 3rd
>>> > party css2 parsers do understand our :alias, will return this as a
>>> > conditional selector, the actual name doesn't seem to have influence,
>>> > so it
>>> > will do the same for :rtl, or :ltr....i'm not yet sure if the :rtl
>>> pseudo
>>> > selector is used only for icons, is it?
>>> >
>>> > af|inputText:disabled:read-only:active  - could this be specified 
>>> by the
>>> > user using 4 different class selectors? a default style with
>>> > ".af-inputText", a disabled style with ".af-inputText-disabled", a
>>> > read-only
>>> > style with ".af-inputText-readOnly" and a active style with
>>> > ".af-inputText-active"? the component can have only one of those
>>> > states at
>>> > one time, right? i would appreciate it if you could explain to me 
>>> this a
>>> > little bit more, what is taken from the user and what is rendered 
>>> in the
>>> > final css.
>>> >
>>> > Thanks,
>>> > Catalin
>>> >
>>> > On 6/19/06, Jeanne Waldman <je...@oracle.com> wrote:
>>> >
>>> >>
>>> >>
>>> >>
>>> >> 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 <je...@oracle.com> 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 <catalin.kormos@gmail.com > 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 < martin.marinschek@gmail.com>
>>> >> 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 < awiner@gmail.com> 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 <ca...@gmail.com> 
>>> 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 < 
>>> martin.marinschek@gmail.com
>>> >
>>> >> >> >> 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 < awiner@gmail.com> 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 < 
>>> catalin.kormos@gmail.com>
>>> >> >> 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
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >>
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >
>>> >>
>>> >>
>>> >
>>>
>>>
>>
>
>