Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Mon, May 23, 2011 at 3:37 AM, Hallvord R. M. Steen wrote: > FYI Aryeh, I just noticed in the context of other work that the Y!Mail rich > text editor seems to set StyleWithCSS to 1 (testing with the "Neo" version > of Y!Mail, don't know if it matters). You probably want to have a look at > how

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Thu, Apr 7, 2011 at 5:57 PM, Tim Down wrote: > I don't recall ever wanting to use execCommand() in non-editable > content myself (although I wouldn't rule it out), but I've answered a > few questions on Stack Overflow where the asker has wanted to > highlight (i.e. change the background colour

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On 7 April 2011 18:36, Aryeh Gregor wrote: > On Wed, Apr 6, 2011 at 7:40 PM, Tim Down wrote: >> Is there an overwhelming reason why execCommand() should be restricted >> to contentEditable/designMode elements, as the spec seems to suggest? > > IIRC from testing, that's how all browsers but IE9 be

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Wed, Apr 6, 2011 at 7:40 PM, Tim Down wrote: > Is there an overwhelming reason why execCommand() should be restricted > to contentEditable/designMode elements, as the spec seems to suggest? IIRC from testing, that's how all browsers but IE9 behave. I guess the reason is that if you have a typ

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

Is there an overwhelming reason why execCommand() should be restricted to contentEditable/designMode elements, as the spec seems to suggest? Tim On 1 March 2011 18:36, Aryeh Gregor wrote: > Two or three weeks ago I began writing a specification for > execCommand() and related functions.  I don't

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Thu, Mar 24, 2011 at 12:41 AM, Ehsan Akhgari wrote: > I thought that you were talking about use cases for CSS mode in general, not > only those particular elements... I guess I wasn't clear. Anyway, I've now specced styleWithCSS and useCSS, and will get back to work implementing more command

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

> I always felt it had valid use-cases in *some* form -- namely, some > authors want conforming content, which means no , while some > authors want markup that will work in crippled HTML processors like > Blackberry's e-mail client, which means they want . The only > question was whether there was

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Wed, Mar 23, 2011 at 1:36 AM, Robert O'Callahan wrote: > So it has valid use cases after all? I always felt it had valid use-cases in *some* form -- namely, some authors want conforming content, which means no , while some authors want markup that will work in crippled HTML processors like Bla

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Wed, Mar 23, 2011 at 12:51 PM, Aryeh Gregor wrote: > On Mon, Mar 21, 2011 at 11:48 PM, Robert O'Callahan > wrote: > > We can deprecate the CSS mode and leave it unspecified, without removing > it > > from Webkit and Gecko. That won't hurt interop since anyone using it is > > probably UA-sniffi

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Mon, Mar 21, 2011 at 7:51 PM, Ehsan Akhgari wrote: > You're proposing to remove something from Gecko and Webkit which has been > supported for many years (about 8 years for Gecko).  We do not have the > ability to make sure that nobody is relying on this in any of the billions of > available

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

> One thing we might want to consider is to merge elements when forcing > style or pushing down style. For example, if we had "hello > world" and bolded "world", I'd expect to get "hello world" > instead of "hello world". While it's not that much of an > improvement in this very simple case, the ef

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Thu, Mar 17, 2011 at 3:31 PM, Aryeh Gregor wrote: > I just rewrote the spec, and it's now both shorter and produces better > results. For a quick view of the results, as compared to the browser > you're currently using, you can look here: > > http://aryeh.name/spec/editcommands/autoimplementat

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Mon, Mar 21, 2011 at 8:48 PM, Robert O'Callahan wrote: > We can deprecate the CSS mode and leave it unspecified, without removing it > from Webkit and Gecko. That won't hurt interop since anyone using it is > probably UA-sniffing already. > > If sometime in the future we decide that a "CSS mode

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

- Original Message - > From: "Robert O'Callahan" > To: "Ehsan Akhgari" > Cc: "Aryeh Gregor" , "whatwg" > , "Ryosuke Niwa" , > "Ehsan Akhgari" , "Hallvord R. M. Steen" > > Sent: Monday, Mar

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Tue, Mar 22, 2011 at 12:55 PM, Ehsan Akhgari wrote: > You're proposing to remove something from Gecko and Webkit which has been > supported for many years (about 8 years for Gecko). We do not have the > ability to make sure that nobody is relying on this in any of the billions > of available

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

