We need a lot more documentation on skinning, that is for sure.
Let me try to explain the -tr-inhibit feature, which is relatively new.
As you know in the default (aka base) skin there are a lot of skin style
definitions.
These get converted somewhat and generated into a css file that is
included into the generated html file when you run
a jspx page.
Let's say the base skin has this definition (among all the other
definitions):
af|inputText::context {
background-color: red;
color: blue;
}
And when you run a page with the nputText component on it, you will get
background-color: red
and color: blue.
The generated CSS file will have this (among all the other styles):
.af_inputText_content {background-color: red; color: blue}
But you don't want background-color red. You want to inhibit it.
You think color blue is ok.
So, you create a skin. (see trinidad-skins.xml for an example). In your
css file you would do this:
af|inputText:content {
-tr-inhibit: background-color
}
Then when you run your page, you won't see a background-color.
The generated css file will have this (among all the other styles):
.af_inputText_content {color: blue}
Let's say you wanted NO styles at all on af|inputText::content.
You would do this:
af|inputText {
-tr-inhibit: all;
}
Then you won't see anything for .af_inputText_content in the generated
css file.
But, as you can see, if you want to inhibit everything, then whew...
you'd need to open up base-desktop.xss and simple-desktop.xss (our base
skins -- and they are in a different format than the css) to get the
keys and then you'd have to type out all the keys
.key1,
.key2,
etc {
-tr-inhibit: all;
}
Not fun.
Inhibiting all properties on the aliases will help a little bit. You can
inhibit font-family everywhere, for example, by doing this:
.AFDefaultFontFamily:alias {
-tr-inhibit: all;
}
And since lots of our skinning keys include the AFDefaultFontFont:alias,
your inhibiting it once will ripple through.
I hope that makes sense. Let me know if you are confused.
By the way, until recently we generated both full names and compressed
names. like:
.af_inputText_content, .x11 {background-color: red; color: blue}
But now we generate one or the other.
If you want to see full style names, then you need to add this to the
web.xml:
<context-param>
<param-name>org.apache.myfaces.trinidadinternal.DISABLE_CONTENT_COMPRESSION</param-name>
<param-value>true</param-value>
</context-param>
- Jeanne
Chris Lowe wrote:
Matt,
Thanks for the pointer, but to be honest all this skinning stuff sends me
into a dizzy state of confusion. I looked at the FAQ which has one
occurrance of "-tr-inhibit" - this directed me to the purpleSkin in the
demo. From there I can see a usage of "-tr-inhibit" but I don't really
understand how I'd apply this in my case.
Cheers,
C.
On 13/02/07, Matt Cooper <[EMAIL PROTECTED]> wrote:
You also can create a custom skin that inhibits styles from the style
definitions using "-tr-inhibit". More details can be found at:
http://wiki.apache.org/myfaces/Trinidad_Skinning_FAQ
Regards,
Matt
On 2/13/07, Chris Lowe <[EMAIL PROTECTED]> wrote:
>
> Hi Adam,
>
> Thanks for the info on the minimal skin, I'll switch to that in the
> meantime. An even more minimal skin would be great though -
anything to
> save bandwidth, server hits and browser parsing of CSS/JS will be
greatly
> appreciated.
>
> My main reasons for not using a skin are cited in my original
post. I'm
> using making minimal use of the Trinidad component set (using <10
> components) and having the CSS download seems excessive, plus learning
> about
> the skinning for my needs was overkill. So for my current project,
regular
> CSS suited my needs for positioning and setting simple attributes like
> width.
>
> I completely get the point of skinning and it looks really useful,
it's
> just
> not necessary at the minute.
>
> I will be using a compression filter for resources like CSS, I've
always
> found that the following filter does everything I need:
>
> http://sourceforge.net/projects/pjl-comp-filter/
>
> Are there any better ones out there?
>
> Are the Trinidad generated CSS/JS files constant between pages? If
so,
do
> you see any problem with setting the HTTP cache headers: "Expires" and
> "Cache-Control" to prevent the browser from requesting these resources
on
> each page request?
>
> Cheers,
>
> Chris.
>
>
>
> On 13/02/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> >
> > Skinning is an integral feature, so there's no turning it
> > off. You could switch to a simpler l+f - minimal, for instance,
> > clocks in at <30K. We could provide an even more minimal l+f,
> > perhaps. But, I wonder, why are you looking to completely disable
> > skinning?
> >
> > If it's an issue of download size, you might consider getting
> > a .gzip filter involved, which will majorly decrease the size
> > of the .css file (~80% smaller). The minimal l+f .css comes
> > in at about 5K once gzip'd.
> >
> > -- Adam
> >
> >
> >
> > On 2/13/07, Chris Lowe <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > Is it possible to switch off skinning altogether? If so, will
turning
> > off
> > > the skinning prevent the wrapping of various components in
SPANs and
> the
> > > download of a ~140k CSS file?
> > >
> > > Cheers,
> > >
> > > Chris.
> > >
> >
>