Re: Conclusion for :read-only and :read-write?

Daniel Glazman wrote:
> Matthew Raymond wrote:
>>   I do not find your use of sarcasm and a logical fallacy involving
>>your level of experience very persuasive.
> 
> Well, I did not find your affirmation that a browser should not be
> the basis for an editor very useful - nor polite - either. Most
> of current wysiwyg editors use as editing layout engine a modified
> extended browser, just because they have to. In particular, the editor
> I am implementing is based on Gecko. Not taking under consideration
> that editors are browser-based can only lead to failure since tools will
> not be editing able to implement the spec. Again, my option 3 was there
> only to list all options, but is NOT realistic in a wysiwyg editor.

   I don't understand what you are trying to say here. How is
implementing :read-only and :read-write in a manner consistent with
markup language semantics any different than the implementation of
:enabled and :disabled? Furthermore, why would you want such a
difference in an HTML editor? (The only reason I can come up with is
that you might have styling for the webpage that causes confusion when
combined with the styling used by your HTML editor to allow easier
editing.) Granted, you do want styling for stuff like |contenteditable|,
but it seems to me that a pure mechanism for editor-specific styling
makes more sense.

> Speaking of read-only, it's not my person who ignores what read-only and
> read-write means in the context of XForms for W3C, but XFoms that
> ignored the very first implementation of read-write/read-only in 
> Microsoft Internet Explorer about SEVEN years ago. That's called
> contenteditable, and it's not my fault if W3C groups always try to
> reinvent the wheel these days. Read-write and read-only are keywords
> full of semantics, and designing them only with forms in mind is
> pointless.

   Look here:

http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/contenteditable.asp

   The only place where Microsoft even uses the term "read/write" is in
specifying whether you can set .contentEditable in JScript or not. Under
no circumstances does it define content with |contenteditable=false| as
"read-only". Furthermore, I tested IE6, and it does not appear to have
ANY support for :read-only and :read-write, and I can't find them on the
MSDN site. The contenteditable attribute fits your "read-write"
definition only because you're using the CSS3-UI definition.

   Microsoft isn't defining :read-only and :read-write as matching
|contenteditable|. You and CSS3-UI are.

> Now, this said, do what you want. I have this feeling - and a few others
> have it too - that contenteditable is much more important than the state
> of forms elements, that web application builders are going to use it
> more and more everyday. If read-write and read-only are designed so they
> are not living well with it, we'll have to come up with something else.
> Eh.

   I've suggested alternatives, and you have yet to comment on them.
Specifically, I suggested the more appropriate pseudo-class name
"editable". I fail to see why there's such a pressing need to use the
current CSS3-UI definitions when :read-only and :read-write have yet to
be implemented in IE, Firefox and Opera. (I suspect Safari hasn't
implemented it either. I can't find anything on the web about it.)

Received on Thursday, 11 August 2005 21:14:58 UTC