W3C home > Mailing lists > Public > www-style@w3.org > August 2005

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

From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Date: Thu, 11 Aug 2005 09:17:03 +0200
Message-ID: <42FAFB6F.9060305@disruptive-innovations.com>
To: www-style@w3.org

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.

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

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.

Received on Thursday, 11 August 2005 07:15:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:20 UTC