forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: CSS in view/viewHelper (was Re: using view/viewHelper)
Date Wed, 20 Apr 2005 14:16:37 GMT
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
> +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

I agree, the contract author should not be concerned with the CSS, just 
as a plugin author is not concerned with the skin/view.

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

+1 It's great to see someone helping him out, he's been alone in 
skinning section area for too long.

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

Does my comment regarding colour groups (in original thread) have 
anything to do with this?


View raw message