Wow, that's not a simple question at all. I'll try to explain why below, and why I think there is no correct answer to that question at this time given the state of art of browsers and underlying specs.

  • Is a WYSIWYG editor just a browser with caret, selection and extra UI?
    • Certainly not and there are two simple examples to prove it:
      1. empty HTML named anchors are meaningful but have no visual impact on the rendering of a document. So, in editing environments, we need to add something to make them visible and selectable.
      2. borderless tables are almost impossible to edit since you can't see where are the cells and how many rows/columns/spans there are in the table. So editors often add a dotted border around the table, lines, rows, cells to make them temporarily visible
  • Are all elements :read-only by default in a browser?
    • Yes. Unless the whole document is made in-browser editable...
  • Are all elements :read-write by default in an editor?
    • Yes but only for documents that are not based on a templates. Documents based on a template assume that all elements are :read-only by default...

Now, let's take an example of a document, edited in a wysiwyg editor, made for a contenteditabl-capable browser:

<html>
 <head>
 <title>contentEditable example</title>
 <style type="text/css">
 *:read-write { border: thick solid black }
 </style>
 </head>
 <body>
 <p>This <strong>important document</strong> has two <em>areas</em>, one editable, and one not editable.</p>
 <p contentEditable="true">This paragraph <strong>can</strong> be edited</p>
 </body>
</html>

The rendering is then as follows, if we accept that :read-write means exactly the same in the browser and in the editor, and if it applies to editors:

in browser in editor
http://glazman.org/weblog/images/in browser http://glazman.org/weblog/images/in editor

Now imagine that document is based on a template saying that the second paragraph, the one that is editable in the browser, cannot be changed by the document's author. The rendering would become as follows:

in browser in editor
http://glazman.org/weblog/images/in browser http://glazman.org/weblog/images/in editor

Hum. Who said wysiwygness?

As you can see, editing this very simple document becomes nightmarish in a wysiwyg editor applying :read-write... If applying :read-write and :read-only consistently between browsers and wysiwyg editors kills wysiwygness, I don't see the point.

And don't tell me that the author of the document should not use a so universal selector (*:read-write) because that's what is going to happen in real life in 99.99% of the cases. The stylesheet is made for the browser and the document cannot specify that it does not apply to editing environments.

So we have really three options wrt to the answer to the original question at the top of this short article:

  1. say that :read-write and :read-only should apply to wysiwyg editing environment but that a requirement for that is a hint on stylesheets saying if they apply to editors or not. Like with media selector when an author can decide to use a given stylesheet on screen and another on print (see also CSS Media Queries). That one is specifically for the CSS WG, HTML WG and XML Core WG of the W3C... (just for the record, all people seriously dealing with stylesheets know about that since the mid-80's...)
  2. say that :read-write and :read-only do not  apply to wysiwyg editing environments. That way, the editing tools are responsible for the editing-mode stylesheet and those styles are not overriden by intrusive browser-mode styles. Of course, it's less Wysiwyg but at least it's better editable
  3. say that :read-write and :read-only apply as in a browser.

From my perspective, only the first one makes real sense. The second one is only a workaround, not a solution. The third one is just not acceptable given the examples above.