On Thu, May 12, 2011 at 4:28 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
Behavior for Enter in contenteditable in current browsers seems to be
as follows:
* IE9 wraps all lines in p (including if you start typing in an
empty text box). If you hit Enter multiple times, it inserts empty
On Wed, May 18, 2011 at 3:22 PM, Ehsan Akhgari eh...@mozilla.com wrote:
What about itemid and accesskey? (There may be other examples that I'm
forgetting right now).
accesskey is unlikely to occur in contenteditable, and duplicates are
technically allowed. itemid is even less likely to occur
On Fri, May 13, 2011 at 12:26 PM, Aryeh Gregor simetrical+...@gmail.com
wrote:
On Fri, May 13, 2011 at 1:48 PM, Ryosuke Niwa rn...@webkit.org wrote:
Note that br and div affect UBA differently so we must consider what
bidirectional text users want as well.
For example, if we had div
On Wed, May 18, 2011 at 2:09 PM, Ojan Vafai o...@chromium.org wrote:
Disagree. I think it should be come div dir=rtlhellow/divdiv
dir=rtl/div. Nesting seems really bad to me. It results in a more
complicated DOM that makes scripting against the resultant DOM extremely
difficult.
If p is
On 11-05-18 2:46 PM, Aryeh Gregor wrote:
Also, we should be preserving inline styles.
We should copy all attributes and have a blacklist of uncopyable attributes.
ID is the only one I can think of off the top of my head that needs
blacklisting.
accesskey, itemid, and name (ona) seem
Am 16.05.2011 21:20 schrieb Aryeh Gregor:
On Mon, May 16, 2011 at 9:33 AM, Markus Ernstderer...@gmx.ch wrote:
I have seen content management systems where text editors tweak the enter
key to behave the same also in non-IE UAs (e.g. if you use Contenido with
TinyMCE, Firefox produces the same
Am 13.05.2011 12:00 schrieb Michael A. Puls II:
On Thu, 12 May 2011 16:28:47 -0400, Aryeh Gregor
simetrical+...@gmail.com wrote:
Another problem with p is that it's very easy to create
unserializable DOMs with it. I've seen cases where at least some
browsers will put things inside p that will
On Tue, May 17, 2011 at 3:04 AM, Markus Ernst derer...@gmx.ch wrote:
If the behavior is settable, it might even be a good idea to leave the
choice of the standard behavior to the UAs. Authors who have a reason to
care can set their preferred behavior, while other authors might prefer to
leave
On Tue, May 17, 2011 at 12:50 PM, Aryeh Gregor simetrical+...@gmail.comwrote:
On Tue, May 17, 2011 at 3:19 AM, Ryosuke Niwa rn...@webkit.org wrote:
I completely disagree. As a user, I want semantics when I write my blog
entry on WordPress so that I can tweak presentation afterwards. e.g. I
Am 12.05.2011 22:28 schrieb Aryeh Gregor:
Behavior for Enter in contenteditable in current browsers seems to be
as follows:
* IE9 wraps all lines inp (including if you start typing in an
empty text box). If you hit Enter multiple times, it inserts empty
ps. Shift-Enter insertsbr.
This is
Am 16.05.2011 15:33 schrieb Markus Ernst:
Am 12.05.2011 22:28 schrieb Aryeh Gregor:
A problem withp is that it has top and bottom margins by default,
so hitting Enter once will look like a double line break. One
real-world execCommand() user I looked at (vBulletin) sets p { margin:
0 } for its
On Fri, May 13, 2011 at 6:29 PM, Ehsan Akhgari eh...@mozilla.com wrote:
We're not going to add pretty-printing for the purposes of this spec, are
we?
No, I didn't realize Boris wasn't talking about web-visible features.
Sure, but how are we going to detect that? Do you agree that they intend
On Thu, 12 May 2011 22:28:47 +0200, Aryeh Gregor
simetrical+...@gmail.com wrote:
Behavior for Enter in contenteditable in current browsers seems to be
as follows:
* IE9 wraps all lines in p (including if you start typing in an
empty text box).
Can't reproduce. If I start typing in an empty
On Thu, 12 May 2011 16:28:47 -0400, Aryeh Gregor
simetrical+...@gmail.com wrote:
Behavior for Enter in contenteditable in current browsers seems to be
as follows:
* IE9 wraps all lines in p (including if you start typing in an
empty text box). If you hit Enter multiple times, it inserts
On Thu, May 12, 2011 at 4:51 PM, Boris Zbarsky bzbar...@mit.edu wrote:
It's used when serializing: things with _moz_dirty are prettyprinted even if
the serialization is trying to preserve the original whitespace layout of
the HTML in general.
The fact that it's an actual content attribute is
On Fri, May 13, 2011 at 10:26 AM, Aryeh Gregor simetrical+...@gmail.comwrote:
I'm not completely decided at this point, but am now leaning toward
br. Currently my spec uses br where some type of break is needed
(e.g., de-indenting an inline node when that would make it the sibling
of some
On 5/13/11 1:26 PM, Aryeh Gregor wrote:
So it's an attribute that affects serialization in a nonstandard way?
Far as I can tell, yes.
What sort of serialization does it affect?
Gecko has way too many serialization modes, most of them not web-exposed
(to support writing decent HTML editors
On Fri, May 13, 2011 at 1:48 PM, Ryosuke Niwa rn...@webkit.org wrote:
Note that br and div affect UBA differently so we must consider what
bidirectional text users want as well.
For example, if we had div dir=rtlhello/div, and inserted br as in
div dir=rtlhellobr/div, then we preserve the RTL
On 5/13/11 3:26 PM, Aryeh Gregor wrote:
א --br-- ב
In IE and WebKit the arrows point right, in Gecko and Opera they point
left.
I _think_ we consider that a bug in Gecko.
Hmm, okay. So it's not an issue I have to care about. (Although of
course when I eventually write a real test suite,
On Fri, May 13, 2011 at 3:38 PM, Boris Zbarsky bzbar...@mit.edu wrote:
I _think_ we consider that a bug in Gecko.
It does violate a should in HTML5, added a while back in reply to that bug:
A br element should separate paragraphs for the purposes of the
Unicode bidirectional algorithm.
On 11-05-13 2:25 PM, Boris Zbarsky wrote:
I just tested innerHTML,
and I found it stripped the attribute, but it didn't seem to add any
whitespace aroundbr,ol, orli.
innerHTML uses OutputRaw which ensures that no prettyprinting happens
ever, no matter what, even if a gun is held to the
On 11-05-13 1:26 PM, Aryeh Gregor wrote:
If you're going to add pretty-printing, doesn't it make more sense to
just add the text nodes directly to the DOM? You're going to have to
deal with the extra nodes anyway as soon as the content round-trips to
a server.
We're not going to add
On 11-05-13 1:48 PM, Ryosuke Niwa wrote:
On Fri, May 13, 2011 at 10:26 AM, Aryeh Gregorsimetrical+...@gmail.comwrote:
Note that br and div affect UBA differently so we must consider what
bidirectional text users want as well.
For example, if we haddiv dir=rtlhello/div, and inserted br as in
div
On Fri, May 13, 2011 at 3:35 PM, Ehsan Akhgari eh...@mozilla.com wrote:
On 11-05-13 1:48 PM, Ryosuke Niwa wrote:
On Fri, May 13, 2011 at 10:26 AM, Aryeh Gregorsimetrical+...@gmail.com
wrote:
Note that br and div affect UBA differently so we must consider what
bidirectional text users want
Behavior for Enter in contenteditable in current browsers seems to be
as follows:
* IE9 wraps all lines in p (including if you start typing in an
empty text box). If you hit Enter multiple times, it inserts empty
ps. Shift-Enter inserts br.
* Firefox 4.0 just uses br _moz_dirty= for Enter and
On 5/12/11 4:28 PM, Aryeh Gregor wrote:
* Firefox 4.0 just usesbr _moz_dirty= for Enter and Shift-Enter,
always. (What's _moz_dirty for?)
It's used when serializing: things with _moz_dirty are prettyprinted
even if the serialization is trying to preserve the original whitespace
layout of
* IE9 wraps all lines in p (including if you start typing in an
empty text box). If you hit Enter multiple times, it inserts empty
ps. Shift-Enter inserts br.
* Firefox 4.0 just uses br _moz_dirty= for Enter and Shift-Enter,
always. (What's _moz_dirty for?)
* Chrome 12 dev doesn't wrap a
27 matches
Mail list logo
