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

Simon Rönnqvist <[email protected]> Sat, 5 Mar 2005 02:44:15 +0200
Newsgroups gmane.editors.bitflux.general
Message-ID <[email protected]>
On Mar 5, 2005, at 02:05, DrSlump wrote:

   Hi!

Now you got me kind of right!

> Now I see what you mean, you want to 'attach' css properties to 
> elements instead of selectors and classes. I never needed or even 
> thought about such functionality, I guess it's too fine-grained and 
> IMHO 95% of the time the same can be accomplished with properly 
> designed css stylesheets.

   Let's cite my original post:
"One thing which I at this point think seems to be missing from the 
Bitflux Editor (and Mozile) is an ability to edit external 
CSS-properties. :-) It'd be great if one for example could give an 
image a specific ID and then in the separate CSS float that element 
right or left. To my present understanding (correct me if I'm wrong) 
I'd have to specify a class i.e. called left or right, which 
semantically wouldn't make any sense. Then I might just as well specify 
a style="float: ..." attribute instead, and then the separation of 
content and style would have failed at that point. (One could of course 
argue wether there's a need for total separation or not, but let's say 
there is. This img floating is just an example.)"

So in this example of mine I wouldn't like to use inline styles, but 
that wouldn't be any worse than assigning styles called floatLeft or 
floatRight. What I'd like to have would be good semantics and total 
separation of content and style.

I.e.
#picture1, #picture3 { float: right; }
#picure2 {float: left; }
#picture3 { border: 1px solid black; }  /* Just one more property to 
point out why this could be more useful than using classes. */

And to make this even more advanced we should of course allow the user 
to use classes and even properties defined by element (i.e. #main img), 
but let's begin with just thinking of ID:s.

> Even if you allow to define custom css properties to an element, based 
> on some restriction rules, you'll need create a css file with those 
> properties classes or add them as inline styles (not so good).
> I still think that a best aproach would be to let the designer add 
> some extra css rules to allow the editor some margin of decission on 
> the final result's design. The only thing needed is some mechanism to 
> present the editor valid css classes for the current element, as 
> described in my previous mail.

   These things were mentioned above.

> Back to your idea, I think the original xml based representation of 
> the rules makes more sense and even if more verbose is clearer than 
> css like syntax.
> By the way, you'll have to use xpath (doing it by regexp could be much 
> slower and error prone) to check which properties can be used for the 
> current element.

   Well I was thinking of using regexp with the CSS-format.
But since we now agree that we'd better go with the XML-format regexp 
is definitely out of the picture. I just need to dive further into the 
world of XML, XSLT, etc., which will be very healthy. Even healthier 
than learning regexps. :-)

   cheers, Simon

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