Hi guys, I know I am a little biased, but check out XStandard. We spent 18 months writing this editor from scratch, not a wrapper around the MSHTML control. The editor generates clean, accessible and semantically rich markup from the get go. There is no colour-picker or font-selector because these tools generate semantically barren code. There are many features that help non-technical user who don't know about best practices write accessible code. Besides requiring alt text for images, summaries for data tables, automatically associating table cells to headers through id/header attributes, and much more, this editor has got a unique feature that we call "Screen Reader Preview" which gives users visual feedback on how screen readers might process content. Check out http://xstandard.com We also setup a forum to discuss implementations, techniques and best practices for generating more accessible markup: http://www.accessifyforum.com/forum17/
Regards, -Vlad XStandard Development Team ----- Original Message ----- From: "Michael Zeltner" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 22, 2004 7:13 PM Subject: Re: [WSG CMS] standards compliant, accessible, semantic xhtml based CMSes? > Ben Bishop wrote: > > Hi Michael, > > hey ben > > thanks for your response! > > > The real killer is the code produced by the inline WYSIWYG editors - > > some of them produce pretty butchered mark-up. I'm yet to see a > > cross-browser WYSIWYG editor that produces valid code, but there are a > > few in the works. > > we have epozng (http://epoz.sourceforge.net/) which is going to be > renamed to "kupu" soon ;) it has nice xhtml output even in ie. maybe > something that the people that are working on such editors should have a > look on. they're moving away from "zope only" implementations anyway ;) > > > A feature of some CMS' - such as FarCry - WYSIWYG editors are treated as > > plug-ins, letting you can choose an editor that covers your > > requirements. When a better WYSIWYG editor comes on the market, you can > > simply plug it in and turn it on. > > same for plone ;) we already have some which are quite usable even if > they're not 1.0 or 0.5 yet ;) - for example the old epoz > (http://www.zfl.uni-bielefeld.de/personal/mjablonski/epoz), kupu (see > above), cmfvisualeeditor (http://sourceforge.net/projects/collective), > and an implementation of fckeditor (http://www.fredck.com/FCKeditor/ - > it's not downloadable yet) > > > Who are these people? Somebody has to invest their time learning these > > skills - the effort has to come from somewhere. > > which effort? learning css of newbies or putting together such a skin? > > first one: http://plone.org/development/teams/ui/css_powered_sites > (thats what i got in the last week - more in the works - we're just > getting 2.0 out ;)) - why do they learn css? because it solves basic > problems they had with ealier plone versions, and they would have them > again - customized templates of earlier versions are able to crash your > current one. and thats not only a plone issue (see things i'm mentioning > later) > > second one: http://plone.org/development/teams/ui/ - to solve the > problems from above. and we keep on coming with new concepts that ease > development and migration between versions, because we agree on "there > is no 'perfect structure' that fits on every site". we just don't > believe in the fact that writing skins from scratch for new projects is > something good ;) > > > I disagree with the "shouldn't need to think", but agree with "it should > > be there." I think it's always important to keep accessibility/usability > > in mind, no matter how small the site is. > > sure but what if someone already thought about that for you? ;) thats > what i mean. we have people that do usability tests and we have people > from the w3c wcag working group. so i guess we're pretty good :) > > > A skin is nothing more than mark-up coupled with CSS and images. It's > > really quite simple to create your own look and feel using products like > > FarCry. > > i didn't use/try farcry but many cmses out there mix parts of logic or > variables with templates - sometimes you have to. that causes problems > like the one i've mentioned above - so migration is needed. how do you > migrate customized markup with logic/outdated variables in it? ;) let's > face it, it's almost impossible when it comes to semi complicated stuff. > > > A CMS should be about making it easier to build and maintain web sites. > > Results are directly proportional to time, effort and/or cost. > > thats what i'm talking about ;) thats why my argument is: having a > "usable, accessible, semantically (almost - we're working things out ;)) > correct, very skinable with css"-cms is faster and easier to maintain > than your own skin with markup and css, that you have to constantly > update to improve usability accessiblity etc etc etc. with a flexible > skin these updates of the standard skin, when you update. > > also, if you have a "plugin" based cms, the problem is that most of the > time the look and feel of a plugin is totally different and you have to > modify it to make it fit into your skin. now if you have a standard set > of widgets that are easily skinable, you end up writing one skin and > every new plugin that you install gets the design of your brand. > > to be arrogant (hehe): plones skin isn't just a skin - it's 50% of the > application. > > in case someone thinks this is some kind of weird promotion: i don't > really want to advertize plone here - but it's all i can take as example > for the things i do. > > regards, michael > -- > </gro.jiin//:ptth> �jiin > ********************************************************* > The CMS discussion list for http://webstandardsgroup.org/ > ********************************************************* > > ********************************************************* The CMS discussion list for http://webstandardsgroup.org/ *********************************************************
