Need a WYSIWYG for custom CMS.
Thinking of building our own custom CMS for work. Can I ask why all decent WYSIWYG editors only output XHTML and not HTML strict?
Can I also ask why no WYSIWYG editors can handle block level styling and are there plans for XStandard to be able to do this?
Johan De Silva / Portfolio
Share: 
The output of XHTML from these tools is because of hype. There used to be a widespread view that XHTML was somehow better than HTML.
As for block-level styling, projects I've worked on have usually haven't had that available as a default feature. The need for it is usually rare, so the editor components only permit hand-authoring it in the HTML source view.
IIRC, there was a system where you could add class names to the interface. Can't find a link to it. I did remember Alastair Campbell's WYSIWYG category. In particular, his Importing CSS article details how class could be incorporated into editors.
Share:
| Quote: |
| The output of XHTML from these tools is because of hype. |
Not at all. The output of XStandard is XML in the XHTML dictionary. The reason why XStandard generates XML output is because many users process the output from the editor using XML tools before the output (content) is merged with a Web page template in order to generate the final Web page. For example, please see Advanced image management article.
The editor also lets users customize the Preview and Screen Reader Preview features via XSLT. This would not be possible if the output was not XML.
And some CMS vendors needs to process content en-masse as a batch process to make changes. For example, if they need to change:
| Code: |
| <h3 class="class-name"> |
to
| Code: |
| <h2 class="new-class-name"> |
The only reliable way to do this for thousands of documents is to use XSLT or XML DOM parser. Using regular expressions can be risky and complicated to write if the markup sometimes contains other attributes such as "id" and "title".
Share:
There's no need to send HTML-with-an-XHTML-DOCTYPE to the browser. You could transform the XML into HTML before final transmission. XSLT has an HTML output mode, for example.
More radically, all the XML parsing could be replaced by HTML parsing. This would allow all the templates and content to be stored using the same HTML as would be transmitted. The same transformations would be possible; you'd just have an HTML parser creating the memory structure which gets transformed instead of an XML parser.
I fully agree with RegEx parsing being a terrible idea, though!
Share:
| Quote: |
| There's no need to send HTML-with-an-XHTML-DOCTYPE to the browser |
I think this would fall outside the scope of this discussion. The discussion started with the question why decent WYSIWYG editors generate XHTML. And my response is that markup generated by the WYSIWYG editor (for CMS) needs to be easily parsable using off-the-shelf tools. XML is the best choice because all development environments have XML parsers and you have such variety like DOM XML parser, XSLT and SAX.
| Quote: |
| all the XML parsing could be replaced by HTML parsing. |
Internally a tool can use HTML parsing but CMS vendors/app developers need to be able to use parsing tools that cannot be replaced by HTML parsers. HTML parsers, which are still exotic tools are based on DOM (I think?), so they cannot replace two wonderful technologies such as XSLT and SAX.
Share:
| Vlad Alexander wrote: | ||
|
| Vlad Alexander wrote: |
| The discussion started with the question why decent WYSIWYG editors generate XHTML. |
| Vlad Alexander wrote: |
| And my response is that markup generated by the WYSIWYG editor (for CMS) needs to be easily parsable using off-the-shelf tools. XML is the best choice because all development environments have XML parsers and you have such variety like DOM XML parser, XSLT and SAX. |
| Vlad Alexander wrote: | ||
|
Even if you use XML for your storage, the XSLT specification says it can generate HTML. So there's still no reason to transmit XHTML as text/html: just use the HTML mode.
Share:
| Cerbera wrote: | ||||
|
see productive online discussionsJack Pickard The Pickards Information Services| Blog | Twit
Share: