Hacker News Reader

Comment by oneeyedpigeon | Hacker News Reader

What kind of markup will this produce? Currently, I'm left guessing as to whether or not it will be the same as I see when I inspect the editor itself. It claims "semantic markup", yet it offers styling tools alongside semantic ones.

View on HN

It produces "rich text" in a clean JSON format, which is one of Quill's strengths IMO. It's also what enables it to be used for real-time collaborative editing across browsers without any weirdness about HTML normalization.

I use Quill on my site to allow trusted but non-technical users to write rich text. It was easy to configure so it only allows a strict subset of tags. My users have been using it for a few months and haven't managed to slip in any disallowed tags, attributes, or styles.

I did the same. But those non-technical users still ask why they can't paint their text red, right-align paragraphs and insert as many line breaks as their good taste suggests. So it can't really work unless they agree to get a bit technical and understand what semantic markup and CSS are. And then, I'd really prefer to teach them some basic markdown and have them use a markdown editor, only so they can stop believing that "what they see is they get".

It produces semantic markup when it can, but in some cases such as font color, there is no semantic representation so it uses the most cross browser/application implementation, which is inline styles.

Explain what you mean by 'semantic markup'. I find people mean the term in two ways: so trivially it's uninteresting or so unrealistic it's implausible.

In my experience, the most common meaning of 'semantic' is 'non-presentational'. For example:

  <font color="#ff0000">hello, world</font>

is non-semantic because it's referring purely to presentation, rather than meaning. I'm not just being obtuse, this is a real-world requirement since our editors need to be able to mark things up according to meaning, but not randomly screw around with our design. I admit there's a blurry line, exemplified by the W3C's redefinition of the 'b' element.

I'd concur that is a good example of 'non-semantic' but what's trickier is to agree on what 'semantic' markup looks like. Short of well-executed microdata - I've always felt that a lot of claims about markup best-practice smacked of cargo-culting.

It's always worth asking the question: "semantic for whom"? i.e. who is the consumer. That clears away a lot of fog.

Reply on news.ycombinator.com