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 HTML is not something they can accommodate in a
> reasonable timef
+1
S
On Wed, Feb 20, 2013 at 4:04 PM, Dimitri Glazkov wrote:
> Folks,
>
> As of https://dvcs.w3.org/hg/webcomponents/rev/505225bb4a7b, the
> custom elements spec no longer has the extra plumbing for
> automatically creating all shadow trees along its inheritance chain.
> This responsibility now
Folks,
As of https://dvcs.w3.org/hg/webcomponents/rev/505225bb4a7b, the
custom elements spec no longer has the extra plumbing for
automatically creating all shadow trees along its inheritance chain.
This responsibility now falls to the developer of the custom element
to do this correctly (for exam
Chrome extensions have a background.html capability with a full dom; I've used
those to prototype the concept. I've also used webkit's CSS fill
(-webkit-canvas) in the mix.
A good deal of experimentation can be done there, prior to hacking up C++.
On Feb 20, 2013, at 11:43 AM, Kenneth Russell
On Fri, Feb 8, 2013 at 9:14 AM, Travis Leithead
wrote:
>>> What would be the advantage? If you wanted to keep dom elements in sync
>>> with the canvas you'd still have to post something from the worker back to
>>> the main thread so the main thread would know to pop.
>
>
>
> Well, it's not a flesh
[I messed up and failed to reply-all a few messages back, see the quoted
text to pick up context]
>> semantic is only important in markup
Hrm, ok. I'll have to think about that.
At any rate, I'm concerned that developers will not be able to predict what
kind of node they will get from a construc
On Wed, Feb 20, 2013 at 9:58 AM, Scott Miles wrote:
> Since many of these cases are 'semantic' elements, whose only raison d'être
> (afaik) is having a particular localName, I'm not sure how we get around
> this without being able to specify an 'extends' option.
>
> document.register('fancy-header
Since many of these cases are 'semantic' elements, whose only raison d'être
(afaik) is having a particular localName, I'm not sure how we get around
this without being able to specify an 'extends' option.
document.register('fancy-header', {
prototype: FancyHeaderPrototype,
extends: 'header'
..
It seems that there's some additional reasoning that needs to go into
whether an element could be constructed as custom tag. Like in this
case, it should work both as a custom tag and as a type extension (the
"is" attr).
:DG<
On Tue, Feb 19, 2013 at 10:13 PM, Daniel Buchner wrote:
> Nope, you're
On Tue, Feb 19, 2013 at 11:26 AM, Ms2ger wrote:
> FWIW, Aryeh is currently studying full time and doesn't follow web standards
> discussions regularly.
I do check them from time to time, though, and will check any personal
e-mail I receive for the time being. In particular, I'm happy to
answer a
On 2/20/13 7:26 AM, Anne van Kesteren wrote:
These already cannot be just localName checks
They often are in practice for extensions and web script.
For browser code or better-written extensions and web script they're
typically localName + namespaceURI checks.
I also fail to see exactly wh
Sorry for the delayed response -- I've been busy with other things and
didn't have time to check my e-mail. Thanks a lot for the feedback
and questions!
On Mon, Feb 4, 2013 at 9:59 PM, Alex Mogilevsky wrote:
> There was a discussion here a while ago on desired default behavior for
> Enter in con
On Tue, Feb 19, 2013 at 11:52 PM, Dimitri Glazkov wrote:
> 3) Since the elements could derive from other existing elements, the
> localName should not be used for determining custom element's type
> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=20913)
>
> PROBLEM: The localName checks are everyw
On Wed, Feb 20, 2013 at 3:01 AM, Scott Miles wrote:
> Perhaps one other COST of the localName issue is the question of
> document.createElement.
>
> document.createElement('x-button') creates , people
> complain because the tag names do not match.
> document.createElement('button').setAttribute('i
On 02/20/2013 08:24 AM, Reitbauer, Alois wrote:
My personal experience is different. We found that using img tags is not
that reliable. Especially in Firefox we recently saw some problems. Img
tags in general have the disadvantage that the amount of data that can
be set is rather limited. While t
15 matches
Mail list logo
