On Thu, Jun 11, 2015 at 4:53 PM Domenic Denicola d...@domenic.me wrote:
Some previous discussion: [1] especiallly [2]
In general I think this is a reasonable thing, but it requires a decent
bit more infrastructure to do things “safely”. For example, consider the
definition [3]. It's generic
On Wed, Apr 30, 2014 at 12:21 AM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Apr 29, 2014 at 8:25 PM, Ted Mielczarek t...@mozilla.com wrote:
On 4/29/2014 7:28 PM, Glenn Maynard wrote:
Gamepad objects should definitely be a snapshot. Otherwise, change
events could only expose the most
On Tue, Apr 29, 2014 at 10:39 AM, Ted Mielczarek t...@mozilla.com wrote:
The only major issue that needs to be fixed in the Gamepad API spec
currently is the liveness of Gamepad objects[1].
Currently this is implemented differently in Firefox and Chrome--Firefox
uses live Gamepad objects, in
On Tue, Apr 29, 2014 at 1:45 PM, Brandon Jones bajo...@google.com wrote:
On Tue Apr 29 2014 at 10:24:48 AM, Mark S. Miller erig...@google.com
wrote:
I don't know anything about Gamepad. Could someone provide enough context
that I can understand the question? Thanks.
The Gamepad API
On Tue, Apr 29, 2014 at 3:27 PM, Florian Bösch pya...@gmail.com wrote:
I think both semantics are workable. I'd likely prefer the gamepad state
to be immutable from JS, because assigning state there is smelly.
Yes, there should be no way for user code to directly alter the value of
properties
On Tue, Apr 29, 2014 at 7:28 PM, Glenn Maynard gl...@zewt.org wrote:
Gamepad objects should definitely be a snapshot. Otherwise, change events
could only expose the most recent state of the gamepad. For example, if
the user presses a button and then releases it very quickly (before the
down
On Tue, Apr 29, 2014 at 9:38 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Tue, Apr 29, 2014 at 7:28 PM, Glenn Maynard gl...@zewt.org wrote:
Gamepad objects should definitely be a snapshot. Otherwise, change
events could only expose the most recent state of the gamepad. For
example
On Wed, Nov 20, 2013 at 12:38 PM, Brian Di Palma off...@gmail.com wrote:
On Tue, Nov 19, 2013 at 10:16 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Mon, Nov 18, 2013 at 11:26 PM, Ryosuke Niwa rn...@apple.com wrote:
We share the concern Jonas expressed here as I've repeatedly
On Mon, Nov 18, 2013 at 7:14 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
Largely independently from the thread that Dimitri just started on the
sync/async/-ish nature of HTML imports I have a problem with how
script execution in the imported document works.
Right now it's defined
On Tue, Nov 19, 2013 at 5:27 PM, John J Barton
johnjbar...@johnjbarton.comwrote:
(snip)
This isn't how node modules or ES6 modules work. A module designed for
use with node can define properties on the `global` (ie. the object whose
bound identifier is the word global) and this is the
On Sunday, October 13, 2013, James Greene wrote:
Oh, does `yield` work anywhere? I thought it was only for use within
generators. Admittedly, I haven't been keeping up with the latest ES6
changes.
yield may only appear in the body of a generator function, denoted by star
syntax: function*
On Wed, Sep 11, 2013 at 9:33 AM, Anne van Kesteren ann...@annevk.nl wrote:
As far as I can tell Element.prototype.matches() is not deployed yet.
Should we instead make selectors first-class citizens, just like
regular expressions, and have this:
var sel = new Selectors(i love selectors,
On Tue, May 14, 2013 at 4:01 PM, Scott Miles sjmi...@google.com wrote:
I can't think of any reason I would want to be able to mess with an import
link ex-post-facto and have it do anything. I would also expect any
registrations to be final and have no particular connection to the link tag
This is hard to follow... Almost like two different discussions are
happening at the same time. One discussion has person: ... the other
person ...
Rick
On Saturday, April 27, 2013, Arthur Barstow wrote:
The Draft minutes from WebApps' April 26 f2f meeting are at the following
and copied
On Tue, Apr 16, 2013 at 9:51 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Rick Waldron wrote:
Of course, but we'd also eat scraps from the trash if that was the only
edible food left on earth. document.createElement() is and has always been
the wrong way—the numbers shown in those graphs
On Wed, Apr 17, 2013 at 3:53 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Wed, Apr 17, 2013 at 6:16 PM, Dimitri Glazkov dglaz...@google.comwrote:
Inspired by Allen's and Scott's ideas in the Benadryl thread, I dug
into understanding what element actually represents.
It seems
On Wed, Apr 17, 2013 at 10:34 PM, Bjoern Hoehrmann derhoe...@gmx.netwrote:
* Rick Waldron wrote:
On Tue, Apr 16, 2013 at 9:51 PM, Bjoern Hoehrmann derhoe...@gmx.net
wrote:
* Rick Waldron wrote:
If I want to make a new button to put in the document, the first thing
my
JS programming
:11 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Wed, Apr 17, 2013 at 6:59 PM, Daniel Buchner dan...@mozilla.comwrote:
*This is just a repackaging of Object.defineProperties( target,
PropertyDescriptors ) thats slightly less obvious because the target
appears to be a string
On Tue, Apr 16, 2013 at 5:33 PM, Dimitri Glazkov dglaz...@google.comwrote:
On Mon, Apr 15, 2013 at 6:59 AM, Anne van Kesteren ann...@annevk.nl
wrote:
I think we should go for one interface per element here. abstract
classes not being constructable seems fine. Node/CharacterData are
On Mon, Apr 15, 2013 at 8:57 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/14/13 5:35 PM, Rick Waldron wrote:
I have a better understanding of problem caused by these generated
HTML*Element constructors: they aren't constructable.
I'd like to understand what's meant here. I have a good
On Mon, Apr 15, 2013 at 11:59 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/15/13 10:45 AM, Rick Waldron wrote:
Sorry, I should've been more specific. What I meant was that:
new HTMLButtonElement();
Doesn't construct an HTMLButtonElement, it throws with an illegal
constructor in Chrome
On Sat, Apr 13, 2013 at 10:16 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
I see two ways you might do this:
1) create a new *anonymous* constructor object that inherits from
HTMLElement. It wouldn't have any unique behavior but it would be uniquely
associated the particular element
On Sun, Apr 14, 2013 at 3:46 PM, Daniel Buchner dan...@mozilla.com wrote:
* Here are four ways to avoid the subclassing problem for custom
elements
*
* 1) Only allow instances of custome dom elements to be instantiated
using document.createElement(x-foo).
*
*
*
*Wearing web developer
On Sun, Apr 14, 2013 at 3:46 PM, Daniel Buchner dan...@mozilla.com wrote:
* Here are four ways to avoid the subclassing problem for custom
elements
*
* 1) Only allow instances of custome dom elements to be instantiated
using document.createElement(x-foo).
*
*
*
*Wearing web developer
On Fri, Apr 12, 2013 at 7:14 PM, Dimitri Glazkov dglaz...@google.comwrote:
On Fri, Apr 12, 2013 at 3:56 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Fri, Apr 12, 2013 at 6:52 PM, Dimitri Glazkov dglaz...@google.com
Can you point me to some concrete example, docs, implementation
On Wed, Apr 10, 2013 at 4:15 PM, Daniel Buchner dan...@mozilla.com wrote:
I have a counter proposal that takes into a count both the
easy-to-declare, 1-to-1 case, as well as the 1-template-to-many-elements
case: https://gist.github.com/csuwldcat/5358039
What about CSP that forbids inline
object itself, which isn't going to work
Rick
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Wed, Apr 10, 2013 at 1:27 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Wed, Apr 10, 2013 at 4:15 PM, Daniel Buchner dan...@mozilla.comwrote:
I have a counter
On Wed, Apr 10, 2013 at 5:35 PM, Daniel Buchner dan...@mozilla.com wrote:
One thing I'm wondering re template elements and the association of a
specific script with them, is what is it really doing for me? From what I
see, not much. It seems the only thing it does, is allows you to have the
Barton
johnjbar...@johnjbarton.com javascript:_e({}, 'cvml',
'johnjbar...@johnjbarton.com'); wrote:
On Wed, Apr 10, 2013 at 6:51 PM, Dimitri Glazkov
dglaz...@google.comjavascript:_e({}, 'cvml', 'dglaz...@google.com');
wrote:
On Wed, Apr 10, 2013 at 6:38 PM, Rick Waldron
waldron.r
This is a lot to digest, but I know the developer community will greatly
appreciate the work that has gone into this—thank you.
On Tue, Mar 26, 2013 at 3:02 AM, Jonas Sicking jo...@sicking.cc wrote:
(snip)
First we need a way to get at AppCache objects:
No mention of installAppCache,
On Tue, Mar 26, 2013 at 9:58 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Mar 26, 2013 at 6:28 PM, Rick Waldron waldron.r...@gmail.com
wrote:
This is a lot to digest, but I know the developer community will greatly
appreciate the work that has gone into this—thank you.
Yeah, I hope
cc John Neumann
On Tue, Feb 19, 2013 at 11:48 AM, Oliver Hunt oli...@apple.com wrote:
JSON is deliberately minimal and deliberately unversioned.
What are you expecting this working group to do? Also, given that JSON is
essentially a subset of ECMAScript literal syntax, I'm unsure why this
On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov dglaz...@google.comwrote:
Folks,
I propose just a bit of sugaring as a compromise, but I want to make
sure this is really sugar and not acid, so please chime in.
1) We give up on unified syntax for ES5 and ES6, and instead focus on
unified
:10 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov dglaz...@google.comwrote:
MyButton = document.register(‘x-button’, {
prototype: MyButton.prototype,
lifecycle: {
created: MyButton
}
});
Does this actually mean
I see the distance measurement unit in centimeters is mentioned only
once, in the description of current device proximity, I would suggest
being explicit and including it in minimum proximity distance and
maximum proximity distance as well.
When the current proximity changes, the user agent must
Please ignore the second question. Thanks.
On Thu, Dec 6, 2012 at 6:02 PM, Rick Waldron waldron.r...@gmail.com wrote:
I see the distance measurement unit in centimeters is mentioned only
once, in the description of current device proximity, I would suggest
being explicit and including
On Monday, October 22, 2012 at 6:04 PM, Chris Pearce wrote:
On 16/10/12 18:48, Maciej Stachowiak wrote:
Many games could work with only non-alphanumeric keys or in some cases only
the mouse. As could slideshows. You only need space/enter/arrows for a full
screen slide presentation.
On Tue, Oct 16, 2012 at 5:42 AM, Florian Bösch pya...@gmail.com wrote:
On Tue, Oct 16, 2012 at 7:48 AM, Maciej Stachowiak m...@apple.com wrote:
What are the cases where webpage-driven (as opposed to
browser-chrome-driven) fullscreen is really compelling, but they need full
keyboard access
On Wed, Oct 17, 2012 at 12:06 PM, Florian Bösch pya...@gmail.com wrote:
On Wed, Oct 17, 2012 at 4:51 PM, Rick Waldron waldron.r...@gmail.comwrote:
I'm not sure where this falls, but how would things like control-w or
cmd-w work? If the non-alphanumerics work, but the alphanumerics do
On Tuesday, October 2, 2012 at 6:14 PM, Florian Bösch wrote:
Speaking from the point of view of a web developer having to use this
feature. It is quite painful having to perform an end-run about failure modes
that are unspecified, undocumented and a moving target. In my understanding,
On Mon, Oct 1, 2012 at 10:58 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
From: Rick Waldron [mailto:waldron.r...@gmail.com]
I wasn't specific enough in my original question, but I did note that I
wasn't referring to construction exceptions, so I'm guessing by your
response
throw in the same
manner that invalid selectors throw? eg. context.querySelector(?)
Rick
** **
*From:* Rick Waldron [mailto:waldron.r...@gmail.com]
*Sent:* Friday, September 28, 2012 4:24 PM
*To:* Cameron McCormack
*Cc:* Travis Leithead; Boris Zbarsky; public-script-co...@w3.org
On Fri, Sep 28, 2012 at 4:14 PM, Cameron McCormack c...@mcc.id.au wrote:
Travis Leithead:
I guess you'd check for URL.href then? Or try { new URL(/test); } catch
(ex) { console.log(not supported); }
I agree with Travis, you should be checking the particular features you
want to use,
On Saturday, September 1, 2012 at 4:02 PM, Glenn Maynard wrote:
On Sat, Sep 1, 2012 at 11:49 AM, David Bruant bruan...@gmail.com
(mailto:bruan...@gmail.com) wrote:
A Sync API for workers is being implemented in Firefox [1].
I'd like to come back to the discussions mentionned in comment
On Saturday, September 1, 2012 at 4:28 PM, Olli Pettay wrote:
On 09/01/2012 11:19 PM, Rick Waldron wrote:
David,
Thanks for preparing this summary—I just wanted to note that I still stand
behind my original, reality based arguments.
One comment inline..
On Saturday
On Sep 1, 2012, at 1:38 PM, Rick Waldron wrote:
On Saturday, September 1, 2012 at 4:28 PM, Olli Pettay wrote:
On 09/01/2012 11:19 PM, Rick Waldron wrote:
David,
Thanks for preparing this summary—I just wanted to note that I still stand
behind my original, reality based arguments.
One
On Sat, Sep 1, 2012 at 5:12 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 09/01/2012 11:38 PM, Rick Waldron wrote:
So far, they all look async. Just calling them sync doesn't make them
sync.
Sure they are sync. They are sync inside worker. We all know that we must
not introduce
new
Comments inline...
On Tue, Aug 21, 2012 at 6:17 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Tue, Aug 21, 2012 at 3:15 PM, Brian Kardell bkard...@gmail.com wrote:
On Aug 21, 2012 5:40 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Aug 21, 2012 at 2:28 PM, Ojan Vafai
On Tue, Aug 21, 2012 at 6:40 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Tue, Aug 21, 2012 at 3:29 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Tue, Aug 21, 2012 at 6:17 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
ul.special li {
onclick: alert('You clicked me
On Thu, May 17, 2012 at 9:31 AM, Scott González scott.gonza...@gmail.comwrote:
I'm sure Yehuda can speak more to the status of scriptlib, but the way I
see it is:
There was a some buzz about scriptlib and the W3C being excited about
developers participating via CGs.
Very few developers
On Thu, May 17, 2012 at 1:05 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, May 17, 2012 at 6:29 PM, Rick Waldron waldron.r...@gmail.com
wrote:
[...]
FWIW, we have bugs filed against DOM for both better event
registration and constructing of event targets:
https://www.w3.org/Bugs
:
On Thu, May 17, 2012 at 9:56 AM, John J Barton
johnjbar...@johnjbarton.com wrote:
On Thu, May 17, 2012 at 9:29 AM, Rick Waldron
waldron.r...@gmail.com
wrote:
Consider the cowpath metaphor - web developers have made highways
out
of
sticks, grass and mud - what we need is someone
On Thu, May 17, 2012 at 3:21 PM, Brian Kardell bkard...@gmail.com wrote:
On Thu, May 17, 2012 at 2:47 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Thu, May 17, 2012 at 2:35 PM, Brian Kardell bkard...@gmail.com
wrote:
So, out of curiosity - do you have a list of things? I'm
snip
Weird, because you posted
this:
https://docs.google.com/document/d/1atsxnstVybfovkX_f6xf2P25i1NT0ilCihJuPDwYWEU/edit?hl=en_US
here: https://bugzilla.mozilla.org/show_bug.cgi?id=604039#c40
Just to be clear, I'm not trying to be aggressive or confrontational, but I
just reread my message
Instead of traditional DOM events being used for Other Events[1], and
considering the high frequency of Gamepad state changes, it might make
sense to provide an API similar to MutationObserver, where a MutationRecord
is created that has snapshots of current and previous states of axes or
On Wed, May 2, 2012 at 5:54 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 05/03/2012 12:48 AM, Rick Waldron wrote:
Instead of traditional DOM events being used for Other Events[1], and
considering the high frequency of Gamepad state changes, it might make
sense to provide an API similar
On Wed, May 2, 2012 at 7:01 PM, Scott Graham scot...@chromium.org wrote:
On Wed, May 2, 2012 at 3:12 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, May 2, 2012 at 5:54 PM, Olli Pettay olli.pet...@helsinki.fi
wrote:
On 05/03/2012 12:48 AM, Rick Waldron wrote:
Instead
Are you saying this is no longer possible?
https://gist.github.com/552549
-Rick
On Sunday, April 22, 2012 at 9:47 AM, Ivan Enderlin @ Hoa wrote:
Hello folks,
Are they any reasons to not have the EventSource interface available in
a WorkerGlobalScope?
The W3C specifies that they
On Mar 13, 2012, at 4:29 AM, Anne van Kesteren ann...@opera.com wrote:
On Mon, 12 Mar 2012 21:06:00 +0100, Rick Waldron waldron.r...@gmail.com
wrote:
On Mar 12, 2012, at 3:06 PM, Anne van Kesteren ann...@opera.com wrote:
On Mon, 12 Mar 2012 19:07:31 +0100, Rick Waldron waldron.r
that you can
do regular array operations on it.
In the future, it will be incredibly easy to make a NodeList into an Array
with the spread operator:
[ ...NodeList ]
// [ node, node, node ]
Rick
On Tue, Mar 13, 2012 at 5:59 AM, Rick Waldron waldron.r...@gmail.comwrote:
On Mar 13, 2012
On Mon, Mar 12, 2012 at 2:00 PM, Adam Klein ad...@chromium.org wrote:
On Thu, Mar 8, 2012 at 11:57 PM, Anne van Kesteren ann...@opera.comwrote:
On Thu, 08 Mar 2012 23:24:45 +0100, Ojan Vafai o...@chromium.org wrote:
Dynamic NodeLists have a significant memory and performance cost. Static
On Mar 12, 2012, at 3:06 PM, Anne van Kesteren ann...@opera.com wrote:
On Mon, 12 Mar 2012 19:07:31 +0100, Rick Waldron waldron.r...@gmail.com
wrote:
The NodeList item() method is a blocker.
Blocker in what way?
As I've always understood it - the item() method is what differentiates
Short answer: yes. Particularly, I know that Rafael has spent
significant time with several of the templating systems, and Dimitri
and several others have had at least a decent exposure to them and the
developers of them.
~TJ
Great! Thanks for the follow up :)
Hey everyone,
I've been following the HTML Parsing and the template element
thread/conversation since it began yesterday and it's very interesting, but
one thing keeps coming to mind - has anyone working on template spent any
significant time using the existing web template systems and practices?
On Tue, Feb 7, 2012 at 2:41 PM, Dimitri Glazkov dglaz...@chromium.orgwrote:
Folks,
To make Web Components more usable, I would like to consider providing
a way to declare event handlers in markup. As I look over the use
cases and try to implement them using the proposed syntax
What about conflict with existing specification rules?
http://dev.w3.org/html5/spec/Overview.html#the-script-element - under #12,
limits the use of event and for attributes to load and window respectively.
Rick
On Tue, Feb 7, 2012 at 3:05 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On
So, one of the biggest issues facing the web right now is the ones that
aren't seen by end users of web sites - they are seen by web developers who
have to wade through cryptic, often bizarre, frequently asymmetrical and
almost alway too concise or too verbose APIs. Proposal and spec authors
have
Apologies, cited the wrong message in this thread, please forgive.
( Rick: -2 ;) )
On Wed, Feb 1, 2012 at 10:20 AM, Rick Waldron waldron.r...@gmail.comwrote:
So, one of the biggest issues facing the web right now is the ones that
aren't seen by end users of web sites - they are seen by web
Just wondering why, in 2012, there are proposals for elements with abbreviated
names. Please stop doing that.
record
Is two characters longer and infinitely more intuitive. Say no to mistakes like
img
Rick
On Jan 31, 2012, at 11:51 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Glen
Following the recent blog post
http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fastand
subsequent Twitter discussion regarding changes to the parameter list
of:
Worker.prototype.postMessage( message [, transfer ] ) [1]
DedicatedWorkerGlobalScope void
On Tue, Dec 13, 2011 at 8:24 AM, Rick Waldron waldron.r...@gmail.comwrote:
Following the recent blog post
http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fastand
subsequent Twitter discussion regarding changes to the parameter list
of:
Worker.prototype.postMessage( message
Dmitry,
Thanks for taking the time to provide these references and resources
Rick
On Nov 18, 2011, at 12:56 PM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Nov 18, 2011 at 12:18 PM, David Levin le...@chromium.org wrote:
The primary use case is one in which messages sent to
DedicatedWorkerGlobalScope are reserved for synchronous messaging.
Mostly, yes, or otherwise
On Thu, Nov 17, 2011 at 1:37 PM, Joshua Bell jsb...@chromium.org wrote:
Jonas and I were having an offline discussing regarding the synchronous
Indexed Database API and noting how clean and straightforward it will allow
Worker scripts to be. One general Worker issue we noted - independent of
On Nov 17, 2011, at 2:37 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Nov 17, 2011 at 2:16 PM, Rick Waldron waldron.r...@gmail.com wrote:
This is counter to the whole premise of Workers, which should be independent
of their renderer process and certainly not block themselves while
On Thu, Nov 17, 2011 at 6:50 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Nov 17, 2011 at 6:17 PM, Rick Waldron waldron.r...@gmail.comwrote:
No, it's not. Messaging should not block either process.
No, it's perfectly fine to block a worker, as long as the worker
explicitly requests
[snip]
ES5.1 clause 8.6.2 says:
The value of the [[Class]] internal property of a host object
may be any String value except one of Arguments, Array,...
In other words, host object provides (such as a DOM implementation) are
not allowed to define new kinds of objects whose
Any DOM NodeList/NodeArray could be converted into a real array by passing
to Array.from( array like )
http://wiki.ecmascript.org/doku.php?id=strawman:array_extras
Avoids creating yet another DOM NodeThing.
/Rick
On Nov 11, 2011, at 6:57 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri,
On Sat, Oct 29, 2011 at 11:28 PM, Cameron McCormack c...@mcc.id.au wrote:
On 20/10/11 3:50 AM, Alex Russell wrote:
I strongly agree that it should be an Array *type*, but I think just
returning a plain Array is the wrong resolution to our NodeList
problem. WebIDL should specify that DOM List
On Wed, Oct 26, 2011 at 4:33 PM, Cameron McCormack c...@mcc.id.au wrote:
On 25/10/11 8:54 PM, Adam Barth wrote:
Another solution to that more than one tag per interface problem is
to introduce subclasses of those interfaces for each tag.
Instead of introducing more interfaces (which don't
As a developer that writes JavaScript every single day, the sheer amount of
typed characters required for using the constructors in this proposal is
enough for me to avoid it at all costs.
On Tue, Oct 25, 2011 at 11:42 PM, Kentaro Hara hara...@chromium.org wrote:
Hi folks,
* Background *
var b = new Blob([foo, bar], { contentType: text/plain });
This is really nice looking and feeling. Options objects are definitely a win
/rw
On Oct 26, 2011 7:17 PM, Jonas Sicking lt;jo...@sicking.ccgt; wrote:
On Tue, Oct 25, 2011 at 12:57 PM, Tab Atkins Jr. lt;jackalm...@gmail.comgt;
From a real-world developer perpective, this API modification is a win.
On Mon, Oct 24, 2011 at 7:01 PM, Ojan Vafai o...@chromium.org wrote:
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
On Fri, Oct 21, 2011 at 11:28 AM, João Eiras jo...@opera.com wrote:
On Thu, 20 Oct 2011 16:39:56 +0200, Igor Oliveira
igor.olive...@openbossa.org wrote:
Hello,
Currently CSSMatrix and SVGMatrix has an immutable API. None of the
method calls change the Matrix, instead, it creates a new
84 matches
Mail list logo
