goglgod.blogg.se - Whats rich text format

The graphical representation of the CKEditor 5 Data ModelĬKEditor 5 is a good example. That’s the case for RTEs, where we can see a few innovative solutions popping up on the market. The proliferation of JavaScript and the maturity of its developers community, started enabling the development of much more ambitious in-browser solutions. The answer may be obvious and here’s where technology comes to the rescue - it’s the re-birth of RTEs. We raised new experts called “Content Architects”, who are meticulously designing all details for optimized content creation.Ĭonsidering this “evolution”, is it a sane decision to have non-programmers, or “normal people”, to have access to the “source code” of the text they produce? Shouldn’t they be simply focused on writing, having simple tools to intuitively add extra value to their content? Nowadays, we talk a lot about “semantic web” - about accessibility. Especially when we’re talking about CMSs. It is clear already that we’re past the early ages when programmers were creating applications for programmers. The most notorious example is Markdown, but many others are available, like BBCode, Textile and all the variations of Wiki Markup. Markdown and SimilarsĪs a way to mitigate the problems with HTML, lightweight markup languages have been created.

It is easy to make mistakes, like missing a closing tag, and have the text destroyed.Īdditionally, if low-quality or misconfigured RTEs are used, the HTML produced by them can be extremely ugly.Ĭonclusion: HMTL is for programmers, not for “normal people”.

It may be harder for a person to read and understand it.

It is hard for an author to write it… I mean pure HTML.

Therefore, considering that we produce text inside browsers, usually targeting browsers as our channels of distribution of such text, it is natural to have HTML as our first option for the data format used to save content. It’s the way we tell browsers what to show to their users. HTML is the native “language” of web pages. As a result you have very low quality on the data produced by such editors. Still many people promote the idea that writing an RTE is a piece of cake, just because of such native features. That’s the reason why many quality RTEs avoid using, or override, most of the native browser features. The madness of contenteditable has already been discussed extensively out there. RTEs are known for using the browser infrastructure for editing as the base of their architecture. That a well configured, modern editor, like CKEditor, is able to keep authors under control, providing them all the necessary features to stay focused and write quality content.

To start off, let’s assume that the old concept that RTEs or WYSIWYG editors are “enemies” is not a concern anymore. Summing up, deciding for the right data format is a non-trivial and critical task. They must be able to understand it and to retrieve the additional value that rich-text provides. Finally, machines, like search engines, may “read” the text.

In e-mails, either as content or notifications.Īdded to the above, we must also take into consideration that data produced in one application can be used by another one.

In a web page, which nowadays must be responsive and adapt to different devices.The fact is that content produced by end-users of our systems can be used in different contexts, for many different purposes. Not taking into consideration the limitations imposed by some markup languages, the most important problem with this is interoperability. After all, we’re developers… introducing new standards fires the natural “why not?” approach. People also tend to bring their own extensions to such markups when implementing their systems, making the problem even bigger. There are dozens of “common” formats out there like HTML, Markdown, BBCode, Textile, XML, TeX, Wiki Markup, etc.