Skip to content

Instantly share code, notes, and snippets.

@mindplay-dk

mindplay-dk/notes.md Secret

Last active December 12, 2015 06:58
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mindplay-dk/ee03c78e4b0a23bff4ec to your computer and use it in GitHub Desktop.
Save mindplay-dk/ee03c78e4b0a23bff4ec to your computer and use it in GitHub Desktop.
Download ZIP
Structured Content Editor
Raw
notes.md

http://www.sitepoint.com/an-open-letter-to-my-joomla-client

It is remarkable how many of these issues come back to the use of WYSIWYG editors - most of these problems are not unique to Joomla, but basically affects every CMS that uses a WYSIWYG, and they have been around since dawn of time. Or at least since WYSIWYG became common.

In my personal opinion, the root cause of this problem is HTML, which isn't really a good format for user-managed content. Don't get me wrong, HTML is of course a great (nay the only) format for delivering content - but for many years, I have thought that it is not a good format for user-managed content, for a couple of reasons:

  1. It's too generic - it can't (feasibly) take into account any client-specific content semantics.

  2. Content structure is "baked in" with the content - markup and user-editable content are a single collection of data.

Separation of model from view is taken for granted in software these days, but content managed with a WYSIWYG is actually worse - it fails to separate three distinct aspects of content:

  1. Structure (div > ol > li > a > ...)
  2. Layout (css classes, inline style-attributes, etc.)
  3. Data (the actual content: titles, sections, paragraphs, list items, images, captions, etc.)

I have been thinking for a while about creating a new type of content editor based on client-specific content semantics, properly separating content from structure. Others have too - there was a brief wave of "WYSIWYM" editors (What You See Is What You Mean) attempting to separate content from structure. Unfortunately, that approach doesn't make much sense to clients, and it doesn't really address the second problem. (or perhaps more accurately, addresses the problem only at the user-interface level.)

What we need is a content editor that lets us define client-specific content semantics, addressing these problems on two fronts:

  1. Content semantics are well-defined and specific to the client's needs - there is a defined "content schema".

  2. Only content is actually stored, with references to fields in "content schema" populated by that content.

  3. Layout/presentation is separated from content and schema, enabling us to make changes and re-render as needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment