No, it doesn't yet. I think that is still a logged issue.
Skin-additions are meant for custom components, and therefore the
assumption is that the selectors won't overlap, as you mentioned Simon.
What might be closer to what we want is
1. @include
or
2. The ability to add more than one css file to skin-extensions.
<skin>
<skin-id>
<style-sheet-name>xxx</style-sheet-name>
<style-sheet-name>www</style-sheet-name>
- Jeanne
Simon Lessard wrote:
Hello again Cristi,
As a quick fix, I think skins' CSS files support @include instruction.
Regards,
~Simon
On 8/16/07, Cristi Toth
<[EMAIL PROTECTED]>
wrote:
Hello
Simon,
It would be great if that would be done!
I think others may agree with this too.
Thanks,
--
Cristi Toth
-------------
Codebeat
www.codebeat.ro
On 8/16/07, Simon Lessard <
[EMAIL PROTECTED]> wrote:
Hello
Cristi,
Although maybe we should deal with that issue, they way you used skin
additions is not what it was meant to be at first. Normally skin
additions should be used to extend the selector set of another existing
skin, like when adding new components, not CSS splitting. Therefore,
skin additions should not be overlapping most of the times. There might
still be an issue if we have the following case:
SimpleSkin
+++++ SimpleSkinAddition
|
|
CustomSkin
+++++ CustomSkinAddition
In that case, CustomSkinAddition should indeed have
priority over SimpleSkinAddition. That being said, I would not be all
against allowing SkinAddition to be used for file splitting.
Regards,
~ Simon
On 8/15/07, Cristi Toth <
[EMAIL PROTECTED]> wrote:
Hi Jeane!
The problem is that I need to split the skin style-sheet into more files
because it's getting huge and harder to maintain
So I'm using skin-additions.
And the property from the skin-addition is always
overriden by the base skin.
I really think that the skin-addition should have the same priority as
the skin-extension
here's a snippet from my trinidad-skins file:
<skins
xmlns="
http://myfaces.apache.org/trinidad/skin">
<skin>
<id>aaadesktop</id>
<family>aaa</family>
<render-kit-id>org.apache.myfaces.trinidad.desktop</render-kit-id>
<style-sheet-name>css/aaa.css</style-sheet-name>
</skin>
<skin-addition>
<skin-id>aaa.desktop</skin-id>
<style-sheet-name>css/layout.css</style-sheet-name>
</skin-addition>
</skins>
and here's a piece from the skin-addition's style sheet:
general-block
{
padding:
0px;
margin:
0px;
border:
0px;
}
base-block {
-tr-rule-ref: selector("AFMediumBackground:alias");
-tr-rule-ref: selector("AFDefaultFontFamily:alias");
-tr-rule-ref: selector("AFDefaultFont:alias");
-tr-rule-ref: selector("general-block");
width:
100%;
height:
100%;
}
html {
-tr-rule-ref: selector("base-block");
}
body {
-tr-rule-ref: selector("base-block");
-tr-inhibit: margin-top;
overflow:
hidden;
}
and here's a piece from the
generated CSS:
general-block
{padding:0px;margin:0px;border:0px}
base-block,html
{background-color:#EBF0F5;font-family:Arial, Helvetica,
sans-serif;font-weight:normal;font-size:12px;padding:0px;margin:0px;border:0px;width:100%;height:100%}
body
{background-color:#EBF0F5;font-family:Arial, Helvetica, sans-serif;
font-weight:normal;font-size:12px;padding:0px;margin:0px;border:0px;width:100%;height:100%;overflow:hidden;
margin-top:8px}
thanks for help!
Cristi Toth
-------------
Codebeat
www.codebeat.ro
On 8/15/07, Jeanne Waldman <
[EMAIL PROTECTED]> wrote:
Can you send me a simple
test case for this scenario so I can see if it is a bug or you are not
implementing it correctly.
What should be happening is we read the base skin in and merge in the
skin extension after.
The skin extensions css properties take precedence. They extend the
base skin's properties.
When we write out the css-2 stylesheet, we have a performance step
where we group all the
selectors with the same css properties together. This will then appear
to be reordering the properties.
Instead of the selectors being generated in the order you wrote them:
.af_foo {font-size: 8px; color: red; font-weight: bold; font-style: italic; font-family: Tahoma}
.af_bar {font-size: 12px; color: black; border-width: 1px}
.af_zoo {font-size: 8px; color: red; font-weight: bold; font-style: italic; font-family: Tahoma}
.af_xyz {color: red}
.af_abc {font-size: 12px; color: black; border-width: 1px}
You'll see them grouped together:
.af_foo, .af_zoo {font-size: 8px; color: red; font-weight: bold;font-style: italic; font-family: Tahoma}
.af_bar, .af_abc {font-size: 12px; color: black; border-width: 1px}
.af_xyz {color: red}
- Jeanne
Cristi Toth wrote:
My problem is even bigger :(
as Simon Lessard already noticed in StyleSheetDocument, on line 477
the method: private
StyleNode _resolveStyle(...) is really buggy
The problem is that it takes all the style definitions of a selector /
element in a 'random' order
and the properties in the first instances are being overwritten by the
same properties from the later instances
This is not good...
At least it would have been ... ok, if the definitions from the skin
extension style-sheet would have been last
but in my example, the base-desktop.xss seems to be last,
so even if I inhibit the annoying { margin-top: 8px } property in the
skin,
it is still overwritten by the instance in base-desktop.xss, which is
last (so it has greater priority)
This is serious trouble
and I don't know how to override this behavior in my current project!
(I can't wait for a snapshot fix)
Can anybody suggest some solution?
Is there an issue on this problem ?
thanks,
Cristi Toth
-------------
Codebeat
www.codebeat.ro
On 8/10/07, Cristi Toth <[EMAIL PROTECTED]
>
wrote:
Hi!
I found a strange default value for IE browser: body { margin-top: 8px } in
base-desktop.xss
on line 3943:
<styleSheet
browsers="ie">
<style
selector="body">
<property
name="margin-top">8px</property>
</style>
...
Why on earth would anybody need this setting?
I lost some valuable time on finding this...
And its effect was really annoying!
--
Cristi Toth
-------------
Codebeat
www.codebeat.ro
--
|
