Re: How could total separation of content (xhtml/xml) and presentation (CSS) be achieved with the Bitflux Editor (or Mozile)?

On Mar 4, 2005, at 16:41, DrSlump wrote:

   Hi!

I don't have any experiance with XPath, but after looking a little in a 
book I think I understood your example.
Anyway I don't think it would have the same functionality as the XML i 
proposed, correct me if I'm wrong. (Sorry for now explaining my example 
properly.)

The thing I described would work like this:
The first rule would allow the editor to assign the a "float: right" or 
"float: left" property to either "div#main img" or "p.editable".
The second rule would allow the editor to assign "text-align: justify" 
or "text-align: left" and/or "font-family: serif" or "font-family: 
sans-serif" to any (*) property but not "div#main".
So how I imagined it could look for the editor would be that he/she 
would be offered a set of choises for each property, i.e. in a popup 
menu.

I don't know if it'd make things any better to have a CSS-kind of 
syntax, because it'd require some new way of thinking anyway. Maybe an 
XML-format would be even less confusing because of that. It could be a 
bit easier to grasp the CSS-like syntax, but on the other hand the 
performance could be suffering and the coding would be more complicated 
(I guess I'd have to start playing with them regular expressions :-).

When I wrote that it'd be for designers I didn't expect it to be for 
code-fearing designers, such designers can't work with templating and 
stuff associated with a CMS anyway.
In that case it'd have to look something like this:

div#main img, p.editable {
   float: right;
   float: left;
}

*, !div#main {
   text-align: justify;
   text-align: left;
   font-family: serif;
   font-family: sans-serif;
}

Comments or ideas anyone?

   cheers, Simon



> Simon Rönnqvist wrote:
>> The first thing I had to start thinking about however was how the 
>> designer would be able to define rules for what the editor could do.
>> I think some kind of easy to understand XML-file could define 
>> something like:
>> <rule>
>>   <context>div#main img</context>
>>   <context>p.editable</context>
>>   <float>
>>     <value>right</value>
>>     <value>left</value>
>>   </float>
>> </rule>
>>
>> <rule>
>>   <context>*</context>
>>   <context><not>div#main</not></context>
>>   <text-align>
>>     <value>justify</value>
>>     <value>left</value>
>>   </text-align>
>>   <font-family>
>>     <value>serif</value>
>>     <value>sans-serif</value>
>>   </font-family>
>> <rule>
>>
>> I guess you get the picture... <context> defines what could come 
>> (wildcards allowed just like in CSS)
>> HERE { css-properties: ...; } in the CSS.
>> The other child-nodes of <rule> would just be CSS-properties.
>> And then their child-nodes would be allowed values.
>
> hi Simon,
>
> In my experience designers are quite confortable with CSS syntax but 
> not so much with XML dialects :(
> What about if the program asks for a css file with the styles 
> available to an editor (without the layout ones), then parse the css 
> and convert its selectors to xpath and create the rules. Then the 
> wysiwyg editor runs the rules' xpath experssions against the current 
> element and the ones that match are displayed as available in the 
> current element to the editor.
>
> css file:
> div#main img {   /* no rule since there is no final class or id */
>  border: 1px solid red;
> }
> div#main img#logo {  /* div[@id['main']//img */
>  margin: 1em;
> }
> div#main img.left { /* div[@id['main']//img */
>  float: left;
> }
> img.right { /* img */
>  float: right;
> }
>
> the program generates the following xml to its use by the wysiwyg 
> editor
> <rules>
>  <rule type="id" match="div[@id='main']//img">logo</rule>
>  <rule type="class" match="div[@id='main']//img">left</rule>
>  <rule type="class" match="img">right</rule>
> </rules>
>
> With big css files it can become slow though. Although if the client 
> browser supports xpath then the match process can be done on the 
> client side.
>
> I don't know though how to handle pseudo-selectors like :hover or 
> :active. Moreover CSS allows to specify several classes to an element, 
> which can be a bit difficult to handle.
>
> The advantatge of this method is that it doesn't require the designer 
> to manually make (and update) yet another file with a brand new syntax 
> to him.
>
> ciao, Iván
> -- 
> bx-editor-users mailing list
> [email protected]
> http://lists.bitflux.ch/cgi-bin/listinfo/bx-editor-users

-- 
bx-editor-users mailing list
[email protected]
http://lists.bitflux.ch/cgi-bin/listinfo/bx-editor-users