Mailing-List: contact tapestry-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tapestry development" <tapestry-dev@jakarta.apache.org>
Message-ID: <3FDB53B9.4040602@comcast.net>
Date: Sat, 13 Dec 2003 13:00:25 -0500
From: Harish Krishnaswamy <hkrishnaswamy@comcast.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: Tapestry development <tapestry-dev@jakarta.apache.org>
Subject: Re: Components with style
References: <CC90B180-2D8A-11D8-BED8-000393A564E6@ehatchersolutions.com>
In-Reply-To: <CC90B180-2D8A-11D8-BED8-000393A564E6@ehatchersolutions.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Designer's will certainly be responsible for the style either way. My only suggestion is to bundle 
the CSS for the component with the component so you don't *have* to specify styles to use the 
component, altough you can if you prefer a different style by overriding the one bundled with the 
component.

I have the following organization for my stylesheets. Specificity: left(least specific) to 
right(most specific).

company level -> project level -> component level -> page level

And I have CSS for every component and every page.

Here I can specify my company level and project level stylesheets in the Border and I can specify 
the page level stylesheet in the page spec, but I have no one place to specify the stylesheets for 
the components. I have to specify them in each page I use the component which is what I am trying to 
avoid.

-Harish

Erik Hatcher wrote:

> Keep in mind one of Tapestry's underlying principals to keep concerns 
> separate and let HTML be clean and totally within a designers hands.  
> CSS is another layer on top of the *structure* that HTML provides.  CSS 
> is not something us "coders" are writing... it is really in a layer 
> above the structure and very much in the hands of the designers if we 
> are fortunate enough to have such artistic people handy on our 
> projects.  So, we need to tread carefully here to ensure that we make it 
> such that designers are allowed to work they need and want work.
> 
> And it seems a single master stylesheet is how things are done and 
> perhaps one (or more) overriding ones for special sections of a site or 
> individual pages, or for different media types.  Right?
> 
> 
> 
> On Saturday, December 13, 2003, at 10:50  AM, Harish Krishnaswamy wrote:
> 
>> I think that would be against the design intent of CSS. CSS is 
>> designed so that the author can provide a style for a page and the 
>> user can override it if he/she wishes to do so. Moreover managing a 
>> single stylesheet would soon become out of control if all pages use a 
>> lot of CSS like mine. Without style, I think, the component would not 
>> be complete as it cannot render appropriately. What we need is a way 
>> to let the pages override the style provided by the component like 
>> Howard suggests and I think CSS takes care of that part. We just have 
>> to take care that the order of the CSS links is appropriate.
>>
>> -Harish
>>
>> Erik Hatcher wrote:
>>
>>> It seems to me that one stylesheet is preferable over lots of 
>>> separate ones though - so that a designer could alter the styles in 
>>> one spot easily.  Components should provide the ability to attach a 
>>> class or id to pieces of what it renders, though, but I don't think 
>>> it is the components job to provide actual styles.
>>> On Friday, December 12, 2003, at 04:33  PM, Harish Krishnaswamy wrote:
>>>
>>>> Hi,
>>>>
>>>> A lot of the components I have developed have their own stylesheets 
>>>> that have to manually incorporated into the pages to render 
>>>> appropriately. Instead can we not provide the ability to bundle 
>>>> stylesheets with the component like we bundle javascript? It seems 
>>>> simple to me, but I have missed the boat on a number of occasions in 
>>>> the past so what do you think?
>>>>
>>>> -Harish
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org