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 time the
On Wed, Jun 17, 2009 at 11:47, William Edneybed...@technicalpursuit.com 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:
On Wed, Jun 17, 2009 at 11:47, William Edneybed...@technicalpursuit.com 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:
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
On Tue, Oct 19, 2010 at 09:50, Garrett Smith dhtmlkitc...@gmail.com 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
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 ann...@opera.com 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
On Fri, Oct 22, 2010 at 12:09, Jonas Sicking jo...@sicking.cc 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 olli.pet...@helsinki.fi 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
On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov dglaz...@chromium.org 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
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:javascripttype=cs
erik
On Thu, Sep 15, 2011 at 00:33, Anne van Kesteren ann...@opera.com wrote:
On Tue, Sep 20, 2011 at 19:47, Boris Zbarsky bzbar...@mit.edu 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
table. Semantically
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
x-foo is more readable than div is=foo it is hard to
dglaz...@chromium.org
wrote:
On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson a...@chromium.org 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 (which
On Tue, Oct 18, 2011 at 09:42, Alex Russell slightly...@google.com 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 =
On Thu, Oct 20, 2011 at 04:18, Alex Russell slightly...@google.com 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
On Thu, Oct 20, 2011 at 04:37, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
On 2011-10-20 13:18, Alex Russell wrote:
On Thu, Oct 20, 2011 at 12:05 PM, Lachlan Huntlachlan.h...@lachy.id.au
wrote:
We need NodeList separate from Array where they are live lists.
No we don't. The fact that
On Thu, Oct 20, 2011 at 04:49, Lachlan Hunt lachlan.h...@lachy.id.au 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
On Thu, Oct 20, 2011 at 09:28, Boris Zbarsky bzbar...@mit.edu 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-land; esp. since it's not clear
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 waldron.r...@gmail.com wrote:
From a real-world developer
On Mon, Oct 24, 2011 at 16:46, Tab Atkins Jr. jackalm...@gmail.com 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:
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 problem. A Blob can also be backed by a
on-disk file.
Could you elaborate?
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 dglaz...@chromium.org
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
On Wed, Feb 8, 2012 at 14:10, Adam Barth w...@adambarth.com wrote:
... Do you have a concrete example of
where nested template declarations are required?
When working with tree like structures it is comment to use recursive templates.
On Tue, Apr 24, 2012 at 06:46, Brian Kardell bkard...@gmail.com 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
On Tue, Apr 24, 2012 at 12:00, Scott González scott.gonza...@gmail.com wrote:
Are there other use cases that are trying to be solved with template?
3. Inert. You don't want to fetch resources at unresolved URLs.
img src=/images/${user}.png
4. Selectors should not match content of the template
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 i...@hixie.ch 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%28origq=new%5CsElement%5C.html%5C%28btnG=Search+Trunk
I'm sure you can find a bunch of jQuery usages too.
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
On Tue, Feb 5, 2013 at 5:28 PM, Boris Zbarsky bzbar...@mit.edu 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
On Tue, Feb 5, 2013 at 8:26 PM, Daniel Buchner dan...@mozilla.com 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
On Wed, Feb 6, 2013 at 5:27 AM, Boris Zbarsky bzbar...@mit.edu 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
On Wed, Feb 6, 2013 at 12:47 PM, Scott Miles sjmi...@google.com 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
On Wed, Feb 6, 2013 at 1:38 PM, Scott Miles sjmi...@google.com wrote:
Sorry, replace MyButton.super() with MyButton.super.call(this);
On Wed, Feb 6, 2013 at 10:37 AM, Scott Miles sjmi...@google.com wrote:
So, neglecting issues around the syntax of document.register and the
privatization of
6, 2013 at 11:59 AM, Scott Miles sjmi...@google.com wrote:
On Wed, Feb 6, 2013 at 11:18 AM, Erik Arvidsson a...@chromium.org
wrote:
On Wed, Feb 6, 2013 at 1:38 PM, Scott Miles sjmi...@google.com
wrote:
Sorry, replace MyButton.super() with MyButton.super.call(this);
On Wed, Feb 6, 2013
On Wed, Feb 6, 2013 at 4:27 PM, Daniel Buchner dan...@mozilla.com 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
On Thu, Feb 7, 2013 at 11:51 PM, Scott Miles sjmi...@google.com 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 sjmi...@google.com 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
On Fri, Feb 8, 2013 at 12:18 PM, Scott Miles sjmi...@google.com 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.
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 waldron.r...@gmail.comwrote:
On Thu, Feb 14, 2013 at
, 2013 at 2:21 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Thu, Feb 14, 2013 at 5:15 PM, Erik Arvidsson a...@chromium.orgwrote:
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
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. jackalm...@gmail.com wrote:
On Tue, Feb 26, 2013 at
Inline
On Wed, Mar 6, 2013 at 7:03 PM, Hajime Morrita morr...@google.com 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
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 dglaz...@chromium.org wrote:
On Thu, Mar 7, 2013 at 2:35 PM, Scott Miles
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
to break it down first before we build it up, if that makes any sense.
Scott
On Fri, Mar 8, 2013 at 9:55 AM, Erik Arvidsson
Also, how would you resolve URLs. Can I use base?
On Mar 12, 2013 10:22 PM, Dominic Cooney domin...@google.com wrote:
On Tue, Mar 12, 2013 at 8:13 AM, Dimitri Glazkov dglaz...@google.comwrote:
Hi folks!
Just had a quick discussion with Elliott and he suggested that instead of
building
On Fri, Mar 22, 2013 at 8:42 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Mar 22, 2013 at 6:27 AM, Hajime Morrita morr...@google.com wrote:
So what about (B): Call x-child first and x-parent second? This solves
the unreadified x-child problem.
And you will have a parent that is not
Maybe I'm missing something but we clearly don't want to include
shadowroot 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 sjmi...@google.com
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 Wed, Apr 10, 2013 at 12:05 PM, Erik Arvidsson a...@chromium.org wrote:
Maybe I'm missing
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 a...@chromium.orgwrote:
Once again, how would this work for input/video?
Are you suggesting that `createShadowRoot` behaves
On Wed, Apr 10, 2013 at 4:43 PM, Rick Waldron waldron.r...@gmail.comwrote:
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
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
On Mon, Apr 15, 2013 at 11:05 PM, Dominic Cooney domin...@google.com wrote:
On Thu, Apr 11, 2013 at 5:53 AM, Erik Arvidsson a...@chromium.org 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.
Sorry
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
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 sjmi...@google.com wrote:
As long as there is a way to access the element from the script, I'm
good.
On Wed, May 15,
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
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
On Fri, Dec 6, 2013 at 2:33 AM, Ryosuke Niwa rn...@apple.com 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
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 ann...@annevk.nlwrote:
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
On Tue, Dec 10, 2013 at 11:15 AM, Anne van Kesteren ann...@annevk.nlwrote:
On Tue, Dec 10, 2013 at 4:10 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Nevertheless, it would be unfortunate to use the in-progress nature of
making the web platform more JavaScript-friendly as an
On Thu, Jan 9, 2014 at 10:57 PM, Ryosuke Niwa rn...@apple.com wrote:
1. The parser does not know that it needs to use MyElement.@@create to
create the JS objects when it sees a my-element.
On the other hand, solving this seems to require running some author
scripts at the element creation
All good points. One issue that we should track...
On Thu, Feb 6, 2014 at 5:20 PM, Hajime Morrita morr...@google.com 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
On Thu, Feb 13, 2014 at 9:00 PM, Maciej Stachowiak m...@apple.com wrote:
On Feb 13, 2014, at 4:01 PM, Alex Russell slightly...@google.com wrote:
A closure is an iron-clad isolation mechanism for object ownership with
regards to the closing-over function object. There's absolutely no
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
On Tue, Feb 18, 2014 at 1:35 PM, Dimitri Glazkov dglaz...@google.comwrote:
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
On Tue, Feb 18, 2014 at 5:59 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 18, 2014 at 10:35 AM, Dimitri Glazkov dglaz...@google.com
wrote:
On Fri, Feb 14, 2014 at 3:58 PM, Jonas Sicking jo...@sicking.cc wrote:
What I mean is that for nodes that doesn't have a constructor,
On Thu, Jan 15, 2015 at 1:09 AM, Dmitry Lomov dslo...@chromium.org wrote:
On Thu, Jan 15, 2015 at 5:11 AM, Yehuda Katz wyc...@gmail.com wrote:
On Wed, Jan 14, 2015 at 3:47 PM, Domenic Denicola d...@domenic.me wrote:
Isn't this at least a little future-hostile to things like `new
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
Dare I say ecma-speak?
(Maybe I got stockholm-syndrome?)
On Thu, Jun 11, 2015 at 4:47 PM, Adam Klein ad...@chromium.org wrote:
On Thu, Jun 11, 2015 at 1:32 PM, Dimitri Glazkov dglaz...@google.com
wrote:
Folks,
Many specs nowadays opt for a more imperative method of expressing
normative
72 matches
Mail list logo
