=i1item 1/li/ol
li id=i2item 2/li
ol id=u3li id=i3item 3/li/ol
/ol
In particular, many UA remove arbitrary id attributes.
Best regards,
Ryosuke Niwa
rn...@google.com
On Mon, Jul 13, 2009 at 4:01 AM, Simon Pieters sim...@opera.com wrote:
I think this is a bug in execCommand('indent') and should be fixed in
browsers.
The spec doesn't seem to list 'indent' at all. It would be helpful if it
was specified.
Yes, we need to specify how execCommand('indent' /
On Thu, Jul 16, 2009 at 9:58 AM, Keryx Webwebmas...@keryx.se wrote:
FWIW, div's do have semantic meaning.
And what if you really want to style something, but not attach semantic
meaning? Or if you want to make your own additional semantics using classes?
Keeping span is really a good idea!
=u1li id=i1item 1/li/ol
li id=i2item 2/li
ol id=u3li id=i3item 3/li/ol
/ol
Well that's just very wrong on so many levels. I don't think we want to
condone it.
That's why I'm suggesting to standarize it. And do you suppose all UA
implementors would correct their behavior?
Ryosuke Niwa
I second that call. While your suggestion seems to prevent some existing
social engineering, you must realize that HTML5 isn't going to be
recommended until ~2020. By that time, everything we talk about social
engineering today will be completely obsolete. Things like this are best
left to be
user friendly to me.
If anything, a momentary pause will be appropriate because what's what we
usually do when reading a book and a line break appears. This clearly isn't
*line break*.
Best,
Ryosuke Niwa
always cumbersome for humans to convert between era and Gregorian
year.
Best,
Ryosuke Niwa
On Sun, Aug 8, 2010 at 6:11 PM, Kit Grose k...@iqmultimedia.com.au wrote:
The field being four digits long doesn't restrict its contents to four
digits only. I suppose you do raise an interesting concern
On Mon, Aug 9, 2010 at 8:36 AM, Andy Mabbett a...@pigsonthewing.org.ukwrote:
On Mon, August 9, 2010 15:10, Daniel Glazman wrote:
Le 09/08/10 03:11, Kit Grose a écrit :
should the year field also permit the entry of BC/AD?
Or a jewish year? Or a muslim year? Or counting since the
On Tue, Aug 10, 2010 at 1:38 PM, Aryeh Gregor
simetrical+...@gmail.comsimetrical%2b...@gmail.com
wrote:
For simplicity, there should be exactly one format submitted to the server,
so that the
server doesn't have to implement every major calendar system on the
off chance it has some user
2010/8/9 Ian Fette (イアンフェッティ) ife...@google.com
I don't understand why I would need an input type=year to get this right
though. If the bank wants something in 年号 it can just let the user type in
1985 and convert that via JS to 昭和60年, no? If anything, having some sort of
picker seems like it
Does ECMAScript currently have a built-in function for encoding decoding
base-64? We might want a built-in base-64 encoder / decoder if we are
implementing this base64-encoded entities.
- Ryosuke
On Wed, Aug 25, 2010 at 1:50 PM, Adam Barth w...@adambarth.com wrote:
== Summary ==
HTML
at this point.
For consistency, I propose to skip children of source and track elements as
well.
Also, the algorithm does not seem to specify the behavior on deprecated (or
undocumented) elements such as isindex. Can we assume that the
serialization of such elements are UA-defined?
Best,
Ryosuke
as the rectangle in this case?
Best regards,
Ryosuke Niwa
Software Engineer
Google Inc.
2010/11/9 Hironori Bono (坊野 博典) hb...@google.com
Greetings,
I'm Hironori Bono, a software engineer of Google. In the
w3c-international ML, we have been discussing to write a proposal that
adds an IME API
to keep Firefox 4 behaving like previous
versions of firefox and allow scripts created using
createContextualFragment to execute.
However, Firefox 4.0 Beta 6 does not execute the script as far as I tested.
Try opening http://dscoder.com/MessageStyle/testcase.html
- Ryosuke Niwa
follow up when the bug is fixed and WebKit's behavior is matched that
of Firefox.
Best regards,
Ryosuke Niwa
Software Engineer
Google Inc.
On Thu, Nov 11, 2010 at 4:34 PM, Ryosuke Niwa rn...@webkit.org wrote:
Greetings all,
I'm working on the WebKit bug 12234 - Using createContextualFragment
On Sat, Jan 1, 2011 at 2:04 PM, Charles Pritchard ch...@jumis.com wrote:
It's the same concept, a memory warning.
On Sat, Jan 1, 2011 at 3:39 PM, Charles Pritchardch...@jumis.com
wrote:
Here are some example implementations; it's up to the vendor, not the
spec.
Tabbed browsing
Chinese, Japanese,
Korean, etc... can provide suitable IMEs so that users can use it.
2. Not all IMEs are free - web page could provide an IME when the client
doesn't have one
3. Some IMEs are better than others - web page supposedly can provide a
better IME.
Best,
Ryosuke Niwa
Chinese, Japanese,
Korean, etc... can provide suitable IMEs so that users can use it.
2. Not all IMEs are free - web page could provide an IME when the client
doesn't have one
3. Some IMEs are better than others - web page supposedly can provide a
better IME.
Best,
Ryosuke Niwa
On Thu, Jan 13, 2011 at 12:52 AM, Marijn Haverbeke mari...@gmail.comwrote:
This sounds good to me. I used the term forwards and backwards
for the DOM Range spec, which I think make more sense. I also think
selectionDirection is a better property name, as Ojan suggests.
Coincidentally,
On Thu, Jan 13, 2011 at 1:26 AM, Ryosuke Niwa ryosuke.n...@gmail.comwrote:
On Thu, Jan 13, 2011 at 12:52 AM, Marijn Haverbeke mari...@gmail.comwrote:
This sounds good to me. I used the term forwards and backwards
for the DOM Range spec, which I think make more sense. I also think
2011/1/13 Kornel Lesiński kor...@geekhood.net
If not, maybe methods to save/restore selection or modify content without
removing selection would be better? (this would allow browsers to support
multiple selected ranges, block selection in multiline inputs, etc.)
var previousSelection =
2011/1/13 Marijn Haverbeke mari...@gmail.com
My typical use case is that I mess with the content of the input, and
then restore the selection. For example, after adding three characters
to the front, I then restore selectionStart and selectionEnd by adding
three to their original values. It
On Thu, Jan 13, 2011 at 3:08 PM, Aryeh Gregor
simetrical+...@gmail.comsimetrical%2b...@gmail.com
wrote:
On Thu, Jan 13, 2011 at 4:26 AM, Ryosuke Niwa ryosuke.n...@gmail.com
wrote:
I don't like top/bottom because it seems to imply certain visual
orientation. (e.g. I think RTL text
On Fri, Jan 14, 2011 at 3:09 AM, Tim Down timd...@gmail.com wrote:
If you don't need the TextRange-like character-based modification, you
can instead use the selection's extend() method (supported in Mozilla,
WebKit and Opera for years) to create a backwards selection:
function
On Fri, Jan 14, 2011 at 11:42 AM, Marijn Haverbeke mari...@gmail.comwrote:
That would work for me, however, it'd be backwards-incompatible -- not
in a critical way, but probably enough to break a few pieces of code.
Also, I assume there is a reason that textarea/textinput content is
not
On Fri, Jan 14, 2011 at 3:09 PM, Marijn Haverbeke mari...@gmail.com wrote:
If you accept that other selection APIs can't be used in textarea /
input,
then why would you expect your property/method to specify direction can
be?
Because I proposed it as *only* working for input fields.
Ah,
On Mon, Jan 17, 2011 at 1:25 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Jan 17, 2011 at 4:15 PM, Boris Zbarsky bzbar...@mit.edu wrote:
If nothing else, I'm thinking things like I would like to buffer up this
3-hour-long-video so I can watch it on the plane, where my network
bandwidth
On Tue, Jan 18, 2011 at 9:11 AM, Zachary Ozer z...@longtailvideo.comwrote:
Currently, there's no way to stop / limit the browser from buffering -
once you hit play, you start downloading and don't stop until the
resource is completely loaded. This is largely the same as Flash, save
the fact
On Wed, Jan 26, 2011 at 10:23 PM, Brett Zamir bret...@yahoo.com wrote:
I'll give a more concrete example, but I did state the problem: separation
of concerns, and the data I want, getting a CSS property for a given
selector.
For example, we want the designer guy to be able to freely change
On Fri, Jan 28, 2011 at 7:59 AM, Aryeh Gregor
simetrical+...@gmail.comsimetrical%2b...@gmail.com
wrote:
2) Have WebKit or Opera run into any websites that depend on being
able to use multiple Ranges per Selection?
As far as I know, there is no bug filed against this, which seems to imply
On Fri, Jan 28, 2011 at 9:05 AM, Tim Down timd...@gmail.com wrote:
Not anytime soon as far as I'm concerned. We do have a comment in the
code
indicating there had been a plan, but I don't think anyone is actively
working on it. Because we haven't had much complaints from users and
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
On Tue, Mar 1, 2011 at 5:18 PM, Makoto Kato m_k...@ga2.so-net.ne.jp wrote:
On Safari 5, even if textbox has IME composition string, text into textbox
can be replaced by DOM/script. But other browser's behaviors are different,
and this is no specification when textbox has composition string.
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
On Thu, Mar 3, 2011 at 7:47 PM, Makoto Kato m_k...@ga2.so-net.ne.jp wrote:
Hi, Niwa-san.
On 2011/03/02 15:30, Ryosuke Niwa wrote:
You must have tested Chrome improperly. We currently have a bug in
Chrome. To see the bug, open the attached test and type nihao with
Chinese IME on Windows
, and are just shorthands for span
style=font-style: italic or span style=vertical-align: sup.
They are not as far as HTML5 spec is concerned.
On Thu, Mar 3, 2011 at 1:09 AM, Ryosuke Niwa rn...@webkit.org wrote:
But contenteditable is used in many CMS and we can't ignore the backward
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 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:
On Wed, Mar 23, 2011 at 9:31 PM, Ehsan Akhgari eh...@mozilla.com wrote:
Usually, when the user is using the keyboard to extend or move the
selection in a document, the result of the keyboard commands vary depending
on the underlying platform.
I think that's a correct assumption. Selection
On Fri, Mar 25, 2011 at 10:46 PM, Ehsan Akhgari eh...@mozilla.com wrote:
But with the behavior of the API changing based on the platform, the author
can either choose to sniff the UA string, or check what the API did after
calling it. The scarier scenario is the author testing their
On Sat, Mar 26, 2011 at 9:38 AM, Ehsan Akhgari eh...@mozilla.com wrote:
Well, it depends on what you want to do. If you want to implement the
spell correction UI I talked about before, for example, you really want to
ask the browser to give you the boundaries of the word, not including any
On Mon, Mar 28, 2011 at 3:57 PM, Ehsan Akhgari eh...@mozilla.com wrote:
I'd also point out that queryCommandValue and queryCommandState in
WebKit return different values depending on platforms.
Do you know more details on this? Which commands have this platform
specific behavior? And
Sorry for the delayed response.
On Tue, Mar 29, 2011 at 11:53 PM, Aryeh Gregor simetrical+...@gmail.comwrote:
That sums up the situation, yes
So is anyone planning on actually trying to remove DOM mutation events, or
not?
We would love to. We've already made DOM mutation events
(via JavaScript, editing, etc...). Because of the way
selection is updated in WebKit, introducing new synchronous event or firing
selectstart/select in new places will be quite tricky for us.
Best,
Ryosuke Niwa
Software Engineer
Google Inc.
On Tue, May 3, 2011 at 4:49 PM, Ian Hickson i...@hixie.ch wrote:
I've added selectionDirection = 'forward'/'backward'/'none'. ('none' is
the default selection direction on Mac OS.)
Thank you for the update! One thing to point out is that setSelectionRange
in WebKit currently sets forward
On Fri, May 6, 2011 at 2:44 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 6 May 2011, Ryosuke Niwa wrote:
On Tue, May 3, 2011 at 4:49 PM, Ian Hickson i...@hixie.ch wrote:
I've added selectionDirection = 'forward'/'backward'/'none'. ('none' is
the default selection direction on Mac OS
On Fri, May 6, 2011 at 2:56 PM, Ian Hickson i...@hixie.ch wrote:
On Windows, sure, it should default to forward just like the spec says.
But on Mac, it should default to none, since otherwise the behaviour is
inconsistent with the platform selection behaviour.
Why is it inconsistent? DOM
On Tue, May 10, 2011 at 8:33 AM, Ojan Vafai o...@chromium.org wrote:
On Mon, May 9, 2011 at 9:05 PM, Ryosuke Niwa rn...@webkit.org wrote:
One question about selectstart. WebKit currently fires whenever selection
is modified by a mouse drag, mouse click, etc... including when a
collapsed
On Tue, May 10, 2011 at 9:03 AM, Ojan Vafai o...@chromium.org wrote:
On Tue, May 10, 2011 at 8:55 AM, Tim Down timd...@gmail.com wrote:
newSelectionRanges on its own wouldn't be as useful as possible, since
it tells you nothing about the selection direction. You could cover
this by adding
, May 10, 2011 at 9:51 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, May 10, 2011 at 9:03 AM, Ojan Vafai o...@chromium.org wrote:
On Tue, May 10, 2011 at 8:55 AM, Tim Down timd...@gmail.com wrote:
newSelectionRanges on its own wouldn't be as useful as possible, since
it tells you nothing
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 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
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
On Thu, May 19, 2011 at 1:10 PM, Aryeh Gregor simetrical+...@gmail.comwrote:
What I have in mind doesn't involve DOM mutation. Imagine the
selection is collapsed in the middle of a text node and the bold
command is called. The browser now has an internal flag set but there
is no change
On Thu, May 26, 2011 at 10:13 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/26/11 12:53 PM, Ryosuke Niwa wrote:
And WebKit is also a part of Mac OS X framework and native applications
that use WebKit as
a part of their applications have no incentive to support Trident, Gecko,
or
Opera
On Thu, May 26, 2011 at 10:40 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/26/11 1:25 PM, Ryosuke Niwa wrote:
Sure. I'm just saying that it'll be hard for us to drop the support for
other elements in practice. I have no problem with spec not including
those elements.
Yes, I understand
On Wed, Jun 15, 2011 at 2:39 PM, Aryeh Gregor aryehgre...@gmail.com wrote:
I originally thought the WebKit/Opera behavior was unreasonable, but
I've come around to thinking it makes more sense than IE/Gecko. It's
simpler and more consistent. If selections are always normalized, we
can
to emulate arrow key movements.
[1] http://dev.w3.org/csswg/css3-writing-modes/
Best,
Ryosuke Niwa
Software Engineer
Google Inc.
On Wed, Jun 15, 2011 at 5:50 PM, Justin Garcia justin.gar...@apple.comwrote:
I think using a Selection object method to emulate arrows keys is strange.
The use case of getSelection().modify() is still unclear [1].
Why not provide a general way to emulate the arrow keys if we think that's
On Thu, Jun 16, 2011 at 10:20 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Wed, Jun 15, 2011 at 6:55 PM, Ryosuke Niwa rn...@webkit.org wrote:
It seems like maintaining the semantics of 'character' and 'line' is the
way
to go then. i.e. modify('move', 'right', character') moves caret
On Thu, Jun 16, 2011 at 11:50 AM, Aryeh Gregor aryehgre...@gmail.comwrote:
For instance, could we just say that empty inline
elements can have the cursor inside them, so foo{}b/bbar and
foob/b{}bar both normalize to foob{}/bbar? That would solve
the specific bug.
What if we had
On Thu, Jun 16, 2011 at 12:12 PM, Boris Zbarsky bzbar...@mit.edu wrote:
This is an interesting situation which is the inverse of the bidi problem.
In the bidi case there is a single point in the DOM which corresponds to
two different user-perceived selection positions. In this case, a single
On Thu, Jun 16, 2011 at 12:33 PM, Ojan Vafai o...@chromium.org wrote:
On Thu, Jun 16, 2011 at 12:09 PM, Ryosuke Niwa rn...@webkit.org wrote:
Yes, I think all selection modified by user should be normalized by
default.
I'm talking more about programmatically set selection. I think we'll
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 Mon, Jun 20, 2011 at 6:14 PM, Silvia Pfeiffer
silviapfeiff...@gmail.comwrote:
In WebVTT we used start and end instead of left and right.
Might that help?
Isn't 'start' and 'end' more analogous to 'forward' and 'backward'? They're
logical movement, right?
- Ryosuke
I'm not sure how that relates to this discussion then.
- Ryosuke
On Mon, Jun 20, 2011 at 6:35 PM, Silvia Pfeiffer
silviapfeiff...@gmail.comwrote:
On Tue, Jun 21, 2011 at 11:19 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Jun 20, 2011 at 6:14 PM, Silvia Pfeiffer
silviapfeiff
On Mon, Jun 27, 2011 at 2:39 PM, Alexey Proskuryakov a...@webkit.org wrote:
I do not think that we should ignore people who are not native speakers and
are writing JavaScript code that works with vertical text. For most people,
left is left, and up is up. There is no reason to make it more
On Mon, Jun 27, 2011 at 2:55 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Jun 27, 2011 at 2:50 PM, Alexey Proskuryakov a...@webkit.orgwrote:
Is there is a significant amount of HTML editing JavaScript code that
would just work with vertical text if not for this one detail? In that case
On Mon, Jun 27, 2011 at 2:50 PM, Alexey Proskuryakov a...@webkit.org wrote:
Is there is a significant amount of HTML editing JavaScript code that would
just work with vertical text if not for this one detail? In that case, it
might be appropriate to utilize such tricks indeed.
I'd expect
://rniwa.com/editing/undomanager.html and see a list of uses cases at
https://rniwa.com/editing/undomanager-usecases.html. The documents are
incomplete and I need your feedback in order to refine details.
Best regards,
Ryosuke Niwa
Software Engineer
Google Inc.
Feedback on sections 1 through 3:
- WebKit treats any font-weight above or equal to 600 as bold because
that's what user sees, and boldness is a binary concept in execCommand;
Firefox 5 appears to do the same.
- WebKit compares colors in rgb/rgba format; e.g. red is first parsed as
On Wed, Jul 27, 2011 at 8:34 PM, Alex Vincent ajvinc...@gmail.com wrote:
I'd like to take a look at this and be very closely involved in this
specification. About a month ago, I wrote this:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031191.html
Oh, yes. I do remember
On Wed, Jul 27, 2011 at 12:36 PM, Aryeh Gregor simetrical+...@gmail.comwrote:
I'm very reluctant to add such things, because it adds corner cases
that vastly complicate processing and allow tons more room for bugs.
It means every single algorithm related to editing needs to be aware
of the
On Wed, Jul 27, 2011 at 11:44 PM, Alex Vincent ajvinc...@gmail.com wrote:
I'm seeing one major hole in your interface: you don't clearly specify how
to *end* a transaction group. This really matters for when I want to
start a group manually, do a bunch of little things, and then end the
On Thu, Jul 28, 2011 at 1:17 PM, Aryeh Gregor simetrical+...@gmail.comwrote:
3.3: The return value of queryCommandEnable depends on beforecut,
beforecopy, and beforepaste events and selection state in WebKit; WebKit
returns false if default actions are prevented in those events or
On Fri, Jul 29, 2011 at 11:07 AM, Dan Gisolfi giso...@us.ibm.com wrote:
My point herein and motivation for the suggestion is that this
functionality (get/set caret) is available in the textarea element. Using
a textarea element you can get/set caret position via
get/setSelectionRange(). These
On Fri, Jul 29, 2011 at 5:08 PM, Jonas Sicking jo...@sicking.cc wrote:
I really do like the undoscope attribute, that is something that is
definitely needed.
Yes. I've considered other possibilities such as letting scripts to manually
instantiate UndoManager objects, etc... but that turned
On Tue, Aug 2, 2011 at 11:30 AM, Ehsan Akhgari eh...@mozilla.com wrote:
This is a very nice proposal; thanks for working on this, Ryosuke! I have
a number of questions and concerns on it, and I would appreciate if you can
comment on these:
Nope! I just REALLY want to fix this.
1. The
On Tue, Aug 2, 2011 at 1:51 PM, Eric U er...@google.com wrote:
I think the manual transaction is what I'd want to make undo/redo in
the edit menu work with jV
[https://addons.mozilla.org/en-US/firefox/addon/jv/]*.
That's great to hear! I've spent so much time reconciling the way managed
On Wed, Jul 27, 2011 at 4:51 PM, Ryosuke Niwa rn...@webkit.org wrote:
Feedback on sections 1 through 3:
- WebKit treats any font-weight above or equal to 600 as bold because
that's what user sees, and boldness is a binary concept in execCommand;
Firefox 5 appears to do the same
Thanks for the feedback! Will fix in the next version.
On Wed, Aug 3, 2011 at 12:21 AM, Anne van Kesteren ann...@opera.com wrote:
You should define the IDL attribute in terms of HTML reflect:
http://whatwg.org/C#reflect And change it to be a boolean rather than a
DOMString. That would make
On Wed, Aug 3, 2011 at 2:18 PM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 03 Aug 2011 22:42:25 +0200, Ehsan Akhgari eh...@mozilla.com
wrote:
You mean contentEditable and undoScope? That would prohibit the use case
of a web application which is not using contentEditable taking
On Wed, Aug 3, 2011 at 2:36 PM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 03 Aug 2011 23:30:59 +0200, Ryosuke Niwa rn...@webkit.org wrote:
I meant those to be identical. I should probably clarify that.
If they are identical I think it is even more clear we should remove the
one
On Wed, Aug 3, 2011 at 1:13 PM, Aryeh Gregor a...@aryeh.name wrote:
On Tue, Aug 2, 2011 at 8:31 PM, Ryosuke Niwa rn...@webkit.org wrote:
Feedback on selections 5 through 7:
The definition of collapsed line break isn't clear. Maybe it's br
immediately before the end of a block
On Wed, Aug 3, 2011 at 2:46 PM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 03 Aug 2011 23:40:27 +0200, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Aug 3, 2011 at 2:36 PM, Anne van Kesteren ann...@opera.com
wrote:
If they are identical I think it is even more clear we should remove
On Fri, Aug 5, 2011 at 9:57 AM, Jonas Sicking jo...@sicking.cc wrote:
Why treat documentElement specially here? Just make the documentElement
*not* have a undoManager by default and have it just use it's ancestor's,
just like all other elements.
The document is an ancestor of the
On Fri, Aug 5, 2011 at 1:59 PM, Jonas Sicking jo...@sicking.cc wrote:
In the case of collaborative editing apps, reapply is different from
apply because the backend server may have a tree of transaction history and
may need to consult on demand in order to determine exactly what mutations
On Fri, Aug 5, 2011 at 5:06 PM, Jonas Sicking jo...@sicking.cc wrote:
Though I guess you can always supply the same function for apply and
reapply, but that means you can't use the convenient inline syntax
that you've used in your examples.
Or does 'reapply' default to the 'apply' function
On Fri, Aug 5, 2011 at 7:12 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Aug 5, 2011 at 5:17 PM, Ryosuke Niwa rn...@webkit.org wrote
You're right that you can redo what the UA did after you unapplied the
managed transaction UA inserted. So maybe replace isn't really that
useful after
. Transaction (or Transacted or
whatever you'd like to call it) is an event that fires after new transaction
is inserted (not cancelable).
- Ryosuke
On Tue, Jul 26, 2011 at 11:34 PM, Ryosuke Niwa rn...@webkit.org wrote:
Hi all,
In the last couple of weeks, I've been working with developers
On Tue, Aug 9, 2011 at 12:31 AM, Jonas Sicking jo...@sicking.cc wrote:
I still see UndoManager.replace in there. I still haven't heard any use
cases that won't be solved better with a beforeEditingAction event (and
solved ok simply using the undo() function until we have a
beforeEditingAction
On Tue, Aug 9, 2011 at 1:17 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 9, 2011 at 12:42 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 12:31 AM, Jonas Sicking jo...@sicking.cc wrote:
Likewise I still haven't heard of any examples where the apply function
isn't
On Tue, Aug 9, 2011 at 1:59 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 9, 2011 at 12:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 1:17 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 9, 2011 at 12:42 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue
On Tue, Aug 9, 2011 at 2:55 PM, Jonas Sicking jo...@sicking.cc wrote:
I don't think it's a matter of which use cases can or can't be solved with
either solution. It's pretty clear to me that all scenarios can be solved
with either API.
Right, they're isomorphic.
It's just a matter of which
On Tue, Aug 9, 2011 at 3:36 PM, Jonas Sicking jo...@sicking.cc wrote:
I do definitely agree that making the reapply function optional helps
a lot in that at least pages don't have to worry about the feature if
they're not using it. If we do that though we should probably rename
the 'apply'
On Wed, Aug 10, 2011 at 4:31 PM, Ehsan Akhgari eh...@mozilla.com wrote:
On 11-06-27 5:30 PM, Ryosuke Niwa wrote:
FYI, I also posted this question on public-html-ig...@w3.org, and I got
exactly one response from Koji, who was supportive of my proposal.
Given that, I'm inclined to say
On Thu, Aug 11, 2011 at 2:53 PM, Ehsan Akhgari eh...@mozilla.com wrote:
I think the confusion is arising because you chose to attach undoManager to
elements, not nodes. Note that document _is_ a node in the DOM, but it's
not an element. I think we should just modify the spec to attach
On Fri, Aug 12, 2011 at 3:07 PM, Ehsan Akhgari eh...@mozilla.com wrote:
On 11-08-09 6:36 PM, Jonas Sicking wrote:
Sure, your API is more convenient in certain situations. But it also
encourages code duplication (I'll note that in the examples you
originally provided in this thread you always
On Fri, Aug 12, 2011 at 3:11 PM, Ehsan Akhgari eh...@mozilla.com wrote:
On 11-08-12 6:10 PM, Ryosuke Niwa wrote:
But having authors add flag in almost all cases isn't that nice either.
Why do you think that authors need to specify the flag in almost all cases?
Because almost all text
1 - 100 of 293 matches
Mail list logo
