An alternate proposal:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-July/040264.html.
What I like about my proposal is that it can be generalized to anything
that returns a Sequence and also is just less awkward than the
TreeWalker/NodeIterator interfaces.
On Sat, Jul 27, 2013 at 6:33
On Thu, May 30, 2013 at 3:52 AM, Aryeh Gregor wrote:
> On Tue, May 28, 2013 at 8:27 PM, Travis Leithead
> wrote:
> > As far as I know, there is no actively maintained editing spec at the
> > moment. Aryeh’s document is a great start but by no means should it be
> > considered complete, or the st
On Mon, Dec 3, 2012 at 9:48 AM, Travis Leithead <
travis.leith...@microsoft.com> wrote:
> >> When were you thinking of kicking off the DOM4 Events process?
>
> ** **
>
> I'd like to have a draft up this week. We may also ask for a FPWD if we're
> ready by the 10th.
>
> ** **
>
> I want t
On Thu, Nov 29, 2012 at 4:31 PM, Ian Hickson wrote:
> On Tue, 17 Jul 2012, Ian Hickson wrote:
> >
> > My plan is to make it so that cross-origin URLs start cross-origin
> > workers. The main unresolved question is how to do this in an opt-in
> > manner. The best idea I've come up with so far is h
amp; 10? (And
> Opera's Alpha-channel implementation). I did a quick check in the latest
> Firefox/Chrome stable branches and couldn't detect it, but wanted to be
> sure.
>
> > -Original Message-
> > From: Hallvord R. M. Steen [mailto:hallv...@opera.com]
e from
> certain parts of the page if this is a hard requirement. The CSS property
> means that the developer’s request can be honored by the user agent without
> script getting in the way of (and possibly delaying) the action.
>
> ** **
>
> *From:* o...@google.com [mailto:o
stom one if desired.
>
You don't want to disable the other items in the context menu though. This
also doesn't solve disabling cut/copy/paste in non-context menus, e.g.
Chrome has these in the Chrome menu.
>
>
> ** **
>
> *From:* o...@google.com [mailto:o...@google.
On Tue, Oct 30, 2012 at 9:42 AM, Hallvord R. M. Steen wrote:
> I'm looking at the beforecut, beforecopy and beforepaste events. I don't
> entirely understand their intent, it seems even more obscure than I
> expected..
>
> Nothing in the official MSDN documentation [1] really explains the
> intera
I'm not sure what specific issues Hallvord has run into, but WebKit
implementing this property is blocked on us having a bit more confidence
that the key/char properties won't be changing. Specifically, I'd like to
see some rough resolution to the following threads:
http://lists.w3.org/Archives/Pub
On Wed, Aug 22, 2012 at 6:49 PM, Ryosuke Niwa wrote:
> On Wed, Aug 22, 2012 at 5:55 PM, Glenn Maynard wrote:
>
>> On Wed, Aug 22, 2012 at 7:36 PM, Maciej Stachowiak wrote:
>>
>>> Ryosuke also raised the possibility of multiple text fields having
>>> separate UndoManagers. On Mac, most apps wipe
On Tue, Aug 21, 2012 at 1:58 PM, Tab Atkins Jr. wrote:
> On Tue, Aug 21, 2012 at 1:42 PM, Ojan Vafai wrote:
> > On Tue, Aug 21, 2012 at 1:01 PM, Tab Atkins Jr.
> > wrote:
> >> On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai wrote:
> >> > Meh. I think this lo
On Tue, Aug 21, 2012 at 1:01 PM, Tab Atkins Jr. wrote:
> On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai wrote:
> > Meh. I think this loses most of the "CSS is so much more convenient"
> > benefits. It's mainly the fact that you don't have to worry about whether
On Tue, Aug 21, 2012 at 11:17 AM, Tab Atkins Jr. wrote:
> I recently participated in an internal thread at Google where it was
> proposed to move a (webkit-specific) feature from an attribute to a
> CSS property, because applying it via a property is *much* more
> convenient.
>
> Similarly, some o
On Wed, Jul 11, 2012 at 3:47 PM, Ryosuke Niwa wrote:
> On Wed, Jul 11, 2012 at 3:35 PM, Ojan Vafai wrote:
>
>> On Wed, Jul 11, 2012 at 3:23 PM, Ryosuke Niwa wrote:
>>
>>> On Wed, Jul 11, 2012 at 3:12 PM, Ojan Vafai wrote:
>>>
>>>> We don&#
On Wed, Jul 11, 2012 at 3:23 PM, Ryosuke Niwa wrote:
> On Wed, Jul 11, 2012 at 3:12 PM, Ojan Vafai wrote:
>
>> On Wed, Jul 11, 2012 at 11:19 AM, Ryosuke Niwa wrote:
>>
>>> On Wed, Jul 11, 2012 at 10:36 AM, Ojan Vafai wrote:
>>>
>>>> Another th
On Wed, Jul 11, 2012 at 11:19 AM, Ryosuke Niwa wrote:
> On Wed, Jul 11, 2012 at 10:36 AM, Ojan Vafai wrote:
>
>> Another thing to consider if we add DOMTransaction back in is that you
>> now need to specifiy what happens in more cases, e.g.:
>> -call transact on the s
Another thing to consider if we add DOMTransaction back in is that you now
need to specifiy what happens in more cases, e.g.:
-call transact on the same DOMTransaction twice
-call transact on a DOMTransaction then modify undo/redo listeners
These are solvable problems, but are just more complicate
On Wed, Jul 4, 2012 at 3:43 PM, Ryosuke Niwa wrote:
> Hi,
>
> In section 3.3 [1], we mention that the user editing actions and drag and
> drop need to be implemented as automatic DOM transactions. But it seems odd
> to expose executeAutomatic function in this case especially for drag & drop.
>
>
On Thu, Jul 5, 2012 at 1:02 PM, Ryosuke Niwa wrote:
> On Thu, Jul 5, 2012 at 12:45 PM, James Graham wrote:
>
>> On Thu, 5 Jul 2012, Ryosuke Niwa wrote:
>>
>>> On Thu, Jul 5, 2012 at 8:08 AM, James Graham **
>>> wrote:
>>>
On 07/05/2012 12:38 AM, Ryosuke Niwa wrote:
> After
On Thu, Jul 5, 2012 at 7:15 AM, Adam Barth wrote:
> On Thu, Jul 5, 2012 at 1:37 AM, Olli Pettay
> wrote:
> > On 07/05/2012 08:00 AM, Adam Barth wrote:
> >> On Wed, Jul 4, 2012 at 5:25 PM, Olli Pettay
> >> wrote:
> >>> On 07/05/2012 03:11 AM, Ryosuke Niwa wrote:
> >>> So, it is very much impleme
On Wed, Jul 4, 2012 at 5:39 PM, Ryosuke Niwa wrote:
> On Jul 4, 2012 5:26 PM, "Olli Pettay" wrote:
> >
> > On 07/05/2012 03:11 AM, Ryosuke Niwa wrote:
> >
> >> On Wed, Jul 4, 2012 at 5:00 PM, Olli Pettay
> >> olli.pet...@helsinki.fi>> wrote:
> >>
> >> On 07/05/2012 01:38 AM, Ryosuke Niwa w
This confusion seems to come up a lot since DOM is part of public-webapps
but uses a separate mailing list. Maybe it's time to reconsider that
decision? It's the editors of the specs who have the largest say here IMO.
Travis, Jacob, Ms2ger, Aryeh, Anne: How would feel about merging DOM
discussions
On Tue, Jun 12, 2012 at 10:48 AM, Elliott Sprehn wrote:
>
>
> On Mon, Jun 11, 2012 at 9:17 PM, Boris Zbarsky wrote:
>
>> On 6/11/12 7:39 PM, Elliott Sprehn wrote:
>>
>>> After discussing this with some other contributors there were questions
>>> on why we're enforcing the order of the document
In principle, I agree with this as a valid goal. It's one among many
though, so the devil is in the details of each specific proposal to balance
out this goal with others (e.g. keeping the platform consistent). I'd love
to see your list of proposals of what it would take to considerably shrink
jQue
On Thu, May 10, 2012 at 9:28 PM, Rafael Weinstein wrote:
> On Thu, May 10, 2012 at 4:19 PM, Ian Hickson wrote:
> > On Thu, 10 May 2012, Rafael Weinstein wrote:
> >> On Thu, May 10, 2012 at 4:01 PM, Ian Hickson wrote:
> >> > On Fri, 11 May 2012, Tab Atkins Jr. wrote:
> >> >
> >> > But ok, let's a
On Thu, May 10, 2012 at 5:13 PM, Rafael Weinstein wrote:
> On Thu, May 10, 2012 at 4:58 PM, Ian Hickson wrote:
> > On Thu, 10 May 2012, Rafael Weinstein wrote:
> >>
> >> Also, I'm curious why it's ok to peak at the first few characters of the
> >> string, and not ok to peak at the token stream un
On Thu, Apr 5, 2012 at 6:19 AM, Aryeh Gregor wrote:
> On Wed, Apr 4, 2012 at 10:07 PM, Ojan Vafai wrote:
> > The original proposal to drop textInput included that beforeInput/input
> > would have a data property of the plain text being inserted. Aryeh, how
> does
> >
On Wed, May 2, 2012 at 6:57 AM, Boris Zbarsky wrote:
> On 5/2/12 2:23 AM, Aryeh Gregor wrote:
>
>> For the former, I'd suggest onbeforecontextmenu, with some way to
>> disable specific options
>>
>
> I would think that disabling cut/copy/paste would apply to main menus too,
> not just context men
On Wed, Apr 25, 2012 at 4:22 PM, Tab Atkins Jr. wrote:
> On Wed, Apr 25, 2012 at 3:31 PM, Ojan Vafai wrote:
> > works for string-based templating. Special
> handling
> > of is not a big enough pain to justify adding a template
> element.
> >
> > For Web Com
works for string-based templating. Special handling
of is not a big enough pain to justify adding a template element.
For Web Components and template systems that want to do DOM based
templating (e.g. MDV), the template element can meet that need much better
than a string-based approach. If noth
BCC: www-dom
CC: public-webapps
The original proposal to drop textInput included that beforeInput/input
would have a data property of the plain text being inserted. Aryeh, how
does that sound to you? Maybe the property should be called 'text'? 'data'
is probably too generic.
On Wed, Apr 4, 2012 a
With my web developer hat on, I would expect the WebKit/IE behavior.
Keypress is fired before the DOM is modified (I tested in Gecko and WebKit
on an input element). As such, I'd expect focus changed during a keypress
event to change where the text is inserted. Notably, Gecko does the
WebKit/IE beh
On Wed, Mar 14, 2012 at 5:32 AM, Anne van Kesteren wrote:
> On Wed, 14 Mar 2012 09:03:23 +0100, Cameron McCormack
> wrote:
>
>> Anne van Kesteren:
>>
>>> Wasn't there a compatibility constrain with doing that?
>>>
>>
>> I don't remember -- the only difference it would make is that
>> Object.getP
The main reason to keep NodeList is because we'd like to add other APIs to
NodeList in the future that operate on the Nodes in the list (e.g. remove).
I don't really see use-cases for wanting a similar thing with the other
cases here, so I think sticking with arrays of Ranges and Regions is fine.
Upon further thought, I take this suggestion back. Static NodeList as it
currently exists is just an underpowered array, but that doesn't mean
that's what it always has to be. In the future, we should add methods to
NodeList that operate on Nodes, e.g. add a remove method to NodeList that
call remo
Dynamic NodeLists have a significant memory and performance cost. Static
NodeLists are basically just under-powered arrays. We should just return
Node arrays from any new APIs that return a list of Nodes. I'd like to see
NodeList get similar treatment to hasFeature, i.e. a note that it not be
used
On Tue, Feb 7, 2012 at 9:28 AM, Dimitri Glazkov wrote:
> On Tue, Feb 7, 2012 at 5:34 AM, Anne van Kesteren
> wrote:
> > On Tue, 07 Feb 2012 13:55:59 +0100, Arthur Barstow <
> art.bars...@nokia.com>
> > wrote:
> >>
> >> I am especially interested in whether Editors and Test
> >> Facilitators/Cont
On Thu, Jan 26, 2012 at 4:42 PM, Glenn Maynard wrote:
> On Thu, Jan 26, 2012 at 6:25 PM, Tab Atkins Jr. wrote:
>
>> As I argued in <
>> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1520.html>,
>> we should absolutely *not* be adding more boolean arguments to the
>> platform. The
On Tue, Jan 24, 2012 at 11:50 AM, Glenn Adams wrote:
>
> On Tue, Jan 24, 2012 at 12:39 PM, Ian Hickson wrote:
>
>> On Tue, 24 Jan 2012, Glenn Adams wrote:
>> >
>> > The problem is that the proposal (as I understand it) is to insert
>> > something like:
>> >
>> > "DOM2 (a REC) is obsolete. Use DO
Can we just compromise on the language here? I don't think we'll find
agreement on the proper way to do spec work.
How about: "DOM2 is no longer updated. DOM4 is the latest actively
maintained version. "
On Tue, Jan 24, 2012 at 11:43 AM, Glenn Adams wrote:
> I'm sorry, but for some, saying DOM2
I support adding warnings. As far as I know, all major browser vendors are
using the more modern version of each of these specs for implementation
work. That's certainly true for WebKit at least. It doesn't help anyone to
look at outdated specs considering them to be the latest and greatest when
th
On Fri, Jan 13, 2012 at 10:55 AM, Boris Zbarsky wrote:
> On 1/13/12 1:28 PM, Aryeh Gregor wrote:
>
>> On Fri, Jan 13, 2012 at 12:34 PM, Boris Zbarsky wrote:
>>
>>> I would prefer a definition that doesn't involve defaultView, actually.
>>> I
>>> don't expect browsers to converge defaultView beh
Can you do anything useful with a selection on a document that doesn't have
a window? If so, the IE9 behavior makes sense. If not, I prefer the WebKit
behavior.
For phrasing it, could you define it in terms of document.defaultView? In
other words that document.getSelection is just "return document
On Wed, Jan 11, 2012 at 8:15 AM, Aryeh Gregor wrote:
> On Tue, Jan 10, 2012 at 4:48 PM, Charles Pritchard
> wrote:
> > Historically, one of my biggest frustrations with contentEditable is that
>
> you have to take it all or none. The lack of configurability is
> frustrating
> > as a developer. M
On Tue, Jan 10, 2012 at 12:30 PM, Aryeh Gregor wrote:
> On Fri, Jan 6, 2012 at 10:12 PM, Ojan Vafai wrote:
> > We should make this configurable via execCommand:
> > document.execCommand("TabBehavior", false, bitmask);
>
> I'm leery of global flags like that,
BCC: whatwg, CC:public-webapps since discussion of the editing spec has
moved
On Tue, Jun 14, 2011 at 12:54 PM, Aryeh Gregor wrote:
> You suggest that the tab key in browsers should act like indent, as in
>
dedicated text editors. This isn't tenable -- it means that if you're
> using Tab to cycl
BCC: whatwg, CC:public-webapps since discussion of the editing spec has
moved
I'm OK with this conclusion, but I still strongly prefer "div" to be the
"default single-line container name". Also, I'd really like the "default
single-line container name" to be configurable in some way. Different apps
On Fri, Jan 6, 2012 at 12:18 PM, Boris Zbarsky wrote:
> On 1/6/12 12:13 PM, Jarred Nicholls wrote:
>
>> WebKit is used in many walled garden environments, so we consider these
>> scenarios, but as a secondary goal to our primary goal of being a
>> standards compliant browser engine. The point be
On Thu, Oct 20, 2011 at 7:02 PM, Ryosuke Niwa wrote:
> On Thu, Oct 20, 2011 at 6:57 PM, Ryosuke Niwa wrote:
>
>> I don't think we can make such an assumption. People mutate DOM on input
>> event all the time:
>> http://codesearch.google.com/#search/&q=%20oninput=&type=cs
>>
>> Including any DOM
What's the point of having deprecated features in a spec? If the purpose of
a specification is to get interoperability, then a UA either does or
doesn't need to implement the feature. There's no point in keeping a
feature that we think should be killed and there's no point in removing a
feature tha
On Fri, Nov 25, 2011 at 1:03 AM, Lachlan Hunt wrote:
> On 2011-11-24 14:49, Robin Berjon wrote:
>
>> So, now for the money question: should we charter this?
>>
>
> Only if someone is volunteering to be the editor and drafts a spec.
Every task we take on in the working group has a cost. It makes
On Tue, Nov 22, 2011 at 4:12 PM, Jonas Sicking wrote:
> On Tue, Nov 22, 2011 at 10:24 AM, Ojan Vafai wrote:
> > On Tue, Nov 22, 2011 at 10:04 AM, Boris Zbarsky
> wrote:
> >> On 11/22/11 12:57 PM, Ojan Vafai wrote:
> >>> I was hoping that we could have
On Tue, Nov 22, 2011 at 10:04 AM, Boris Zbarsky wrote:
> On 11/22/11 12:57 PM, Ojan Vafai wrote:
>
>> The fewer properties that are exposed this way, the smaller the quirk
>> is.
>>
>
> I think the problem is that from web developers point of view the quirk
On Tue, Nov 22, 2011 at 5:28 AM, Anne van Kesteren wrote:
> On Tue, 22 Nov 2011 03:58:32 +0100, Ojan Vafai wrote:
>
>> I think this is the only sane solution to this problem. Lets split up the
>> Element interface.
>>
>
> I think an IDL annotation would wo
+ian since this wording is actually in the HTML spec.
I'm not sure how exactly this should be specced. DOM4 could specify the two
interfaces and HTML could use those definitions?
On Mon, Nov 21, 2011 at 7:05 PM, Boris Zbarsky wrote:
> On 11/21/11 9:58 PM, Ojan Vafai wrote:
>
>>
I think this is the only sane solution to this problem. Lets split up the
Element interface. I'm not attached to these names, but something
like ElementExposed and Element. Element inherits (mixins?) ElementExposed
and only the methods on ElementExposed are exposed to the on* lookup chain.
Element
se are not strings though, so you can't
use the response from an XHR here.
On Mon, Nov 7, 2011 at 8:36 PM, Jonas Sicking wrote:
> On Mon, Nov 7, 2011 at 8:23 PM, Ryan Seddon wrote:
> > On Tue, Nov 8, 2011 at 4:30 AM, Ojan Vafai wrote:
> >>
> >> I don't really
I don't really follow. Script won't execute until you append the fragment
to the DOM, at which point the fragment itself doesn't go in the DOM, just
it's children. So, I'm not really sure what sandboxing on fragments would
do.
On Fri, Nov 4, 2011 at 11:14 PM, Ryan Seddon wrote:
> This would be a
Importantly, the context-less use-case is by far the common one when you're
constructing a DOM in JS.
On Fri, Nov 4, 2011 at 12:55 PM, Yehuda Katz wrote:
> My use-cases all want pure DOM nodes with no extra cruft added,
> because they assume insertion into proper containers. This is true
> about
If we can get away with it WRT web compat, we should make
createContextualFragment work context-less and we should make
DocumentFragment.innerHTML work as Yehuda describes. There are clear
use-cases for this that web devs want to do all the time.
I don't see any downside except if the web already
On Tue, Oct 25, 2011 at 4:58 PM, Tab Atkins Jr. wrote:
> On Tue, Oct 25, 2011 at 4:56 PM, Ojan Vafai wrote:
> > On Tue, Oct 25, 2011 at 4:44 PM, Bjoern Hoehrmann
> wrote:
> >>
> >> * Tab Atkins Jr. wrote:
> >> >Did you not understand my example? el.fin
On Tue, Oct 25, 2011 at 4:44 PM, Bjoern Hoehrmann wrote:
> * Tab Atkins Jr. wrote:
> >Did you not understand my example? el.find("+ foo, + bar") feels
> >really weird and I don't like it. I'm okay with a single selector
> >starting with a combinator, like el.find("+ foo"), but not a selector
>
On Tue, Oct 25, 2011 at 12:57 PM, Tab Atkins Jr. wrote:
> On Tue, Oct 25, 2011 at 12:53 PM, Ojan Vafai wrote:
> > The new API is smaller and simpler. Less to implement and less for web
> > developers to understand. If it can meet all our use-cases without
> > significant
The new API is smaller and simpler. Less to implement and less for web
developers to understand. If it can meet all our use-cases without
significant performance problems, then it's a win and we should do it.
For line-endings, you could have the Blob constructor also take an optional
endings argum
On Mon, Oct 24, 2011 at 7:49 PM, Erik Arvidsson wrote:
> On Mon, Oct 24, 2011 at 19:23, Jonas Sicking wrote:
> >> On the topic of getting rid of BlobBuilder, do you have thoughts on
> losing
> >> the ability to back it by an on-disk file?
> >
> > I'm not sure I understand the problem. A Blob can
On Mon, Oct 24, 2011 at 6:40 PM, Jonas Sicking wrote:
> On Mon, Oct 24, 2011 at 4:46 PM, Tab Atkins Jr.
> wrote:
> > On Mon, Oct 24, 2011 at 4:33 PM, Eric U wrote:
> >> The only things that this lacks that BlobBuilder has are the endings
> >> parameter for '\n' conversion in text and the conten
On Mon, Oct 24, 2011 at 3:52 PM, Jonas Sicking wrote:
> Hi everyone,
>
> It was pointed out to me on twitter that BlobBuilder can be replaced
> with simply making Blob constructable. I.e. the following code:
>
> var bb = new BlobBuilder();
> bb.append(blob1);
> bb.append(blob2);
> bb.append("some
On Thu, Oct 20, 2011 at 1:06 PM, Ryosuke Niwa wrote:
> On Thu, Oct 13, 2011 at 7:20 PM, Ojan Vafai wrote:
>
>> Overall I really like the proposal (both having the events and Jonas's
>> addition to include them in the undo transaction). We'd fire the
>> aft
On Wed, Oct 19, 2011 at 7:07 PM, Jonas Sicking wrote:
> On Tue, Oct 18, 2011 at 9:42 AM, Alex Russell
> wrote:
> > Lachlan and I have been having an...um...*spirited* twitter discussion
> > regarding querySelectorAll, the (deceased?) queryScopedSelectorAll,
> > and ":scope". He asked me to conti
Overall, I wholeheartedly support the proposal.
I don't really see the benefit of allowing starting with a combinator. I
think it's a rare case that you actually care about the scope element and in
those cases, using :scope is fine. Instead of element.findAll("> div >
.thinger"), you use element.f
On Tue, Aug 30, 2011 at 6:39 PM, Jonas Sicking wrote:
> On Tue, Aug 30, 2011 at 5:07 PM, Ryosuke Niwa wrote:
> > On Tue, Aug 30, 2011 at 4:34 PM, Darin Adler wrote:
> >>
> >> My question was not about the undo command. I meant that if I
> implemented
> >> a handler for the aftereditaction event
On Fri, Sep 30, 2011 at 12:40 PM, Ms2ger wrote:
> On 09/29/2011 04:32 PM, Doug Schepers wrote:
>
>> Hi, Adam-
>>
>> I'm glad to see some progress on a replacement for Mutation Events.
>>
>> Would you be interested in being the editor for this spec? It's already
>> in our charter, we just need som
I support this.
On Tue, Sep 13, 2011 at 1:30 PM, Ryosuke Niwa wrote:
> I think it's a great idea to get your spec more attention in W3C community
> specially because some UA vendors don't participate in discussions on
> whatwg.
>
> - Ryosuke
>
> On Tue, Sep 13, 2011 at 1:27 PM, Aryeh Gregor wro
On Wed, Jul 20, 2011 at 10:30 AM, Olli Pettay wrote:
> On 07/20/2011 06:46 PM, Jonas Sicking wrote:
>
> Hence I'm leaning towards using the almost-asynchronous proposal for
now. If we end up getting the feedback from people that use mutation
events today that they won't be able to solve
On Tue, Jul 5, 2011 at 5:36 PM, Ryosuke Niwa wrote:
> On Tue, Jul 5, 2011 at 5:27 PM, Rafael Weinstein wrote:
>>
>> It seems like these are rarified enough cases that visual artifacts
>> are acceptable collateral damage if you do this. [Put another way, if
>> you care enough about the visual poli
On Mon, Jul 4, 2011 at 10:16 AM, Adam Klein wrote:
> On Mon, Jul 4, 2011 at 9:57 AM, Olli Pettay
> wrote:
> > On 07/04/2011 07:28 PM, Ojan Vafai wrote:
> >> Apologies in advance if my comment makes no sense. This is a long
> >> thread, I tried to digest it all. :)
Apologies in advance if my comment makes no sense. This is a long thread, I
tried to digest it all. :)
On Sat, Jul 2, 2011 at 7:07 AM, Boris Zbarsky wrote:
> That may be ok, if the use cases that incur this cost are rare and the
> common case can be better served by a different approach.
>
> Or
On Tue, May 3, 2011 at 3:20 AM, Hallvord R. M. Steen wrote:
> On Tue, 03 May 2011 07:10:10 +0900, João Eiras
> wrote:
>
> event.clipboardData.getDocumentFragment()
>>>
>>> which would return a parsed and when applicable sanitized view of any
>>> markup the implementation supports from the clipbo
On Mon, Apr 25, 2011 at 11:31 AM, Jonas Sicking wrote:
> First off is document.createTreeWalker and
> document.createNodeIterator. They have the same signature which
> currently is:
>
> document.createX(root, whatToShow, filter, entityReferenceExpansion);
>
> Given that entity references are bein
On Thu, Mar 3, 2011 at 1:46 AM, Boris Zbarsky wrote:
> On 3/2/11 5:52 AM, Jonas Sicking wrote:
>
>> I'm not quite sure what you mean by "via JSON" given that JSON is a
>> serialization format.
>>
>
> The idea would be to take the input object, sanitize it by doing
>
> obj = JSON.parse(JSON.seria
On Tue, Mar 1, 2011 at 7:23 PM, Anne van Kesteren wrote:
> On Tue, 01 Mar 2011 09:00:27 +0100, Garrett Smith
> wrote:
>
>> Mouse.click(document.body, {clientX : 10});
>>
>
> Yeah, that would be simpler. However, we do not really have this pattern
> anywhere in browser APIs and I believe last tim
I also support.
On Thu, Feb 24, 2011 at 11:28 AM, Jonas Sicking wrote:
> I support this.
>
> / Jonas
>
> On Wed, Feb 23, 2011 at 8:20 AM, Arthur Barstow
> wrote:
> > Anne and Ms2ger (representing Mozilla Foundation) have continued to work
> on
> > the DOM Core spec and they propose publishing a
Thanks for working on this!
On Wed, Jan 5, 2011 at 2:41 PM, Ryosuke Niwa wrote:
>
> If the cursor is in an editable element, the default action is to insert
>> clipboard data in the most suitable format supported for the given context.
>>
>> In an editable context, the paste event's target prope
On Fri, Nov 19, 2010 at 2:54 PM, Cameron McCormack wrote:
> Darin Fisher:
> > How about just running the callback once the tab becomes visible again?
> It
> > will run, but just not unless there is reason to animate/paint.
>
> I can imagine a situation where you have an animation that goes for,
appendParameter/clearParameter seems fine to me.
On Wed, Sep 22, 2010 at 2:53 AM, Tab Atkins Jr. wrote:
> On Mon, Sep 20, 2010 at 11:56 PM, Adam Barth wrote:
> > Ok. I'm sold on having an API for constructing query parameters.
> > Thoughts on what it should look like? Here's what jQuery does:
How about setParameter(name, value...) that takes var_args number of values?
Alternately, it could take either a DOMString or an Array for the
value. I prefer the var_args.
Also, getParameterByName and getAllParametersByName seem unnecessarily
wordy. How about getParameter/getParameterAll to match
On Mon, Sep 20, 2010 at 4:27 PM, Adam Barth wrote:
> On Sun, Sep 19, 2010 at 10:48 PM, Devdatta Akhawe
> wrote:
> >> 1) There are now two methods for getting at the URL parameters. The
> >
> > and none for setting them?
>
> That's correct. Looking at various libraries, there seems to be much
>
On Fri, May 14, 2010 at 12:00 PM, Tyler Close wrote:
> On Fri, May 14, 2010 at 11:27 AM, Dirk Pranke
> wrote:
> > You are correct that it is possible to use CORS unsafely. It is possible
> to use
> > UMP unsafely,
>
> Again, that is broken logic. It is possible to write unsafe code in
> C++, but
On Wed, May 12, 2010 at 9:01 AM, Tyler Close wrote:
> In the general case, including many common cases, doing this
> validation is not feasible. The CORS specification should not be
> allowed to proceed through standardization without providing
> developers a robust solution to this problem.
>
>
On Mon, May 10, 2010 at 4:34 PM, Dirk Pranke wrote:
> 3) UMP appears to be nearly a subset of CORS, and does have a lot of
> nice properties for security and simplicity. We support UMP and would
> like to see the syntax continue to be unified with CORS so that it is
> in fact a subset (I believe
On Tue, May 11, 2010 at 11:17 AM, Tyler Close wrote:
> On Tue, May 11, 2010 at 10:54 AM, Anne van Kesteren
> wrote:
> > On Tue, 11 May 2010 19:48:57 +0200, Tyler Close > wrote:
> >> Firefox, Chrome and Caja have now all declared an interest in
> >> implementing UMP. Opera and Safari have both d
On Wed, Apr 21, 2010 at 10:39 AM, Tyler Close wrote:
> On Tue, Apr 20, 2010 at 10:07 PM, Anne van Kesteren
> wrote:
> > On Wed, 21 Apr 2010 01:27:10 +0900, Tyler Close
> > wrote:
> >>
> >> Why can't it be made exactly like UMP? All of the requirements in UMP
> >> have been discussed at length a
On Fri, Jun 19, 2009 at 2:10 PM, Jonas Sicking wrote:
> On Thu, Jun 18, 2009 at 8:30 PM, Ian Hickson wrote:
> >> On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathan
> wrote:
> >> > Hixie, I think a Base64 representation of the file resource may be
> >> > sufficient, particularly for the image use c
93 matches
Mail list logo
