Dimitri: Okay, I can follow up with Ryosuke. I’m happy to share our thoughts
and needs for subclassing components.
Anne/Steve: I’d originally indicated that this technique couldn't be applied to
extending native HTML elements. Since the two of your seemed interested in
that, I spent some time
Ryosuke, Jan,
It might be useful for you two folks to work through Jan's Shadow DOM
composition/inheritance insight (use cases?) together and see how they
could be resolved without having multiple shadow roots per element. I would
love to take advantage of all the work you both have done thinking
On Thu, Feb 12, 2015 at 11:33 AM, Steve Faulkner
faulkner.st...@gmail.com wrote:
this turned up today:
A possible solution for web component subclasses
https://github.com/JanMiksovsky/base-template#a-possible-solution-for-web-component-subclasses
needs people who actually understand this
this turned up today:
A possible solution for web component subclasses
https://github.com/JanMiksovsky/base-template#a-possible-solution-for-web-component-subclasses
needs people who actually understand this stuff to critique ;-)
--
Regards
SteveF
HTML 5.1
On 12 February 2015 at 10:58, Anne van Kesteren ann...@annevk.nl wrote:
which is a very different problem from what you want to solve, no?
The problem I think needs solving for minimum viable custom elements is
reducing reliance on bolt-on accessibility. From the example provided
On Feb 12, 2015, at 4:50 AM, Steve Faulkner faulkner.st...@gmail.com wrote:
On 12 February 2015 at 10:58, Anne van Kesteren ann...@annevk.nl
mailto:ann...@annevk.nl wrote:
which is a very different problem from what you want to solve, no?
The problem I think needs solving for minimum
As an example I made a simple input-based Custom Element which prevents
alphabetic input, and dropped it in an very simple Ember app.
Here's the version with a subclassed input:
http://jsbin.com/mevemu/1/edit?html,output
And the version with an input nested in a custom element:
Thanks for the mentioning the Ember issue Chris :) I've filed it here:
https://github.com/tildeio/htmlbars/issues/288
On Thu, Feb 5, 2015 at 7:13 AM, Chris Bateman chrisb...@gmail.com wrote:
As an example I made a simple input-based Custom Element which prevents
alphabetic input, and dropped it
On Feb 4, 2015, at 7:59 AM, Domenic Denicola d...@domenic.me wrote:
In IRC Anne and I were briefly discussing how type= is the is= of Web
Applications 1.0. That is, input type=date is similar to img is=x-gif
or similar---it has a reasonable fallback behavior, but in reality it is a
Yeah, I had noted in that post that wrapping a native element with a custom
element was an option - only drawback is that the markup isn't as terse (which
is generally advertised as one of the selling points of Custom Elements). But
that doesn't seem like a deal breaker to me, if subclassing
On 4 February 2015 at 16:51, Ryosuke Niwa rn...@apple.com wrote:
my-custom-formatterinput/my-custom-formatter
I think if this worked. i.e. hid the styling and allowed styling over top,
while allowing access to the input functionality would be a good solution
for the many many instances of
See https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0435.html
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0435.html
first.
On Feb 4, 2015, at 6:43 AM, Chris Bateman chrisb...@gmail.com wrote:
Assuming a situation where a native element – with custom
On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com wrote:
On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com wrote:
On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com wrote:
On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com
wrote:
So a web page author would write
x-slider min=-100 ... etc.
and then the custom element would sprout an input type=range ...etc
with the attribute values copied across? Then the web page author knows
nothing about the input element, so if they want to programmatically the
value of the custom
On Feb 4, 2015, at 11:26 AM, Alice Boxhall aboxh...@google.com wrote:
So a web page author would write
x-slider min=-100 ... etc.
and then the custom element would sprout an input type=range ...etc with
the attribute values copied across?
No. The page author would write x-sliderinput
On Feb 4, 2015, at 10:54 AM, Alice Boxhall aboxh...@google.com wrote:
On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com
mailto:rn...@apple.com wrote:
On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com
mailto:bkard...@gmail.com wrote:
On Wed, Feb 4, 2015 at
On Feb 4, 2015, at 11:11 AM, Chris Bateman chrisb...@gmail.com wrote:
Ugh, I forgot about that. Without subclassing - terseness is a very minor
drawback, but remapping the interface is a big pain.
Could you give us a concrete use case in which remapping the interface is
necessary or
On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com wrote:
Yeah, I had noted in that post that wrapping a native element with a
custom element was an option - only drawback is that the markup isn't as
terse (which is generally advertised as one of the selling points of Custom
On Feb 4, 2015, at 9:05 AM, Steve Faulkner faulkner.st...@gmail.com wrote:
On 4 February 2015 at 16:51, Ryosuke Niwa rn...@apple.com
mailto:rn...@apple.com wrote:
my-custom-formatterinput/my-custom-formatter
I think if this worked. i.e. hid the styling and allowed styling over top,
On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell bkard...@gmail.com wrote:
On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com wrote:
On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com wrote:
On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com wrote:
On
On 4 February 2015 at 19:05, Alice Boxhall aboxh...@google.com wrote:
So then how do we treat it as fallback content i.e. un-rendered, while
allowing it to be accessible to to the AT layer?
I suggest as in the working canvas example i provided, it not only be
exposed AT but also to keyboard
On Feb 4, 2015, at 11:05 AM, Alice Boxhall aboxh...@google.com wrote:
On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell bkard...@gmail.com
mailto:bkard...@gmail.com wrote:
On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com
mailto:aboxh...@google.com wrote:
On Wed, Feb 4,
Ugh, I forgot about that. Without subclassing - terseness is a very minor
drawback, but remapping the interface is a big pain.
On Wed, Feb 4, 2015 at 1:01 PM, Brian Kardell bkard...@gmail.com wrote:
On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com wrote:
On Wed, Feb 4, 2015
Assuming a situation where a native element – with custom functionality –
is dynamically injected into the page, the basic options I can think of are:
- input is=my-custom-formatter
- input class=my-custom-formatter and a page-level listener
- input class=my-custom-formatter and call a
On Wed, Feb 4, 2015 at 3:43 PM, Chris Bateman chrisb...@gmail.com wrote:
An better example of both A and B (than my previous hypothetical) might be
GitHub's time is=relative-time extension:
https://github.com/github/time-elements/.
FWIW, I do want subclassing of builtins to work. Maybe not
I hope others can address the question of why custom element callbacks are
useful, and meet the bar of being a feature we should add to the web platform
(with all the UA-coordination that requires). I just wanted to interject into
this input discussion.
In IRC Anne and I were briefly
Why don't we just make all input elements support these new attributes
we're adding?
In my opinion, I'd say because you can't possibly cover every case - what
about doing the same kind of formatting for social security numbers, credit
card numbers, phone numbers, or who knows what else? How
On Feb 3, 2015, at 7:13 AM, Chris Bateman chrisb...@gmail.com wrote:
Why don't we just make all input elements support these new attributes we're
adding?
In my opinion, I'd say because you can't possibly cover every case - what
about doing the same kind of formatting for social
On Sat, Jan 31, 2015 at 10:41 PM, Elliott Sprehn espr...@chromium.org wrote:
The animation is a custom element called paper-ripple, where do you see it
using -webkit-tap-highlight-color?
The initial page uses that. Ryosuke's reply to this particular demo is
a lot more on topic. It's not using
On Sat, Jan 31, 2015 at 7:40 PM, Chris Bateman chrisb...@gmail.com wrote:
The -webkit-appreance CSS is definitely another issue, so here's an example
with just JS behavior:
input is=number-input decimals=2
The way to do this, FWIW, is input type=number step=0.01 and solve
the styling issue.
On Jan 31, 2015, at 10:40 AM, Chris Bateman chrisb...@gmail.com wrote:
The -webkit-appreance CSS is definitely another issue, so here's an example
with just JS behavior:
input is=number-input decimals=2
This component would only allow numeric input, and insert decimals, commas,
etc.
On Sat, Jan 31, 2015 at 5:58 AM, fantasai fantasai.li...@inkedblade.net wrote:
-webkit-appearance: none isn't a proprietary extension, it's a prefixed
version of something that was once in a standards-track document. It
got removed because there were serious design problems with the original
On Sat, Jan 31, 2015 at 8:25 AM, Tantek Çelik tan...@cs.stanford.edu wrote:
I'm tracking the state of requests for 'appearance' here:
https://wiki.csswg.org/spec/css4-ui#appearance
Feel free to directly edit that wiki page and add more concrete data /
research that you think will help make a
On Fri, Jan 30, 2015 at 7:22 PM, Alice Boxhall aboxh...@google.com wrote:
Sure, that works for this example (which was created in a huge rush at the
last minute before a talk, like probably 90% of my productive work), but I
don't believe it wouldn't work for
On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner
faulkner.st...@gmail.com wrote:
In this radio and checkbox example (view in chrome)
https://rawgit.com/alice/web-components-demos/master/index.html
(which has been referenced several times in this thread, but no one has
critiqued to my
On Jan 30, 2015, at 10:22 AM, Alice Boxhall aboxh...@google.com wrote:
On Fri, Jan 30, 2015 at 8:46 AM, Anne van Kesteren ann...@annevk.nl
mailto:ann...@annevk.nl wrote:
On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner
faulkner.st...@gmail.com mailto:faulkner.st...@gmail.com wrote:
In
On 01/30/2015 07:54 PM, Ryosuke Niwa wrote:
On Jan 30, 2015, at 10:22 AM, Alice Boxhall aboxh...@google.com
mailto:aboxh...@google.com wrote:
The only way it overcomes that is by relying on a proprietary
extension called -webkit-appearance that is not standardized and does
not
I'm tracking the state of requests for 'appearance' here:
https://wiki.csswg.org/spec/css4-ui#appearance
Feel free to directly edit that wiki page and add more concrete data /
research that you think will help make a decision in terms of design
etc.
For now, there is insufficient data to show
On 29 January 2015 at 19:48, Ryosuke Niwa rn...@apple.com wrote:
And we have a proposal to do both of these things: decorators [1]
yes, indeed. What is the status of decorators? Last I looked, it had
been removed from the web components umbrella, so I thought it had
been sent to a farm upstate,
Anne wrote:
but do you see a viable way to get there?
I don't have enough technical understanding to know what is viable or not,
you and others are saying that the current accessibility feature support
baked in to custom elements spec via is= is not acceptable
To recap
What is= provides:
A
On 29 January 2015 at 14:54, Steve Faulkner faulkner.st...@gmail.com wrote:
I think being able to extend existing elements has potential value to
developers far beyond accessibility (it just so happens that accessibility
is helped a lot by re-use of existing HTML features.)
I agree with
One additional point, unrelated to accessibility: is also enables
piggybacking to special parser behavior of existing elements. For example,
I can extend template or link.
Here are some examples:
http://jsbin.com/xuheb/3/edit?html,output
On Thu, Jan 29, 2015 at 3:54 PM, Steve Faulkner
faulkner.st...@gmail.com wrote:
I don't have enough technical understanding to know what is viable or not,
you and others are saying that the current accessibility feature support
baked in to custom elements spec via is= is not acceptable
That
I don't have enough technical understanding to know what is viable or not,
you and others are saying that the current accessibility feature support
baked in to custom elements spec via is= is not acceptable
That seems rather disingenuous.
where am I being disingenuous?
I don't
On Fri, Jan 30, 2015 at 3:52 AM, Brian Kardell bkard...@gmail.com wrote:
On Thu, Jan 29, 2015 at 10:33 AM, Bruce Lawson bru...@opera.com wrote:
On 29 January 2015 at 14:54, Steve Faulkner faulkner.st...@gmail.com
wrote:
I think being able to extend existing elements has potential value to
On Thu, Jan 29, 2015 at 1:50 PM, Elliott Sprehn espr...@chromium.org
wrote:
On Fri, Jan 30, 2015 at 3:52 AM, Brian Kardell bkard...@gmail.com wrote:
On Thu, Jan 29, 2015 at 10:33 AM, Bruce Lawson bru...@opera.com wrote:
On 29 January 2015 at 14:54, Steve Faulkner faulkner.st...@gmail.com
On 29 January 2015 at 19:09, Brian Kardell bkard...@gmail.com wrote:
composition actually seems to let you express something equally good without
ambiguity more easily except insofar as giving you a really first-class
fallback option if you don't support JS, but... I'm having a really hard
On Jan 29, 2015, at 7:52 AM, Steve Faulkner faulkner.st...@gmail.com wrote:
On 29 January 2015 at 15:37, Anne van Kesteren ann...@annevk.nl
mailto:ann...@annevk.nl wrote:
I don't have enough technical understanding to know what is viable or not,
you and others are saying that the current
On Thu, Jan 29, 2015 at 2:43 PM, Bruce Lawson bru...@opera.com wrote:
[snip]
a really first-class fallback option if you don't support JS is
vital for the quarter of a billion people who use Opera Mini and the
100 million people who use the Nokia proxy browser. Fallback rather
than
On Fri, Jan 16, 2015 at 8:06 PM, Domenic Denicola d...@domenic.me wrote:
From: Ryosuke Niwa [mailto:rn...@apple.com]
However, nobody has suggested a design that satisfies both of our
requirements: using ES6 constructor for element initialization
Could you say more about why this is a
On Jan 16, 2015, at 4:07 PM, Dimitri Glazkov dglaz...@google.com wrote:
On Fri, Jan 16, 2015 at 1:14 PM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 15, 2015, at 7:25 PM, Dimitri Glazkov dglaz...@google.com wrote:
On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa rn...@apple.com wrote:
When an
hi ted,
I think others have responded to your question, but wanted to chip in.
I agree that for non interactive elements the usefulness of type extensions
is limited, but not useless.
For example: An experiment subclassing footer [5] and one implementing the
HTML5 outline algorithm [6]
There has
On 16 January 2015 at 10:25, Steve Faulkner faulkner.st...@gmail.com
wrote:
https://rawgit.com/alice/web-components-demos/master/index.html
apologies, this demo needs chrome to illustrate it working well.
--
Regards
SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
On Fri, Jan 16, 2015 at 11:25 AM, Steve Faulkner
faulkner.st...@gmail.com wrote:
With custom tags everything must be bolted on, with type extensions this is
not the case.
I don't disagree with this, but is= solves none of the problems of
why developers moved away from native elements in the
On Thu, Jan 15, 2015 at 8:18 PM, Dimitri Glazkov dglaz...@google.com wrote:
Why is Not having identity at creation-time is currently a mismatch with
the rest of the platform a problem? Why does it all have to be consistent
across the board? Are there any other platform objects that are created
Hi Anne,
I have not suggested is= as the method that must be implemented (I have not
demanded anything), what I have tried to suggest is that minimum viable
custom elements with all accessibility as bolt-on is a poor solution by
design. From an acc view it means custom elements are nothing more
On Fri, Jan 16, 2015 at 2:29 AM, Ryosuke Niwa rn...@apple.com wrote:
And I'm suggesting to do the same (picking the simplest design) in HTML
custom elements by only supporting synchronous definition of elements, and
letting authors and frameworks decide how to upgrade existing elements if
On Jan 16, 2015, at 9:58 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Jan 16, 2015 at 2:29 AM, Ryosuke Niwa rn...@apple.com wrote:
And I'm suggesting to do the same (picking the simplest design) in HTML
custom elements by only supporting synchronous definition of elements, and
From: Ryosuke Niwa [mailto:rn...@apple.com]
However, nobody has suggested a design that satisfies both of our
requirements: using ES6 constructor for element initialization
Hi Ryosuke,
Could you say more about why this is a requirement? In particular, why you
require that developers type
On Jan 15, 2015, at 7:25 PM, Dimitri Glazkov dglaz...@google.com wrote:
On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa rn...@apple.com
mailto:rn...@apple.com wrote:
When an author imports a ES6 module, we don't create a fake object which gets
resolved later by rewriting its prototype.
On Fri, Jan 16, 2015 at 1:14 PM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 15, 2015, at 7:25 PM, Dimitri Glazkov dglaz...@google.com wrote:
On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa rn...@apple.com wrote:
When an author imports a ES6 module, we don't create a fake object which
gets
No argument that callbacks are also a useful new addition.
:DG
On Wed, Jan 14, 2015 at 9:25 PM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 14, 2015, at 6:45 AM, Anne van Kesteren ann...@annevk.nl wrote:
* Existing lifecycle callbacks plus those agreed (copying, adopting).
Could you give us pointers for a proposed definition of these two callbacks
if
Anne, maybe you could write on the wiki what the current Web Components
implementation in Chrome is using. That would make it a bit easier to
follow for people who didn't follow all of the discussion so far.
Kenneth
On Thu Jan 15 2015 at 5:05:35 PM Anne van Kesteren ann...@annevk.nl wrote:
On
On Wed, Jan 14, 2015 at 9:52 PM, Dimitri Glazkov dglaz...@google.com wrote:
FWIW, I think that element upgrade is sort of fundamental to the usefulness
of custom elements. In a world where most scripts are non-blocking (that's
hopefully the modern world we should aim for), I'll effectively
On Thu, Jan 15, 2015 at 5:12 PM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.com wrote:
Anne, maybe you could write on the wiki what the current Web Components
implementation in Chrome is using. That would make it a bit easier to follow
for people who didn't follow all of the
Thanks, this is very useful!
On Thu Jan 15 2015 at 5:40:02 PM Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Jan 15, 2015 at 5:12 PM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.com wrote:
Anne, maybe you could write on the wiki what the current Web Components
implementation
From: Dimitri Glazkov [mailto:dglaz...@google.com]
Why is Not having identity at creation-time is currently a mismatch with the
rest of the platform a problem? Why does it all have to be consistent across
the board? Are there any other platform objects that are created by HTML
parser or a
On Thu, Jan 15, 2015 at 12:27 PM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 15, 2015, at 11:47 AM, Brian Kardell bkard...@gmail.com wrote:
Not to sidetrack the discussion but Steve Faulker made what I think was a
valid observation and I haven't seen a response... Did I miss it?
When and in
On Thu, Jan 15, 2015 at 8:03 AM, Anne van Kesteren ann...@annevk.nl wrote:
* I think we could iterate towards a v2 that has an aspect of
upgrading but perhaps works a bit differently from the current setup.
E.g. a way to include an entire subtree of custom elements with a
fallback mechanism
From: Ryosuke Niwa [mailto:rn...@apple.com]
Unfortunately for developers, native syntax for inheritance in Stink 2.0
cannot be used to subclass views in Odour.
The native syntax for inheritance can definitely be used! You just can't
override the constructor, since constructing a view is a
, focus support, reaction to the presence/absence
of the disabled attribute, etc.
-Original Message-
From: Edward O'Connor [mailto:eocon...@apple.com]
Sent: Thursday, January 15, 2015 18:33
To: WebApps WG
Subject: Re: Minimum viable custom elements
Hi all,
Steve wrote:
[I]t also does
Hi all,
Steve wrote:
[I]t also does not address subclassing normal elements. Again, while
that seems desirable
Given that subclassing normal elements is the easiest and most robust
method (for developers) of implementing semantics[1] and interaction
support necessary for accessibility I
On Jan 15, 2015, at 11:28 AM, Domenic Denicola d...@domenic.me wrote:
From: Dimitri Glazkov [mailto:dglaz...@google.com]
Why is Not having identity at creation-time is currently a mismatch with
the rest of the platform a problem? Why does it all have to be consistent
across the board?
Not to sidetrack the discussion but Steve Faulker made what I think was a
valid observation and I haven't seen a response... Did I miss it?
Subject: Re: Minimum viable custom elements
Hi all,
Steve wrote:
[I]t also does not address subclassing normal elements. Again, while
that seems desirable
Given that subclassing normal elements is the easiest and most robust
method (for developers) of implementing semantics[1
On Jan 15, 2015, at 3:17 PM, Domenic Denicola d...@domenic.me wrote:
From: Ryosuke Niwa [mailto:rn...@apple.com]
If ES6 classes' constructor doesn't fundamentally work with custom elements,
then why don't we change the design of ES6 classes.
We would essentially be saying that the
On Jan 14, 2015, at 12:52 PM, Dimitri Glazkov dglaz...@google.com wrote:
FWIW, I think that element upgrade is sort of fundamental to the usefulness
of custom elements. In a world where most scripts are non-blocking (that's
hopefully the modern world we should aim for), I'll effectively
On Jan 15, 2015, at 11:47 AM, Brian Kardell bkard...@gmail.com wrote:
Not to sidetrack the discussion but Steve Faulker made what I think was a
valid observation and I haven't seen a response... Did I miss it?
When and in which thread? Could you give us a pointer?
- R. Niwa
FWIW, I think that element upgrade is sort of fundamental to the usefulness
of custom elements. In a world where most scripts are non-blocking (that's
hopefully the modern world we should aim for), I'll effectively expect to
walk the tree anyway.
And if I walk the tree anyway, what's the point of
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24579
On Wed, Jan 14, 2015 at 11:11 AM, Domenic Denicola d...@domenic.me wrote:
From: Erik Arvidsson [mailto:a...@google.com]
I'm not sure how that is speced but in Blink we have an extended IDL
attribute called CustomElementCallbacks which
On Jan 14, 2015, at 12:25 PM, Domenic Denicola d...@domenic.me wrote:
From: Ryosuke Niwa [mailto:rn...@apple.com]
Let me restate the problem using an example. Suppose we're parsing
my-element/my-elementmy-other-element/my-other-element.
Once the HTML is parsed, the DOM tree is
From: Erik Arvidsson [mailto:a...@google.com]
I'm not sure how that is speced but in Blink we have an extended IDL
attribute called CustomElementCallbacks which means that we are going to call
the pending callbacks after the method/setter.
If I recall this is how Anne and others were
On Jan 14, 2015, at 10:41 AM, Domenic Denicola d...@domenic.me wrote:
From: Ryosuke Niwa [mailto:rn...@apple.com]
See Boris' responses in another thread [1] and [2]. Jonas outlined how this
could work in the same thread [3]
Thanks for the references. But avoiding this problem is
From: Ryosuke Niwa [mailto:rn...@apple.com]
Let me restate the problem using an example. Suppose we're parsing
my-element/my-elementmy-other-element/my-other-element.
Once the HTML is parsed, the DOM tree is constructed with two DOM elements.
Now we call the constructors on those
On Jan 14, 2015, at 6:45 AM, Anne van Kesteren ann...@annevk.nl wrote:
I've been trying to think of the smallest setup that adds value, can
get broad agreement, and is therefore hopefully interoperable fast.
* ES6-style class syntax to declare the imperative constructor.
* No subclassing
On 1/14/15 9:45 AM, Anne van Kesteren wrote:
* No subclassing of normal elements for now.
You mean subclassing anything more specific than HTMLElement/SVGElement,
yes? Presumably we still want subclassing of HTMLElement and maybe
SVGElement?
* Parsing of declarative syntax invokes the
From: Anne van Kesteren [mailto:ann...@annevk.nl]
Could you explain how this works in more detail?
I haven't checked, but my impression was we could just use the same processing
model the current spec uses for createdCallback, and use the constructor
instead.
On 14 January 2015 at 14:45, Anne van Kesteren ann...@annevk.nl wrote:
t also does not address subclassing normal elements. Again, while
that seems desirable
Given that subclassing normal elements is the easiest and most robust
method (for developers) of implementing semantics[1] and
On Wed, Jan 14, 2015 at 4:28 PM, Erik Arvidsson a...@google.com 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
(script element) is executed. That way the parser does not have to be
stalled by
On Jan 14, 2015, at 9:50 AM, Domenic Denicola d...@domenic.me wrote:
From: Anne van Kesteren [mailto:ann...@annevk.nl]
Could you explain how this works in more detail?
I haven't checked, but my impression was we could just use the same
processing model the current spec uses for
From: Ryosuke Niwa [mailto:rn...@apple.com]
See Boris' responses in another thread [1] and [2]. Jonas outlined how this
could work in the same thread [3]
Thanks for the references. But avoiding this problem is exactly what Arv and I
were talking about.
The mechanism that createdCallback
92 matches
Mail list logo
