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: <3FDC0E4A.307@comcast.net>
Date: Sun, 14 Dec 2003 02:16:26 -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: Fwd: Components with style
References: <E8093EAA-2DAB-11D8-8A77-000393A564E6@ehatchersolutions.com>
In-Reply-To: <E8093EAA-2DAB-11D8-8A77-000393A564E6@ehatchersolutions.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Please see inline...

Erik Hatcher wrote:

> 
> 
> Begin forwarded message:
> 
>> From: Travis McCauley <travis.mccauley@alumni.virginia.edu>
>> Date: Sat Dec 13, 2003  1:56:38  PM US/Eastern
>> To: erik@ehatchersolutions.com
>> Subject: Re: Components with style
>>
>> Eric,
>> Hi. I sent this in to Tapestry-dev but it seems it didn't make the  
>> list. If it seems relevant to folks, you might pass on the links.
>> Cheers, Travis
>> p.s. I got a java job up here in Toronto doing...Struts. :)
>>
>>
>> Hi,
>>
>> My comments might pertain more to component/page design but I'm not  
>> totally clear what changes to Shell are being suggested so here goes.
>>
>> I tend more toward's Eric's view that, in general, components should  
>> provide structural elements, not presentational. So encouraging users  
>> of a component to specify class and/or id attributes is definitely  good.

I am certainly for specifying the class and id attributes but I disagree with the opinion that 
components should only provide the structural elements. My reasoning is that we are building visual 
components and that a visual component would not be one wihtout its presentational attributes. 
Imagine a tab component with just headings and data for each tab without any presentational attributes.

>>
>> When you use CSS for layout and not just for formatting (as per WAI  
>> recommendations), it is crucial to have total control over the 
>> styles.  As new browsers come along and old ones are updated with new 
>> CSS  behaviour, quite often the only way to provide a consistent  
>> presentation to a wide range of browsers is to employ CSS tricks (eg.  
>> @import) that hide certain bits of the style sheet and provide  
>> slightly different CSS rules for certain browsers. For me, a dynamic  
>> set of stylesheets that live in the classpath would be very difficult  
>> to work with.

My intension is not to take away the control of styles from the application developer but to not 
force the developer to control the style. I am only suggesting that the components have a default 
presentation that can be overridden by the application developer/designer.

>>
>> As for ordering link elements, the only gotchas I know about are in  
>> the use of the 'title' attribute and in how user agents are supposed  
>> to select 'preferred' stylesheets. If this could be an issue in the  
>> design of any new Shell functionality, all relevant details can be  
>> found here:

My intension to order the links is to facilitate inheritance and not to provide alternate 
stylesheets. Perhaps more research needs to be done in this area but overall it seems to me that 
persistent stylesheets can simply be ordered to define specificity of an element with multiple styles.

>>
>> http://www.w3.org/TR/REC-html40/present/styles.html#specifying-external
>> http://www.w3.org/TR/REC-html40/struct/links.html#linksandss
>>
>> Best Regards,
>> Travis McCauley
>> Toronto, ON

-Harish

>>
>>
>>> Quickly glancing at the specs, it seems like the stylesheet belongs  
>>> in the <head>. Even otherwise, I think, it would be best for us to  
>>> control the ordering of the stylesheets if it was all in one place.  
>>> So, I think, we probably should let the Shell component be  
>>> responsible for styles.
>>>
>>> -Harish
>>>
>>> Howard M. Lewis Ship wrote:
>>>
>>>>  No, it's a good idea. I have to check where stylesheet data goes  
>>>> ... it may be limited to the <head>
>>>>  (instead <html>), in which case we may need the Shell component to  
>>>> be responsible for accumulating
>>>>  stylesheet info.
>>>>  --
>>>>  Howard M. Lewis Ship
>>>>  Creator, Tapestry: Java Web Components
>>>>  http://jakarta.apache.org/tapestry
>>>>  http://jakarta.apache.org/commons/sandbox/hivemind/
>>>>  http://javatapestry.blogspot.com
>>>>
>>>>> -----Original Message-----
>>>>> From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net] Sent:  
>>>>> Friday, December 12, 2003 4:33 PM
>>>>> To: Tapestry development
>>>>> Subject: Components with style
>>>>>
>>>>>
>>>>> 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