Why not just depend on the authors (Jili) using a sensible naming scheme
at this time? E.g. use 'package'_'component class'_'specific class'.
That works now, and has hardly any risk of colliding. That way, the
rounder border component could have it's own css file, and the user's
wouldn't have to do anything special for it to work.
Eelco
Jonathan Locke wrote:
one idea i have is that components themselves get to decide how they
contribute CSS info.
for your RoundCornerBorder, you might simply /not/ contribute CSS info
and instead generate it local to the component. the problem with that
is that if you have a site with hundreds of these components, they'll
all have inline per-instance css, which is inefficient. you ideally
want to be able to have this all inline at the top of a page or even
in a separate file if all the instances are going to have the same
colors etc. right?
Jonathan Locke wrote:
yeah, i was wondering about that...
i've written a bunch of a proof of concept for the stylesheet ideas
i've been throwing around and i'm kindof stopped on this problem at
the moment...
Gili wrote:
On Sun, 13 Feb 2005 17:38:36 +0100, Eelco Hillenius wrote:
Authors should never depend on globally defined styles like for <p>
etc. They should use classes, selectors and inline styles. Now,
selectors can be a problem, as when you use the id attribute for
wicket components, that id will generally be less usable for css.
What authors can do - like I do a lot in the project I'm working on
- is to use <span or <div tags for marking style, and within that
the usual wicket tags.
Agreed, but say for my RoundCornerBorder, how do I bind my CSS
so it is local only to my component?
Gili
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real
users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
