I just checked the skinning based on an agent name and its version,
Trinidad ignores the version. Example, I created a skin-family with the
following in its CSS file.
@agent ie (version: 6)
{
.class5
{
color: red;
font-size: 13px;
}
}
@agent ie (version: 7)
{
.class6
{
color: green;
font-size: 20px;
}
}
The CSS file sent to the ie 6.0 browser contains both .class5 and
.class6. I tested it against the branch 1.2.12.1 and 1.2.12.2. Did I
miss anything or is it a bug?
Thanks
Mamallan
P.S: Used a web-debugger tool called fiddler to examine the CSS file
downloaded to the browser
Blake Sullivan wrote:
Mamallan Uthaman said the following On 12/28/2009 12:24 PM PT:
Hi Jeanne,
Please find my response inline.
Thanks
Mamallan
Jeanne Waldman wrote:
Blake is working on this feature.
Also, can you explain the kinds of things you need to skin
differently for your different agents? I'm curious.
These agent-based customizations are very much depended on
applications. To name a few, Blackberry browsers don't support
:active pseudo element unlike iPhone. So in an iPhone on clicking a
link, we can have a loading-image as background using
.Oralink:active. Also, I usually override default background color of
buttons in Windows Mobile.
Do you need to add extra @agent rules, or do you have what you need.
No, we have added enough agents and platforms. Currently, we only
need the feature TRINIDAD-1547 to handle different agents based on
versions and @import support for better usability.
Mammallan, it's gross, but you can support multiple agents using the
OR feature of the queries:
@agent blackberry and (version:4.5), blackberry and (version:4.4),
blackberry and (version:4.3), blackberry and (version:4.2), blackberry
and (version:4.1), blackberry and (version:4.0)
-- Blake Sullivan
Jeanne
Mamallan Uthaman wrote, On 12/23/2009 9:15 PM PT:
Hi Jeanne,
I tried to implement a single CSS file to handle all mobile
browsers, but couldn't as @agent rule doesn't support range of
version. Example, I need to add some skinning only for blackberry
browsers of versions < 4.6. I noticed that you have been tracking
@agent range-of -version feature in TRINIDAD-1547. I am looking
forward to using this feature.
As this feature is needed for skinning mobile-agents, we can
consider deprecating skinFamilyType API after this feature's release.
Thanks
Mamallan
Jeanne Waldman wrote:
If you deprecate it, you can't then rename it. You'd have to
deprecate skinFamilyType, create a new method with a better name,
and then deprecate that when we have @import. So we'd end up with
two deprecated apis in the end, which is not very clean.
I think for now you should:
1. deprecate skinFamilyType and stop using it yourself
2. add @agent or @platform support to handle all the agents or
platforms you need for mobile.
3. use one skin-family and one css file until we have @import
support or multiple <style-sheet-name>s per skin.
The con of having so many skin-families is that the app developer
needs to figure out which skin-family to use for each agent and
render-kit-id.
Another con is the app developer needs to modify all the .css
files if he wants to make one change that affects them all, like
color: black to color:blue. If we use one skin-family, then the
app developer can make one change in one file that affects all
devices if he wants.
Jeanne
Mamallan Uthaman wrote, On 12/22/2009 12:35 PM PT:
Hi Blake,
Yes, this API should be eventually removed. I am thinking as a
first step to deprecate and rename it. After implementing @import
on platform basis, we can remove this API. Please share your
thoughts?
Thanks
Mamallan
Blake Sullivan wrote:
Mamallan,
Related to what Andrew is saying, I think that the real issue is
that this is the wrong api. Agents don't have skins--skins are
specialized for agents. It seems that there were two issues
that lead to the addition of this api:
1) The desire to specialize the skin based on the platform
2) You didn't want to lump all of the skins into a single css file
Of these, the first was critical, the second a cleanliness
issue. Include support would fix the first of these, while
extending the @agent selection syntax to support per-platform
selection would solve the more critical problem.
In addition, my understanding is that this api was only added to
the RequestContextImpl, rather than the RequestContext itself
and so is only accidentally available to page authors through EL.
-- Blake Sullivan
On Dec 22, 2009, at 11:07 AM, Mamallan Uthaman wrote:
Hi Andrew,
Thanks for your suggestion. Yes, we may not need this API if we
could implement @import in the skin parser. For the time being,
I am planning to rename this API.
Thanks
Mamallan
Andrew Robinson wrote:
Would this be needed if we could just implement an @import in
the skin parser?
Then you could have something like this:
@agent ie {
@import url("ie.skin.css");
}
Now we could have CSS for each browser as desired, including
mobile
browsers. It would be more flexible this way than changing the
API
IMO.
-Andrew
On Sun, Dec 20, 2009 at 11:25 PM, Mamallan Uthaman
<mamallan.utha...@oracle.com> wrote:
Hi all,
I need your valuable suggestions in renaming the following
Trinidad API that
is used only in mobile development.
API Name:
skinFamilyType. It can be accessed using EL #
{requestContext.agent.skinFamilyType}
What is skinFamilyType API?
CSS-support of mobile browsers varies drastically as most of the
mobile-browsers don’t strictly follow W3C standards. After
analyzing various
mobile-browsers, we have categorized mobile-browsers based
on their
CSS-support and exposed the category thru this API. Example,
this API
returns 'nokiawebkit' for NokiaS60 and 'iPhonewebkit' for
iPhone.
Why Renaming?
This API doesn't return any skin-family; it simply returns
the category to
which a mobile-browser belongs based on the mobile-browser's
CSS-support. So
the new name should reflect what it returns.
Alternate Name:
styleCategory
Typical Usage:
As CSS-support of mobile browsers varies drastically,
developers usually
create their own skinning with different versions of
style-classes based on
a mobile-browser's CSS-support. To handle all mobile-browsers
in a single
CSS-file, developers have to include lots of style-classes
and tweaking such
as @agent/@platform rules. The resulting CSS-file will be
very huge, and it
is not manageable. So developers prefer to maintain separate
CSS files based
on mobile-browsers’ CSS-support. By creating different
skin-families with
names same as values returned by this API, developers can
easily switch to a
CSS file based on a requesting mobile-browser's CSS-support.
To illustrate with an example:
trinidad-config.xml contains
#{requestContext.agent.skinFamilyType}
(Remember, skinFamilyType returns 'nokiawebkit' for NokiaS60 and
'iPhonewebkit' for iPhone)
trinidad-skin.xml contains
<skin>
<id>iPhonewebkit</id>
<family>iPhonewebkit</family>
<render-kit-id>org.apache.myfaces.trinidad.desktop</render-kit-id>
<style-sheet-name>styles/iPhone.css</style-sheet-name>
<! -- iPhone.css is a CSS file created by a developer
to handle
iPhone -->
</skin>
<skin>
<id>nokiawebkit</id>
<family>nokiawebkit</family>
<render-kit-id>org.apache.myfaces.trinidad.desktop</render-kit-id>
<style-sheet-name>styles/symbian.css</style-sheet-name>
<! -- symbian.css is a CSS file created by a developer
to handle
NokiaS60-->
</skin>
Thanks
Mamallan
