Re: CSS Aliases

Can I add my support for such a suggestion.

The main use case I see for it today is when at the application level you join together multiple html / css libraries.

For example: 
I have an application for renting Books, It use a library management framework that generate tagged html like:
	<tr class="rented"><td class="author">King</td>...</tr>
in a table to represent that the book is actually rented.
The application A use Bootstrap and we would like to map .rented to ..SomethingBootstrapSavy.
Application B that use the same book framework for different device would like to map it differently, map it to MyPreferedCssLibrary ..Unavailable style.

That is the use case I see for aliases: 
Joining, at the application level, styled html (that I do not have control over) with css (that I do not have control over either).

I see that this thread id dated (over 4 years now), does a solution exist by now to this problem?
If so please point me in the right direction.

Thank,

--
Jean-François Veillette
Analyste programmeur,
Développement informatique


> 
> From: Matt Patenaude <MattPat@mattpat.net> 
> Date: Mon, 6 Oct 2008 22:21:16 -0400
> Message-Id: <47F23D40-5972-4E9E-855B-6FE9743576C7@mattpat.net> 
> To: www-style@w3.org 
> 
> Hi all,
> 
> I was working on a project today, and I thought of something that  
> might be a useful and powerful addition to CSS: aliases.
> 
> It happens all too often that I want to completely duplicate a style  
> definition for a class to another class, in order to have a better  
> semantic name for the data I'm styling. For instance, lets say I have  
> the class "product" and the class "service." On my page, I would like  
> these to be style similarly. If I have an existing declaration for  
> "product" like so...
> 
> .product {
> 	font-weight: bold;
> 	...
> }
> 
> ... it isn't a problem, I can just change the selector to  
> ".product, .service". However, let's say my rules get a little more  
> complex:
> 
> div.product:first-child > h3 + p {
> 	font-weight: bold;
> }
> 
> Contrived example? Absolutely. But just to make the point, the  
> selector would now have to become "div.product:first-child > h3 + p,  
> div.service:first-child > h3 + p", which is more than a little  
> redundant. And let's say I have several rules, all of which  
> contain .product in some permutation or another. Isn't it an awful lot  
> of work to have to duplicate those selectors across the board (along  
> with being difficult to maintain), just to add a little extra semantic  
> goodness?
> 
> My proposal: CSS Aliases. CSS should allow you to map one selector as  
> an alias as another selector, that works intelligently across the  
> board. In a simple example, imagine something like this:
> 
> @alias selector(.product) selector(.service)
> 
> In this example, any element with the class of "service" would inherit  
> all styles of the class "product" automatically. Let's make it a bit  
> more complex:
> 
> @alias selector(.alternateRow) selector(#myTable tr.oddRow)
> 
> Essentially, something intelligent like this would make it much easier  
> to adapt CSS styles to pages regardless of the semantic naming of  
> their elements. In the example above, the styles for anything with  
> class "alternateRow" is also applied to rows with class "oddRow" in  
> the table identified as "myTable".
> 
> The beauty here is that the selectors can be as complex as desired.  
> For instance, let's say that, through inherited styles, the first  
> paragraph of every "product" has styling I want to apply to the  
> entirety of every "client." Even if I don't have a rule definition  
> called ".product p:first-child", this should still work:
> 
> @alias selector(.product p:first-child) selector(.client)
> 
> If I tried really hard, I could come up with a more complex example  
> that would show even more benefit to something like this, but I think  
> what I've come up with is sufficient. ;) It may be superfluous, but  
> personally I think it would be a great language feature to have.
> 
> Thanks!
> 
> Sincerely,
> Matt Patenaude

Received on Tuesday, 18 February 2014 17:30:37 UTC