We can use this approach to create templates for anything – a block with a chunk of descriptive text and an image, an event, a product listing and so on. She doesn’t need to worry about adding any style – the designer will worry about that and because the data is marked up correctly it is going to be very easy to use CSS to make it look exactly as we want. In the admin this template turns into a form, the content editor just needs to fill in the form with the right details. In Perch if I want the editor to add some contact details, I create a template with those details marked up using microformats. This is something we’ve been doing with custom CMS builds for a long time over at and is really the core concept in Perch – our small CMS product. We need to provide a way to enable people to enter content in a way that maintains the meaning. Firstly, a lot of content that we are asking people to edit is not freeform, it has structure, semantic meaning. I think the alternative comes in two forms. It is hard to get the average content editor to use the correct heading level – never mind use microformats to enter an event or contact information! So they suck. Consider adding an event to a page listing events for example, the designer may have created rules in the CSS to make the title, description and date display a certain way – but only if the correct mark-up and classes are added. They end up with a big area and need to work our what to add in order for the content to be formatted as the designer intended. This can enable all kinds of stuff to get into your content, which is then very hard to remove and fundamentally tied to the current design of the site.įor a content administrator a WYSIWYG editor is actually a very poor way for them to add content to the website. For developers, even if you switch off most of the buttons, just allowing the administrator to enter simple formatting and links, you still have a situation where a user is entering HTML which you then display on the website. Unless you carefully go through and remove all the creativity that stuff is going to stay there. Anywhere that allows people to enter HTML via an editor allows them to get as creative as they like, using any mark-up that they like. WYSIWYG Editors suck because as a designer you lose control over big chunks of the design. While content editors are busy changing headings to Comic Sans, pondering the use of a grimacing smiley on their about us page or getting creative with colour, they are not considering the actual copy they are adding to the site. WYSIWYG Editors suck because they promote thinking about style rather than content. What You See Is What You Get WHERE exactly? On a regular desktop browser, on your iPad, phone, in RSS, read out by a speaking browser? In most CMS implementations, you don’t see what you get on the web anyway, what you see is a textarea replaced by a box with a bunch of buttons at the top and you can see what your changes will look like in the context of that box – not on the site you are managing. WYSIWYG Editors suck because firstly, they are a flawed premise.
I think these things are responsible for not only a lot of badly formatted content, but also for holding back the development of better ways of allowing non-technical users to deliver content. But its functionality can be easily extended andĬustomized to fit any requirements.Recently I spoke at the Highland Fling Conference in Edinburgh and, as part of my presentation on Choosing the right Content Management System, I had a bit of a rant about the use of WYSIWYG editors in Content Management Systems. It comes with the basic set of formatting features. It is based on modern "contenteditable"ĪPI so it should work everywhere as is. Text Editor Framework7 comes with a touch-friendly Rich Text Editor component. Text Editor element.įor example: var textEditor = app. el - HTMLElement or string (with CSS Selector).( el)- get Text Editor instance by HTML element
0 kommentar(er)
