You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by BURGHARD Éric <er...@systheo.com> on 2004/11/24 15:46:46 UTC

XMLCSS

Hi,

I've submited a patch several month ago, to handle css in a browser
independant way (different css may be generated from a common xmlcss
depending on user-agent string submitted by the browser (ie no more css
hacks))

I've just enhance the process to include named rules and macros with
parameters, and i think that it could allow us to share a library of css
macros for styling sites (menus for example), in a simple and soc manner.
So let me explain (sorry it's quite long but i want to be the clearest
possible):

First just a remainder:

an xmlcss file is writen like that:
<css>
 <rule select=".myclass">
   <padding value="0"/>
   <margin top="10px/>
 </rule>
</css>

and is converted by an xsl transformation in
.myclass {
 padding: 0;
 margin-top: 10px;
}

Now you can use variable
 <define name="blue" value="#0000CC"/>

 <rule select=".myclass">
   <padding value="0"/>
   <margin top="10px"/>
   <color value="{$blue}"/>
 </rule>

Now IE5 is boring you with one of its (numerous) irritating bug. you know
how to fix it in an "IE way", but don't want to poluate other css browser
that works well without:

 <rule select=".myclass">
   <padding value="0"/>
   <margin top="10px"/>
   <color value="{$blue}"/>
   <float value="none" agent="ie5"/>
 </rule>

 float: none;

will appear only on browser that claims to be IE.

Now you can use named rule to reuse a set of rules

<rule name="item-spacing">
   <padding value="0"/>
   <margin top="10px"/>
   <float value="none" agent="ie5"/>
</rule>

<rule name="blue">
  <background color="white"/>
  <color value="{$blue}"/>
</rule>

<rule select=".my1class" apply="item-spacing">
<rule select=".my2class" apply="item-spacing blue">

Ok. Now you want to style different <ul> for implementing horizontal,
vertical, 3D, and so on menus. To achieve that, you could inject the
appropriate classes in your xhtml code, but doing that way is against the
SOC concepts (xhtml is tied with the way ul should appear). You could not
change that later without changing the generatig code or css rules
semantics (for example you had to change the .threed class definition if
you don't want 3D aspect anymore so the choosen name become a nonsens)

The better way (i think) is name your xhtml elements (id and class) by what
they are and not by what they should like, and use macros to generate
appropriate rules.

for example lets say you had a ul which is your "mainmenu" in your page. in
xmlcss, once you had defined the macro "menu" this could be simple as
putting in your xmlcss file

<css>
 ...
 <menu div=".mainmenu" orient="horizontal" anchor="right"/>
 <menu div=".secondarymenu" orient="vertical" anchor="left"/>
 ...
</css>

so how its working. quite simple in fact. Say that your xhtml looks like
that:

<div class="mainmenu">
<ul>
  <li><a>first item</a>
  <li><a>first item</a>
</ul>
</div>

to style this as a menu you had to define rules on div, ul, li and a. so you
had to declare a macro that way

   <define name="menu">
        <param name="div"/>
        <!-- horizontal by default -->
        <param name="orient" select="'horizontal'"/>
        <!-- left aligned by default -->
        <param name="anchor" select="'left'"/>
        <rule select="{$div}" apply="{$orient}-{$anchor}-div"/>
        <rule select="{$div} ul" apply="{$orient}-{$anchor}-ul"/>
        <rule select="{$div} li" apply="{$orient}-{$anchor}-li"/>
        <rule select="{$div} a" apply="{$orient}-{$anchor}-a"/>
    </define>

and define the named rules which contains the rules
<rule name="horizontal-left-div">...</rule>
<rule name="horizontal-left-ul">...</rule>
<rule name="horizontal-left-li">...</rule>
<rule name="horizontal-left-a">...</rule>

and so on..

you could now put all that stuff in a separate file and include it with
<css>
  <include src="cssmacros_menu.xml"/>
  ...
</css>

any thought ?

regards.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XMLCSS

Posted by BURGHARD Éric <er...@systheo.com>.
Hi, 

I will set up an example and a patch later to convince you that xmlcss with
macros is much more readable that css (it's the main reproach apparently:
just see my later post). I hope that this example will show too that
starting sharing macros libraries will greatly help webdesigner to be less
technician in a pure css environnement.

Regards


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XMLCSS

Posted by BURGHARD Éric <er...@systheo.com>.
Gunter D'Hondt wrote:

> in my opinion "css in xml-format" harms the SoC coz it's the webdesigner
> that builds the css and they are so used of working with visual tools like
> TopStyle to easily edit the stylesheet; there you can select the "IE &
> Netscape compliant" css properties

A webdesigner in a real world had to know xhtml and css syntaxes. If you
look at dreamweaver generated code, you will certainly notice that besides
the fact that it's a graphical tool, it's doesn't apply SoC in the sens
that the generated xhtml is tied to specific classes (style1, style2,
style3, ...).

xmlcss is not a graphical tool but just a tool that help a skilled
webdesigner to style an xhtml in a zengarden way
(http://www.csszengarden.com/) by reusing set of rules through macros.

> and as far as I know the next spec for css would include inheritance which
> will be a really great advantage; but how will you do that in xml; by
> adding an attribute "extends"?
> Gunter

ok but can we do in the present ?  We just didn't use all CSS2 in our
project for standard acceptance reasons. Do i have to wait 3 years for
CSS4 ?

inheritance is already here in xmlcss with the apply attribute. Once
inheritance will be in css, the stylesheet would generate optimised css for
all the browser that claims to support it (using css syntax). And what
about variables and macros ?

By using macros we could help a webdesigner to setup menus for example
without boring him with model boxes differences or css tricks. He just had
to concentrate on color and padding and placement.

When i heard that xmlcss is not as readable that css, i'm not agree. And it
will be easy to convince you. if prefer reading

<menu div=".menu" orient="horizontal" anchor="left"/>

instead of 

.menu {
  font-family: Arial, Verdana, sans-serif;
  font-weight: bold;
  font-size: 8pt;
  float: left;
  width: 100%;
}

.menu ul {
  list-style-type: none;
  float: left;
}

.menu li {
  width: auto;
  white-space: nowrap;
  float: left;
}

.menu a {
  padding-bottom: 1pt;
  padding-top: 1pt;
  padding-right: 5pt;
  padding-left: 5pt;
  text-align: center;
  text-decoration: none;
  white-space: nowrap;
  display: block;
}


for which i need to be overskilled to know that they represent a left
anchored horizontal menu.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XMLCSS

Posted by BURGHARD Éric <er...@systheo.com>.
Jean Pierre LeJacq wrote:

> On Wed, 24 Nov 2004, Bertrand Delacretaz wrote:
> 
>> Le 24 nov. 04, à 15:46, BURGHARD Éric a écrit :
>>
>> > ...an xmlcss file is writen like that:
>> > <css>
>> >  <rule select=".myclass">
>> >    <padding value="0"/>
>> >    <margin top="10px/>
>> >  </rule>n t
>> > </css>....
>>
>> The problem might be getting people to write CSS in XML. The
>> native CSS syntax is so much more comfortable to write.
> 

yes true. but the conversion is really straight forward. I wrote for example
a simple sed script which convert existing css into xmlcss. With a good xml
editor you've got completion, syntax checking, ...

> Cross browser support for CSS is such that hacks are almost always
> required for non-trivial use of CSS.  Probably the simplest example
> is the use of non-standard box model that IE 5.5 and below use.
> These hacks generally use known CSS parser errors in the various
> browsers involving among other things white space and comments.
> 
> I don't quite see how these hacks could be implemented in your
> proposal.
> 

You don't need theses hacks. You had the agent attribute. just write

<width value="100%"/>
<width value="98%" agent="ie"/>

or

<width value="100%" agent="! ie"/>
<width value="98%" agent="ie"/>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XMLCSS

Posted by BURGHARD Éric <er...@systheo.com>.
Bertrand Delacretaz wrote:

> Le 24 nov. 04, à 15:46, BURGHARD Éric a écrit :
> 
>> ...an xmlcss file is writen like that:
>> <css>
>>  <rule select=".myclass">
>>    <padding value="0"/>
>>    <margin top="10px/>
>>  </rule>
>> </css>....
> 
> ouch. Angle brackets strike again ;-)
> 

:-)

>> ...any thought ?
> 
> Without having looked at the details, I like the idea!
> 
> The problem might be getting people to write CSS in XML. The native CSS
> syntax is so much more comfortable to write.
> 

yeah but it was easier for me to write it in xml (for parsing and
transforming reasons) instead of writing an expression syntax above css.
With xml i can use the power (and stability) of xslt, and my standard xml
editor (outline view is more readeable than a rought css) for completion
and syntax checking. xmlcss is just an xmlification of css. without defines
an macros, convertion is immediate in both ways (simple scripts can do that
for you).

