On Mon, May 23, 2011 at 3:37 AM, Hallvord R. M. Steen
hallv...@opera.com 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
On Wed, Apr 6, 2011 at 7:40 PM, Tim Down timd...@gmail.com 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
On 7 April 2011 18:36, Aryeh Gregor simetrical+...@gmail.com wrote:
On Wed, Apr 6, 2011 at 7:40 PM, Tim Down timd...@gmail.com wrote:
Is there an overwhelming reason why execCommand() should be restricted
to contentEditable/designMode elements, as the spec seems to suggest?
IIRC from testing,
On Thu, Apr 7, 2011 at 5:57 PM, Tim Down timd...@gmail.com 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
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 simetrical+...@gmail.com wrote:
Two or three weeks ago I began writing a specification for
execCommand() and
On Thu, Mar 24, 2011 at 12:41 AM, Ehsan Akhgari eh...@mozilla.com 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
On Wed, Mar 23, 2011 at 1:36 AM, Robert O'Callahan rob...@ocallahan.org 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 font, while some
authors want markup that will work in crippled
I always felt it had valid use-cases in *some* form -- namely, some
authors want conforming content, which means no font, while some
authors want markup that will work in crippled HTML processors like
Blackberry's e-mail client, which means they want font. The only
question was whether there
...@opera.com
Sent: Monday, March 21, 2011 11:48:41 PM
Subject: Re: [whatwg] Ongoing work on an editing commands (execCommand())
specification
On Tue, Mar 22, 2011 at 12:55 PM, Ehsan Akhgari eh...@mozilla.com
wrote:
You're proposing to remove something from Gecko and Webkit which has
been
On Mon, Mar 21, 2011 at 8:48 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
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
On Thu, Mar 17, 2011 at 3:31 PM, Aryeh Gregor simetrical+...@gmail.comwrote:
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:
One thing we might want to consider is to merge elements when forcing
style or pushing down style. For example, if we had bhello
/bworld and bolded world, I'd expect to get bhello world/b
instead of bhello /bbworld/b. While it's not that much of an
improvement in this very simple case, the
On Wed, Mar 23, 2011 at 12:51 PM, Aryeh Gregor simetrical+...@gmail.comwrote:
On Mon, Mar 21, 2011 at 11:48 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
We can deprecate the CSS mode and leave it unspecified, without removing
it
from Webkit and Gecko. That won't hurt interop since
On Sat, Mar 19, 2011 at 1:23 AM, Ehsan Akhgari ehsan.akhg...@gmail.com 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
: Re: [whatwg] Ongoing work on an editing commands (execCommand())
specification
On Sat, Mar 19, 2011 at 1:23 AM, Ehsan Akhgari
ehsan.akhg...@gmail.com 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
On Tue, Mar 22, 2011 at 12:55 PM, Ehsan Akhgari eh...@mozilla.com 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
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 some
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)
I
On 11-03-04 10:23 PM, Ryosuke Niwa wrote:
On Sat, Mar 5, 2011 at 3:58 AM, Aryeh Gregorsimetrical+...@gmail.comwrote:
On Thu, Mar 3, 2011 at 5:45 PM, Ryosuke Niwarn...@webkit.org wrote:
Backward compatibility. I suspect that there are many web contents that
depend on styleWithCSS available
On 18 March 2011 00:43, Aryeh Gregor simetrical+...@gmail.com wrote:
On Thu, Mar 17, 2011 at 6:45 PM, Tim Down timd...@gmail.com 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
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
On Sun, Mar 13, 2011 at 5:20 PM, Markus Ernst derer...@gmx.ch wrote:
IMO, from the moment you decide to use b 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,
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
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
div style=font-weight:bold
pFoo
pBar baz
/div
should we produce something like
div
p style=font-weight: boldFoo
pbBar/bbaz
/div
like WebKit does, or
On Fri, Mar 4, 2011 at 10:23 PM, Ryosuke Niwa rn...@webkit.org 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
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
Am 03.03.2011 20:53 schrieb Aryeh Gregor:
I get the hand-editing argument.b is much nicer to hand-edit than
span style=font-weight: bold, and also fewer bytes. But why would
anyone wantspan style=font-weight: bold?
pbText/b/p is even fewer bytes and more readable than p
On Thu, Mar 3, 2011 at 5:45 PM, Ryosuke Niwa rn...@webkit.org 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
Am 04.03.2011 19:58 schrieb Aryeh Gregor:
2) In CSS mode, use CSS where the tag isn't conforming (font, etc.)
or there is no tag (like hiliteColor).
3) In non-CSS mode, use tags where available even if not conforming
(font, etc.), and only use CSS if there's no tag for the feature
(like
On Sat, Mar 5, 2011 at 3:58 AM, Aryeh Gregor simetrical+...@gmail.comwrote:
On Thu, Mar 3, 2011 at 5:45 PM, Ryosuke Niwa rn...@webkit.org wrote:
Backward compatibility. I suspect that there are many web contents that
depend on styleWithCSS available on WebKit / Gecko.
Generally, I've been
On 3/4/2011 3:53 AM, Aryeh Gregor wrote:
On Wed, Mar 2, 2011 at 8:27 PM, Brett Zamirbret...@yahoo.com 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
span style=font-style:
On Thu, Mar 3, 2011 at 4:03 PM, Brett Zamir bret...@yahoo.com 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
Great discussions!
On Fri, Mar 4, 2011 at 4:53 AM, Aryeh Gregor simetrical+...@gmail.comwrote:
On Wed, Mar 2, 2011 at 8:27 PM, Brett Zamir bret...@yahoo.com wrote:
Maybe the use of non-CSS mode was for backward-compatibility with earlier
versions or for easier overriding of styling in the
On Tue, Mar 1, 2011 at 5:11 PM, Ryosuke Niwa rn...@webkit.org 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
On 3/3/2011 3:18 AM, Aryeh Gregor wrote:
On Tue, Mar 1, 2011 at 5:11 PM, Ryosuke Niwarn...@webkit.org 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
On Thu, Mar 3, 2011 at 4:18 AM, Aryeh Gregor simetrical+...@gmail.comwrote:
On Tue, Mar 1, 2011 at 5:11 PM, Ryosuke Niwa rn...@webkit.org 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?
On Thu, Mar 3, 2011 at 4:18 AM, Aryeh Gregor simetrical+...@gmail.comwrote:
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
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,
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
On Wed, Mar 2, 2011 at 7:11 AM, Ryosuke Niwa rn...@webkit.org 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
40 matches
Mail list logo
