On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov wrote:
> What do you think?
+1
It would surely allow certain use cases to be covered that are not
covered today with form control elements.
How about not throwing on new ShadowTree(element) and just append a
new shadow root after the existing ones?
On Tue, Aug 30, 2011 at 22:33, Dominic Cooney wrote:
> You will notice that this says nothing about how prototypes are wired
> up. It should. Maybe the argument to extend should have an optional
> second field, proto, that specifies the new methods/getters/setters
> that ContactPicker's prototype
I'm also in favor of removing this. This does more harm than good.
Unfortunately I found ~200 uses of this in code search.
http://www.google.com/codesearch#search/&q=%5C.isSameNode%5C(%20lang:javascript&type=cs
erik
On Thu, Sep 15, 2011 at 00:33, Anne van Kesteren wrote:
> On Fri, 09 Se
On Tue, Sep 20, 2011 at 19:47, Boris Zbarsky wrote:
> A comment on use cases that was brought up over here.
>
> There's a use case that is not addressed by XBL1 and impossible to quite
> address in a JS library that goes as follows. Say you have some data in a
> . Semantically it's a data table.
Splitting this up into two different things is great.
Allowing attaching an alternative shadow tree through CSS but
disabling any JS to be run seems like the right thing to do.
I'm also in favor of the "is" attribute. Even though I think that
is more readable than it is hard to argue about
the
>> On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson wrote:
>>> Splitting this up into two different things is great.
>>
>> The specific meaning of "splitting up" is where the things get
>> interesting. As far as I understand Hixie's idea, the component
On Tue, Oct 18, 2011 at 09:42, Alex Russell wrote:
> Ah, but we don't need to care what CSS thinks of our DOM-only API. We
> can live and let live by building on ":scope" and specifying find* as
> syntactic sugar, defined as:
>
> HTMLDocument.prototype.find =
> HTMLElement.prototype.find = funct
On Thu, Oct 20, 2011 at 04:18, Alex Russell wrote:
> No we don't. The fact that there's someone else who has a handle to
> the list and can mutate it underneath you is a documentation issue,
> not a question of type...unless the argument is that the slots should
> be non-configurable, non-writable
On Thu, Oct 20, 2011 at 04:37, Lachlan Hunt wrote:
> On 2011-10-20 13:18, Alex Russell wrote:
>>
>> On Thu, Oct 20, 2011 at 12:05 PM, Lachlan Hunt
>> wrote:
>>>
>>> We need NodeList separate from Array where they are live lists.
>>
>> No we don't. The fact that there's someone else who has a hand
On Thu, Oct 20, 2011 at 04:49, Lachlan Hunt wrote:
> On 2011-10-20 13:35, Sean Hogan wrote:
>>
>> I wonder if anyone is relying on querySelectorAll() returning a
>> StaticNodeList?
>
> Only if there are people out there using list.item(n) instead of list[n], or
> people extending the NodeList inte
On Thu, Oct 20, 2011 at 09:28, Boris Zbarsky wrote:
> On 10/20/11 12:02 PM, Erik Arvidsson wrote:
>>
>> That is an ES violation. A non configurable, non writable data
>> property is not allowed to change its value.
>
> It's not clear what that means in proxy
Yeah, this is easily a win for the web platform. Smaller, more concise
API. I like it.
As Ojan said; Please use rest params here so that there is no need to
create the extra array.
erik
On Mon, Oct 24, 2011 at 16:07, Rick Waldron wrote:
> From a real-world developer perpective, this API
On Mon, Oct 24, 2011 at 16:46, Tab Atkins Jr. wrote:
> Easy. The destructuring stuff proposed for ES lets you easily say things
> like:
>
> function(blobparts..., keywordargs) {
> // blobparts is an array of all but the last arg
> // keywordargs is the last arg
> }
>
> or even:
>
> function(bl
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 also be backed by a
> on-disk file.
>
> Could you elaborate?
I thin
On Mon, Oct 24, 2011 at 19:54, Jonas Sicking wrote:
> Sure. Though you could also just do
>
> var b = new Blob();
> b = new Blob([b, data]);
> b = new Blob([b, moreData]);
That works for me.
--
erik
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033360.html
I'm in favor of making DocumentFragment.prototype.set innerHTML do the above.
erik
On Tue Feb 07 11:41:24 GMT-800 2012, Dimitri Glazkov
wrote:
> The pros are:
> * It's declarative and intuitively logical
I think this is a cons. Now you need both markup and code where you only
had code before.
This also does not scale very well and it brings us down the XBL/HTC path:
On Wed, Feb 8, 2012 at 14:10, Adam Barth wrote:
> ... Do you have a concrete example of
> where nested declarations are required?
When working with tree like structures it is comment to use recursive templates.
http://code.google.com/p/mdv/source/browse/use_cases/tree.html
--
erik
On Tue, Apr 24, 2012 at 06:46, Brian Kardell wrote:
> I know of many, many templating systems and I have simply never (aside
> from MDV) seen it in exactly this light (that is templates actually
> embedded in others), regardless of whether those are for within the
> browser for generating HTML (or
On Tue, Apr 24, 2012 at 12:00, Scott González wrote:
> Are there other use cases that are trying to be solved with ?
3. Inert. You don't want to fetch resources at unresolved URLs.
4. Selectors should not match content of the template
both of these works fine with
My concern with the proposal is that it currently requires libraries
to still do a regexp and special case frameset and html.
We should imply the correct context for all tags in HTML5, not matter
if we like them or not. I think it is important that any valid HTML
with one top level node works and
On Thu, May 10, 2012 at 3:18 PM, Ian Hickson wrote:
> Yes, I understand that. But what's the use case?
http://code.google.com/p/dart/source/search?q=new%5CsElement%5C.html%5C%28&origq=new%5CsElement%5C.html%5C%28&btnG=Search+Trunk
I'm sure you can find a bunch of jQuery usages too.
--
erik
addShadowRoot seem wrong to me to. Usually add* methods takes an
argument of something that is supposed to be added to the context
object.
If we are going with a factory function I think that createShadowRoot
is the right name even though create methods have a lot of bad history
in the DOM APIs.
The way document.register is currently proposed makes it
future-hostile to ES6. I've heard several people from different
organizations say that this is a blocking issue.
Over the last couple of days we (me, Dimitri and others) have worked
on some alterations to the current spec proposal. The discu
On Tue, Feb 5, 2013 at 5:28 PM, Boris Zbarsky wrote:
> So in particular this allows creation of "uninitialized" instances in some
> sense, yes?
Depends how much logic is put in the constructor vs @@create. For DOM
Elements I think we want to put *all* the logic in create. @@create
does not allow
On Tue, Feb 5, 2013 at 8:26 PM, Daniel Buchner wrote:
> I have two questions:
>
> Does this affect our ability to polyfill doc.register in current browsers?
Good point. This is really important to us as well so we most likely
need to tweak this to make sure it will work.
Do we need to be able to
On Wed, Feb 6, 2013 at 5:27 AM, Boris Zbarsky wrote:
> Note that I'm still checking how feasible this is in SpiderMonkey on any
> sort of finite timeframe, if we do decide to do this. Functions right now
> don't have a [[Construct]] member in spidermonkey that's stored on a
> function directly; i
On Wed, Feb 6, 2013 at 12:47 PM, Scott Miles wrote:
>>> Instead of passing in functions to document.register we can call methods
>>> on the custom element.
>
> My understanding is that the 'passing in functions' was a design decision,
> not a technical one. IOW, Dimitri spec'd it that way so these
On Wed, Feb 6, 2013 at 1:38 PM, Scott Miles wrote:
> Sorry, replace MyButton.super() with MyButton.super.call(this);
>
>
> On Wed, Feb 6, 2013 at 10:37 AM, Scott Miles wrote:
>>
>> So, neglecting issues around the syntax of document.register and the
>> privatization of callbacks, is it fair to sa
:01 PM, Scott Miles wrote:
>>>>
>>>> Errata:
>>>> makePrototypeTwiddlingConstructorForDomNodes needs to know the extendee
>>>>
>>>> var ctor = makePrototypeTwiddlingConstructorForDomNodes(inExtends,
>>>> inClass);
On Wed, Feb 6, 2013 at 4:27 PM, Daniel Buchner wrote:
> So you're directly setting the user-added methods on matched elements in
> browsers that don't support proto, but what about accessors?
>
> If we modified the spec (as previously suggested) to take an *unbaked*
> prototype object, we could po
rnative would be to introduce another method, something like
> 'document.extendElement'. Usage would be like so:
>
> MyButton = function() { ... };
> MyButton.prototype = { ... };
> MyButton = document.extendElement('button', MyButton);
> document.regist
On Thu, Feb 7, 2013 at 11:51 PM, Scott Miles wrote:
> P.P.S. Arv, do you have a preference from my three versions (or none of the
> above)?
I prefer number 2. This is what we want for ES6 anyway. Both 1 and 3
makes me have to repeat myself.
--
erik
On Fri, Feb 8, 2013 at 11:54 AM, Scott Miles wrote:
> The idea is supposed to be that 1 and 3 are only stopgaps until we get 'what
> we want'. In the future when you can derive a DOM element directly, both
> bits of extra code can fall away. Was that clear? Does it change anything in
> your mind?
On Fri, Feb 8, 2013 at 12:18 PM, Scott Miles wrote:
> Sorry, I'm not quite following.
>
> 1. We cannot really extends anything else but
> HTMLElement/HTMLUnknownElement.
> 2. We cannot return the correct function object from document.register.
>
> I don't see why these are true?
1. Because an ele
#x27;s that you cannot extend DOM
> 'classes' with JS. That's what's driving all of this, and afaik, affects
> native implementations just as much as shims. Probably I should have
> separated this from the 'class' question more clearly, but my goal was to
> reach
Yeah, this post does not really talk about syntax. It comes after a
discussion how we could use ES6 class syntax.
The ES6 classes have the same semantics as provided in this thread using
ES5.
On Thu, Feb 14, 2013 at 5:10 PM, Rick Waldron wrote:
>
> On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazko
prototype,
>>> lifecycle: {
>>> created: MyButton
>>> }
>>> });
>>>
>>> What's the benefit of allowing this syntax? I don't immediately see why
>>> you couldn't just do it the other way.
>>>
>>>
On Wed, Feb 20, 2013 at 11:36 PM, Jonas Sicking wrote:
> On Feb 19, 2013 3:54 PM, "Dimitri Glazkov" wrote:
>> 2) Custom element constructor runs at the time of parsing HTML, as the
>> tree is constructed.
>>
>> PROBLEM: Several implementers let me know that allowing to run JS
>> while parsing HTM
Also, if shadows are public by default the API to access the shadow is well
defined. If shadows are private by default and components decide to expose
the shadow ad hoc then there is no standardized API.
On Feb 26, 2013 1:59 PM, "Tab Atkins Jr." wrote:
> On Tue, Feb 26, 2013 at 10:44 AM, Dominic
Inline
On Wed, Mar 6, 2013 at 7:03 PM, Hajime Morrita wrote:
> One consequence is that it will become harder to cache (including negative
> cache) these values. We need to traverse the prototype chain in C++, which
> is typically slower than doing it in JS, on every lifecycle event. Or we
> need
If you have a tag name it is easy to get the prototype.
var tmp = elementElement.ownerDocument.createElement(tagName);
var prototype = Object.getPrototypeOf(tmp);
On Fri, Mar 8, 2013 at 12:16 PM, Dimitri Glazkov wrote:
> On Thu, Mar 7, 2013 at 2:35 PM, Scott Miles wrote:
>> Currently, if I docu
hen why not make the
>> imperative form convenient? If it's important to be able to do your own
>> prototype marshaling, then won't this feature be missed in declarative form?
>>
>> I'm wary of defanging the declarative form completely. But I guess I want
>
Also, how would you resolve URLs. Can I use ?
On Mar 12, 2013 10:22 PM, "Dominic Cooney" wrote:
> On Tue, Mar 12, 2013 at 8:13 AM, Dimitri Glazkov wrote:
>
>> Hi folks!
>>
>> Just had a quick discussion with Elliott and he suggested that instead of
>> building full-blown Documents, the just make
On Fri, Mar 22, 2013 at 8:42 AM, Anne van Kesteren wrote:
> On Fri, Mar 22, 2013 at 6:27 AM, Hajime Morrita wrote:
>> So what about (B): Call first and second? This solves
>> the "unreadified " problem.
>
> And you will have a parent that is not ready.
>
> Or if you have
>
>
>
> you'll either
Maybe I'm missing something but we clearly don't want to include
in the general innerHTML getter case. If I implement
input[type=range] using custom elements + shadow DOM I don't want innerHTML
to show the internal guts.
On Wed, Apr 10, 2013 at 2:30 PM, Scott Miles wrote:
> I don't see any rea
st on a node unless you hadn't
> specifically put it there (as opposed to Shadow DOM intrinsic to a
> particular element type).
>
> With this inner/outer rule, all serialization cases I can think of work in
> a sane fashion, no lossiness.
>
> Scott
>
>
>
> On W
>> non-intrinsic Shadow DOM, but my rule of thumb is this: 'node.outerHTML'
>> should produce markup that parses back into 'node' (assuming all
>> dependencies exist).
>>
>>
>> On Wed, Apr 10, 2013 at 12:15 PM, Erik Arvidsson wrote:
>>
>>>
On Wed, Apr 10, 2013 at 4:43 PM, Rick Waldron wrote:
> A bigger issue with proposal is that the global object appears to be the
> element's instance object itself, which isn't going to work
>
+1
I'm not sure that `this` was supposed to be the [[Global]] object? But
agree with you, this is someth
Hi Allen,
Fortunately the state of this is pretty close to what you are suggesting.
We started of with the imperative solution and then went to look at a
declarative version. At this point, the discussion got a bit side tracked.
Lets back up and see what we have for the imperative version:
class
ES6 defines class side inheritance. We should update WebIDL to do the same
to align them.
On Thu, Apr 11, 2013 at 12:50 PM, Allen Wirfs-Brock
wrote:
>
> On Apr 11, 2013, at 9:32 AM, Boris Zbarsky wrote:
>
> > On 4/11/13 12:23 PM, Allen Wirfs-Brock wrote:
> >> So why don't you make "register" a st
On Mon, Apr 15, 2013 at 11:05 PM, Dominic Cooney wrote:
> On Thu, Apr 11, 2013 at 5:53 AM, Erik Arvidsson wrote:
>>
>> For the record I'm opposed to what you are proposoing. I don't like that
>> you lose the symmetry between innerHTML and outerHTML.
>
>
>
The thing about reprojection is that it makes implementers life harder
but it makes developers life easy. I'd rather have us do the hard work
here.
For the record, we have two independent implementations of the Shadow
DOM spec so that should debunk some of the myths that this is too hard
to implem
Walking the ancestors from document.currentScript is a start. Is that
sufficient or should we add a document.currentElement?
On Wed, May 15, 2013 at 2:34 PM, Scott Miles wrote:
> As long as there is a way to access the from the
There seems to be some idea that HTML imports are supposed to do
everything. The primary use case for HTML imports is a way to import DOM
trees. Since HTML already have ways to embed CSS and script, HTML imports
can act as a container format. But do not let perfect be the enemy of good.
Lets not tr
The custom element draft does add a new synchronization point. After
setting innerHTML (for example), before returning to the script the
callbacks for the custom elements created by innerHTML are called in tree
order.
This does lead to the possibility to observer objects that have not yet had
thei
On Fri, Dec 6, 2013 at 2:33 AM, Ryosuke Niwa wrote:
> It appears to me that we should definitely have a good answer for this
> question before the specification reaches CR
> given that the definition of ES6 classes is pretty stable at this point.
ES6 classes do not introduce any new semantics o
Better APIs are better.
What I think you (and Ryosuke) are trying to do is bundling. If shadow dom
works without custom elements it should be its own spec. If template
element works without shadow dom it should be its own spec. If custom
elements work without shadow dom and templates don't bundle
On Tue, Dec 10, 2013 at 10:34 AM, Anne van Kesteren wrote:
> I think Ryosuke has a point here though. ES6 brings subclassing to the
> platform, but are not even close to reimagining the platform in terms
> of that.
ES6 does not bring sub classing to the table. It has been there all along
(since
On Tue, Dec 10, 2013 at 11:15 AM, Anne van Kesteren wrote:
> On Tue, Dec 10, 2013 at 4:10 PM, Domenic Denicola
> wrote:
> > Nevertheless, it would be unfortunate to use the in-progress nature of
> making the web platform more JavaScript-friendly as an argument for making
> it more JavaScript host
On Thu, Jan 9, 2014 at 10:57 PM, Ryosuke Niwa wrote:
> > 1. The parser does not know that it needs to use MyElement.@@create to
> create the JS objects when it sees a .
>
> On the other hand, solving this seems to require running some author
> scripts at the element creation time, at some later t
All good points. One issue that we should track...
On Thu, Feb 6, 2014 at 5:20 PM, Hajime Morrita wrote:
> This seems related to discussion around selection [1].
>
> My claim there was that the selection shouldn't cross shadow boundary, at
> least from the boundary crossing shouldn't be visible s
On Thu, Feb 13, 2014 at 9:00 PM, Maciej Stachowiak wrote:
>
> On Feb 13, 2014, at 4:01 PM, Alex Russell wrote:
>
> A closure is an iron-clad isolation mechanism for object ownership with
> regards to the closing-over function object. There's absolutely no
> iteration of the closed-over state of
Another alternative is to disallow DOM traversal and DOM mutation inside
these constructors. By disallow I mean throw an error! Here is a rough
outline of what the algorithm might look like.
Let there be a global counter CostomElementConstructionCounter which is
initially set to 0.
1. Parse and b
On Tue, Feb 18, 2014 at 1:35 PM, Dimitri Glazkov wrote:
> Here's an alternative proposal:
>
> 1) The Web developers are already aware of the fact that you can create
> new instances of JS objects without running their constructors with
> Object.create
>
These are not the instances you are looking
On Tue, Feb 18, 2014 at 5:59 PM, Jonas Sicking wrote:
> On Tue, Feb 18, 2014 at 10:35 AM, Dimitri Glazkov
> wrote:
> >
> >
> >
> > On Fri, Feb 14, 2014 at 3:58 PM, Jonas Sicking wrote:
> >>
> >>
> >> What I mean is that for nodes that doesn't have a constructor, and
> >> whose parent doesn't ha
In ES6 the constructor does both allocation and initialization. At
upgrade time it is too late to do allocation so we cannot call the
constructor at that time. We would need a callback for this, call it
upgradeCallback for example.
When the parser sees a custom element (any element with a dash in
On Wed, Jan 14, 2015 at 9:53 AM, Boris Zbarsky wrote:
> On 1/14/15 9:45 AM, Anne van Kesteren wrote:
>> * Parsing of declarative syntax invokes the registered constructor
>> synchronously.
>
>
> I would like to understand what this means, exactly. For example, what is
> the proposed behavior of d
On Wed, Jan 14, 2015 at 12:31 PM, Anne van Kesteren wrote:
> On Wed, Jan 14, 2015 at 4:28 PM, Erik Arvidsson wrote:
>> I don't see why it has to be done synchronously? We can do what we do
>> it today and do it synchronously-ish, that is before any user script
>> (s
On Thu, Jan 15, 2015 at 1:09 AM, Dmitry Lomov wrote:
>
>
> On Thu, Jan 15, 2015 at 5:11 AM, Yehuda Katz wrote:
>>
>> On Wed, Jan 14, 2015 at 3:47 PM, Domenic Denicola wrote:
>>
>> Isn't this at least a little future-hostile to things like `new
>> MyElement(attrs)`? Is there a way we could get ba
Dare I say ecma-speak?
(Maybe I got stockholm-syndrome?)
On Thu, Jun 11, 2015 at 4:47 PM, Adam Klein wrote:
> On Thu, Jun 11, 2015 at 1:32 PM, Dimitri Glazkov
> wrote:
>>
>> Folks,
>>
>> Many specs nowadays opt for a more imperative method of expressing
>> normative requirements, and using algo
When DOM was first spec'ed the collection interfaces all had some kind
of item method. These methods sometimes return like null[1] and
sometimes other values such as an empty string [2]. The JavaScript
bindings for these allows us to use indexed getters instead of calling
the item method.
The prob
On Tue, Oct 19, 2010 at 09:50, Garrett Smith wrote:
...
> CSSStyleDeclaration. What about the other "collection" objects? HTML5
> says that collections are now callable and specifies that "indexed"
> property access on collections returns null. But what about other APIs
> such as NodeList, NamedNo
The forminput and formchange events are dispatched on all resettable
elements in a form when any element associated with the form
dispatches an input or a change event.
Is this case really worth the cost of increasing the size of the API
when it can easily be achieved with capturing events?
erik
On Oct 22, 2010 2:00 AM, "Anne van Kesteren" wrote:
> Yeah, I don't mind moving these features to libraries. Anyone implemented
> them apart from Opera?
Neither WebKit nor Gecko implements it:
https://bugs.webkit.org/show_bug.cgi?id=26141
https://bugzilla.mozilla.org/show_bug.cgi?id=605997
IE9 b
On Fri, Oct 22, 2010 at 12:09, Jonas Sicking wrote:
> This means that we should also remove
> dispatchFormInput/dispatchFormChange from the HTML5 spec, right?
That was my intention and the subject hints at that. Sorry for not
including it in the body as well.
--
erik
On Wed, Apr 27, 2011 at 08:33, Olli Pettay wrote:
> Not sure why this had some relation with XBL. Unless you are
> planning to put the template based DOM nodes to anonymous DOM.
The relation to XBL is that XBL has a template element and inside it
you can "bind" attributes and content to the host
Forwarded from whatwg upon Ian's request.
Forwarded conversation
Subject: Exposing EventTarget to JavaScript
From: *Erik Arvidsson*
Date: Fri, Apr 24, 2009 at 10:00
To: whatwg
Almost all JavaScript libraries and web apps of moderate size end up
reimplementing e
The HTML5 spec says to fire the input event when the user changes a radio
button or a checkbox. However, the spec says "When the input event applies,
any time the user causes the element's *value* to change". For
input[type="radio"] and input[type="checkbox"] the input event should be
fired any tim
On Wed, Jun 17, 2009 at 11:47, William Edney wrote:
> Folks -
> Not sure this is relevant, but I'm tracking/contributing to the following
> two bugs around 'resize' events:
> One for Mozilla:
> https://bugzilla.mozilla.org/show_bug.cgi?id=227495
> and one for Webkit:
> https://bugs.webkit.org/show_
On Wed, Jun 17, 2009 at 11:47, William Edney wrote:
> Folks -
> Not sure this is relevant, but I'm tracking/contributing to the following
> two bugs around 'resize' events:
> One for Mozilla:
> https://bugzilla.mozilla.org/show_bug.cgi?id=227495
> and one for Webkit:
> https://bugs.webkit.org/show_
81 matches
Mail list logo
