On Tue, Aug 30, 2011 at 12:15 PM, Ryosuke Niwa wrote:
>
> 4. Jonas requested that we have manualTransact and managedTransact instead
> of single transact on undoManager for clarity. I think this is a good idea
> but I'd rather settle the naming issue first.
>
If we're making this change (presum
Þann fös 9.sep 2011 19:27, skrifaði Benjamin Hawkes-Lewis:
On Thu, Sep 8, 2011 at 4:58 PM, Bjartur Thorlacius wrote:
Why use when you have onclick and a settable document.location? :)
I think there are sound reasons to provide user agent conformance
requirements for a@href and to allow it a
Hi all,
I've updated the working draft: http://rniwa.com/editing/undomanager.html
The summary of changes:
- Managed transaction has been renamed to automatic transaction
- Moved undoManager IDL attribute from Node to Element and Document
- Automatic transactions no longer undo/redo DOM
Þann sun 11.sep 2011 18:44, skrifaði Michael A. Puls II:
I don't think < and > are in the list of safe URI characters. All
URI-based functions seem to percent-encode them too. Keeping them
encoded is definitely good for data URIs in text/plain documents so the
don't interfere with the < and > tha
"Michael A. Puls II" schrieb am Sun, 11 Sep 2011
13:54:01 -0400:
> On Sun, 11 Sep 2011 11:30:07 -0400, Daniel Holbert
> wrote:
>
> > […]
> >
> >data:text/html,here is some italic text
>
> I don't really like that though as it's not portable. If I wanted to
> copy that from the address fiel
On Sun, 11 Sep 2011 12:14:08 -0400, Glenn Maynard wrote:
On Sun, Sep 11, 2011 at 10:21 AM, Michael A. Puls II
wrote:
Not only must "#" be "%23" if you don't want it as a frag id, but ">"
and
"<" should be "%3E" and "%3C".
I'm not sure about the spec on this, but Firefox actively unencode
On Sun, 11 Sep 2011 11:30:07 -0400, Daniel Holbert
wrote:
On 09/11/2011 07:21 AM, Michael A. Puls II wrote:
Not only must "#" be "%23" if you don't want it as a frag id, but ">"
and "<" should be "%3E" and "%3C".
[...]
> Of course, if you can percent-encode everything needed as you type,
On 2011-09-11 17:30, Daniel Holbert wrote:
On 09/11/2011 07:21 AM, Michael A. Puls II wrote:
Not only must "#" be "%23" if you don't want it as a frag id, but ">"
and "<" should be "%3E" and "%3C".
[...]
> Of course, if you can percent-encode everything needed as you type, you
> can hand-auth
On 2011-09-11 18:56, Daniel Holbert wrote:
On 09/11/2011 02:09 AM, Julian Reschke wrote:
Given the fact that this change made it into the release without any
major uproar there might be a chance that other UAs might simply adopt
it.
(To be clear -- the proposal hasn't made it into any releases
On 09/11/2011 02:09 AM, Julian Reschke wrote:
Given the fact that this change made it into the release without any
major uproar there might be a chance that other UAs might simply adopt it.
(To be clear -- the proposal hasn't made it into any releases yet. Right
now it's just an idea.)
~Dani
On Sat, Sep 10, 2011 at 5:15 PM, Daniel Holbert wrote:
> This could be more intuitive/do-what-I-mean if we restricted the cases
> under which "#" is treated as a fragment-ID delimiter inside of data URIs.
> In particular: when a "#" character is followed by ">" or "<" in a data
> URI, I propose t
On 09/11/2011 07:21 AM, Michael A. Puls II wrote:
Not only must "#" be "%23" if you don't want it as a frag id, but ">"
and "<" should be "%3E" and "%3C".
[...]
> Of course, if you can percent-encode everything needed as you type, you
> can hand-author the URI data. But, who wants to do that,
A
On Sat, 10 Sep 2011 17:15:09 -0400, Daniel Holbert
wrote:
Browsers handle the "#" character in data URIs very differently, and the
arguably "correct" behavior is probably not what authors actually want
in many cases.
This could be more intuitive/do-what-I-mean if we restricted the cases
On 2011-09-11 04:51, Boris Zbarsky wrote:
...
I think you misunderstand my position. I'm weakly against the proposal
in question; the strongest argument in favor of the proposal is that
there is either a current or future deployed base of data: URIs that
won't work without it but do work in eithe
14 matches
Mail list logo
