In most of our applications, content created and formatted with a rich text editor remains relevant for a long time. In this situation it is desirable to format the text with classes instead of inline styles so that, in case there is a site redesign, the design of this content is easily changed and remains consistent with the overall design of the page. At the moment it is possible to use addFormat to add a class, but the editor doesn't seem to recognise it consistently leading to erratic behaviour, like for example nested span tags with the same class or the inability to remove a class created as such.
+1 this
I was a little bit shocked to see inline-styles in the generated code. So it's funny that the editor itself is cross platform compatible, but the generated text is not, at least not very useful for responsive design.
Cross platform compatibility is the reason inline styles are used. If you try to paste contenteditable text in Firefox into other applications like Word, class styles are not copied over, but inline styles are. It's not the prettiest markup but is the most practical for the time being. Some users might be willing to sacrifice this for the benefits of classes bring such as responsive design, which is why this is a feature on the roadmap.
@jhchen thank you for clarifying the decision.
+1. for my uses allowing responsive design is much more important than being able to copy into Word.
Here's a demo showing how to switch between using styles or classes in Quill 1.0: http://beta.quilljs.com/playground/#class-vs-inline-style
What about indent class attribute
Most helpful comment
Here's a demo showing how to switch between using styles or classes in Quill 1.0: http://beta.quilljs.com/playground/#class-vs-inline-style