On Fri, Jun 19, 2009 at 2:10 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jun 18, 2009 at 8:30 PM, Ian Hicksoni...@hixie.ch wrote:
On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathana...@mozilla.com
wrote:
Hixie, I think a Base64 representation of the file resource may be
sufficient,
On Wed, Apr 21, 2010 at 10:39 AM, Tyler Close tyler.cl...@gmail.com wrote:
On Tue, Apr 20, 2010 at 10:07 PM, Anne van Kesteren ann...@opera.com
wrote:
On Wed, 21 Apr 2010 01:27:10 +0900, Tyler Close tyler.cl...@gmail.com
wrote:
Why can't it be made exactly like UMP? All of the
On Tue, May 11, 2010 at 11:17 AM, Tyler Close tyler.cl...@gmail.com wrote:
On Tue, May 11, 2010 at 10:54 AM, Anne van Kesteren ann...@opera.com
wrote:
On Tue, 11 May 2010 19:48:57 +0200, Tyler Close tyler.cl...@gmail.com
wrote:
Firefox, Chrome and Caja have now all declared an interest in
On Mon, May 10, 2010 at 4:34 PM, Dirk Pranke dpra...@chromium.org 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
On Wed, May 12, 2010 at 9:01 AM, Tyler Close tyler.cl...@gmail.com 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
On Fri, May 14, 2010 at 12:00 PM, Tyler Close tyler.cl...@gmail.com wrote:
On Fri, May 14, 2010 at 11:27 AM, Dirk Pranke dpra...@chromium.org
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
On Mon, Sep 20, 2010 at 4:27 PM, Adam Barth w...@adambarth.com wrote:
On Sun, Sep 19, 2010 at 10:48 PM, Devdatta Akhawe dev.akh...@gmail.com
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
How about setParameter(name, value...) that takes var_args number of values?
Alternately, it could take either a DOMString or an ArrayDOMString for the
value. I prefer the var_args.
Also, getParameterByName and getAllParametersByName seem unnecessarily
wordy. How about
appendParameter/clearParameter seems fine to me.
On Wed, Sep 22, 2010 at 2:53 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Mon, Sep 20, 2010 at 11:56 PM, Adam Barth w...@adambarth.com wrote:
Ok. I'm sold on having an API for constructing query parameters.
Thoughts on what it should
Thanks for working on this!
On Wed, Jan 5, 2011 at 2:41 PM, Ryosuke Niwa rn...@webkit.org 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
I also support.
On Thu, Feb 24, 2011 at 11:28 AM, Jonas Sicking jo...@sicking.cc wrote:
I support this.
/ Jonas
On Wed, Feb 23, 2011 at 8:20 AM, Arthur Barstow art.bars...@nokia.com
wrote:
Anne and Ms2ger (representing Mozilla Foundation) have continued to work
on
the DOM Core spec
On Tue, Mar 1, 2011 at 7:23 PM, Anne van Kesteren ann...@opera.com wrote:
On Tue, 01 Mar 2011 09:00:27 +0100, Garrett Smith dhtmlkitc...@gmail.com
wrote:
Mouse.click(document.body, {clientX : 10});
Yeah, that would be simpler. However, we do not really have this pattern
anywhere in
On Thu, Mar 3, 2011 at 1:46 AM, Boris Zbarsky bzbar...@mit.edu 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 =
On Mon, Apr 25, 2011 at 11:31 AM, Jonas Sicking jo...@sicking.cc 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
On Tue, May 3, 2011 at 3:20 AM, Hallvord R. M. Steen hallv...@opera.comwrote:
On Tue, 03 May 2011 07:10:10 +0900, João Eiras joao.ei...@gmail.com
wrote:
event.clipboardData.getDocumentFragment()
which would return a parsed and when applicable sanitized view of any
markup the
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 bzbar...@mit.edu 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
On Mon, Jul 4, 2011 at 10:16 AM, Adam Klein ad...@chromium.org wrote:
On Mon, Jul 4, 2011 at 9:57 AM, Olli Pettay olli.pet...@helsinki.fi
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
On Tue, Jul 5, 2011 at 5:36 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Jul 5, 2011 at 5:27 PM, Rafael Weinstein rafa...@google.comwrote:
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
On Wed, Jul 20, 2011 at 10:30 AM, Olli Pettay olli.pet...@helsinki.fiwrote:
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
I support this.
On Tue, Sep 13, 2011 at 1:30 PM, Ryosuke Niwa rn...@webkit.org 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
On Fri, Sep 30, 2011 at 12:40 PM, Ms2ger ms2...@gmail.com 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
On Tue, Aug 30, 2011 at 6:39 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 30, 2011 at 5:07 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 30, 2011 at 4:34 PM, Darin Adler da...@apple.com wrote:
My question was not about the undo command. I meant that if I
implemented
a
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
On Mon, Oct 24, 2011 at 3:52 PM, Jonas Sicking jo...@sicking.cc 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);
On Mon, Oct 24, 2011 at 6:40 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Oct 24, 2011 at 4:46 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Mon, Oct 24, 2011 at 4:33 PM, Eric U er...@google.com wrote:
The only things that this lacks that BlobBuilder has are the endings
parameter
On Mon, Oct 24, 2011 at 7:49 PM, Erik Arvidsson a...@chromium.org wrote:
On Mon, Oct 24, 2011 at 19:23, Jonas Sicking jo...@sicking.cc 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 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
On Tue, Oct 25, 2011 at 12:57 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Tue, Oct 25, 2011 at 12:53 PM, Ojan Vafai o...@chromium.org 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
On Tue, Oct 25, 2011 at 4:58 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Tue, Oct 25, 2011 at 4:56 PM, Ojan Vafai o...@chromium.org wrote:
On Tue, Oct 25, 2011 at 4:44 PM, Bjoern Hoehrmann derhoe...@gmx.net
wrote:
* Tab Atkins Jr. wrote:
Did you not understand my example? el.find
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
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.
+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 bzbar...@mit.edu wrote:
On 11/21/11 9:58 PM, Ojan Vafai wrote:
I
On Tue, Nov 22, 2011 at 5:28 AM, Anne van Kesteren ann...@opera.com wrote:
On Tue, 22 Nov 2011 03:58:32 +0100, Ojan Vafai o...@chromium.org wrote:
I think this is the only sane solution to this problem. Lets split up the
Element interface.
I think an IDL annotation would work better from
On Tue, Nov 22, 2011 at 10:04 AM, Boris Zbarsky bzbar...@mit.edu 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 quirky
behavior is _not_ exposing
On Tue, Nov 22, 2011 at 4:12 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Nov 22, 2011 at 10:24 AM, Ojan Vafai o...@chromium.org wrote:
On Tue, Nov 22, 2011 at 10:04 AM, Boris Zbarsky bzbar...@mit.edu
wrote:
On 11/22/11 12:57 PM, Ojan Vafai wrote:
I was hoping that we could have
On Fri, Nov 25, 2011 at 1:03 AM, Lachlan Hunt lachlan.h...@lachy.id.auwrote:
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
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
On Thu, Oct 20, 2011 at 7:02 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Oct 20, 2011 at 6:57 PM, Ryosuke Niwa rn...@webkit.org 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
On Fri, Jan 6, 2012 at 12:18 PM, Boris Zbarsky bzbar...@mit.edu 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
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
have
BCC: whatwg, CC:public-webapps since discussion of the editing spec has
moved
On Tue, Jun 14, 2011 at 12:54 PM, Aryeh Gregor simetrical+...@gmail.comwrote:
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
On Tue, Jan 10, 2012 at 12:30 PM, Aryeh Gregor a...@aryeh.name wrote:
On Fri, Jan 6, 2012 at 10:12 PM, Ojan Vafai o...@chromium.org wrote:
We should make this configurable via execCommand:
document.execCommand(TabBehavior, false, bitmask);
I'm leery of global flags like that, because
On Wed, Jan 11, 2012 at 8:15 AM, Aryeh Gregor a...@aryeh.name wrote:
On Tue, Jan 10, 2012 at 4:48 PM, Charles Pritchard ch...@jumis.com
wrote:
Historically, one of my biggest frustrations with contentEditable is that
you have to take it all or none. The lack of configurability is
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
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
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. link to DOM4
On Tue, Jan 24, 2012 at 11:43 AM, Glenn Adams gl...@skynav.com wrote:
I'm sorry,
On Tue, Jan 24, 2012 at 11:50 AM, Glenn Adams gl...@skynav.com wrote:
On Tue, Jan 24, 2012 at 12:39 PM, Ian Hickson i...@hixie.ch 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
On Thu, Jan 26, 2012 at 4:42 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Jan 26, 2012 at 6:25 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
As I argued in
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1520.html,
we should absolutely *not* be adding more boolean arguments
On Tue, Feb 7, 2012 at 9:28 AM, Dimitri Glazkov dglaz...@google.com wrote:
On Tue, Feb 7, 2012 at 5:34 AM, Anne van Kesteren ann...@opera.com
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
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
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
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.
On Wed, Mar 14, 2012 at 5:32 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 14 Mar 2012 09:03:23 +0100, Cameron McCormack c...@mcc.id.au
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
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
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
script type=text/html works for string-based templating. Special handling
of /script 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
On Wed, Apr 25, 2012 at 4:22 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Wed, Apr 25, 2012 at 3:31 PM, Ojan Vafai o...@chromium.org wrote:
script type=text/html works for string-based templating. Special
handling
of /script is not a big enough pain to justify adding a template
element
On Thu, Apr 5, 2012 at 6:19 AM, Aryeh Gregor a...@aryeh.name wrote:
On Wed, Apr 4, 2012 at 10:07 PM, Ojan Vafai o...@chromium.org 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 Thu, May 10, 2012 at 5:13 PM, Rafael Weinstein rafa...@google.comwrote:
On Thu, May 10, 2012 at 4:58 PM, Ian Hickson i...@hixie.ch 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
On Thu, May 10, 2012 at 9:28 PM, Rafael Weinstein rafa...@google.comwrote:
On Thu, May 10, 2012 at 4:19 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 10 May 2012, Rafael Weinstein wrote:
On Thu, May 10, 2012 at 4:01 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 May 2012, Tab Atkins Jr.
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
On Tue, Jun 12, 2012 at 10:48 AM, Elliott Sprehn espr...@gmail.com wrote:
On Mon, Jun 11, 2012 at 9:17 PM, Boris Zbarsky bzbar...@mit.edu 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
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
On Wed, Jul 4, 2012 at 5:39 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Jul 4, 2012 5:26 PM, Olli Pettay olli.pet...@helsinki.fi 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.fimailto:
olli.pet...@helsinki.fi
On Thu, Jul 5, 2012 at 7:15 AM, Adam Barth w...@adambarth.com wrote:
On Thu, Jul 5, 2012 at 1:37 AM, Olli Pettay olli.pet...@helsinki.fi
wrote:
On 07/05/2012 08:00 AM, Adam Barth wrote:
On Wed, Jul 4, 2012 at 5:25 PM, Olli Pettay olli.pet...@helsinki.fi
wrote:
On 07/05/2012 03:11 AM,
On Thu, Jul 5, 2012 at 1:02 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Jul 5, 2012 at 12:45 PM, James Graham jgra...@opera.com wrote:
On Thu, 5 Jul 2012, Ryosuke Niwa wrote:
On Thu, Jul 5, 2012 at 8:08 AM, James Graham jgra...@opera.com **
wrote:
On 07/05/2012 12:38 AM,
On Wed, Jul 4, 2012 at 3:43 PM, Ryosuke Niwa rn...@webkit.org 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
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
On Wed, Jul 11, 2012 at 11:19 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jul 11, 2012 at 10:36 AM, Ojan Vafai o...@chromium.org 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 Wed, Jul 11, 2012 at 3:23 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jul 11, 2012 at 3:12 PM, Ojan Vafai o...@chromium.org wrote:
On Wed, Jul 11, 2012 at 11:19 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jul 11, 2012 at 10:36 AM, Ojan Vafai o...@chromium.org wrote:
Another
On Wed, Jul 11, 2012 at 3:47 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jul 11, 2012 at 3:35 PM, Ojan Vafai o...@chromium.org wrote:
On Wed, Jul 11, 2012 at 3:23 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jul 11, 2012 at 3:12 PM, Ojan Vafai o...@chromium.org wrote:
We don't
On Tue, Aug 21, 2012 at 11:17 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
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.
On Tue, Aug 21, 2012 at 1:01 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai o...@chromium.org 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 1:58 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Tue, Aug 21, 2012 at 1:42 PM, Ojan Vafai o...@chromium.org wrote:
On Tue, Aug 21, 2012 at 1:01 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai o...@chromium.org wrote
On Wed, Aug 22, 2012 at 6:49 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Aug 22, 2012 at 5:55 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Aug 22, 2012 at 7:36 PM, Maciej Stachowiak m...@apple.com wrote:
Ryosuke also raised the possibility of multiple text fields having
separate
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:
On Tue, Oct 30, 2012 at 9:42 AM, Hallvord R. M. Steen hallv...@opera.comwrote:
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
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.com] *On Behalf Of *Ojan Vafai
*Sent:* Wednesday, October 31, 2012 10:21 PM
*To:* Hallvord R
be honored by the user agent without
script getting in the way of (and possibly delaying) the action.
** **
*From:* o...@google.com [mailto:o...@google.com] *On Behalf Of *Ojan Vafai
*Sent:* Thursday, November 1, 2012 4:38 PM
*To:* Travis Leithead
*Cc:* Hallvord R. M. Steen; WebApps WG
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]
Sent: Thursday, November 1, 2012 1:37 PM
To: Ojan Vafai
Cc: Travis Leithead; public
On Thu, Nov 29, 2012 at 4:31 PM, Ian Hickson i...@hixie.ch 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
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 to have D4E
On Thu, May 30, 2013 at 3:52 AM, Aryeh Gregor a...@aryeh.name wrote:
On Tue, May 28, 2013 at 8:27 PM, Travis Leithead
travis.leith...@microsoft.com 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
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 SequenceNode and also is just less awkward than the
TreeWalker/NodeIterator interfaces.
On Sat, Jul 27, 2013 at
84 matches
Mail list logo
