Great minds think alike! Dominic started this discussion here just a
few days ago:
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0881.html
On Sat, Mar 23, 2013 at 10:53 AM, Alan Stearns stea...@adobe.com wrote:
Hey all,
I've been looking at the algorithm for offsetParent [1]
Hello folks!
It seems that we've had a bit of informal feedback on the Web
Components as the name for the link rel=component spec (cc'd some
of the feedbackers).
So... these malcontents are suggesting that Web Components is more a
of a general name for all the cool things we're inventing, and
It's in Shadow DOM. These are the droids you're looking for:
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html
http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-301/
On Wed, Mar 27, 2013 at 9:52 AM, Mike Kamermans niho...@gmail.com wrote:
Hey all,
are style
So. :
rel type: import
spec name:
1) HTML Imports
2) Web Imports
:DG
On Thu, Mar 28, 2013 at 11:12 AM, Eric Bidelman ericbidel...@google.com wrote:
+1 on HTML Imports - link ref=import
I am okay with this. Despite it sounding like a front for a shady
criminal organization. I can't complain. I mean, look at Shadow DOM.
:DG
To close the loop, I renamed the spec to HTML Imports, which is now
at https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/imports/index.html.
P.S. Not an April Fool's joke.
:DG
The trick here is to figure out whether de-duping is observable by the
author (other than as a performance gain). If it's not, it's a
performance optimization by a user agent. If it is, it's a spec
feature.
:DG
On Tue, Apr 9, 2013 at 10:53 AM, Scott Miles sjmi...@google.com wrote:
When writing
Apologies for not replying earlier. The last few weeks were a bit...
uhm... hectic.
On Tue, Mar 19, 2013 at 1:57 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Mar 19, 2013 at 12:05 AM, Roland Steiner
rolandstei...@google.com wrote:
.) Being an element, can a shadowroot can itself have a
Dear Webappsonites,
There's been a ton of thinking on what the custom elements declarative
syntax must look like. Here, I present something has near-ideal
developer ergonomics at the expense of terrible sins in other areas.
Consider it to be beacon, rather than a concrete proposal.
First, let's
On Tue, Apr 9, 2013 at 11:42 AM, Scott Miles sjmi...@google.com wrote:
Duplicate fetching is not observable, but duplicate parsing and duplicate
copies are observable.
Preventing duplicate parsing and duplicate copies allows us to use 'imports'
without a secondary packaging mechanism. For
declarative syntax
To: Rick Waldron waldron.r...@gmail.com
Cc: Scott Miles sjmi...@google.com, Rafael Weinstein
rafa...@google.com, Dimitri Glazkov dglaz...@google.com,
public-webapps public-webapps@w3.org, Blake Kaplan
mrb...@mozilla.com, William Chen wc...@mozilla.com, Boris Zbarsky
bzbar
On Wed, Apr 10, 2013 at 6:38 PM, Rick Waldron waldron.r...@gmail.com wrote:
Everyone's answer to this should be no; changing the expected value of the
top level this, in some magical way, simply won't work.
Can you explain why you feel this way?
:DG
Hello, TC39 peeps! I am happy to have you and your expertise here.
On Wed, Apr 10, 2013 at 11:14 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
This can all be expresses, but less clearly and concisely using ES3/5 syntax.
But since we are talking about a new HTML feature, I'd recommend
On Fri, Apr 12, 2013 at 3:56 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Fri, Apr 12, 2013 at 6:52 PM, Dimitri Glazkov dglaz...@google.com
Can you point me to some concrete example, docs, implementation, code
(anything) that I might gain some insight into these generated constructors
On Fri, Apr 12, 2013 at 2:25 PM, Scott Miles sjmi...@google.com 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).
of deduping]?
I don't believe it's *needed* exactly, but we imagined somebody wanting
to import HTML, use it destructively, then import it again.
That may be totally crazy. :)
Scott
On Wed, Apr 10, 2013 at 11:50 AM, Dimitri Glazkov dglaz...@google.com
wrote:
On Tue, Apr 9, 2013 at 11:42 AM
On Mon, Apr 15, 2013 at 6:59 AM, Anne van Kesteren ann...@annevk.nl wrote:
I think we should go for one interface per element here. abstract
classes not being constructable seems fine. Node/CharacterData are
similar to that. This would mean HTMLH1Element, ..., of which
compatibility impact
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
On Tue, Apr 16, 2013 at 3:00 PM, Daniel Buchner dan...@mozilla.com 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
On Tue, Apr 16, 2013 at 3:07 PM, Daniel Buchner dan...@mozilla.com 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
I think there were several f2f conversations around that. I can't
remember if we had an email thread around this.
It used to be called created, but the timing at which the callback
is called makes the name misleading. For example, when parsing, by the
time the callback is invoked, the custom
On Wed, Apr 17, 2013 at 3:00 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Apr 16, 2013 at 10:33 PM, Dimitri Glazkov dglaz...@google.com wrote:
On Mon, Apr 15, 2013 at 6:59 AM, Anne van Kesteren ann...@annevk.nl wrote:
The other problem we need to solve is that document.createElement(x
On Wed, Apr 17, 2013 at 3:53 PM, Rick Waldron waldron.r...@gmail.com wrote:
HTMLElementElement.define('x-foo', {
erhmahgerd: { writable: false, value: BOOKS! }
});
This is just a repackaging of Object.defineProperties( target,
PropertyDescriptors ) thats slightly less obvious because
Hi Ted!
Thanks for the kudos. We Shadow DOM elves are hard at work on making
the world a better place :)
I think you're raising good questions. I am sensitive of the fact that
you are just starting the journey into the shadows and volunteer to be
your Aragorn.
Yes, Shadow DOM is fairly complex,
Greetings, fellow public-webappsters!
Over the past few weeks, I've been digging through implementation
feedback and bugs, and polishing the Custom Elements spec. I think it
is now in a pretty nice state, so come lookit:
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html
On Wed, May 1, 2013 at 11:49 AM, Ryosuke Niwa rn...@apple.com wrote:
On Apr 30, 2013, at 12:07 PM, Daniel Freedman dfre...@google.com wrote:
I'm concerned that if the spec shipped as you described, that it would not
be useful enough to developers to bother using it at all.
I'm concerned
, Dimitri Glazkov dglaz...@chromium.org
wrote:
On Wed, May 1, 2013 at 11:49 AM, Ryosuke Niwa rn...@apple.com wrote:
On Apr 30, 2013, at 12:07 PM, Daniel Freedman dfre...@google.com
wrote:
I'm concerned that if the spec shipped as you described, that it would
not be useful enough
Thanks for the announcement, Chaals!
Since we will only have a day for this Awesome Web Components Party
(even less than a full day, technically), I want to narrow the topic
down a bit to Shadow DOM and CSS interaction. Here's a quick problem
statement.
There are currently several places where
On the second thought: why not make imports dynamic, just like stylesheets?
:DG
On Tue, May 14, 2013 at 11:29 AM, Dimitri Glazkov dglaz...@google.com wrote:
On Tue, May 14, 2013 at 9:35 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, May 14, 2013 at 12:45 AM, Hajime Morrita morr
On Tue, May 14, 2013 at 8:04 PM, Jonas Sicking jo...@sicking.cc wrote:
Apparently I wasn't clear enough before.
We shouldn't add dynamically updating imports of components just
because we're choosing to reuse link. We add dynamic imports if
there are use cases.
I agree, but I am not stressed
On Tue, May 14, 2013 at 2:21 PM, Simon Pieters sim...@opera.com wrote:
That seems to be an argument based on aesthetics. That's worth considering,
of course, but I think is a relatively weak argument. In particular I care
about the first bullet point above. link is not capable of executing
Despite little love from Scott for the mischievous walrus -- }); --
proliferation across the Web, are there any other cries of horror that
I should be listening to? I am hankering to write this as a spec
draft. Yell now to stop me.
:DG
On Wed, May 15, 2013 at 4:00 PM, Angelina Fabbro
angelinafab...@gmail.com wrote:
I assume meeting notes will be posted to the list for those who can't
attend? A lot of good topics there.
Yes!
There's a new ::distributed() pseudo-element function, which
provides a way for a shadow tree to
As promised in
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0685.html,
I sketched out custom element declarative syntax using the last
completion value idea:
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#declaring-custom-elements
Please look it over.
I fixed bug 22079 in https://dvcs.w3.org/hg/webcomponents/rev/879790e093f8.
The gist of the change:
* when parser sees declarations, it adds them into a queue
* the queue is emptied at a microtask checkpoint.
* weee!
:DG
On Tue, May 21, 2013 at 1:02 PM, Dimitri Glazkov dglaz...@chromium.org
On Mon, Jun 3, 2013 at 9:34 PM, Tobie Langel tobie.lan...@gmail.com wrote:
Regardless, adding a className of idl to WebIDL blocks would go a long way.
Think that's doable?
Sure thing! Please file a bug so we don't forget. It's easy -- click
the File a bug button in the top right corner of the
3
On Tue, Jun 4, 2013 at 7:05 AM, Tobie Langel to...@fb.com wrote:
Done: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22254. Thanks.
--tobie
On Tuesday, June 4, 2013 at 12:00 AM, Dimitri Glazkov wrote:
On Mon, Jun 3, 2013 at 9:34 PM, Tobie Langel tobie.lan...@gmail.com
I think keeping the information about a URL is a cool idea and we need to do it:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22255
:DG
On Fri, May 31, 2013 at 3:10 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, May 30, 2013 at 10:57 AM, Boris Zbarsky bzbar...@mit.edu wrote:
4) your idea
On Fri, Jun 14, 2013 at 10:26 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 14 Jun 2013, Dirk Schulze wrote:
On Jun 14, 2013, at 6:41 AM, Robin Berjon ro...@w3.org wrote:
now that template is in HTML, I was wondering if some of the other
specs needed the same treatment.
Some of the specs
Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=22407 to track this.
:DG
On Thu, May 16, 2013 at 9:39 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, May 15, 2013 at 9:08 PM, Simon Pieters sim...@opera.com wrote:
Case study: img was historically not capable of executing script from
Morrita-san is right.
Guy, the only time you would see FOUC with imports is in the same
situations when you see FOUC with styles: when the rendering engine
decided to give up the import ever loading.
:DG
On Sun, Jun 23, 2013 at 11:31 PM, Hajime Morrita morr...@google.com wrote:
Hello,
HTML
On Mon, Jun 24, 2013 at 1:33 PM, Guy Bedford guybedf...@googlemail.com wrote:
Thanks Morrita-san and Dimitri for clarifying, that sounds great.
Also to be sure, just like styles, could HTML imports be injected after the
page load to dynamically load? Also would the `onload` event be triggered
On Tue, Jul 2, 2013 at 8:28 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
We discussed this in a previous meeting (surfacing nested component
parts, either automatically or via a switch) but I don't recall what
the conclusion was. Dimitri?
The issue is tracked by
On Thu, Aug 1, 2013 at 6:17 AM, Marcos Caceres w...@marcosc.com wrote:
Hi Kornel,
Although I have complete empathy about your criticisms regarding JSON, it is
actually quite fit for this purpose. Using HTML in the way you describe is
kinda problematic, in that it could include scripts and
On Sun, Sep 1, 2013 at 9:42 AM, Alexey Kuzmin ale...@alexeykuzmin.com wrote:
Hello!
As I understand current spec [1] there is only two ways to provide styles
for DOM elements in shadow trees:
1) add styles to document and set apply-author-styles flag for shadow tree
or
2) use inline styles
This progress update is brought to you in part by the Sith Order:
Sith: When The Light Side Just Ain't Cuttin' It.
Part 1: Revenge of the :host
Turns out, it's bad to be Super Man. After the Shadow DOM meetup,
where we decided that shadow host could be matched by both outer and
inner trees
On Tue, Sep 10, 2013 at 6:54 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Sep 10, 2013 at 1:32 AM, Dimitri Glazkov dglaz...@google.com wrote:
To calm the brave guinea people down, I showed them a magic trick. Out
of my sleeve, I pulled out two new combinators: A hat (^) and a cat
This section of the explainer is obsolete, see
http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0287.html for
details. Here's a bug to remove these parts from the explainer:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23393
:DG
On Tue, Oct 1, 2013 at 2:30 AM, Kamil Leszczuk
Sure thing, Art!
* Introduction to Web Components (http://www.w3.org/TR/components-intro/)
status should be WD, next working draft coming out shortly, adjusting for
changes in the underlying specs. Dominic Cooney (domin...@chromium.org) is
the primary editor of this document.
* Custom Elements
A better view of bugs is here:
https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14968hide_resolved=1
The only remaining bug is to coordinate with Math and SVG working groups to
make sure that they don't step on our dashes:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23256
Everything
On Sat, Oct 5, 2013 at 5:22 AM, Michael[tm] Smith m...@w3.org wrote:
Hi Art,
Arthur Barstow art.bars...@nokia.com, 2013-10-05 08:00 -0400:
On 10/4/13 8:12 PM, ext Dimitri Glazkov wrote:
A better view of bugs is here:
https://www.w3.org/Bugs/Public/showdependencytree.cgi?id
On Sun, Oct 6, 2013 at 6:26 AM, Angelina Fabbro angelinafab...@gmail.comwrote:
So, Anne just reopened this bug:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22305
To bring in the discussion here and provide some context, a bunch of us
got together at the Mozilla Summit in Brussels to
On Sun, Oct 6, 2013 at 9:21 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Sun, Oct 6, 2013 at 5:25 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
On Sun, Oct 6, 2013 at 6:26 AM, Angelina Fabbro
angelinafab...@gmail.com
wrote:
And, if the script is executed against the global/window
I marked all custom element next level bugs as RESOLVED+LATER. They are
here: http://bit.ly/GIZamj
On Thu, Oct 10, 2013 at 1:06 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 9, 2013 at 10:55 PM, Jonas Sicking jo...@sicking.cc wrote:
Maybe it's time to reconsider if ShadowRoot should be an element rather
than
a DocumentFragment again?
Actually, that's the first thing I said
x-meta element to
access the database, and the details are are encapsulated inside the x-meta
implementation.
Scott
On Fri, Oct 18, 2013 at 3:37 PM, Blake Kaplan mrb...@gmail.com wrote:
On Sun, Oct 6, 2013 at 9:38 AM, Dimitri Glazkov dglaz...@chromium.org
wrote:
So you have link href
On Wed, Oct 9, 2013 at 2:54 PM, Elliott Sprehn espr...@gmail.com wrote:
shadowRoot.appendChild(new Text()) should probably throw an exception.
Woke up in the middle of the night and realized that throwing breaks
ShadowRoot.innerHTML (or we'll have to add new rules to hoist/drop text
nodes in
On Sun, Nov 10, 2013 at 6:49 PM, Arthur Barstow art.bars...@nokia.comwrote:
Hi Dimitri, Dominic,
Ryosuke is here in Shezhen at WebApps' f2f meeting. We would like to have
one or both of you join us (via voice conference) on Tuesday morning to
talk about Web Components and his comments below.
'Sup yo!
There was a thought-provoking post by Steve Souders [1] this weekend that
involved HTML Imports (yay!) and document.write (boo!), which triggered a
Twitter conversation [2], which triggered some conversations with Arv and
Alex, which finally erupted in this email.
Today, HTML Imports
On Mon, Nov 18, 2013 at 8:26 PM, Ryosuke Niwa rn...@apple.com wrote:
We share the concern Jonas expressed here as I've repeatedly mentioned on
another threads.
On Nov 18, 2013, at 4:14 PM, Jonas Sicking jo...@sicking.cc wrote:
This has several downsides:
* Libraries can easily collide with
John's commentary just triggered a thought in my head. We should stop
saying that HTML Imports block rendering. Because in reality, they don't.
It's the scripts that block rendering.
Steve's argument is not about HTML Imports needing to be async. It's about
supporting legacy content with HTML
Stepping back a bit, I think we're struggling to ignore the elephant in the
room. This elephant is the fact that there's no specification (or API) that
defines (or provides facilities to control) when rendering happens. And for
that matter, what rendering means.
The original reason why script
On Wed, Nov 27, 2013 at 11:35 AM, Steve Souders soud...@google.com wrote:
According to the HTML 4
spechttp://www.w3.org/TR/html401/struct/links.html#h-12.1.3LINK tags must
appear in HEAD:
*The LINK element may only appear in the head of a document.*
We probably need something more modern
On Wed, Nov 27, 2013 at 12:19 PM, Steve Souders soud...@google.com wrote:
Given that most examples of Custom Elements are visible elements in the
body and the spec doesn't indicate its example is in the HEAD, this example
will likely increase the number of websites that put HTML Import LINK
On Wed, Nov 27, 2013 at 12:41 PM, Boris Zbarsky bzbar...@mit.edu wrote:
http://www.whatwg.org/specs/web-apps/current-work/
multipage/sections.html#the-body-element says its content model (this
part is normative!) is http://www.whatwg.org/specs/web-apps/current-work/
Dear WebApps WG,
The Last Call comment period had ended and we're ready to proceed to CR.
Yay!
The LC comments are tracked here:
http://www.w3.org/wiki/Webapps/LCWD-custom-elements-20131024/
The following (minor) tweaks to the spec were made to the spec during this
period:
*
On Thu, Nov 28, 2013 at 1:49 AM, Ms2ger ms2...@gmail.com wrote:
On 11/27/2013 08:44 PM, Dimitri Glazkov wrote:
Sure. Nothing precludes the author from using custom elements in HEAD.
Except the HTML parser. Unknown elements imply /headbody. Feel free to
use the Live DOM Viewer to confirm
the ability to do a thorough enough review of the spec
to say that it's ready for CR. I believe both Mozilla and Apple raised
this concern when we went into LC.
/ Jonas
On Wed, Nov 27, 2013 at 2:39 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
Dear WebApps WG,
The Last Call comment period had
On Wed, Dec 4, 2013 at 4:32 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma off...@gmail.com wrote:
I would say though that I get the feeling that Web Components seems a
specification that seems really pushed/rushed and I worry that might
lead
On Wed, Dec 4, 2013 at 9:56 AM, Dimitri Glazkov dglaz...@chromium.orgwrote:
On Wed, Dec 4, 2013 at 4:32 AM, Anne van Kesteren ann...@annevk.nlwrote:
On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma off...@gmail.com wrote:
I would say though that I get the feeling that Web Components seems
On Thu, Dec 5, 2013 at 7:55 PM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
3) The approach pollutes global name space with constructors. This had
been voiced many times as unacceptable by developers.
4) How does build
There were several threads around this in March/April, but the main gist is
that we can't allow running user code when the parser is building the tree,
and thus we would need to decouple the timing of the constructor being
called from the [[Construct]] internal method to make constructors
On Thu, Dec 5, 2013 at 9:03 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 5, 2013, at 8:43 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
There were several threads around this in March/April, but the main gist
is that we can't allow running user code when the parser is building the
tree
On Thu, Dec 5, 2013 at 8:50 PM, Ryosuke Niwa rn...@apple.com wrote:
Thanks.
On Dec 5, 2013, at 8:30 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Thu, Dec 5, 2013 at 7:55 PM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov dglaz...@chromium.org
wrote
On Thu, Jan 9, 2014 at 5:17 AM, Arthur Barstow art.bars...@nokia.comwrote:
Hi Dimitri All,
FYI, yesterday I moved all of the Web Components specs in PubStatus to its
own table [PubStatus-WC] to help address the so, what is the status of Web
Components standardization in WebApps use case (as
Hello public-webapps,
As HTML imports [1] are implemented across browsers, there’s a potential
for diversity of opinion in how rendering of documents with imports occurs.
What blocks rendering? What doesn’t? To prevent the inevitable pain of
converging on a de-facto standard behavior, it would be
On Fri, Jan 24, 2014 at 5:53 PM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 23, 2014, at 2:45 PM, Dimitri Glazkov dglaz...@google.com wrote:
As HTML imports [1] are implemented across browsers, there’s a potential
for diversity of opinion in how rendering of documents with imports occurs
Durrr. Forgot a NOT.
On Tue, Feb 11, 2014 at 3:29 PM, Dimitri Glazkov dglaz...@chromium.orgwrote:
I am NOT exactly sure what problem this thread hopes to raise and whether
there is a need for anything other than what is already planned.
On Thu, Jan 30, 2014 at 3:03 PM, Ryosuke Niwa rn...@apple.com wrote:
Hi,
Could someone clarify why we want to allow out-of-order registration of
custom elements? Can we also have (a pointer to) concrete use cases for
this feature?
The thing is if an author wants to replace or customize a
On Thu, Feb 6, 2014 at 9:15 PM, Ryosuke Niwa rn...@apple.com wrote:
I'll also note that none of builtin HTML elements have resolved state.
Sure, because HTML elements are added to the registry before the main
document is loaded.
:DG
On Tue, Feb 11, 2014 at 3:50 PM, Maciej Stachowiak m...@apple.com wrote:
On Feb 11, 2014, at 3:29 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
Dimitri, Maciej, Ryosuke - is there a mutually agreeable solution here?
I am exactly sure what problem this thread hopes to raise
Hello public-webapps!
As promised, here's the plans and expectations summary for the Web
Components spec umbrella. Apologies for taking so long.
== Web Components Explainer ==
Current Editor: domin...@google.com
Status: Non-normative document
The explainer is continually updated to reflect the
On Thu, Feb 13, 2014 at 6:50 PM, Jonas Sicking jo...@sicking.cc wrote:
Dimitri, I'd still love to hear feedback from you on the idea above.
Seems like it could fix one of the design issues that a lot of people
have reacted to.
I am not sure I fully understand how this will work. Let me try
On Fri, Feb 14, 2014 at 10:36 AM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Feb 14, 2014 at 9:25 AM, Dimitri Glazkov dglaz...@google.com
wrote:
On Thu, Feb 13, 2014 at 6:50 PM, Jonas Sicking jo...@sicking.cc wrote:
Dimitri, I'd still love to hear feedback from you on the idea above
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, and
whose parent doesn't have a constructor, no need to add them to the
above arrays. Just insert them into their parent. That means that when
that the
On Tue, Feb 18, 2014 at 11:24 AM, Erik Arvidsson a...@chromium.org wrote:
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
On Tue, Feb 18, 2014 at 2: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
Let me try and repeat this back to you, standards-nerd-style:
Now that we have custom elements, there's even more need for notifying a
style engine of a change in internal elements state -- that is, without
expressing it in attributes (class names, ids, etc.). We want the ability
to make custom
Folks,
Over time, I've realized how difficult it is to trace decision points and
the thought process in email archive and bug comments. So I started writing
short(ish) articles to summarize and crystallize some of crucial bits. I
called them the Shadow DOM Diaries:
to relevant
email threads will help bootstrap newcomers get up to speed if they wanted
to give feedback on public-webapps and Bugzilla.
- R. Niwa
On Apr 7, 2014, at 11:52 AM, Dimitri Glazkov dglaz...@google.com wrote:
Folks,
Over time, I've realized how difficult it is to trace decision
Actually, Friday sounds better for me too!
:DG
On Mon, Apr 7, 2014 at 10:55 PM, Maciej Stachowiak m...@apple.com wrote:
Hi folks,
I’d really appreciate it if we could decide whether Web Components related
topics will be discussed Thursday or Friday. It is the topic I am most
personally
On Mon, Apr 7, 2014 at 3:53 PM, Dimitri Glazkov dglaz...@chromium.orgwrote:
* Inheritance / multiple shadow roots
Here's a good example we can start with when discussing multiple shadow
roots: http://polymer.github.io/core-menu/components/core-menu/demo.html
:DG
* Imperative Content distribution API
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429
Also started a gist with some discussion fodder for tomorrow:
https://gist.github.com/dglazkov/ce96f673b0b2ce7b8c55
:DG
On Thu, Apr 17, 2014 at 2:42 AM, Ryosuke Niwa rn...@apple.com wrote:
*Review: Template Inheritance in the Current Specification*
In the current specification, a super class doesn't define any hooks for
subclasses. Instead, it defines insertion points into which nodes from the
original DOM
On Thu, Apr 17, 2014 at 2:42 AM, Ryosuke Niwa rn...@apple.com wrote:
*Review: Template Inheritance in the Current Specification*
In the current specification, a super class doesn't define any hooks for
subclasses. Instead, it defines insertion points into which nodes from the
original DOM
BTW, here's a jsbin that implements yield/transclude using existing Shadow
DOM plumbing:
http://jsbin.com/pacim/1/edit
:DG
Here's a jsbin that uses the shadow-as-function syntax and does the same
thing:
http://jsbin.com/peqoz/2/edit
:DG
On Tue, Apr 22, 2014 at 10:46 AM, Dimitri Glazkov dglaz...@chromium.orgwrote:
BTW, here's a jsbin that implements yield/transclude using existing Shadow
DOM plumbing:
http
On Sun, Apr 27, 2014 at 2:36 PM, Ryosuke Niwa rn...@apple.com wrote:
On Apr 22, 2014, at 10:46 AM, Dimitri Glazkov dglaz...@chromium.org
wrote:
BTW, here's a jsbin that implements yield/transclude using existing Shadow
DOM plumbing:
http://jsbin.com/pacim/1/edit
Thanks for an example
Possibly relevant to the conversation: Jan Miksovsky (cc'd) had been
thinking in this problem space for a while, and has a couple of great blog
posts on the topic:
http://blog.quickui.org/2013/11/08/filling-slots-in-shadow/
Greetings, WebApp-ateurs!
At the last F2F, there was some positive sentiment toward setting up a
regular conference call to discuss Web Components-related topics.
On Art's advice, I thereby present this lovely survey that seeks to
find a good time slot for such a conference call:
201 - 300 of 399 matches
Mail list logo
