Hi all,
this week I am at a client, so my answer can take a while.
On Sat, 2005-04-16 at 19:54 -0700, Diwaker Gupta wrote:
> > > Due to the way CSS works, if I have to define new properties for
> > > the nav-bar say, then I first have to UNDO all of the changes made
by
> > > the CSS files loaded by default, and then define the CSS
properties
> > > the way I want them to.
> > > ...
> > > A simple option that controls inclusion of default CSS
> > > files should fix the problem.
> >
> > I see 2 options here:
> > 1) We *do not* provide a css implementation for a specific contract
nor the basic.css
> > but provide a css stylesheet for all possible contracts (e.g.
default.css) and basic elements.
>
> +1
>
> > 2) We keep the current implementation.
> >
> > 1) will save compilation time. 2) gives css controll to the contract
authors.
> > What are our preferences on that?
>
> Why do contract authors want CSS control? With our focus on separation
> of content from presentation, I think the user should have complete
> control over how content is rendered. If the contract authors have a
> "preferred default" CSS spec, we can just include it in default.css
>
Ok, I see. I just think that the contract author and the designer are
the same person. ...but if they are (s)he can also add it to the
default.css.
> > Either way, the default.css (1.) or all from (2.) *have to* be
defined in the default.fv
> > as e.g. <forrest:css url="default.css"/>.
>
> +1
>
> > If no CSS is defined in the view then *no* css will be linked in the
presentation.
>
> I don't think this is a very good idea. First users of forrest are
> often novices, and by default, we want to output a slick-looking site.
> We've already heard reports of people turning away from Forrest
> because none of the default skins were striking. So we *definitely*
> want a nice looking default implementation, at the same time making it
> easy for users to use their own CSS from scratch.
Agree, would you suggest if no forrest:css is defined that the default
is included?
> > That will drop the need to UNDO the properties of the CSS files and
open a
> > more efficient way to provide a custom css implementation for the
contracts
> > ("simple option that controls inclusion of default CSS").
>
> Right. If our default implementation resides in default.css, then
> users can simply use something like
> <forrest:css url="user.css"/> or something similar to use their own
> CSS stylesheet. Further, if they still want to inherit the default CSS
> and make changes on top of that (instead of starting from scratch, and
> this will lower the barrier to entry), they can simply import the
> default.css in their user.css
>
:) Yes that is the way to go.
> > *Point 2 - css theming*
> > Have a look at this document and search for "theming":
> > "The view is creating the html-skelleton that is used for theming.
> > Themes are view dependent but e.g. you can write one theme for x
view derivatives.
> > Theming adds colors and general appearance info. In html it's css
files for example,
> > or the skinconf color information."
> >
>
> So my understanding is that we might want to retain things like
> "colors" across various views (HTML, PDF etc?) which is why specifying
> colors in skinconf is a good idea since doing colors in CSS only would
> restrict them to XHTML output. Or did I miss something? If thats the
> case, it sounds fine to me.
>
Yes and no. The color profiling is for user that do not have deep
knowledge of css and would prefer not to touch the css-stylesheets (like
me). ;-) This user can define different colors for a "theme".
...and yes this color properties can be used as well in any other output
format, if enabled.
> > The idea (having point 1 in mind) should be to have 2 layers for the
theming.
> > One adds the general appearance (default.css) the other enables
color information (default.color.css).
>
> Lets avoid putting in two "default" CSS files. If we need to include
> color specs in CSS as well (apart from skinconf), lets just do it in
> default.css itself. IMHO, having something like default.color.css just
> makes things more confusing.
>
Ok, ATM we have two files in our skins e.g.
http://svn.apache.org/viewcvs.cgi/forrest/trunk/main/webapp/skins/pelt/css/profile.css.xslt?view=markup
for the job. It is easier to maintain and match the colors but I reckon it
should not be that big of a problem to implement it in one file. Anyway like
you see this file is a xsl. The other is a plain css. That is why IMO it would
be better to have 2 different files.
...but maybe we have to talk about resource bundling and overcome this
problem by defining a default bundle.
I will try to implement the above tonight and check this in tomorrow
morning (I do not have Internet in the hotel).
Thanks for all your thoughts and hints. You are the first one (I guess)
using views besides myself. Perfect.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