- Original Message - > From: "Aryeh Gregor" > To: "Ehsan Akhgari" > Cc: "whatwg" , eh...@mozilla.com, "Hallvord R. M. > Steen" , "Ryosuke Niwa" > > Sent: Monday, March 21, 2011 1:25:40 PM > Subject: Re: [whatwg] On

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Sat, Mar 19, 2011 at 1:23 AM, Ehsan Akhgari wrote: > I don't think this is a useful argument for not supporting the CSS mode. >  But if you're looking for examples, a quick Google search suggested that > elRTE can take advantage of the CSS mode (possibly among many other rich > text editing fra

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On 11-03-04 10:23 PM, Ryosuke Niwa wrote: > > On Sat, Mar 5, 2011 at 3:58 AM, Aryeh Gregorwrote: > >> On Thu, Mar 3, 2011 at 5:45 PM, Ryosuke Niwa wrote: >>> >>> Backward compatibility. I suspect that there are many web contents that >>> depend on styleWithCSS available on WebKit / Gecko. >> >> G

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On 11-03-02 2:18 PM, Aryeh Gregor wrote: >> >> Styling a Range / Unstyling a Range doesn't seem to split the range into >> segments of phrasing contents. How does your algorithm avoid wrapping a >> non-phrasing element with a span? (e.g. we don't want to wrap div, >> blockquote, etc... with a span

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

Hi everyone. Firstly, I'm very happy to see some action in this area, and sorry that I'm catching up with the thread with a delay. I'll try to respond to individual messages where I have something to say, to make following the thread easier. On 11-03-13 4:46 PM, Aryeh Gregor wrote: > > I did som

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On 18 March 2011 00:43, Aryeh Gregor wrote: > On Thu, Mar 17, 2011 at 6:45 PM, Tim Down wrote: >> I'm interested in this stuff and am very grateful for your work. I've >> been writing a document.execCommand() replacement for my Rangy library >> (http://code.google.com/p/rangy/), so this is all ex

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Thu, Mar 17, 2011 at 6:45 PM, Tim Down wrote: > Is a column full of > > "Exception: [Exception... "Not enough arguments" nsresult: "0x80570001 > (NS_ERROR_XPC_NOT_ENOUGH_ARGS)" location: "JS frame :: > http://aryeh.name/spec/editcommands/implementation.js :: getState :: > line 1046" data: no]"

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Thu, Mar 17, 2011 at 3:31 PM, Aryeh Gregor wrote: > * In one case, the spec adds around a single space, while WebKit > doesn't; I'm inclined to say this is a WebKit bug (which also occurs > in my spec implementation as viewed in WebKit, but not Firefox, since > WebKit mangles ranges when you a

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

Is a column full of "Exception: [Exception... "Not enough arguments" nsresult: "0x80570001 (NS_ERROR_XPC_NOT_ENOUGH_ARGS)" location: "JS frame :: http://aryeh.name/spec/editcommands/implementation.js :: getState :: line 1046" data: no]" the expected result in Firefox 3.6.15? I'm interested in th

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

I just rewrote the spec, and it's now both shorter and produces better results. For a quick view of the results, as compared to the browser you're currently using, you can look here: http://aryeh.name/spec/editcommands/autoimplementation.html That link isn't stable, and will change and possibly

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Sun, Mar 13, 2011 at 5:20 PM, Markus Ernst wrote: > IMO, from the moment you decide to use and not style="bold" (be it due > to a user selectable mode or not), style="bold" should actually be totally > avoided. . . . > > I think that the code generated should be homogeneous, independent from t

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

Am 13.03.2011 21:46 schrieb Aryeh Gregor: 2) How much work should we go to to produce nice-looking markup? E.g., if the user unbolds "baz" in Foo Bar baz should we produce something like Foo Barbaz like WebKit does, or would it be okay to do Foo Barbaz to avoid the complexity, given

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

I did some research, looking at three different rich editing suites: vBulletin's WYSIWYG editor, jwysiwyg (a jQuery plugin), and TinyMCE (used by Wordpress). I also looked at CKEditor, but I don't think it uses execCommand() at all. My full notes are at

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Fri, Mar 4, 2011 at 10:23 PM, Ryosuke Niwa wrote: > I disagree.  The editing behaviors of browsers are fairly consistent across > browsers as of now even though they fail to deal with many edge cases. >  While we should try to spec and agree on those edge cases, we shouldn't > suddenly change t

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Sat, Mar 5, 2011 at 3:58 AM, Aryeh Gregor wrote: > On Thu, Mar 3, 2011 at 5:45 PM, Ryosuke Niwa wrote: > > Backward compatibility. I suspect that there are many web contents that > > depend on styleWithCSS available on WebKit / Gecko. > > Generally, I've been assuming that sites that already

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

Am 04.03.2011 19:58 schrieb Aryeh Gregor: 2) In CSS mode, use CSS where the tag isn't conforming (, etc.) or there is no tag (like hiliteColor). 3) In non-CSS mode, use tags where available even if not conforming (, etc.), and only use CSS if there's no tag for the feature (like hiliteColor).

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Thu, Mar 3, 2011 at 5:45 PM, Ryosuke Niwa wrote: > Backward compatibility.  I suspect that there are many web contents that > depend on styleWithCSS available on WebKit / Gecko. Generally, I've been assuming that sites that already use execCommand() will either 1) not depend on particular mark

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

Am 03.03.2011 20:53 schrieb Aryeh Gregor: I get the hand-editing argument. is much nicer to hand-edit than , and also fewer bytes. But why would anyone want? Text is even fewer bytes and more readable than style="font-weight:bold">Text. So if you don't want to leave the choice to RTE authors

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

Am 01.03.2011 19:36 schrieb Aryeh Gregor: Two or three weeks ago I began writing a specification for execCommand() and related functions. I don't have anything implementable yet -- it's very incomplete and there are known issues with the existing stuff. But I thought I'd post it for any early r

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

Great discussions! On Fri, Mar 4, 2011 at 4:53 AM, Aryeh Gregor wrote: > On Wed, Mar 2, 2011 at 8:27 PM, Brett Zamir wrote: > > Maybe the use of non-CSS mode was for backward-compatibility with earlier > > versions or for easier overriding of styling in the target document > (e.g., > > "b {color

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Thu, Mar 3, 2011 at 4:03 PM, Brett Zamir wrote: > Since span is meant to be a generic container with no inherent meaning or > formatting of its own (except being understood as being of inline display), > formatting a span without reference to class would be a pretty broad stroke > to paint, whe

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On 3/4/2011 3:53 AM, Aryeh Gregor wrote: On Wed, Mar 2, 2011 at 8:27 PM, Brett Zamir wrote: In any case, spans with inline styles are much less likely to conflict with other styling I'm not sure what you mean by this. Functionally, in what way is less likely to conflict with other styling t

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Thu, Mar 3, 2011 at 4:18 AM, Aryeh Gregor wrote: > > > Unstyling a Range doesn't work for text decorations because overriding > > text-decoration property doesn't clear underline nor line-through. > > This is already noted as an issue in the spec (under "underline" in > the command list). I wr

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Thu, Mar 3, 2011 at 4:18 AM, Aryeh Gregor wrote: > On Tue, Mar 1, 2011 at 5:11 PM, Ryosuke Niwa wrote: > > Styling a Range doesn't support styleWithCSS=false > > I saw this feature in Mozilla's docs, but I don't really get it. What > use-cases does it have? Why do we need to support both way

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On 3/3/2011 3:18 AM, Aryeh Gregor wrote: On Tue, Mar 1, 2011 at 5:11 PM, Ryosuke Niwa wrote: Styling a Range doesn't support styleWithCSS=false I saw this feature in Mozilla's docs, but I don't really get it. What use-cases does it have? Why do we need to support both ways of doing things if

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Tue, Mar 1, 2011 at 5:11 PM, Ryosuke Niwa wrote: > Styling a Range doesn't support styleWithCSS=false I saw this feature in Mozilla's docs, but I don't really get it. What use-cases does it have? Why do we need to support both ways of doing things if they create the same visible effect? > I

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

On Wed, Mar 2, 2011 at 7:11 AM, Ryosuke Niwa wrote: > Great to see some spec'ing work here. Some issues with your document: > >- Styling a Range doesn't support styleWithCSS=false >- Ignores possibility of JavaScript modifying DOM while your algorithm >is running - This is actually c

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

Great that this is getting attention spec-wise! First, could it be that the link you posted is broken (I get "404 - No such project." when clicking on it)? Also, reposting my initial comment I sent you, as you requested: In your draft you write: I'm not sure if my priorities in writing the algor

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

Great to see some spec'ing work here. Some issues with your document: - Styling a Range doesn't support styleWithCSS=false - Ignores possibility of JavaScript modifying DOM while your algorithm is running - This is actually consistent with TOT WebKit where dispatches of DOM mutation e

[whatwg] Ongoing work on an editing commands (execCommand()) specification

Two or three weeks ago I began writing a specification for execCommand() and related functions. I don't have anything implementable yet -- it's very incomplete and there are known issues with the existing stuff. But I thought I'd post it for any early review comments on the direction I'm taking,