Le 21/06/11 00:00, Aryeh Gregor a écrit :
On Mon, Jun 20, 2011 at 5:32 PM, Ehsan Akhgarieh...@mozilla.com wrote:
There's a very good reason why existing browser engines have to resort to
nbsp; hacks. It's the only practical way to make sure that foo__bar
(s/_/ /) entered into an editable
Am 21.06.2011 02:16 schrieb Ojan Vafai:
It is certainly the case that some large subset of users use spaces to align
content, not to mention really care about things like two spaces after
periods, etc. One way or another, contentEditable needs to support this.
If we were starting with a clean
On Mon, Jun 20, 2011 at 6:05 PM, Ryosuke Niwa rn...@webkit.org wrote:
Problem is that not all user agents, in particular, mail clients support
white-space: pre-wrap.
Good point. That's pretty much the final nail in the coffin. I'll
specify something with nbsp's here, although I don't know how
On Mon, Jun 20, 2011 at 5:09 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
Does anyone have any suggestions on how best to handle this? It seems
like no matter what we do, the best advice to authors would be to set
white-space: pre-wrap on the editable region and the resulting
editable
If the user has the cursor positioned at the beginning or end of a
line, or immediately before or after a space, and hits space,
inserting a space at the current location would result in no visible
effect. Thus browsers will typically insert an nbsp in at least some
of these conditions, and/or
There's a very good reason why existing browser engines have to resort
to nbsp; hacks. It's the only practical way to make sure that
foo__bar (s/_/ /) entered into an editable element would appear the
intended way when the innerHTML of the editable area is submitted to a
server and later
Aryeh Gregor writes:
The behavior we really want here is to output regular spaces, and use
white-space: pre-wrap.
Does anyone have any suggestions on how best to handle this? It seems
like no matter what we do, the best advice to authors would be to set
white-space: pre-wrap on the
On Mon, Jun 20, 2011 at 5:32 PM, Ehsan Akhgari eh...@mozilla.com wrote:
There's a very good reason why existing browser engines have to resort to
nbsp; hacks. It's the only practical way to make sure that foo__bar
(s/_/ /) entered into an editable element would appear the intended way when
On Mon, Jun 20, 2011 at 3:00 PM, Aryeh Gregor simetrical+...@gmail.comwrote:
Is that really such a problem? At worst, there will be annoying
mismatches between the same content when it's editable and not
editable. Usually these won't really mess up the document, but if the
author notices
On 11-06-20 6:00 PM, Aryeh Gregor wrote:
On Mon, Jun 20, 2011 at 5:32 PM, Ehsan Akhgarieh...@mozilla.com wrote:
There's a very good reason why existing browser engines have to resort to
nbsp; hacks. It's the only practical way to make sure that foo__bar
(s/_/ /) entered into an editable
It is certainly the case that some large subset of users use spaces to align
content, not to mention really care about things like two spaces after
periods, etc. One way or another, contentEditable needs to support this.
If we were starting with a clean slate, the editing behavior we want is
11 matches
Mail list logo
