On 5/11/14, 3:40 PM, Tab Atkins Jr. wrote:
Note, though, that WebIDL *does* have things that can act like
abstract base classes
Does it? Can you point me to one other than MapClass?
-Boris
On 5/9/14, 4:20 AM, 송정기 wrote:
Providing base interface for Cache interface
Yes, but what does that actually mean in practice? Will there be
AsyncMap.prototype methods that can operate on any AsyncMap instance
including Cache? What would those methods do?
Regarding the implication to ES, I
I'm looking at
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#cache-list
here.
The point of [MapClass] (assuming [MapClass] stays in the WebIDL spec at
all) is to declare interfaces that quack enough like Map that it makes
sense to have them be instanceof Map and
In particular, given that get() wants to return a Promise, why do we
want values() to return a list of Cache objects synchronously?
Similar for keys(): if has() needs to be async, then how can has() be sync.
-Boris
On 5/9/14, 12:26 AM, Jungkee Song wrote:
Right. We're defining an AsyncMap interface [1] which Cache interface
and CacheList interface are based off of. AsyncMap isn't spec'd yet in
any place than in the .ts file. A difficulty encountered is we don't
have any IDL construct for this yet. Any
On 4/29/14, 11:32 AM, Anne van Kesteren wrote:
I think the main problem with making a Gamepad live is that the
lifetime of the object has to be lifetime of the associated global.
Otherwise GC can be observed through expandos.
For what it's worth, the way Gecko implements this is by setting up
On 4/29/14, 1:46 PM, Mark S. Miller wrote:
How would either make GC observable?
Consider the following code:
navigator.getGamepads()[0].foo = 5;
var intervals = 0;
var id = setInterval(function() {
++intervals;
if (navigator.getGamepads()[0].foo != 5) {
alert(What happened
On 4/11/14 10:09 AM, Domenic Denicola wrote:
- https://www.w3.org/Bugs/Public/show_bug.cgi?id=13145
-
https://web.archive.org/web/20121127212525/http://aryeh.name/spec/innertext/innertext.html
The outcome of that was basically that the WebKit folks wanted innerText
to be some sort of
On 3/20/14 11:39 AM, Domenic Denicola wrote:
If you return something that doesn't match the declared return value, that's a
spec bug, but it has no impact on anything.
True, though the spec bug may make the spec not implementable (e.g. in a
UA that autogenerates code from the IDL for a
On 3/20/14 11:46 AM, Michael van Ouwerkerk wrote:
So it is not normative? It seems it would be very informative though, so
still worth adding to the spec. But it seems it would be even better if
it was changed to be normative.
It's normative in the sense that the implementation of the method
On 3/17/14 12:08 PM, Anne van Kesteren wrote:
Well, Chrome does not have Type 4, yet is implementing parts of the
their elements using shadow DOM constructs.
What makes you say Chrome doesn't have Type 4?
They do in fact have it for the case in question, as far as I can tell
(inaccessible
On 3/9/14 8:30 PM, Hallvord R. M. Steen wrote:
I've added the statement The event bubbles and is cancelable. to the
description of each (copy/cut/paste) event:
http://dev.w3.org/2006/webapi/clipops/clipops.html#events
That works, though it might be clearer to put that in the dispatch a
The clipboard API draft [1] doesn't seem to say whether paste events, or
any other events fired by fires a clipboard event bubble. Or whether
they're cancelable, for that matter. Presumably it should say something
on the matter.
-Boris
[1]
On 2/14/14 2:03 PM, Erik Arvidsson wrote:
Then we need to guard all DOM traversal and DOM mutation methods and
throw if the counter is non zero.
This is a fairly nontrivial whack-a-mole exercise, sadly (starting with
defining traversal).
-Boris
On 2/13/14 5:35 AM, Anne van Kesteren wrote:
Also, Type 2 can be used for built-in elements
Built-in elements need Type 4.
-Boris
On 2/7/14 12:32 PM, Scott González wrote:
What about developers who are sending requests as the page is unloading?
Does Beacon address their use cases? If not, what are the use cases?
-Boris
On 2/4/14 11:48 AM, Arun Ranganathan wrote:
A web page using the FileSystem API in JavaScript and working in two separate
browser implementations seems like a good measure of interoperability
A good measure of interop is a test suite that actually tests edge cases
(something that a web page
On 1/14/14 7:33 AM, Arthur Barstow wrote:
[2]:
https://github.com/domenic/promises-unwrapping/blob/master/docs/writing-specifications-with-promises.md
One issue I just realized, as I was considering how to implement some of
this stuff in automated ways. All the terms in the Creating Promises
On 1/16/14 1:29 PM, Domenic Denicola wrote:
Hmm, I don't quite understand the concern.
You're creating new objects using things like Promise.cast(). That will
create an object whose prototype is Promise.prototype. But which
realm's Promise is it using in this case? That needs to be
On 1/14/14 9:22 AM, Domenic Denicola wrote:
Do you think it would be improved by nesting step 5 under These steps will be run
asynchronously?
Yes. Otherwise if there is another method that allows synchronously
checking whether a bookmark has been added I would expect such a method
to
On 1/14/14 10:44 AM, Domenic Denicola wrote:
I do want to clarify that I want to avoid explicitly queuing needless tasks,
which then themselves go and perform asynchronous actions. Instead, just
perform the asynchronous action, and use the promise microtask queue to the
deliver the results.
On 1/14/14 10:44 AM, Domenic Denicola wrote:
So maybe we need slightly better phrasing; help appreciated.
Maybe the right way to spec this is to simply use two algorithms...
Algorithm A has some steps, then says to perform B asynchronously and
returns a promise. B has a bunch of steps that
On 1/13/14 6:00 AM, James Graham wrote:
A simple in-browser test runner is now available in the
web-platform-tests repository.
James, thank you for doing that!
I suggest that henceforth we stop compiling implementation reports by
hand on wiki pages and instead ask implementors to provide the
On 1/10/14 11:10 AM, Erik Arvidsson wrote:
My hope was that it would be rare to override Symbol.create for Elements
so in most cases we would not need to call user code.
For spec purposes and parser implementation design purposes that doesn't
matter. If user code can be called, the
On 1/9/14 8:39 PM, Goktug Gokdogan wrote:
Is it really part of the plans (i.e. making HTMLElement constructible)?
Ideally, yes. The main problem with making HTMLElement constructible is
this: What tag name should it use when it constructs? If it were not
for that, it would already be
On 1/9/14 8:50 PM, Goktug Gokdogan wrote:
Can't it be passed by constructor call?
Possibly, yes. The spec was in flux for a while, but looks like
@@create does in fact get passed the constructor arguments, so it can
create different objects based on those.
-Boris
On 1/9/14 10:57 PM, Ryosuke Niwa wrote:
Given that, we could maybe cheat and in fact do some sort of delayed calling of the
constructor of ES6 subclasses of elements. You'd still be able to observe these objects
in an unconstructed state from the subclass pov, but at least it wouldn't be
a
On 1/6/14 8:52 PM, Goktug Gokdogan wrote:
function MyCustomElement() {};
MyCustomElement.prototype = Object.create(HTMLElement.prototype);
document.appendChild(new MyCustomElement());
If this were actually using ES6 classes (and if HTMLElement were
constructible), this would in fact
On 12/17/13 3:29 AM, Jonas Sicking wrote:
This is a good point. Would this have performance implications for
down-level browsers? I don't know if prescanners etc in contemporary
browsers are smart enough to ignore script tags that use a non-JS
type attribute.
Gecko's is not. Not least because
On 12/12/13 7:24 AM, pira...@gmail.com wrote:
Should have data: and blob: schemes the same consideration here?
I would think not, since blob: URLs have a built-in concept of origin
that's actually important, so are presumably covered by the origin of
worker url is the same as the origin of
On 12/11/13 8:42 AM, Arthur Barstow wrote:
[IR] http://www.w3.org/wiki/Webapps/Interop/WebWorkers
Looking at this link, there are passes marked for obviously incorrect
tests (e.g. see https://www.w3.org/Bugs/Public/show_bug.cgi?id=24077
which says that
On 12/12/13 2:01 PM, Jonas Sicking wrote:
We can certainly debate if throwing an exception or if asynchronously
reporting a network error is the right thing to do for things like
XHR.send(closedBlob) or FileReader.readAsX(closedBlob).
Or form submission after fileInput.files[0].close() ?
On 12/10/13 10:34 AM, Anne van Kesteren wrote:
E.g. the dialog's close() method won't work as defined
right now on a subclass of HTMLDialogElement.
Why not?
I assumed that actual ES6 subclassing, complete with invoking the right
superclass @@create, would in fact produce an object for which
On 12/10/13 6:30 PM, Jonas Sicking wrote:
I would also think that you need properties to position the ::popout.
Oh, yes. The extra fun here is:
1) Should the popout be able to paint outside the browser window?
Right now, comboboxes (select size=1) can but normal CSS boxes cannot.
2) The
On 12/7/13 5:37 PM, Domenic Denicola wrote:
$(document.querySelector(.my-slider)).slider(option, disabled, false);
instead of
document.querySelector(.my-slider).disabled = false;
I should note that the latter is _much_ more likely to be fast, for
people who care about that sort of thin. In
On 12/6/13 1:29 PM, Joshua Bell wrote:
// Throws TypeError on older implementations since Dictionary won't
coerce to Number (?)
Sure it will. It'll do ToNumber() and probably end up NaN (which
becomes 0 as an unsigned long long) unless your object has a valueOf
method that returns
On 12/6/13 2:37 PM, Joshua Bell wrote:
This behavior is specified in prose, not IDL:
https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBFactory-open-IDBOpenDBRequest-DOMString-name-unsigned-long-long-version
If the value of version is 0 (zero), the implementation must throw a
On 12/6/13 10:25 PM, Domenic Denicola wrote:
We can create our own arrows with (multiple) background images, or ::after.
You can, but if it doesn't match the scrollbar width in cases when there
is a scrollbar the result looks pretty terrible when the popup is
opened... And scrollbar widths
On 12/5/13 4:30 AM, Ryosuke Niwa wrote:
As I understand it, people want to do:
select name=cities is=map
That's not the main issue being discussed right now, as far as I can tell.
What's being discussed, I think, is that people want to do things like:
input type=date
and then style the
On 12/6/13 12:03 AM, Ryosuke Niwa wrote:
That sounds like an implementation detail of Blink/WebKit.
It seems like a pretty fundamental restriction for all current HTML
parsers. In particular, the HTML parsing algorithm has no provisions
for script mutating the DOM at random points in the
On 12/2/13 6:42 AM, Mounir Lamouri wrote:
a 'findinpage' event could be fired on the
document when the user initiates a find in page and the page would be
able to call .preventDefault() on the event in order to show its own UI.
I assume with a user option to not fire that event and use the
On 11/27/13 2:44 PM, Dimitri Glazkov wrote:
If the rel attribute is used, the element is restricted to the head
element.
This is part of a non-normative content (a note), so I think we're off
the hook here :)
No. The normative bit is sort of scattered around the spec, but for
example:
On 11/27/13 3:54 PM, Dimitri Glazkov wrote:
I see. Do you know why?
Because people wanted link to mean something, or something. I really
can't say.
It seems that all browsers support it anywhere
And the spec requires them to, yes.
and this looks like just validator hoop-jumping.
On 10/30/13 5:56 PM, Ryosuke Niwa wrote:
Interesting. Could you point me to the part of the spec. that mandates this
behavior?
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#images-0
says:
When an img element represents some text and the user agent does
not
On 10/14/13 12:11 AM, Ryosuke Niwa wrote:
If I'm not mistaken, how alternative text is presented is up to UA vendors.
You're mistaken. The HTML spec actually defines the behavior here, in
standards mode: it's presented as text inside a non-replaced inline
(effectively as if content:
On 10/8/13 7:47 AM, Simon Pieters wrote:
Pro tip: use http://www.w3.org/2009/07/webidl-check (I invoke it in my
Makefile for CSSOM).
Hmm. What makes sure this is updated when the spec is updated? I just
tried this:
interface Foo {
void x(optional long y, long z);
};
and the
On 10/4/13 10:48 AM, Kyle Huey wrote:
If a File object (which has a name) is used instead of a Blob I think we
should treat it as if something like Content-Disposition:
filename=$file.name http://file.name was specified in an HTTP
request.
Gecko does, because a bunch of servers send it. See
On 9/20/13 7:19 AM, Simon Pieters wrote:
It's defined here:
http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#dom-document-cookie
Though note that this part of the spec is in flux. In particular, the
whole HTMLDocument vs Document vs XMLDocument mess is still unclear, and
On 9/20/13 7:28 AM, Simon Pieters wrote:
(I'm not sure where the spec says that the above case is a network
error, though.)
https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html section 4.6.7
lands us in Otherwise, follow the cross-origin request steps and
terminate the steps for this
On 9/19/13 8:52 PM, Anne van Kesteren wrote:
That would prohibit processing the data URL incrementally. Or at least
require you to know the size of it in advance somehow.
I'm not sure I follow. The size of the data for a data: URL is always
known as long as you have the entire URL, no?
On 9/19/13 4:47 PM, Hallvord Steen wrote:
Hi,
I see Gecko fakes a Content-Length header (visible to
getAllResponseHeaders()) when you load a data: URL with XHR. This is wrong per the spec
(which is explicitly requiring only a single Content-Type response header) but it looks
more like a
On 9/19/13 9:31 PM, Anne van Kesteren wrote:
Doesn't that depend on how you end up storing it whether getting that
information is fast and easy to get ahead of time?
I suppose, if you store them somewhere where you don't know how much
space they're taking up in the storage... But at some
On 9/19/13 10:51 PM, Julian Aubourg wrote:
But Content-Length is not the same as the length of the string
containing the Data URL.
Sure. It can also be a simple formula computed from that length, in the
case of base64-encoded data URLs.
And of course you have to subtract out the length of
On 9/19/13 11:39 PM, Julian Aubourg wrote:
We need to check the encoding
You mean the base64 or lack thereof?
we need to make sure we
know how to determine the actual length for this encoding
For base64 you do. Otherwise, it's a malformed data URI.
we need a way
to not store length if
On 9/20/13 1:05 AM, James Greene wrote:
Just an observation — perhaps an obvious one to others who are more
familiar with the various URI specs and whatnot — but I've always
considered the comma and prior to be the equivalent of HTTP headers
(metadata) for the image, so to me the Content-Length
On 9/18/13 4:52 AM, Dominique Hazael-Massieux wrote:
should read instead
dictionary ClipboardEventInit : EventInit {
DOMString data;
DOMString dataType;
};
What Gecko's WebIDL has here is:
dictionary ClipboardEventInit : EventInit
{
DOMString data
On 9/18/13 10:09 AM, James Greene wrote:
Remember that the URL referenced is not for the latest version of this
spec. Correct URL:
http://www.w3.org/TR/clipboard-apis/
Again, this has no IDL for the dictionary at all. That's clearly wrong.
-Boris
On 9/16/13 5:48 PM, Tab Atkins Jr. wrote:
That code isn't depending on matchesSelector, it's depending on
fooMatchesSelector *or* matchesSelector. As long as the former works,
it's fine - we don't need to add the latter as well.
Tab,
What's a new rendering engine supposed to do? Implement
On 9/13/13 10:49 AM, Anne van Kesteren wrote:
On Fri, Sep 13, 2013 at 3:22 PM, Boris Zbarsky bzbar...@mit.edu wrote:
In any case, my real questions revolve around generic vs branded methods and
whatnot, which are not covered by those two bugs.
I think they should be generic
OK, fwiw I think
On 9/13/13 10:58 AM, Anne van Kesteren wrote:
On Fri, Sep 13, 2013 at 3:53 PM, Boris Zbarsky bzbar...@mit.edu wrote:
OK, fwiw I think I agree. The next question is whether they should be
generic in the elements of the collection or not too.
I don't really follow this. Are you talking about
On 9/13/13 11:22 AM, Domenic Denicola wrote:
Ideally, ES6 will give most of the macros needed, in the form of class
syntax, default arguments, and destructuring argument lists. It's not all you need,
certainly, but it does obviate a lot of WebIDL
None of those affect the common pitfalls
On 9/13/13 11:50 AM, Boris Zbarsky wrote:
As in, I expect UAs to continue to use such declarative languages internally no
matter what the specs are doing.
And if the expectation is correct, there is value on only doing the
mapping from behavior to declarative once in the open instead of each
On 9/13/13 12:01 PM, Domenic Denicola wrote:
Really? Argument defaulting and destructuring, at the very least
Is typically not used in web specs until very recently.
As has been defining classes with constructors and classes that can be
inherited from.
Classes with constructors, agreed.
On 9/13/13 2:46 PM, Domenic Denicola wrote:
Thanks Boris, this is indeed all very helpful. I just wanted to point out that what you are calling
dictionaries is largely covered by what I called destructuring, on the
input side at least. E.g.
Furthermore, privileged code should never be
On 9/13/13 3:19 PM, Domenic Denicola wrote:
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
Consider this IDL:
dictionary Dict1 {
long a = 5;
};
dictionary Dict2 {
sequenceDict1 dicts;
}
void foo(optional Dict2 arg);
How would you express eqivalent semantics
On 9/12/13 12:57 PM, Domenic Denicola wrote:
That sounds cool too! I was just concerned it wouldn't be optimizable enough.
I think it depends on what you mean by enough.
Getting properties out of an array is much faster in script (e.g.
self-hosted) than it is via the C++ API, at least for
On 9/12/13 12:38 PM, Domenic Denicola wrote:
One idea we had for this was as outlined in the gist at [1], where they try to call some
internal [[QuerySelectorAll]]-like method of things contained within it
Why is that needed? If we just want this to be generic and all, it
seems simplest to
On 9/12/13 11:19 AM, Boris Zbarsky wrote:
On 9/12/13 10:27 AM, Anne van Kesteren wrote:
http://dom.spec.whatwg.org/ now includes these methods as well as the
new Elements return value
I would appreciate some discussion on public-script-coord about the IDL
stuff you're making up here
On 9/12/13 1:09 PM, Domenic Denicola wrote:
Hmm, the issue is, this internal-properties thing is pretty prevalent in ES6
generally. All the built-ins can now be subclassed, and the mechanism in the
spec for that is by giving them internal data properties that are initialized
by their
On 9/12/13 10:27 AM, Anne van Kesteren wrote:
http://dom.spec.whatwg.org/ now includes these methods as well as the
new Elements return value
I would appreciate some discussion on public-script-coord about the IDL
stuff you're making up here.
-Boris
On 9/11/13 9:52 AM, Rick Waldron wrote:
A prime use case: a cache of selector objects that are useful when
matching event.target for event handler delegation patterns.
Note that UAs already do some internal caching of parsed selector
objects used with querySelector. Of course an explicit
On 9/11/13 12:26 PM, Brian Kardell wrote:
If something with the same name but different
signature or functionality goes out unprefixed, things will break.
Why is this, exactly? Is code assuming that mozFoo, webkitFoo and
foo are interchangeable? Because they sure aren't, in general.
In
This is implementor feedback on
http://www.w3.org/TR/webmessaging/#event-definitions
See https://www.w3.org/Bugs/Public/show_bug.cgi?id=23176
Note that there is no coverage of the behavior here in the test suite,
apparently, so Blink's implementation doesn't match what the spec
currently has
On 9/6/13 9:13 PM, Brett Zamir wrote:
I am wondering whether thought has been given to allowing selectors
beginning with for use with querySelector/All
There have, as have selectors like :scope .sharedClass. Gecko had
an implementation of the :scope version of this at one point, but people
On 6/24/13 2:31 AM, Hajime Morrita wrote:
HTML Imports spec relies on the concept of things that is blocking
scripts.
In HTML, link-ed styles are blocking scripts. So All styles that
precede a script are loaded before the script execution.
On 6/9/13 7:35 PM, Timmy Willison wrote:
I was a little confused. I realized something I already knew in that
elem.querySelector[All] does limit the matched set to the descendants of
element
Right. But find() does not, for what it's worth, depending on the exact
selector used. It can return
On 5/28/13 2:28 PM, Dimitri Glazkov wrote:
This is a really good question. Web developers expressed the need for
properly resolving URLs pretty much as soon as they heard of HTML
Imports: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19870.
Right, not surprising.
What they want is for this
Basic question: what should the base URI be for a node that's part of a
shadow tree that comes from some URI that's not the document URI?
Making it be the base URI of the resulting ownerDocument is nice and
simple and involves no spec changes and means that relative URIs to
things like
On 5/9/13 6:43 AM, Arthur Barstow wrote:
Boris - would you please indicate if you are OK with the way 21555 has
been fixed/resolved?
I am, yes.
-Boris
On 4/30/13 1:52 PM, Erik Arvidsson wrote:
For the record, we have two independent implementations of the Shadow
DOM spec
Do we? Correct ones that are actually shipping in a UA?
-Boris
On 4/22/13 12:47 PM, Tab Atkins Jr. wrote:
As long as you don't spin the event loop
That's tricky. Here's some simple code at global scope:
request = indexedDB.open('database');
request.onsuccess = function () {};
Can that code spin the event loop between the open() call and the
onsuccess
On 4/22/13 1:31 PM, Tab Atkins Jr. wrote:
Is there a reason to not pass the success/error/upgradeneeded callbacks in a
dictionary to open() in this case, so that the request object is born with
the right bits and the actual reques it not kicked off until _after_ the
side-effects of getting them
On 4/22/13 1:41 PM, Tab Atkins Jr. wrote:
On Mon, Apr 22, 2013 at 10:36 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/22/13 1:31 PM, Tab Atkins Jr. wrote:
Is there a reason to not pass the success/error/upgradeneeded callbacks
in a
dictionary to open() in this case, so that the request object
On 4/22/13 4:36 PM, Joshua Bell wrote:
The debugger spins the event loop
Fwiw, that seems like a bug in the debugger (albeit a common one in
browser debuggers) :(
-Boris
On 4/17/13 11:16 PM, Rick Waldron wrote:
I'm of the mind that browser vendors and implementors need to be
accountable to the developers using the platform, instead of developers
being hostages of the platform.
As this specifically applies to .ownerDocument, note that lots of
elements have all
On 4/16/13 11:59 AM, Anne van Kesteren wrote:
I guess arguably that's how we define fetching in general (ignoring
redirects) but it does mean you have to wait for the response (to see
if it's a redirect or 401/407) before you can dispatch loadend on
.upload which is contrary to what we decided a
On 4/14/13 1:49 PM, Scott Miles wrote:
Erik Arvidsson came up with a strategy for overcoming this in Blink, but
to my recollection Boris Zbarsky said this was a non-starter in Gecko.
Just to be clear, the proposal there was to take an already existing
function object and call some UA-provided
On 4/14/13 3:07 PM, Allen Wirfs-Brock wrote:
2, 3, 4
I believe have been suggested in one form or another, but as I
mentioned, were determined to be non-starters for Gecko. I don't think
we've heard anything from IE team.
Well #4 has been accepted for ES6 by all TC39 participants including
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 understanding
of how these constructors work in Gecko+SpiderMonkey, but I'm
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 and HTMLButtonElement is not a constructor in
Firefox (I'm sure this is the
On 4/15/13 3:46 PM, Rick Waldron wrote:
What I was expecting the above to produce is a constructor capable of
something like this:
var smile = new Smile();
smile.nodeType === 1;
For that, you have to have a way for Smile to get the @@construct of
HTMLButtonElement. There's no way to
On 4/11/13 12:23 PM, Allen Wirfs-Brock wrote:
So why don't you make register a static method on HTMLElement and then
define the element semantics so it automatically does:
MyElement.register()
This would normally invoke the inherited static method
I lost track of something here. Why
On 4/11/13 1:29 PM, Anne van Kesteren wrote:
On Thu, Apr 11, 2013 at 6:23 PM, Anne van Kesteren ann...@annevk.nl wrote:
So how much can we still change fullscreen? It should really use futures.
It seems Gecko and Chrome have it prefixed
Isn't the thing that matters whether _sites_ have it
On 4/11/13 12:50 PM, Allen Wirfs-Brock wrote:
Yes ES6 has class-side inheritance
OK. Should we be doing that with WebIDL interface objects, perhaps? It
would certainly make sense to me to do that, as long we we don't run
into web compat issues.
-Boris
On 4/11/13 12:55 PM, Boris Zbarsky wrote:
On 4/11/13 12:50 PM, Allen Wirfs-Brock wrote:
Yes ES6 has class-side inheritance
OK. Should we be doing that with WebIDL interface objects, perhaps? It
would certainly make sense to me to do that, as long we we don't run
into web compat issues
On 4/5/13 2:57 PM, Mike Kamermans wrote:
The getter/setter incur virtually no overhead, being baked into JS at the
lowest possible level, compared to mutation observers, which are rather
heavy hitting things for notifying non-owner objects of changes.
For what it's worth, I welcome actual
I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20394 to track
this. Not sure whether that's enough to get it on the issues list...
-Boris
On 4/2/13 2:08 PM, Boris Zbarsky wrote:
I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20394 to track
this.
Of course I meant https://www.w3.org/Bugs/Public/show_bug.cgi?id=21555
-Boris
On 3/28/13 12:55 PM, Elliott Sprehn wrote:
and isPositioned is a bitfield check
That happens to be a WebKit-specific claim, as far as I can tell.
parse the property name
As is this.
But yes, the general claim that the JS APIs for doing this right now are
full of performance fail stands.
Scott Miles wrote:
This is a thorny problem, but my initial reaction is that you
threaded the needle appropriately. I don't see how we avoid some
lossiness in this situation.
Note that if you're using offsetWith/Height/Top/Bottom you already lose,
because they return integers.
I think we
101 - 200 of 759 matches
Mail list logo
