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 <[EMAIL PROTECTED]> 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 <[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
>> >> >> >
>> >> >> >
>> >> >>
>> >> >
>> >>
>> >>
>> >
>>
>>
>