> generated CSS can be cached by Cocoon (or by whatever front-end cache
> you're using).Maybe it would be easier for this to have different CSS
> URLs (generated by Cocoon based on browser detection) for the different
> browsers, instead of generating variable CSS content for the same CSS
> URL based on the browser type.
> 

In fact, there are two steps and two pipelines. The first one generate an
xslt stylesheet (yes a stylesheet that generate another stylesheet)
responsible for transforming a given xmlcss (only macros and definitions
are used in this step) for a given browser. You can use cocoon caching.

the second pipeline (which match for example css/*.css) just do the
transformation on the xmlcss with the stylesheet generated at the first
step (using of cocoon:/ in src url). this step can be cached too.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XMLCSS

Posted by Gunter D'Hondt <gu...@sofico.be>.
in my opinion "css in xml-format" harms the SoC coz it's the webdesigner 
that builds the css and they are so used of working with visual tools like 
TopStyle to easily edit the stylesheet; there you can select the "IE & 
Netscape compliant" css properties
and as far as I know the next spec for css would include inheritance which 
will be a really great advantage; but how will you do that in xml; by 
adding an attribute "extends"?
Gunter




Bertrand Delacretaz <bd...@apache.org> 
24-11-2004 16:41
Please respond to
users@cocoon.apache.org


To
users@cocoon.apache.org
cc

Subject
Re: XMLCSS






Le 24 nov. 04, à 15:46, BURGHARD Éric a écrit :

> ...an xmlcss file is writen like that:
> <css>
>  <rule select=".myclass">
>    <padding value="0"/>
>    <margin top="10px/>
>  </rule>
> </css>....

ouch. Angle brackets strike again ;-)

> ...any thought ?

Without having looked at the details, I like the idea!

The problem might be getting people to write CSS in XML. The native CSS 
syntax is so much more comfortable to write.

Another point to consider is cacheability: you'll have to make sure the 
generated CSS can be cached by Cocoon (or by whatever front-end cache 
you're using).Maybe it would be easier for this to have different CSS 
URLs (generated by Cocoon based on browser detection) for the different 
browsers, instead of generating variable CSS content for the same CSS 
URL based on the browser type.

-Bertrand



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XMLCSS

Posted by Miles Elam <mi...@pcextremist.com>.
Most browsers are moving toward better and better W3C spec compliance.  
The notable holdout  by a certain large software company can be 
mitigated with the use of Dean Edwards's IE7 code.

http://dean.edwards.name/IE7/

It's still in development, but no more so than the code suggested here. 
  The advantage to using the above is that standard CSS authoring is 
encouraged without extensive hacks or translations.  I think standard 
CSS authoring is the key.  Translating to XML for conditional 
processing is IMHO a step in the wrong direction.  You almost guarantee 
that you will be the only one who can ever write CSS for your site.

- Miles Elam

P.S.  I can't hurt that because of the extra client-side processing, 
other browsers will seem faster than IE.  Not that I would ever want to 
sabotage IE performance to prove a point.  No.  Never.  ;-)


On Nov 24, 2004, at 8:16 AM, Jean Pierre LeJacq wrote:

> On Wed, 24 Nov 2004, Bertrand Delacretaz wrote:
>
>> Le 24 nov. 04, à 15:46, BURGHARD Éric a écrit :
>>
>>> ...an xmlcss file is writen like that:
>>> <css>
>>>  <rule select=".myclass">
>>>    <padding value="0"/>
>>>    <margin top="10px/>
>>>  </rule>
>>> </css>....
>>
>> The problem might be getting people to write CSS in XML. The
>> native CSS syntax is so much more comfortable to write.
>
> Cross browser support for CSS is such that hacks are almost always
> required for non-trivial use of CSS.  Probably the simplest example
> is the use of non-standard box model that IE 5.5 and below use.
> These hacks generally use known CSS parser errors in the various
> browsers involving among other things white space and comments.
>
> I don't quite see how these hacks could be implemented in your
> proposal.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XMLCSS

Posted by Jean Pierre LeJacq <jp...@quoininc.com>.
On Wed, 24 Nov 2004, Bertrand Delacretaz wrote:

> Le 24 nov. 04, � 15:46, BURGHARD �ric a �crit :
>
> > ...an xmlcss file is writen like that:
> > <css>
> >  <rule select=".myclass">
> >    <padding value="0"/>
> >    <margin top="10px/>
> >  </rule>
> > </css>....
>
> The problem might be getting people to write CSS in XML. The
> native CSS syntax is so much more comfortable to write.

Cross browser support for CSS is such that hacks are almost always
required for non-trivial use of CSS.  Probably the simplest example
is the use of non-standard box model that IE 5.5 and below use.
These hacks generally use known CSS parser errors in the various
browsers involving among other things white space and comments.

I don't quite see how these hacks could be implemented in your
proposal.

-- 
JP



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: XMLCSS

Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 24 nov. 04, à 15:46, BURGHARD Éric a écrit :

> ...an xmlcss file is writen like that:
> <css>
>  <rule select=".myclass">
>    <padding value="0"/>
>    <margin top="10px/>
>  </rule>
> </css>....

ouch. Angle brackets strike again ;-)

> ...any thought ?

Without having looked at the details, I like the idea!

The problem might be getting people to write CSS in XML. The native CSS 
syntax is so much more comfortable to write.

Another point to consider is cacheability: you'll have to make sure the 
generated CSS can be cached by Cocoon (or by whatever front-end cache 
you're using).Maybe it would be easier for this to have different CSS 
URLs (generated by Cocoon based on browser detection) for the different 
browsers, instead of generating variable CSS content for the same CSS 
URL based on the browser type.

-Bertrand