- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Fri, 19 Aug 2011 11:54:32 -0400
2011/8/18 Alfonso Mart?nez de Lizarrondo <amla70 at gmail.com>:
> Showing all whitespace would be the most complete solution, but if the rest
> of browsers could behave like Opera and handle this, that would be enough
> for most of the people:
>
> br:before {content: "\B6";}
That doesn't sound like a great solution, since it doesn't work for
line breaks created by things like <p>. There's no visible difference
between <div>foo</div><div>bar</div> and foo<br>bar, so it's confusing
to have them behave differently. I'm not surprised that browsers
don't agree here, though, because <br> is pretty magical and
underspecified.
> on the other side it's clear that besides the .execCommand a good Editing
> spec should state or hint about other features that the browsers must
> implement to behave properly (like showing the caret so the user knows where
> he's typing,? enable the user to select parts of the content,...). These
> might look trivial, but iOS5 seems to be the first mobile browser that will
> behave good enough so that both CKEditor and TinyMCE will enable the support
> for it (check the comments in
> http://code.google.com/p/android/issues/detail?id=8253 about the Android
> browser)
> A browser that provides a perfect implementation of all the execCommands but
> doesn't allow the user to type or select is worthless for editing.
There's not much need to specify things that are completely obvious.
If Android's browser doesn't support contenteditable, that means they
haven't gotten around to it yet, and writing in a standard that they
have to do it isn't going to make them do it any faster. Standards
are necessary to allow implementers to implement the same thing when
they want to implement it at all, not to make them implement something
that they aren't interested in right now.
Received on Friday, 19 August 2011 08:54:32 UTC