Hello, public-webapps!
There's a lot work happening in the Web Components land, and for those
not following closely, here is a summary. I hope to start sending this
out regularly.
As already mentioned, there's
https://plus.google.com/b/103330502635338602217/ where I post more
granular updates.
Hello, public-webapps!
Here's another summary of work, happening in Web Components.
SHADOW DOM (https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978)
* First bits of the Shadow DOM test suite have landed:
http://w3c-test.org/webapps/ShadowDOM/tests/submissions/Google/tests.html
* More
On Wed, Feb 8, 2012 at 11:25 PM, Henri Sivonen hsivo...@iki.fi wrote:
On Thu, Feb 9, 2012 at 12:00 AM, Dimitri Glazkov dglaz...@chromium.org
wrote:
== IDEA 1: Keep template contents parsing in the tokenizer ==
Not this!
Here's why:
Making something look like markup but then not tokenizing
On Wed, Apr 18, 2012 at 7:49 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Tue, Apr 3, 2012 at 1:21 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
Perhaps lost among other updates was the fact that I've gotten the
first draft of HTML Templates spec out:
http://dvcs.w3.org/hg/webcomponents/raw
Eric Meyer (cc'd) posted an intriguing article about custom tags and
local semantics:
http://meyerweb.com/eric/thoughts/2012/04/10/element-customization/
I must say, even though the current direction we take with Web
Components does not involve custom tags, I still find the current,
is
On Wed, Apr 25, 2012 at 10:45 AM, Brian Kardell bkard...@gmail.com wrote:
Earlier in this thread I mentioned I expect, however, that there
might be larger ideas behind why not to
do this in the sense of web components or declarative MDV-like data
binding...
I guess this is mostly a question
On Wed, Apr 25, 2012 at 11:32 AM, Brian Kardell bkard...@gmail.com wrote:
On Wed, Apr 25, 2012 at 1:57 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
On Wed, Apr 25, 2012 at 10:45 AM, Brian Kardell bkard...@gmail.com wrote:
Earlier in this thread I mentioned I expect, however
Based on the hallway conversations at the F2F, here are some notes for
the upcoming Custom Elements spec.
Custom tags vs. is attribute
- is attribute is awkward, overly verbose
- custom tags introduce local semantics
- generally viewed as a rabbit-hole discussion in WebApps scope
- Tantek
FYI: I buffed up the explainer to conform to PubRules:
http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html
:DG
On Mon, May 7, 2012 at 8:09 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, May 7, 2012 at 9:04 PM, Ian Hickson i...@hixie.ch wrote:
If there's better ways we should certainly consider them. We have to bear
in mind though that fallback is something most authors don't spend much
time on,
On Tue, May 8, 2012 at 5:49 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, May 8, 2012 at 2:33 PM, Scott González scott.gonza...@gmail.com
wrote:
Accessibility is hard.
What makes it hard here is that you have to implement everything from
scratch. You have to implement keyboard
On Tue, May 15, 2012 at 9:32 PM, Yehuda Katz wyc...@gmail.com wrote:
In the past year or so, I've participated in a number of threads that were
implicitly about adding features to browsers that would shrink the size of
existing libraries.
Inevitably, those discussions end up litigating
This is neat! I especially appreciated the Method/Attribute patterns.
I will use this.
Should I be concerned about what seems to be a lively competition
between ReSpec and Anolis. Do we need this tussle? Can we not just
decide which tool to use?
:DG
On Wed, May 23, 2012 at 5:45 AM, Anne van
Here's another installment of updates around Web Components:
COMPONENTS INTRO
(https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14949hide_resolved=1):
* The document is now a FPWD: http://www.w3.org/TR/components-intro/
SHADOW DOM
Here's yet another series of updates around Web Components:
* X-Tag, a library from Mozilla (the closest thing we have today to a
custom DOM elements polyfill) is doing well and enjoying warm
reception across the interwebs: http://mozilla.github.com/x-tag/
* Alex Komoroske and I did a talk on
Interesting. Perhaps that's where CSSOM for Regions could live?
:DG
On Mon, Aug 13, 2012 at 11:19 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
The CSSWG would like to add a new top-level object called CSS that
we can hang several functions and constructors off of, so that we can
avoid the
Greetings, Public-Webapp-lings,
It's time for the sem-regular update from the Web Components-land.
SHADOW DOM
(https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978hide_resolved=1):
Quite a few updates, from minor clarification tweaks to rather massive updates.
The events section,
Folks,
Several peeps now mentioned to me that the visibility of work in
Bugzilla is not very high: a special step of watching an email is
required to get all the updates in real time. I do make the regular
update posts (as you may have noticed), but those are somewhat
post-factum, and don't have
...@oupeng.com wrote:
(12/08/17 0:36), Dimitri Glazkov wrote:
Another idea is to have a separate mailing list for this. At least,
there will be some opt-in step that will give other
public-webapps-nauts at choice.
We have public-webapps-bugzilla[1] already, but I have no idea why we
can't just turn
Can we extend this to custom DOM element registration somehow?
ul.newsli {
identity: x-news-item;
}
or maybe even:
ul.newsli {
identity: url(//example.com/test/news.html#news-item);
}
:DG
On Tue, Aug 21, 2012 at 4:13 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Aug 21,
attribute behavior.
:DG
On Wed, Aug 22, 2012 at 12:09 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Aug 21, 2012 at 5:48 PM, Dimitri Glazkov dglaz...@google.com wrote:
Can we extend this to custom DOM element registration somehow?
ul.newsli {
identity: x-news-item;
}
or maybe
Folks,
Over the last few weeks, while trying to flesh out the Custom DOM
Elements spec
(http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html),
meeting with various folks and talking to actual developers who would
be using Web Components (hello, Twitterfolk!), I am starting to
Hello folks,
The semi-regular string of updates around the Web Components effort persists!
SHADOW DOM
(https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978hide_resolved=1):
The big news, of course, is the a fresh new Working Draft of the
Shadow DOM spec:
Hi folks!
While you are all having good TPAC fun, I thought I would bring this
bug to your attention:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19562
There's been several comments from developers about the fact that
Shadow DOM encapsulation is _too_ well-sealed for various long tail,
but
:
On Nov 1, 2012, at 12:02 AM, Dimitri Glazkov dglaz...@google.com wrote:
Hi folks!
While you are all having good TPAC fun, I thought I would bring this
bug to your attention:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19562
There's been several comments from developers about the fact
On Thu, Nov 1, 2012 at 9:02 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/1/12 7:41 AM, Tab Atkins Jr. wrote:
There was no good *reason* to be private by default
Yes, there was. It makes it much simpler to author non-buggy components.
Most component authors don't really contemplate how
Folks,
Throughout the year-long (whoa!) history of the Shadow DOM spec,
various people commented on how odd the constructable ShadowRoot
pattern was:
var root = new ShadowRoot(host); // both creates an instance *and*
makes an association between this instance and host.
People (I cc'd most of
?
Cheers,
Maciej
On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov dglaz...@google.com wrote:
Folks,
Throughout the year-long (whoa!) history of the Shadow DOM spec,
various people commented on how odd the constructable ShadowRoot
pattern was:
var root = new ShadowRoot(host); // both creates
On Thu, Nov 8, 2012 at 9:48 AM, Maciej Stachowiak m...@apple.com wrote:
On Nov 6, 2012, at 3:29 PM, Dimitri Glazkov dglaz...@google.com wrote:
On Thu, Nov 1, 2012 at 8:39 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
6) The isolated setting essentially means that there's a new
document
at 9:49 AM, Dimitri Glazkov dglaz...@google.com wrote:
Sure. Here's a simple example without getting into traversable shadow
trees (those are still being discussed in a different thread):
A1) Using constructable ShadowRoot:
var element = document.querySelector('div#foo');
// let's add a shadow
On Thu, Nov 8, 2012 at 9:26 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/8/12 9:28 AM, Elliott Sprehn wrote:
If you're worried about malicious attacks on your widget, shadows being
private is not enough. You need a whole new scripting context.
Er... yes, you do. Do widgets not get that?
On Mon, Nov 12, 2012 at 10:47 PM, Angelina Fabbro
angelinafab...@gmail.com wrote:
Hello public-webapps,
Hi Angelina! I really enjoyed your video. It was great.
1. It looks like from the spec and the code in Glazkov's polyfill that if I
add and remove the 'is' attribute, the shadow tree
On Tue, Nov 13, 2012 at 7:48 PM, Angelina Fabbro
angelinafab...@gmail.com wrote:
I was having an exchange with a gentleman named Tom Ashworth that made it's
way off list.
What he had said to me in a previous message about @host:
@host { } is weird. As far as I can tell, nothing inside it
Yes! And by the way, I need to start work on an actual spec for this,
as I mentioned here:
http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0587.html
:DG
On Tue, Nov 13, 2012 at 8:22 AM, Clayton Watts clet...@gmail.com wrote:
Hello, Angelina,
I'm certainly not the definitive
I made the change to the editor's draft:
http://dvcs.w3.org/hg/webcomponents/rev/e0dfe2ac8104
You can read the shiny new parts of the spec here:
http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#extensions-to-element
Please let me know if I goofed up something, preferably
-element-older-shadow-root
Please let me know if I goofed anything up. File bugs or yell at me.
:DG
On Fri, Nov 9, 2012 at 10:17 AM, Dimitri Glazkov dglaz...@chromium.orgwrote:
On Thu, Nov 8, 2012 at 9:26 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/8/12 9:28 AM, Elliott Sprehn wrote
On Wed, Nov 28, 2012 at 2:51 PM, Maciej Stachowiak m...@apple.com wrote:
Does this support the previously discussed mechanism of allowing either
public or private components? I'm not able to tell from the referenced
sections.
There's no private flag in place yet, I filed the bug to make
On Sun, Dec 9, 2012 at 8:16 PM, Boris Zbarsky bzbar...@mit.edu wrote:
function CustomElementConstructor = Element ();
partial interface Document {
CustomElementConstructor register(DOMString name,
optional Options options);
};
Yep.
Thanks! https://www.w3.org/Bugs/Public/show_bug.cgi?id=19092
:DG
On Wed, Dec 26, 2012 at 10:08 PM, Jens O. Meiert j...@meiert.com wrote:
I noticed two typos in the Web Components draft [1]:
* Under “4 Decorators”: “hanlders”
* Under “6.3 CSS and Shadow DOM”: “…inherifance”
HTH,
Jens.
On Wed, Feb 6, 2013 at 9:56 AM, Erik Arvidsson a...@chromium.org wrote:
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
On Tue, Feb 5, 2013 at 5:43 PM, Daniel Buchner dan...@mozilla.com wrote:
So we're removing the async nature of the API? How is this a good trade? I
thought this was one of the benefits? Is polyfilling still possible in a
sane way that adheres to the specified behavior?
I don't think anyone
On Wed, Feb 6, 2013 at 9:03 AM, Erik Arvidsson a...@chromium.org wrote:
Do we need to be able to do new MyButton or is
document.createElement/innerHTML/parser sufficient? If we need to be
able to do new in the polyfill I think we either need to tweak
document.register or get the developer to
On Thu, Feb 7, 2013 at 9:17 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Feb 7, 2013 at 5:02 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
I think this is a nicer solution. Will we have defaults associated with
some
types of events or is it completely up to the shadow tree
I think we have the solution for polyfills: return a slightly different
object from document.register. Should we do the same thing for ES5/3 or
should we spec this as overwriting of the [[Construct]] method?
:DG
On Wed, Feb 6, 2013 at 10:01 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/6/13 5:07 PM, Erik Arvidsson wrote:
This refactoring is needed for ES6 anyway so it might be worth looking
into no matter what.
Well, yes, but it's a matter of timeframes. It's incredibly unlikely that
a complete
On Fri, Feb 8, 2013 at 3:13 PM, Scott Miles sjmi...@google.com wrote:
Aha, I see, that's a very good question.
Being discussed here.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20913
:DG
On Mon, Feb 11, 2013 at 3:49 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
Right now, the shadow root inside a component isn't an element, so it
can't host styles, etc. This makes a few things weird, though.
For example, it means that it's non-trivial to get at the style of
text nodes
On Mon, Feb 11, 2013 at 12:12 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
It's possible to style a host element from within the shadow's
stylesheet, and use the host's own qualities, by using the @host rule.
It's also possible to style the shadow elements themselves, in their
own
On Tue, Feb 12, 2013 at 3:24 AM, Anne van Kesteren ann...@annevk.nl wrote:
If the goal of custom elements is to expose the guts of what happens
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#monkeypatch-create-element
is the wrong solution. Currently new Image() and
On Tue, Feb 12, 2013 at 7:55 AM, Anne van Kesteren ann...@annevk.nl wrote:
The more I read this algorithm to figure out how to rewrite DOM event
dispatch the more confused I get. For starters it would probably help
if ancestor was renamed to event parent.
Well.. I am not sure what event
On Tue, Feb 12, 2013 at 9:13 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Feb 12, 2013 at 5:06 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
By the wrongness, do you mean the running shadow tree instantiation and
element finalization steps? If so, they are workarounds for our
On Mon, Feb 11, 2013 at 8:40 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/7/13 6:15 PM, Dimitri Glazkov wrote:
1) Expose the ability to override [[Construct]]. Arv tells me that he
spoke with V8 peeps and they think they can do this fairly easily. How's
the SpiderMonkey story looking here
Folks,
I propose just a bit of sugaring as a compromise, but I want to make
sure this is really sugar and not acid, so please chime in.
1) We give up on unified syntax for ES5 and ES6, and instead focus on
unified plumbing
2) document.register returns a custom element constructor as a result,
On Thu, Feb 14, 2013 at 2:40 PM, Scott Miles sjmi...@google.com wrote:
In all constructions the *actual* calling of HTMLButtonElement is done by
the browser.
No, this is not correct. It's the exact opposite :)
In this compromise proposal, the browser isn't calling any of the
constructors. Arv
On Thu, Feb 14, 2013 at 2:23 PM, Scott Miles sjmi...@google.com wrote:
MyButton = document.register(‘x-button’, {
prototype: MyButton.prototype,
lifecycle: {
created: MyButton
}
});
What's the benefit of allowing this syntax? I don't immediately see why you
couldn't just do it
On Thu, Feb 14, 2013 at 2:47 PM, Scott Miles sjmi...@google.com wrote:
Developer cannot call HTMLButtonElement. So whatever work it represents that
MUST be done by the browser.
Right. I think we're agreeing, but using different words. An instance
of an HTMLButtonElement-derived element consists
On Thu, Feb 14, 2013 at 2:53 PM, Scott Miles sjmi...@google.com wrote:
Well, yes, here ya go: (o). But I must be missing something. You wouldn't
propose two APIs if they were equivalent, and I don't see how these are not
(in any meaningful way).
The only difference is that one spits out a
Thank you for enumerating the list, Jonas!
On Thu, Feb 14, 2013 at 11:12 PM, Jonas Sicking jo...@sicking.cc wrote:
I chatted with Blake about this today and had some thoughts.
There is definitely no simple answer here, feels like using either an
Element or a DocumentFragment has some crappy
On Mon, Feb 18, 2013 at 12:06 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Feb 18, 2013 at 1:48 AM, Anne van Kesteren ann...@annevk.nl wrote:
So given that consensus still putting it on ShadowRoot strikes me like
a bad idea (as I think I've said somewhere in a bug). The same goes
for
On Fri, Feb 15, 2013 at 8:42 AM, Daniel Buchner dan...@mozilla.com wrote:
I'm not sure I buy the idea that two ways of doing the same thing does not
seem like a good approach - the web platform's imperative and declarative
duality is, by nature, two-way. Having two methods or an option that
On Mon, Feb 18, 2013 at 12:47 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Feb 18, 2013 at 8:42 PM, Dimitri Glazkov dglaz...@google.com wrote:
Also, I want to know better which part of _putting it on ShadowRoot_
strikes Anne as bad. I would like striking him at all, especially
On Mon, Feb 18, 2013 at 1:01 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Feb 18, 2013 at 8:57 PM, Dimitri Glazkov dglaz...@google.com wrote:
Still unclear. Are you saying this: if we have API members on
ShadowRoot that aren't on DocumentFragment, then ShadowRoot should
)
document.createElement('button', 'x-button'), now I cannot encode my tag in
a single variable (i.e. document.createElement(someTag))
document.createElement('button/x-button'), I just made this up, but maybe it
would work.
Scott
On Tue, Feb 19, 2013 at 3:52 PM, Dimitri Glazkov dglaz
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 dan...@mozilla.com
On Tue, Feb 26, 2013 at 1:43 PM, Blake Kaplan mrb...@gmail.com wrote:
On Tue, Feb 26, 2013 at 11:05 AM, Erik Arvidsson a...@google.com wrote:
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
A few of browser/webdev folks got together and went (again!) over the
custom elements design. One problem stuck out: handling of created
callbacks (and other future callbacks, by induction) for derived
custom elements.
For example, if Raj defined a create callback for his foo-raj
element, and
Here are all the callbacks that we could think of:
* readyCallback (artist formerly known as create) -- called when the
element is instantiated with generated constructor, createElement/NS
or shortly after it was instantiated and placed in a tree during
parser tree construction
*
On Wed, Mar 6, 2013 at 2:20 PM, Scott Miles sjmi...@google.com wrote:
That's the ultimate goal IMO, and when I channel Alex Russell (without
permission). =P
Don't we already have Fake Alex for that (https://twitter.com/FakeAlexRussell)?
:DG
On Thu, Mar 7, 2013 at 8:55 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Chances are that behavior would remain for the foreseeable future even if
page-provided components expose their internals, from what I understand...
So that's a somewhat orthogonal discussion, sadly. :(
I agree, it's very
On Thu, Mar 7, 2013 at 11:00 AM, Boris Zbarsky bzbar...@mit.edu wrote:
We're talking about both, in general. Until this conversation started at
least one implementor was planning to ship exposed-by-default with no way to
not expose, as far as I can tell.
I _think_, but am not sure, that this
Hello fellow web-appanauts,
The day you've been waiting for had finally arrived (or not, depending
on the type of day been waiting for).
Here's a first rough draft of the Web Components spec:
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.html
This spec looks really
On Thu, Mar 7, 2013 at 2:35 PM, Scott Miles sjmi...@google.com wrote:
Currently, if I document.register something, it's my job to supply a
complete prototype.
For HTMLElementElement on the other hand, I supply a tag name to extend, and
the prototype containing the extensions, and the system
On Wed, Mar 6, 2013 at 1:55 PM, Dimitri Glazkov dglaz...@google.com wrote:
Cons:
* The callbacks now hang out in the wind as prototype members. Foolish
people can invoke them, inspectors show them, etc.
This con could get uncomfortably exciting if we try building HTML
elements with custom
On Wed, Mar 6, 2013 at 4:26 PM, Blake Kaplan mrb...@gmail.com wrote:
On Wed, Mar 6, 2013 at 1:55 PM, Dimitri Glazkov dglaz...@google.com wrote:
1) Somehow magically chain create callbacks. In Lucy's case,
foo-lucy will call both Raj's and Lucy's callbacks.
2) Get rid of a separate lifecycle
As I started work on the components spec, I realized something terrible:
a) even if all HTML parsers could run script at any point when
constructing tree, and
b) even if all JS engines supported overriding [[Construct]] internal
method on Function,
c) we still can't make custom element
On Fri, Mar 8, 2013 at 10:41 AM, Anne van Kesteren ann...@annevk.nl wrote:
Components don't directly correlate with custom elements. They are
just documents that you can load together with your document. With
things like multi-threaded parser, these are useful on their own, even
without custom
On Fri, Mar 8, 2013 at 12:22 PM, Steve Orvell sorv...@google.com wrote:
I also find the name confusing. It's common to use the term 'component' when
describing the functionality of a custom element.
What about HTML Modules?
Then we probably need to rename link rel=module for consistency?
:DG
On Fri, Mar 8, 2013 at 12:30 PM, Steve Orvell sorv...@google.com wrote:
Indeed. Unfortunately, using 'module' here could be confusing wrt ES6
modules. Perhaps package is better?
The name is difficult. My main point is that using components causes
unnecessary confusion.
I understand. Welcome
On Fri, Mar 8, 2013 at 1:15 PM, Scott Miles sjmi...@google.com wrote:
Agree. Seems like Dimitri and Anne decided that these targets are
'document', did they not?
rel=document seems to communicate that the relation of the linked
resources to the document is document, which is at least cyclical
On Fri, Mar 8, 2013 at 1:13 PM, Jonas Sicking jo...@sicking.cc wrote:
Related to the ongoing discussion about whether to expose the shadow
tree of web components by default or not, but somewhat orthogonal to
it, I think there is a question of *how* to expose the web component
shadow tree.
If
On Sat, Mar 9, 2013 at 4:36 AM, Arthur Barstow art.bars...@nokia.comwrote:
[ Apology for top-posting and continuing the cross-posting ]
Hi Brad,
Thanks, yes earlier security review and feedback would be good.
My preference is to use public-webapps (solely) for all discussions
related to
On Mon, Mar 11, 2013 at 10:14 AM, Anne van Kesteren ann...@annevk.nlwrote:
On Fri, Mar 8, 2013 at 6:53 PM, Dimitri Glazkov dglaz...@google.com
wrote:
That's not the problem, that's a feature :) Think of it as a
template tag for documents.
I'd think that author expectations would
On Fri, Mar 8, 2013 at 1:47 PM, Robert Ginda rgi...@chromium.org wrote:
rel=include ?
And Inclusions as the name? Or HTML Inclusions? This could work.
Any objections or better names? Rob might just win this one.
:DG
Hi folks!
Just had a quick discussion with Elliott and he suggested that instead of
building full-blown Documents, the link rel=components just make
DocumentFragments, just like template does.
Looking at
http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#the-document-object
and
On Tue, Mar 12, 2013 at 1:42 AM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Mar 11, 2013 at 5:45 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 3/11/13 5:18 PM, Elliott Sprehn wrote:
inserted and removed can probably be end of micro task, but
attributeChanged definitely needs to be
On Tue, Mar 12, 2013 at 3:46 AM, Anne van Kesteren ann...@annevk.nl wrote:
I recommend discussing this with the HTML parser crowd and performance
crowd. I would've thought we would not want to repeat mistakes made in
the past.
Yup, been doing this for a while now. The stylesheet-like
Quick update: we had a really productive lunch with a bunch of Mozilla and
Google peeps (cc'd)
After mulling this whole thing over, we're decided keep shadow trees
traversable with a special provision for built-in HTML elements (UA shadow
trees) to be non-traversable, per spec.
We reached this
On Wed, Mar 13, 2013 at 5:41 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Mar 12, 2013 at 4:53 PM, Dimitri Glazkov dglaz...@google.com
wrote:
Yup, been doing this for a while now. The stylesheet-like behavior seems
to
have settled as the least evil of the compromises. It's
On Tue, Mar 12, 2013 at 10:20 PM, Dominic Cooney domin...@google.comwrote:
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 full-blown Documents, the link rel=components
On Wed, Mar 13, 2013 at 7:25 AM, Erik Arvidsson a...@google.com wrote:
Also, how would you resolve URLs. Can I use base?
Interesting question. If indeed using base is a requirement, we can't use
DocumentFragments.
Another point here: since each component has its own location, then
Sounds good: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21275
On Wed, Mar 13, 2013 at 1:35 PM, Anne van Kesteren ann...@annevk.nl wrote:
Lets override all the encoding magic the HTML layer might bring with
it and simply always decode these resources using utf-8, just as we do
with
On Thu, Mar 14, 2013 at 7:10 AM, Hill, Brad bh...@paypal-inc.com wrote:
Is there time available on the April F2F agenda for discussion of this?
If not in WebApps, would relevant WG members be willing to join us if we
found time to discuss in WebAppSec’s timeslot Thursday or Friday?
just DocumentFragments in the same document?
:DG
On Mon, Mar 11, 2013 at 4:13 PM, Dimitri Glazkov dglaz...@google.comwrote:
Hi folks!
Just had a quick discussion with Elliott and he suggested that instead of
building full-blown Documents, the link rel=components just make
DocumentFragments
Hi Mike, the spec you're looking for is under development here:
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.html
:DG
On Fri, Mar 15, 2013 at 7:07 AM, Mike Kamermans niho...@gmail.com wrote:
Hey all,
I searched the archive at
On Thu, Mar 14, 2013 at 8:09 PM, Dominic Cooney domin...@google.com wrote:
On Fri, Mar 15, 2013 at 9:43 AM, Dimitri Glazkov dglaz...@google.comwrote:
Here's one scenario where keeping components Documents might be a good
idea. Suppose you just built a multi-threaded parser into your renderer
I am a big fan.
:DG
On Sun, Mar 17, 2013 at 1:46 PM, Elliott Sprehn espr...@gmail.com wrote:
I'd rather like it if the spec said the component document is a document
that's always in standards mode and has no children and then the contents
of the component were put into a DocumentFragment.
Should it bother us
To close the loop: A bunch of Mozilla/Google peeps got together on
Friday and discussed this. We came away with the conclusion that
moving callbacks to the custom element prototype looks like the right
thing. It's not without warts, but who is, amirite?
I'll give spec'ing this out a shot and then
Last Friday, still energized after the productive Mozilla/Google
meeting, a few of us (cc'd) dug into Shadow DOM. And boy, did that go
south quickly! But let's start from the top.
We puzzled over the the similarity of two seemingly disconnected problems:
a) ShadowRoot is a DocumentFragment and
On Fri, Mar 22, 2013 at 9:35 AM, Scott Miles sjmi...@google.com wrote:
In our work, we adopt a composition rule that a node knows about it's own
children and can have expectations of them, but can make no assumptions
about it's parent or siblings. As a coding model we've found it to be
101 - 200 of 399 matches
Mail list logo
