forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diwaker Gupta <diwakergu...@gmail.com>
Subject Re: CSS in view/viewHelper (was Re: using view/viewHelper)
Date Sun, 17 Apr 2005 02:54:51 GMT
> > 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
 
> 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.

> 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

> *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.

> 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.

Cheers
-- 
Diwaker Gupta
http://resolute.ucsd.edu/diwaker

Mime
View raw message