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 Wed, Apr 17, 2013 at 10:34 PM, Bjoern Hoehrmann wrote:
> * Rick Waldron wrote:
> >On Tue, Apr 16, 2013 at 9:51 PM, Bjoern Hoehrmann
> wrote:
> >> * Rick Waldron wrote:
> >> >If I want to make a new button to put in the document, the first thing
> my
> >> >JS programming experience tells me:
>
* Rick Waldron wrote:
>On Tue, Apr 16, 2013 at 9:51 PM, Bjoern Hoehrmann wrote:
>> * Rick Waldron wrote:
>> >If I want to make a new button to put in the document, the first thing my
>> >JS programming experience tells me:
>> >
>> > new Button();
>>
>> And if you read code like `new A();` your pr
On Wed, Apr 17, 2013 at 8:14 PM, Rick Waldron wrote:
> document !== [[Global]], so I'm not sure what other global this `example`
> method could be defined on that this would ever possibly be true. Let's just
> agree that this will fail for all the right reasons.
That would be different from how n
On Tue, Apr 16, 2013 at 9:51 PM, Bjoern Hoehrmann wrote:
> * Rick Waldron wrote:
> >Of course, but we'd also eat scraps from the trash if that was the only
> >edible food left on earth. document.createElement() is and has always been
> >"the wrong way"—the numbers shown in those graphs are grossl
* Rick Waldron wrote:
>Of course, but we'd also eat scraps from the trash if that was the only
>edible food left on earth. document.createElement() is and has always been
>"the wrong way"—the numbers shown in those graphs are grossly skewed by a
>complete lack of any real alternative.
>
>If I want
On Apr 16, 2013, at 4:08 PM, Daniel Buchner wrote:
> "Deferring just the script features of would help with the timing
> and probably allow a better long term solution to be designed."
>
> If the callbacks are not mutable or become inert after registration (as I
> believe was the case), how w
*"Deferring just the script features of would help with the
timing and probably allow a better long term solution to be designed."*
If the callbacks are not mutable or become inert after registration (as I
believe was the case), how would a developer do this --> *"Imperative code
could presumably
On Apr 16, 2013, at 3:13 PM, Dimitri Glazkov wrote:
> On Tue, Apr 16, 2013 at 3:07 PM, Daniel Buchner wrote:
>> One thing I've heard from many of our in-house developers, is that they
>> prefer the imperative syntax, with one caveat: we provide an easy way to
>> allow components import/require/r
On Tue, Apr 16, 2013 at 3:07 PM, Daniel Buchner wrote:
> One thing I've heard from many of our in-house developers, is that they
> prefer the imperative syntax, with one caveat: we provide an easy way to
> allow components import/require/rely-upon other components. This could
> obviously be done u
One thing I've heard from many of our in-house developers, is that they
prefer the imperative syntax, with one caveat: we provide an easy way to
allow components import/require/rely-upon other components. This could
obviously be done using ES6 Modules, but is there anything we can do to
address tha
On Tue, Apr 16, 2013 at 3:00 PM, Daniel Buchner wrote:
> "I am going to offer a cop-out option: maybe we simply don't offer
> imperative syntax as part of the spec?"
>
> Why would we do this if the imperative syntax is "solid", "nicely
> compatible", and relatively uncontentious? Did you mean to s
*"I am going to offer a cop-out option: maybe we simply don't offer
imperative syntax as part of the spec?"
*
Why would we do this if the imperative syntax is "solid", "nicely
compatible", and relatively uncontentious? Did you mean to say declarative?
Daniel J. Buchner
Product Manager, Developer E
Wow. What a thread. I look away for a day, and this magic beanstalk is all
the way to the clouds.
I am happy to see that all newcomers are now up to speed. I am heartened to
recognize the same WTFs and grumbling that we went through along the path.
I feel your pain -- I've been there myself. As Hi
Would this be possible using the Scott and Brendan's idea of using a
specific element for prototyping? -->
https://gist.github.com/csuwldcat/5392291
On Mon, Apr 15, 2013 at 3:33 PM, John J Barton
wrote:
> I think that rendering a placeholder (eg blank image) then filling it in
> rather than bloc
I think that rendering a placeholder (eg blank image) then filling it in
rather than blocking is good if done well (eg images with pre-allocated
space). Otherwise it's bad but less bad than blocking ;-).
But if you allow this implementation, then this whole discussion confuses
me even more. I'm th
*
*
*Gee, that's not very encouraging: this is the most important kind of issue
for a developer, more so than whether the API is inheritance-like or not.*
IMO, the not-yet-upgraded case is nothing new, and developers will hardly
be surprised. This nit is no different than if devs include a jQuery
On Mon, Apr 15, 2013 at 2:01 PM, Scott Miles wrote:
> >> What happens if the construction/initialization of the custom element
> calls one of the element's member functions overridden by code in a
> ?
>
> IIRC it's not possible to override methods that will be called from inside
> of builtins, so
>> So we can override some methods but not others, depending on the
implementation?
You can override methods that will be called from JS, but not from C++
(depending on platform).
>> Gee, that's not very encouraging
I was trying to just say we have been aware of these issue too and there
are eff
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 do
*How, as component author, do I ensure that my imperative set up code runs
and modifies my element DOM content before the user sees the un-modified
custom element declared in mark-up? (I'm cheating, since this issue isn't
specific to your ) *
When you say "...runs before the user sees the unmodifi
>> What happens if the construction/initialization of the custom element
calls one of the element's member functions overridden by code in a
?
IIRC it's not possible to override methods that will be called from inside
of builtins, so I don't believe this is an issue (unless we change the
playfield
*At least somebody explain why this is conceptually wrong.
*
Nothing is conceptually wrong with what you've stated Scott. I could live
with a element that is scoped to the as long as there
was some sort of 'registeredCallback' (as you previously alluded to many
posts back) that would be executed
> 1) call 'init' when component instance tag is encountered, blocking
parsing,
Fwiw, it was said that calling user code from inside the Parser could
cause Armageddon, not just block the parser. I don't recall the details,
unfortunately.
On Mon, Apr 15, 2013 at 11:44 AM, John J Barton wrote:
>
On Mon, Apr 15, 2013 at 11:59 AM, Boris Zbarsky wrote:
> On 4/15/13 10:45 AM, Rick Waldron wrote:
>
>> Sorry, I should've been more specific. What I meant was that:
>>
>> new HTMLButtonElement();
>>
>> Doesn't construct an HTMLButtonElement, it throws with an "illegal
>> constructor" in Chrome an
On Mon, Apr 15, 2013 at 11:29 AM, Scott Miles wrote:
> Thank you for your patience. :)
>
ditto.
>
>
> > ? user's instance code? Do you mean: Running component instance
> initialization during document construction is Bad?
>
> My 'x-foo' has an 'init' method that I wrote that has to execute bef
On Mon, Apr 15, 2013 at 10:38 AM, Scott Miles wrote:
> Dimitri is trying to avoid 'block[ing] instance construction' because
> instances can be in the main document markup.
>
Yes we sure hope so!
>
> The main document can have a bunch of markup for custom elements. If the
> user has made eleme
Dimitri is trying to avoid 'block[ing] instance construction' because
instances can be in the main document markup.
The main document can have a bunch of markup for custom elements. If the
user has made element definitions a-priori to parsing that markup
(including inside wrote:
>
>
>
> On Mon, A
On Mon, Apr 15, 2013 at 9:44 AM, Scott Miles wrote:
> >> Why do the constructors of component instances run during component
> loading?
>
> I'm not sure what you are referring to. What does 'component loading' mean?
>
> >> Why not use standard events rather than callbacks?
>
>
> I'll some of the
Sorry for the extra posts. I promise to slow down.
>> Why not use standard events rather than callbacks?
I believe a better answer is that it was decided these callbacks had to
work synchronously relative to imperative construction.
So, I can do
var xfoo = document.createElement('x-foo');
x
>> The callbacks are convenient because (1) there is no question of 'who
registers a listener' (2) I can simply call my 'super' callback (or not) to
get inherited behavior.<<
One minute later, these seem like bad reasons. I shouldn't have shot from
the hip, let me do some research.
On Mon, Apr 1
>> Why do the constructors of component instances run during component
loading?
I'm not sure what you are referring to. What does 'component loading' mean?
>> Why not use standard events rather than callbacks?
This was discussed quite a bit, here is my off-the-cuff response. I may
have to do arc
Why do the constructors of component instances run during component loading?
Why not use standard events rather than callbacks?
Thanks,
jjb
On Apr 15, 2013 9:04 AM, "Scott Miles" wrote:
> Again, 'readyCallback' exists because it's a Bad Idea to run user code
> during parsing (tree construction)
Again, 'readyCallback' exists because it's a Bad Idea to run user code
during parsing (tree construction). Ready-time is not the same as
construct-time.
This is the Pinocchio problem:
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html
Scott
On Mon, Apr 15, 2013 at 7:45 AM,
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 Mon, Apr 15, 2013 at 8:57 AM, Boris Zbarsky wrote:
> On 4/14/13 5:35 PM, Rick Waldron wrote:
>
>> I have a better understanding of problem caused by these generated
>> HTML*Element constructors: they aren't constructable.
>>
>
> I'd like to understand what's meant here. I have a good understa
On Mon, Apr 15, 2013 at 1:55 PM, Boris Zbarsky wrote:
> On 4/14/13 4:57 PM, Rick Waldron wrote:
>> Of course, but we'd also eat scraps from the trash if that was the only
>> edible food left on earth. document.createElement() is and has always
>> been "the wrong way"—the numbers shown in those gra
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/14/13 4:57 PM, Rick Waldron wrote:
Of course, but we'd also eat scraps from the trash if that was the only
edible food left on earth. document.createElement() is and has always
been "the wrong way"—the numbers shown in those graphs are grossly
skewed by a complete lack of any real alternativ
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 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
>> This is somehow "ok" because it's polyfillable?
The polyfill thing is a red-herring, let's not cloud the issue.
>> The platforms need to make them constructable
Agreed, but the estimates are months or years to make it so, which is too
long to block these features.
>> "hack" around the probl
On Sun, Apr 14, 2013 at 3:46 PM, Daniel Buchner wrote:
> *>> Here are four ways to avoid the subclassing problem for custom
> elements
> *
> *>> 1) Only allow instances of custome dom elements to be instantiated
> using document.createElement("x-foo").
> *
> *
> *
> *Wearing web developer hat, I
On Sun, Apr 14, 2013 at 3:46 PM, Daniel Buchner wrote:
> *>> Here are four ways to avoid the subclassing problem for custom
> elements
> *
> *>> 1) Only allow instances of custome dom elements to be instantiated
> using document.createElement("x-foo").
> *
> *
> *
> *Wearing web developer hat, I
Fwiw, I believe we can polyfill just about anything, this is not the issue
(afaict).
But even targetting latest Firefox and IE 11, the time frame looks to be
many months before we can actually subclass builtins.
On Sun, Apr 14, 2013 at 12:46 PM, Daniel Buchner wrote:
> *>> Here are four ways t
I almost forgot, there is a secondary problem with 'normal constructors',
see here:
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0728.html
Sorry in advance, lol.
On Sun, Apr 14, 2013 at 12:22 PM, Scott Miles wrote:
> errata: XFooPrototype = Object.create(HTMLElement.prototype
>> Alex Russell have been advocating that WebIDL should be allow
constructor-like interfaces
Absolutely agree. But these are horns of this dilemma.
>> #4 has been accepted for ES6 by all TC39 participants
Yes, I believe this is a timing issue. I am told it will be a long time
before #4 is practi
errata: XFooPrototype = Object.create(HTMLElement.prototype, {
On Sun, Apr 14, 2013 at 12:21 PM, Scott Miles wrote:
> >> Alex Russell have been advocating that WebIDL should be allow
> constructor-like interfaces
>
> Absolutely agree. But these are horns of this dilemma.
>
> >> #4 has been acce
*>> Here are four ways to avoid the subclassing problem for custom elements
*
*>> 1) Only allow instances of custome dom elements to be instantiated
using document.createElement("x-foo").
*
*
*
*Wearing web developer hat, I never make elements any other way than
createElement (or HTML), so this wo
On Apr 14, 2013, at 11:40 AM, Scott Miles wrote:
> >> Here are four ways to avoid the subclassing problem for custom elements
> >> 1) Only allow instances of custome dom elements to be instantiated using
> >> document.createElement("x-foo").
>
> Wearing web developer hat, I never make element
Re: subclassing builtins, the problem we have is stated here:
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0266.html
On Sun, Apr 14, 2013 at 11:52 AM, Allen Wirfs-Brock
wrote:
>
> On Apr 14, 2013, at 10:49 AM, Scott Miles wrote:
>
> >> the challenge with creating a "normal cons
On Apr 14, 2013, at 10:49 AM, Scott Miles wrote:
> >> the challenge with creating a "normal constructor"
>
> Forgive me if my language is imprecise, but the basic notion is that in
> general one cannot create a constructor that creates a DOM node because
> (most? all?) browsers make under the
First of all, thanks for diving in on this Allen (and Rick and Blake et al).
>> all built-in HTML*Element constructors are global so making app defined
custom elements also be global doesn't seem like it is introducing any new
ugliness
Yes, but that set of constructors is tightly controlled, and
On Sat, Apr 13, 2013 at 10:16 PM, Allen Wirfs-Brock
wrote:
>
>
> I see two ways you might do this:
>
> 1) create a new *anonymous* constructor object that inherits from
> HTMLElement. It wouldn't have any unique behavior but it would be uniquely
> associated the particular that defined it and i
>> the challenge with creating a "normal constructor"
Forgive me if my language is imprecise, but the basic notion is that in
general one cannot create a constructor that creates a DOM node because
(most? all?) browsers make under the hood mappings to internal code (C++
for Blink and Webkit). For
Can Scott or Daniel or someone explain the challenge with creating a
"normal constructor" that has been mentioned a few times (Scott mentioned
has-a). I get the feeling that several people are playing catch up on that
challenge and the implications that are causing worry. Until people have
some s
On Apr 13, 2013 8:57 PM, "Daniel Buchner" wrote:
>
> @Rick - if we generated a constructor that was in scope when the script
was executed, there is no need for rebinding 'this'. I'd gladly ditch the
rebinding in favor of sane, default, generated constructors.
I think we need someone to summarize
On Fri, Apr 12, 2013 at 2:25 PM, Scott Miles wrote:
> I realize this doesn't fit any existing conceptual model (that I know of)
> but I think it's worth pointing out that all we really want to do is define
> a prototype for the element (as opposed to running arbitrary script).
>
> Invented pseudo-
On Fri, Apr 12, 2013 at 3:20 PM, Dimitri Glazkov wrote:
> 2) since we do have to live with generated constructors -- at least
> for a little while, we have two decoupled operations:
>
> a) create prototype
> b) generate constructor.
>
Is this order required? Can we not generate the constructor, t
On Fri, Apr 12, 2013 at 3:56 PM, Rick Waldron wrote:
>
>
>
> On Fri, Apr 12, 2013 at 6:52 PM, Dimitri Glazkov
> Can you point me to some concrete example, docs, implementation, code
> (anything) that I might gain some insight into these generated constructors
> you speak of? Thanks :)
Spec:
ht
On Fri, Apr 12, 2013 at 7:14 PM, Dimitri Glazkov wrote:
> On Fri, Apr 12, 2013 at 3:56 PM, Rick Waldron
> wrote:
> >
> >
> >
> > On Fri, Apr 12, 2013 at 6:52 PM, Dimitri Glazkov
>
> > Can you point me to some concrete example, docs, implementation, code
> > (anything) that I might gain some insi
@Scott - interesting, but there are valid reasons for having access to the
global scope/document:
- Components that benefit from top-level delegation
- Components that need to analyze their destination environment before
codifying their definition
Know what I mean?
On Fri, Apr 12, 2013
62 matches
Mail list logo
