16:04:48 <RRSAgent> RRSAgent has joined #webapps
16:04:48 <RRSAgent> logging to http://www.w3.org/2014/04/11-webapps-irc
16:04:57 <alia> alia has joined #webapps
16:05:12 <aizu> aizu has joined #webapps
16:05:18 <ArtB> RRSAgent, log spans midnight
16:05:18 <RRSAgent> I'm logging. I don't understand 'log spans midnight', ArtB.  Try /msg RRSAgent help
16:05:53 <Arrrno> Arrrno has joined #webapps
16:06:30 <ArtB> ScribeNick: ArtB
16:06:34 <ArtB> Scribe: Art
16:06:47 <krisk> krisk has joined #webapps
16:06:51 <Arrrno> Present+ Arnaud_Braud
16:06:54 <israelh> israelh has joined #webapps
16:06:59 <tyoshino> Present+ Takeshi_Yoshino
16:07:22 <ArtB> Meeting: WebApps f2f Meeting (San Jose CA US)
16:07:38 <dglazkov> http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0074.html
16:07:53 <krisk> present+  krisk
16:08:06 <dglazkov> present+ dglazkov
16:08:14 <Zakim> -[IPcaller]
16:08:28 <ArtB> Agenda: https://www.w3.org/wiki/Webapps/April2014Meeting
16:08:36 <israelh> present+ israel hilerio
16:08:41 <adrianba> adrianba has joined #webapps
16:08:41 <Zakim> +[IPcaller]
16:08:41 <ArtB> Present+ Art_Barstow
16:08:42 <anssik> Present+ Anssi_Kostiainen
16:08:45 <alia> Present+ Ali_Alabbas
16:08:46 <Yves> Present+ Yves_Lafon
16:08:50 <BenjamP> BenjamP has joined #webapps
16:08:51 <rniwa> rniwa has joined #webapps
16:08:54 <smaug> Zakim, [IPcaller] is Olli_Pettay
16:08:54 <Zakim> +Olli_Pettay; got it
16:08:54 <cwilso> Present+ Chris_Wilson
16:08:54 <israelh> present+ israel_hilerio
16:08:54 <FerasM> Present+ Feras_Moussa
16:08:55 <MikeSmith> Present+ MichaelTmSmith
16:08:57 <john_hazen> Present+ John_Hazen
16:08:59 <falken> Present+ Matt_Falkenhagen
16:09:01 <smaug> Zakim, nick smaug is Olli_Pettay
16:09:01 <Zakim> ok, smaug, I now associate you with Olli_Pettay
16:09:07 <BenjamP> Present+ Ben_Peters
16:09:16 <adrianba> Present+ Adrian_Bateman
16:09:44 <zqzhang> zqzhang has joined #webapps
16:09:47 <hayato> Present+ Hayato_Ito
16:10:01 <zqzhang> Present+ Zhiqiang_Zhang
16:10:06 <Deen_King-Smith> Deen_King-Smith has joined #webapps
16:10:33 <Deen_King-Smith> Deen_King-Smith has left #webapps
16:10:48 <dksmith> dksmith has joined #webapps
16:10:52 <ArtB> RRSAgent, meeting spans midnight
16:11:05 <opoto> opoto has joined #webapps
16:11:13 <opoto> present+ Olivier_Potonniee
16:11:23 <xiaoqian> xiaoqian has joined #webapps
16:12:35 <Zakim> +[Paypal]
16:12:58 <smaug> hello all
16:13:47 <genelian_> genelian_ has joined #webapps
16:14:12 <genelian_> present+ Gene_Lian
16:14:42 <jinsong> jinsong has joined #webapps
16:14:55 <ArtB> zakim, who's here?
16:14:55 <Zakim> On the phone I see ??P2, Olli_Pettay, [Paypal]
16:14:57 <Zakim> On IRC I see jinsong, genelian_, xiaoqian, opoto, dksmith, zqzhang, rniwa, BenjamP, adrianba, israelh, krisk, Arrrno, aizu, alia, RRSAgent, Zakim, Bin_Hu, FerasM, lmclister, smaug,
16:14:57 <Zakim> ... john_hazen, ArtB, anssik, chaals, stryx`_, astearns, richt_, dom, skddc, hayato, kochi, paul___irish, krijnhoetmer, tobie__, morrita, slightlyoff, dfreedm_, cwilso, timeless_,
16:15:01 <Zakim> ... scheib__, jsbell, dcooney, dglazkov, cabanier__, krit, tyoshino, hober, falken, Domenic_, pdr__, gavin, tzik, shepazu, jgraham, decadance, gsnedders, heycam|away, schuki
16:15:23 <ArtB> RRSAgent, make minutes
16:15:23 <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/11-webapps-minutes.html ArtB
16:16:54 <MikeSmith> Zakim, who's on the phone?
16:16:54 <Zakim> On the phone I see ??P2, Olli_Pettay, [Paypal]
16:17:25 <jmajnert> jmajnert has joined #webapps
16:17:31 <anssik> zakim, ??P2 is me
16:17:31 <Zakim> +anssik; got it
16:18:31 <jungkees> jungkees has joined #webapps
16:18:38 <jungkees> Present+ Jungkee_Song
16:19:34 <Travis> Travis has joined #webapps
16:20:22 <israelh> Topic: Web Components
16:20:32 <adrianba> scribe: israelh
16:21:35 <plh> plh has joined #webapps
16:21:51 <israelh> dglazkov: WOuld like to break down discussion into three topics: Shadow DOM, Custom Elements, and HTML Inputs
16:21:54 <aizu> aizu has joined #webapps
16:22:00 <adrianba> s/Inputs/Imports/
16:22:13 <israelh> ... Shadow DOM is the more interesting.  Let's pick which one we want to discuss first.
16:22:25 <israelh> ... Start with Custom Elements ?
16:22:33 <krisk> s/WOuld/Would/
16:22:39 <israelh> ... Shadow DOM after that?
16:22:54 <israelh> ... Custom elements is in first draft
16:23:05 <ArtB> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html -> Custom Elements Editor's Draft
16:23:17 <dglazkov> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578
16:23:23 <israelh> ... And interesting topic to start with 24578 buhg
16:23:30 <israelh> ... Registering a register primitive
16:24:27 <israelh> ... Having the ability to expose internal attributes on Customer elements allow you to clone it, assing it to a different document
16:25:02 <ArtB> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567#c69 -> Anne's comment #69 for bug 20567
16:25:21 <israelh> ... The idea is that when an element is adopted from one doc to another, and as an an author of the element you will get a callback that allows you to reason about the attribute being used in other elements
16:25:58 <israelh> ... also, the idea that you could use the registry as a way to scope the element names.
16:26:24 <alia> alia has joined #webapps
16:27:27 <alia_> alia_ has joined #webapps
16:28:04 <israelh> ... a web developer has a sub-tree in their document and would like to parse their specific elements from the local registry.  Having a scoping concept would be very useful for them.  However, if you want to rountrip when coming back form the parse you would have problems
16:28:22 <israelh> ... because when you serialize the tree the parse would have no idea of where that element came from, thus surprising.
16:28:45 <israelh> ... I would like to introduce the registry concept into the spec and see where it goes from there.
16:29:03 <israelh> ... I want to allow allowNode callback to reason about registries.
16:29:21 <israelh> ... I would like to get everyone's opinion about it.
16:29:48 <israelh> rniwa: What is the use case for the callback.
16:30:34 <israelh> dglazkov: deeper into this subject.  IE and FF have a behavior that is different from blink and WebKit and their prototype when it is adopted from another doc.
16:30:58 <israelh> ... IE and FF when you are adopted from one doc to another, you loose your old prototypes.  Blink and WebKit don't do that.
16:31:11 <israelh> ... there is disagrements whether this should be on spec.
16:31:51 <israelh> ... the callback we are discussing provides a mechanism to allow elements to update the prototypes dynamically. Thus, becoming and implementation detail instead of part of the spec.
16:32:32 <israelh> rniwa: it might be more useful to standardize the UA behaviors instead of putting this on the hands of the devs.
16:33:09 <israelh> dglazkov: for custom elements this decision is not so clear.  It is not always clear what is the right behavior.  Specially if the definintion of my element is not defined on the new environment.
16:33:30 <israelh> ... element foo may colide with a different definition of another element foo on that document.
16:33:59 <israelh> rniwa: it seems strange that each doc would behave diff on each environment.  It doesn't allow you to reason about the custom element on the environment that is being used.
16:34:24 <israelh> dglazkov: this seems bad if you don't have the ability to reason about the custom elements diff.
16:34:30 <israelh> adrianba: it would be bad.
16:35:03 <israelh> rniwa: it seems like we need to figure out how we can guarantee that the custom element keeps the same information across document.  Maybe this is the issue.
16:35:19 <israelh> dglazkov: that is what registers let you do. You can look at the registry and reason about this.
16:35:55 <israelh> rniwa: potentially you can have a global map for each page. that checks if the definition of the class has been raised and possibly rejected.  Some type of consistency check.
16:36:29 <israelh> ... we probably don't want to reason about having different custom elements that are of the same expected type.
16:36:52 <israelh> dglazkov: the thing is that it doesn't have to be the case, the problem is that the scenario could happen and we need to figure out how to deal with this.
16:37:41 <israelh> rniwa: for ex. you can imagine the registry happening about all in one script context, within one navigation.
16:38:14 <israelh> dglazkov: there is a specific reason the registry is scoped to the doc.  because each doc could have its own set of elements.
16:39:00 <israelh> ... in xhr docs don't have a registry for custom elements and don't run script.
16:39:17 <israelh> ... there is no document in browsing context.  there is no association between document and browser context.
16:39:35 <israelh> rniwa: in the case of XHR, there isn't any document context.
16:40:06 <israelh> dglazkov: the create implementation of create document should have a document context.
16:40:17 <KenjiBX> KenjiBX has joined #webapps
16:41:08 <israelh> ... (looking at spec chapters looking for something )
16:41:31 <rniwa> s/document context/browsing context/
16:42:27 <israelh> ... creating and passing a regisry section, we do associate a new registry at that point when creating a new import document (those things don't have a browsing context but are able to operate as if they had a registry)
16:42:51 <israelh> ... It is a good idea to look at this bug 20567 and understand what needs to be done here.
16:43:00 <dglazkov> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567#c69
16:43:22 <israelh> rniwa: exposing a list of custom registries seems like a good thing. but I'm not sure how the ability to update the definition of the doc using this information is a good idea.
16:43:51 <israelh> adrianba: if you end up with a button and import a different button (but when looking at the elements they look the same) that seems like a bad situation.
16:44:24 <israelh> dglazkov: I agree this is a bad situation, that is what we are trying to solve.
16:44:40 <israelh> ... this is not a use case, it is more of how do we deal with this if it happens.
16:44:54 <israelh> adrianba: can we just say that the call fails and the element doesn't work.
16:45:40 <israelh> dglazkov: it seems reasonable to make it work, however we need to reason about their seirialization differences.
16:46:26 <israelh> adrianba: can we clone the prototype?
16:46:47 <israelh> ... if we import from one doc to another and then clone the prototype things might work.
16:47:42 <israelh> dglazkov: I'm not sure there is a concept of cloning the prototype.  the notion that you are attached to the old world, where someone creates a doc, registers things to it, import those notes, but not sure why you would do that although it is supported.
16:48:04 <israelh> rniwa: maybe we could have the registry that is shared across elements that come from the same origin.
16:48:33 <smaug> what does cloning the prototype mean? should the expando properties from the old prototype be cloned too?
16:48:55 <israelh> ... if we do that, we have the same issue where one prototype has multiple def, but if we had this mechanism (park all docs in the same origin) we might be okay if registration is simulatneous. It would reduce the instance in which the def are diff.
16:49:23 <mjs> mjs has joined #webapps
16:49:24 <israelh> ... after we create the object, that doesn't mean that the two objects are the same.
16:49:28 <mjs> q+
16:49:41 <israelh> dglazkov: if you want to compare, you would have to introduce the abiltiy to compare diff between elements.
16:50:26 <israelh> rniwa: if we allow customents, we need to provide that ability to compare themselves.  This could be a big developer issue.  We need to come up with a solution where we don't burden the author of the custom element.
16:51:31 <plh> ack mjs
16:51:54 <israelh> mjs: clarification, do we have the usecase for adapt a custom element from one doc to another, is this a real case or theoretical.
16:52:13 <israelh> adrianba: is the situation where the custom element has the same name but a different instantiation
16:52:44 <israelh> mjs: can we just let this scenario fail, or do we need to support it? failing seems like a good approach if this is an edge case.
16:53:10 <israelh> dglazkov: I didn't say this wasn't sufficient, i would like to reduce the number of errors we throw.
16:53:26 <israelh> ... yes it simplifies but it will likely anoy the developer.
16:53:46 <israelh> mjs: It will only anoy the author if this is a common case, otherwise he should be okay.
16:53:53 <KenjiBX> +q
16:54:23 <kochi_w3c> kochi_w3c has joined #webapps
16:54:23 <israelh> dglazkov: there are many shades of gray here. There is a reasonable situation with HTML templates when you are moving from a template to the main document.  We need to support this situation, we don't want to throw.
16:54:38 <ArtB> q?
16:54:43 <israelh> mjs: there are simple behaviors we could support without throwing.
16:55:14 <israelh> ... (talking about possible options). buttom line we should err on the side of simplicity.
16:55:39 <Yves> msg &systeam triple checked which passwd, the old or the new one? ;)
16:55:51 <israelh> dglazkov: the main case where we need to do the right thing is when we deal with multiple docs that are import docs and templates.  Those things have to work, if we start messing with the definitions there we are in trouble.
16:55:59 <Yves> s/msg &systeam triple checked which passwd, the old or the new one? ;)//
16:56:09 <israelh> mjs: import docs share the same registry.
16:56:33 <israelh> ... requiring docs to deal with extra complexities seems difficult to address as a component author.
16:57:17 <israelh> dglazkov: what complexity are you talking: adapt mode callback and registry?  The adopt mode callback allows for changes to be reacted when loading resources.
16:57:41 <israelh> mjs: do custom elements allow for remove and insert into documents?
16:57:43 <israelh> dglazkov: no
16:58:22 <israelh> mjs: adapt doesn't seem like a special case unless, many people have already created custom elements without this functionality.
16:58:49 <israelh> dglazkov: not sure how DOM core works here. Anne had some ideas here.  We can definetely talk about the importance of this callback.
16:59:13 <israelh> mjs: what is the correct venue to discuss this?
16:59:20 <israelh> dglazkov:  20567 bug is the right venue for this.
16:59:30 <adrianba> ack next
16:59:40 <rniwa> +q
16:59:49 <israelh> KenjiBX:
17:00:25 <israelh> KenjiBX: it seems there is no real case, and the conclusion is to make it fail.  If we find out later that there is a use case, can we then deal with this situation.
17:01:23 <israelh> dglazkov: I beleive this is reasonable. That is the reason I wanted to bring it up to the group. I wanted to get everyone's opinion in the need to register.  I will put it in the back burner.  THere are some usescases  that might help.  I'm not feeling the love right now.
17:01:47 <israelh> ... we can talk about the difference between adoption and registration.
17:01:58 <ArtB> ack rniwa
17:02:07 <israelh> mjs: adpation node without inserting anywhere is very rare, (doesn't seem to happen).
17:03:47 <israelh> ... if they were to change to insert doc and remove doc, then we could easily look for customer default view.  if we had that, elements could check that.  If I had the option of adding the adapt callback then I would prefer the ability to inserting attach and detach.
17:04:02 <ArtB> Present+ Maciej, Laszlo_Gombos, Alex_Russell
17:04:27 <israelh> mjs: if we had remove and insert, we could simplify the operations.
17:04:37 <tantek> tantek has joined #webapps
17:04:50 <israelh> dglazkov: please provide feedback on bug and state your opinion, it could be that what you are suggesting is good enough.
17:05:15 <israelh> mjs: maybe we should have a different bug on remove and add callback
17:05:41 <rniwa> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24577
17:05:49 <israelh> dglazkov: there seems to be one bug on this (24577)
17:07:23 <israelh> mjs: I think Anne in this bug is looking at the leaking of the entire document when the element moves.
17:07:53 <israelh> dglazkov: any help here would be appreciated, maybe if we solve this problem we might be in good shape for the previous bug.
17:08:14 <israelh> mjs: It seems like letting thing fails would be the initial good approach for this.
17:08:37 <israelh> ... perhaps the concept of a global registry that is shared everywhere could be an interesting approach.
17:09:13 <israelh> dglazkov: let's work on these two bugs and discuss the possibility to add remove and add from document concepts.
17:09:57 <israelh> dglazkov: is the ship in the water or the deep in the ground :-)
17:10:05 <alia> Scribe: Ali
17:10:09 <alia> ScribeNick: alia
17:11:10 <alia> dglazkov: I need something in my custom elements to mean something different. Use case: I'm building a framework. Custom elements are in and out of the framework. Inside is the plumbing that uses custom elements because it's useful. How to separate the two and don't expose to each other.
17:12:13 <ArtB> RRSAgent, make minutes
17:12:13 <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/11-webapps-minutes.html ArtB
17:12:14 <alia> ... Shadow DOM is a good example. Parser is per docment. But that seems like a bad idea. Maybe we could let the frameworks define the registry that contains the internal plumbing and feed it to innerHTML of the fragment parsing of the shadow trees that they're creating so that when they create these things they get the definitions of these outside elements.
17:12:33 <ArtB> RRSAgent, make log Public
17:12:48 <mjs> q+
17:12:53 <ArtB> RRSAgent, make minutes
17:12:53 <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/11-webapps-minutes.html ArtB
17:13:16 <alia> ... Allows the ability to scope the parser. Bringing up here. Give me a doc registry and add stuff to it. May have a method that is in addition to pass the registry.
17:13:21 <Lachy> Lachy has joined #webapps
17:13:47 <alia> ... Can put things in template and as it's being inserted into the shadow tree, they will be inflated the proper way. Not sure if this is outlandish or crazy or both.
17:14:37 <ArtB> ack mjs
17:14:44 <alia> mjs: Want to understand the use case better. Two possible meanings. An element that is used in the light DOM. TR in TABLE. TR outside of TABLE is not sensical. Other compound elements that have these structures. Want to have some elements as implementation details.
17:15:34 <alia> dglazkov: You're right on. Shadow DOM is the prime use case, but there are some thoughts on this in light DOM. Parent changes the meaning of the element outside.
17:16:02 <alia> mjs: Need different ways of dealing with these two cases. Need an attachment of the custom element to be conditional based on the parent element.
17:16:10 <alia> ... Which do we want?
17:16:33 <alia> dglazkov: I don't care how it's fixed, but we need a fix. In my mind, having meaning changed based on the parent is a path to madness.
17:16:53 <adrianba> q?
17:17:03 <alia> mjs: Want to refactor internal implementation. Two completely different use cases.
17:17:36 <alia> dglazkov: When a developer has no Shadow DOM, they only have one of them. Here is my internal and external stuff. Spoken from a developer who has not ever had a shadow tree.
17:17:54 <rniwa> q+
17:18:33 <alia> alexrussel: We don't know what we don't know in this area. We don't know what people actually want to do. If we make it possible to create new local namesets, it removes any incentive to agree on global names. We lose our ability to define elements and custom semantics. Would lose value on the web.
17:19:46 <alia> mjs: Depends on which use case. Some degree of global agreement. There can be imports, but some internal that it can use. Cleaner way to do it, than have scoped registry. Only some of the names I define can be exported. May change the way the that import function works, so it is not suggested we do it right now.
17:20:18 <alia> ... TR almost makes sense in the context of the TABLE element. There are specific elements that are defined in this hierarchy.
17:21:09 <alia> ... It seems obvious that people would want to build things like this. It clearly is a use case. Do not agree with using private names would reduce incentive to create global names.
17:21:38 <alia> ... Get developers to participate in the group so we can have a direct conversation with them to understand the use cases better.
17:22:04 <alia> ... It would help if you want clarification on this feedback to ask them directly.
17:22:09 <alia> dglazkov: I will try to get people.
17:22:23 <alia> ... We have beaten this registry thing pretty well. Moving on to custom elements.
17:22:55 <alia> ... I want to tackle exposing element on callback queues first.
17:23:07 <ArtB> http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0074.html -> Dimitri's topic list
17:23:20 <alia> ... There was a valid point brought up that custom element spec reminds us of a special kind of mutation observers.
17:24:22 <jsbell_> jsbell_ has joined #webapps
17:24:31 <alia> ... In the custom elements spec, in queueing and invoking callback. The general idea is there is a quantum of time for invoking callbacks that is different than queueing callbacks. Might be a good idea to expose this a mutation observer so that developers can start using it directly.
17:24:37 <alia> ... Want to gauge opinion.
17:25:24 <dglazkov> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24579
17:25:39 <FerasM> FerasM has joined #webapps
17:25:48 <alia> rniwa: Only feedback is that it is vaguely specified. Transitioning between scripts. Multiple stacks of user scripts and user agent scripts that would result in messy situation. Running two user scripts with an interleaved DOM script based on the spec's wording. Could use more clarification.
17:26:21 <alia> dglazkov: Posted a bug 24579. After callback, drain the pool, so that we can fix the problem
17:27:02 <alia> mjs: Super inconvenient because every native method that does this wouldn't require annotation. If implementations are done in native and client code, the draining needs to be conditional. There are some cases when this could happen.
17:27:48 <alia> dglazkov: This is a separate topic and so we need to separate the abstractions. Need to separate the quantum of time for callbacks and queueing. Start trusting it in a certain point in time and stop at a certain point in time.
17:27:59 <alia> ... Only a few methods that do this.
17:28:16 <alia> mjs: There are many methods that don't mutate DOM but could mutate script that mutate DOM.
17:28:32 <dglazkov> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/Element.idl
17:29:24 <alia> dglazkov: Already done this in Blink, if you look at the element.IDL, you would see a bunch of Custom element callbacks. Some of them, some will, but it's not really that bad.
17:29:36 <alia> mjs: Let me ask a specific quesiton, does dispatch event have this notation?
17:29:44 <alia> ... Could retake the DOM.
17:29:52 <alia> dglazkov: Dispatch event itself does not mutate DOM.
17:30:11 <ArtB> q?
17:30:34 <alia> ... In the event handler will have its own draining which will arrive at a consistent state.
17:30:51 <alia> mjs: Will always be at a safe point in this case.
17:31:00 <ArtB> ack rniwa
17:31:22 <morrita> Just FYI: https://code.google.com/p/chromium/codesearch#search/&q=CustomElementCallbacks%20file:idl
17:31:27 <john_hazen> s/could mutate script/could include script/
17:31:30 <alia> dglazkov: Trying to wrap up mutation events. Did not participate in mutation observers but will give it a shot and see what I can come up with.
17:32:24 <alia> rniwa: Jonas pointed out on one of the threads is that mutation observers calling each other back while in an observer itself, with this new nano task timing, it's possible to create an element in the observer and that could create an issue.
17:33:43 <alia> dglazkov: When changed to a generic mechanism, but solved by queues. Need to look into this in more detail. Mutation observer observes per element, narrowed down. An element queue and a callback queue, and every element has an element queue, separating these out allows for handling this in a consistent fashion.
17:34:10 <alia> rniwa: Trying really hard to solve issue where removing the element itself.
17:34:45 <alia> dglazkov: Going to see them being called in the same order for consistency. If observing yourself, you see that you are being attached.
17:35:03 <alia> mjs: I don't think that's the biggest problem. The problem is that attaching can occur inside the attach.
17:35:53 <alia> ... In attach callback that removes a node, inside the attach, document.body.appendChild(this). Inside that attach, you would insert back in the document, at which point you would be calling attach again.
17:36:51 <alia> dglazkov: The element queue solves this. While inside of the attach handler, you won't hear any callbacks until completion. What is the element that you're procesing and which is the callback you're processing is asked when there is an execution.
17:37:25 <alia> rniwa: Attach will be called, but the detach will be called later.
17:37:37 <mounir> mounir has joined #webapps
17:37:44 <alia> dglazkov: After finishing running callback of attach, then attach would occur.
17:38:23 <ArtB> q?
17:38:48 <alia> ... When using element callbacks, you have to rely on what the callbacks tell you, because the state is going to tell you either you're going to observe the outside world or only the callbacks that arrived. If you have been detached despite having been attached, it will work because you can trust the callbakcs.
17:38:59 <alia> s/callbakcs/callbacks
17:39:53 <alia> rniwa: In the custom code, there may be some event that asynchronously causes issues.
17:40:28 <alia> ArtB: Now going to break, coming back at 11.
17:43:01 <marcosc> marcosc has joined #webapps
17:59:44 <ArtB> RRSAgent, make minutes
17:59:44 <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/11-webapps-minutes.html ArtB
18:02:03 <krisk> krisk has joined #webapps
18:02:06 <krisk> scribe: krisk
18:02:46 <darobin> darobin has joined #webapps
18:03:24 <Zakim> -Olli_Pettay
18:03:38 <smaug> (another meeting)
18:03:52 <rniwa> rniwa has joined #webapps
18:04:32 <plh> plh has joined #webapps
18:04:34 <kochi_w3c> kochi_w3c has joined #webapps
18:05:12 <krisk> artb: proposes to have a meeting once in a while for web components
18:05:15 <mjs> mjs has joined #webapps
18:05:16 <ArtB> ACTION: barstow work with Dimitr re a Web Components calls/meetings
18:05:16 <trackbot> Created ACTION-727 - Work with dimitr re a web components calls/meetings [on Arthur Barstow - due 2014-04-18].
18:05:27 <krisk> ACTION: artb setup semi regular meeting for web components
18:05:27 <trackbot> Created ACTION-728 - Setup semi regular meeting for web components [on Arthur Barstow - due 2014-04-18].
18:05:32 <krisk> TOPIC: Custom Elements
18:05:44 <krisk> ..automatic upgrade of custom elements
18:06:04 <krisk> dglazkov: I'd like to present a use case for this..
18:06:13 <krisk> ..after an element is registered
18:06:42 <krisk> ..section 7 in spec, step #7 (run element upgrade algo)
18:07:38 <krisk> If an element in or outside of a tree when the registation comes around the element will take the right shape
18:08:10 <krisk> The key use case was that when we would run queryselector would not work (shadow doms)
18:08:20 <krisk> ..we wanted to make this easier for devs
18:08:48 <krisk> The side effect is that a sync loaded document, framework devs want to get to a consistent state and don't want to do extra work
18:09:20 <krisk> ..When I talked to amber, they were very unhappy I removed this from the spec (which I didn't) and then they were very happy
18:10:04 <krisk> ..They don't want to have to deal with ambiguity when this element will be completed
18:10:34 <krisk> It's basically queryselectorall'ible everywhere
18:10:53 <krisk> mjs: Some people from apple don't like this...
18:11:18 <krisk> ..You want to load some custom element - three problems
18:11:46 <krisk> ..web page load parse is slow, forces UA do display partial display
18:12:05 <krisk> ..Manually have to go check or manually upgrade these elements
18:12:21 <krisk> If you just want to know when the state is done and complete
18:12:45 <krisk> ..you could wait until all are done loading, not optimal, if one set if slow
18:13:30 <krisk> The third option is what is in the spec, if you access the element before the upgrade has been complete you have a problem
18:13:50 <krisk> ..which is a hazard - accessing an html element proto
18:13:58 <krisk> ..so you have to wait
18:14:14 <krisk> Either way you better not do any scripting untill all is complete
18:15:07 <krisk> dglazkov: The key part you can access this until the upgrade has completed
18:15:17 <krisk> mjs: you can't save a ref
18:15:38 <krisk> dgazkov: it will always be the same ref
18:15:57 <krisk> .The swizzle doesn't modify the change...
18:16:41 <krisk> ..we ensure the swizzle only adds more items on top of the proto
18:17:48 <krisk> mjs: Let me ask a clarifying question..
18:18:13 <krisk> dglazkov: you can't go from select to my custom select
18:18:31 <krisk> mjs: can you not only do this with a generic html element?
18:19:30 <krisk> dglazkov: you need to specificaly call to extend select
18:19:37 <arunranga> arunranga has joined #webapps
18:20:19 <krisk> dglazkov: this make sure that you only insert items at the top of the prototype chain
18:20:41 <krisk> ..Then you can save, set prop, to the elements, etc...
18:21:05 <krisk> ..before the upgrade
18:21:35 <krisk> mjs: It seem that from the 3 possible choices, we don't want the bad perf.
18:22:28 <krisk> mjs: you have the hazard or you get the work done but the the proto-type may not be perfect until the upgrade is complete
18:22:49 <krisk> ..It's not required but a nice to have in the base system
18:23:19 <krisk> dglazkov: We have to make sure that with multiple frameworks need a single 'go'
18:23:51 <krisk> mjs: one for of this would be a single event for all is one possible solution, not that I'm saying this is the best solution
18:24:13 <krisk> alex: feedback from users has been pretty strong that not having this ability is bad
18:24:51 <krisk> mjs: how we choose to do 'science' compared to asks from feedback?
18:25:26 <krisk> rniwa: For page that use the old style (display:none)..
18:25:47 <krisk> dglazkov: that has never been the case - psudeo - unresolved whould be the 'match'
18:26:09 <krisk> rniwa: so now if you have some component that load sync, you have to have some style that uses component
18:26:26 <slightlyoff> (I also added that strong feedback across multiple toolkits/users is distinct from weak feedback)
18:27:42 <krisk> dglazkov: this is not a problem at least in webkit and blink
18:28:07 <krisk> dglazkov: the problem we have seen is you really can only do display:none or a block
18:28:18 <krisk> rniwa: let me make my point
18:29:11 <krisk> ..if the author had to specify the style for an unresolved element, which will not be consistent on page load times
18:29:16 <lmclister> lmclister has joined #webapps
18:29:37 <krisk> ..Their is basically no way to get consistent results of the element rendering
18:30:03 <krisk> dglazkov: This has nothing related to upgrade mechanism
18:30:12 <KenjiBX> KenjiBX has joined #webapps
18:31:10 <krisk> mjs: one use case, could be a select control that shows up like a map
18:31:33 <krisk> ..before the upgrade it would look ugly until the upgrade has occured.
18:31:45 <krisk> ..even display: none would be ugly
18:31:58 <krisk> ..no real way exists to fix this problem
18:32:31 <krisk> alex: we shoud ask css to help to get a mechanism to be in control of the display/paint/rendering can start
18:33:38 <krisk> dglazkov: web devs do bad patterns to try to control this pattern, like in editing..
18:34:02 <krisk> ...one framework uses document.write...
18:34:56 <krisk> rniwa: can we take this upgrade to the mailig list?
18:35:05 <krisk> dglazkov: sure
18:35:19 <tantek_> tantek_ has joined #webapps
18:35:29 <krisk> rniwa: To help close on the flash of styling issues
18:35:45 <krisk> TOPIC: Shadow Dom
18:35:56 <dglazkov> smaug: are you there?
18:36:01 <smaug> just a sec
18:36:03 <krisk> yves will now scribe!
18:36:05 <Yves> scribe: Yves
18:36:10 <smaug> now
18:36:12 <Zakim> +[IPcaller]
18:36:45 <darobin> Zakim, [ is smaug
18:36:45 <Zakim> sorry, darobin, I do not recognize a party named '['
18:36:52 <darobin> Zakim, +[ is smaug
18:36:52 <Zakim> sorry, darobin, I do not recognize a party named '+['
18:37:28 <smaug> good
18:37:39 <dglazkov> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887
18:38:58 <dglazkov> https://etherpad.mozilla.org/RKukNtHHlO
18:39:09 <Yves> rniwa: issue is about nested shadow dom
18:39:25 <Yves> dglazkov: etherpad above has canonical examples
18:40:32 <skddc_> skddc_ has joined #webapps
18:41:59 <Yves> rniwa: why firing the even at the last insertion point is not enough?
18:42:50 <Yves> dglazkov: as the insertion point is at the most nested place, the nesting shadow tree does not hear the event
18:42:59 <rniwa> s/the even at/the event at/
18:43:52 <Yves> one solution was to generate interim div to listen to the insertion point, which is bad as well
18:43:55 <ArtB> q?
18:44:15 <Yves> the specs breaks the invariant that item in the even path are always children of the next item
18:46:09 <Yves> rniwa: is the spec bz's proposal?
18:46:27 <Yves> dglazkov: no it's the other one
18:47:06 <smaug> ++ rniwa
18:49:05 <Yves> (Hayato Ito describes the alg)
18:52:18 <Yves> Hayato: the second algorithm has more complexity
18:53:27 <Yves> dglazkov: I agree that preserving the invariant is desirable
18:53:41 <smaug> more ++ to rniwa
18:53:56 <smaug> rniwa: were you surprised somehow?
18:54:25 <Yves> rniwa: to me, bz's proposal make more sense. Much easier for developers
18:54:43 <Yves> ArtB: looks like we have a way forward here
18:56:57 <Yves> maciej: how about discussing encapsulation?
18:57:17 <darobin> ScribeNick: darobin
18:57:38 <mjs> http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0312.html
18:57:44 <darobin> mjs: back in Dec 2012 we had a big discussion about Components and traversability of the shadow DOM and how that relates to encapsulation
18:57:48 <darobin> ... the upshot was this
18:58:00 <darobin> ... previous to that the shadow was not traversable from the outside, after it was
18:58:17 <darobin> ... we tentatively agreed that it made sense to provide both public and private modes, and even a more isolated mode
18:58:29 <darobin> ... I would really like it if at least the public and private mode could both be supported
18:58:39 <darobin> ... isolated mode has some design that needs to be investigates
18:59:01 <darobin> ... private might be the wrong name, give the impression of a security boundary, we could say open/closed
18:59:17 <darobin> ... I'd really like to address this before it's too late to make changes to how shadowRoots work
18:59:23 <darobin> ... what can I do to help move this forward?
18:59:36 <darobin> dglazkov: I totally want to do these modes
18:59:58 <darobin> ... because of the opacity of the style engine we don't have a great way of controlling this
19:00:01 <darobin> ... in JS it's easy
19:00:11 <darobin> ... but for styling we don't have a way to prevent this
19:00:20 <darobin> ... I udnerstand the need for it, I want to add it to the spec
19:00:33 <darobin> ... I can make it the next thing I work on
19:00:44 <dglazkov> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144
19:00:45 <krisk> s/udnerstand/understand/
19:01:01 <darobin> dglazkov: the way I thought I'd tackle this problem
19:01:13 <darobin> ... today you don't pass anythin when you create a shadow
19:01:18 <darobin> ... we could pass in a property bag
19:01:29 <darobin> ... I would suggest a string value so that we can add isolated later
19:01:48 <darobin> s/... I would suggest/mjs: I would suggest/
19:01:57 <darobin> dglazkov: maybe we could close style separately
19:02:21 <hallvors> hallvors has joined #webapps
19:02:24 <darobin> mjs: there are interesting side effects with querySelection then
19:02:34 <darobin> dglazkov: so it could be a single flag
19:02:51 <darobin> ... the ability to look inside is important because tools need introspection
19:03:09 <darobin> mjs: it doesn't make sense to do these separately (matching selectors, looking into the DOM)
19:03:15 <darobin> ... because you can use one to do the other
19:03:22 <darobin> dglazkov: I think that's reasonable
19:03:44 <darobin> mjs: if it's a string, we can add one later. Scales better than bag of booleans
19:04:00 <darobin> dglazkov: we have to prevent people to style into built-in element, so we have this mode
19:04:26 <darobin> ... to me it was literally a matter of getting to do this, got distracted
19:04:34 <darobin> ... I can start working on this
19:04:46 <darobin> mjs: I'm willing to offer help with reading, implementing, etc.
19:04:51 <darobin> ... I'm very interested in getting this in
19:05:09 <darobin> ... I thikn it's a fundamental building block for fully isolated components, which I think are a great use case
19:05:26 <darobin> dglazkov: I've also been looking at implementing all the HTML elements as custom elements
19:05:31 <darobin> ... so this is useful for that too
19:05:39 <hober> MikeSmith: I went to create a bug on the Shadow Styling spec, blocked on 20144, but there's no component for it in Bugzilla.
19:06:22 <darobin> rniwa: should we discuss which should be the default?
19:06:26 <darobin> [hilarity ensues]
19:06:41 <darobin> mjs: let's do the uncontroversial part first, debate later
19:06:48 <darobin> dglazkov: next?
19:07:05 <darobin> mjs: isolation?
19:07:21 <darobin> dglazkov: I would like insight
19:07:26 <darobin> mjs: one thing I noted in the bug
19:07:43 <darobin> ... there are 2 things you need, DOM encapsulation, and a walled-off scripting environment
19:07:50 <darobin> ... no global namespace, clean prototypes
19:08:08 <falken> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16509
19:08:10 <darobin> ... you also need sanitising paramters passed in and their return values from methods
19:08:23 <darobin> ... you need to rewrap DOM nodes across the boundary
19:08:30 <darobin> ... so you need Structured Clone Plus
19:08:39 <darobin> ... otherwise you can pass trapped values
19:08:46 <darobin> dglazkov: I think you're right.... eventually
19:09:06 <darobin> mjs: if you want the page to be protected, you need a support mechanism other than script tag
19:09:12 <darobin> ... you need to run script safely
19:09:25 <darobin> ... XBL2 has a way of addressing things, you can import things
19:09:46 <darobin> ... pretty different from HTML Import which has script run in your context
19:09:56 <darobin> ... for safe imports you need a different mechanism
19:10:03 <darobin> dglazkov: there's a proposal for a DOMWorker
19:10:11 <darobin> ... a Worker that runs in your thread in step
19:10:22 <darobin> ... postMessaging only, can be loaded x-origin
19:10:34 <darobin> ... but once loaded is in its own worker
19:10:41 <darobin> mjs: can it export its registration?
19:10:48 <darobin> dglazkov: no, it works in its own shadow
19:10:54 <darobin> ... the worker manages the element
19:11:07 <darobin> ... the element acts from the outside as if it has a shadow tree but you can't get to it
19:11:15 <darobin> ... but from the inside it has a shadowRoot
19:11:19 <darobin> mjs: that seems insufficient
19:11:33 <darobin> ... you need to be able to register from the inside and sanitisation at the boundary
19:11:48 <darobin> slightlyoff: you can get that by reducing the surface area to attributes
19:11:54 <darobin> ... forward the attribute changes
19:12:13 <darobin> mjs: if your goal is to implement HTML this is not enough, elements need to expose APIs
19:12:23 <darobin> dglazkov: I feel that HTML elements don't need that
19:12:41 <darobin> mjs: e.g. video and canvas are useless without APIs
19:12:54 <darobin> dglazkov: yes, but HTML does not need isolation
19:13:07 <darobin> ... isolation is collaboration between components that don't trust one another
19:13:19 <darobin> ... it seems to me the HTML elements model is different
19:13:31 <darobin> mjs: HTML elements certainly don't trust the page
19:13:39 <darobin> ... but I'm not sure that saves you a lot of complexity
19:14:04 <darobin> ... HTML element have a membrane where elements are sanitised, more than cloning since it supports DOM nodes and such
19:14:31 <darobin> dglazkov: you could define an IDL for contract
19:14:52 <darobin> rniwa: in a way yes, we can create a wrapper object for the prototype and function calls are forwarded after sanitisation
19:15:17 <darobin> mjs: in and out values get converted in the same way as they do for JS/C++ communication
19:15:36 <darobin> slightlyoff: only asynchronous?
19:15:46 <darobin> mjs: that's not powerful enough to implement HTML
19:16:01 <darobin> ... do we need to be able to do HTML, or is "like HTML but asynchronous" enough?
19:16:06 <darobin> dglazkov: I'd like to be able to implement HTML
19:16:16 <darobin> ... as an aspirational goal, though maybe not reached
19:16:22 <darobin> mjs: I think it's not impossible
19:16:28 <darobin> ... XBL had something that was powerful enough
19:16:39 <darobin> ... it's a question of what you're willing to give up
19:16:58 <darobin> ... if DOM Workers are already in the same thread, then you don't lose much by allowing sync methods
19:17:10 <darobin> ... it's important to be clear on whether something is an actual goal
19:17:39 <darobin> ... as a reviewer I need to know what the goals are
19:17:46 <darobin> dglazkov: so I think it's an actual goal
19:17:59 <darobin> ... is the [Like] button thing the same scenario
19:18:06 <darobin> ... as the built-in HTML elements
19:18:24 <darobin> mjs: the like widget case it needs communication with the communication case
19:18:37 <darobin> ... it would likely not be a dealbreaker to be limited to async and certain data type
19:18:54 <darobin> ... HTML elements need sanitisation on the way in
19:19:13 <darobin> ... returning values also, don't want anyone to violate my internal prototype
19:19:27 <darobin> ... the only thing that the like widget stuff doesn't need is sync communication
19:19:41 <darobin> ... so I think they're similar enough that you could use the same plumbing
19:19:53 <darobin> slightlyoff: we will probably have to rely on ES6 Proxies to define the membrane
19:20:22 <darobin> rniwa: if we really want to make everything async, we could have the wrapper return a Promise, and resolve when the method returns
19:20:39 <darobin> ... there are many ways to solve the issue
19:20:46 <darobin> dglazkov: structure this goal as this
19:20:56 <darobin> ... we at the limit want to implement all of the HTML elements in JS
19:21:14 <darobin> ... similar widgets with trust issues are lower-fidelity subcases of the same
19:21:42 <darobin> rniwa: I'm not sure I agree with this, there are some really funky HTLM elements, do you want to implement <custom-script>?
19:22:32 <darobin> mjs: it's hard because either they'd have to be implemented in terms of existing elements or you'd need new primitives
19:22:51 <darobin> ... also you don't want them to be able to change their parsing, e.g. reimplementing <table> or <script>
19:23:08 <darobin> ... altering behaviour of the parser is beyond membranes
19:23:33 <darobin> dglazkov: the reason you need these membranes is because inside of the element are capabilities you don't want to leak to the author
19:23:52 <ArtB> q?
19:23:52 <darobin> mjs: that's a security issue
19:24:10 <darobin> ... but there's also a robustness issue where if you pass a bad value you don't want a component to barf all over itself
19:24:16 <darobin> ... you need a membrane for that
19:24:25 <darobin> dglazkov: I don't think this is a major point
19:24:31 <darobin> ... I udnerstand what you're saying
19:24:37 <darobin> ... agree 100% on the membrane idaes
19:24:51 <darobin> ... I'm signing up to do this
19:24:58 <krisk> s/idase/ideas/
19:25:37 <rniwa> s/idaes/ideas/
19:25:58 <darobin> mjs: we have to limit ourselves to createElement because the parser is funky, and we have to exclude some unsafe primitives like <input type=file>
19:26:10 <darobin> s/udnerstand/understand/
19:26:24 <arunranga> arunranga has left #webapps
19:26:25 <darobin> ... we need a more fleshed out spec for security review
19:26:53 <darobin> slightlyoff: this sort of primitive allows for all sorts of attacks
19:27:11 <darobin> mjs: there are some existing systems that take control of everything and try to sanitise everything
19:27:20 <darobin> slightlyoff: our experience is that that's very brittle
19:27:40 <darobin> mjs: I tend to be wary of things that are complex and need to be gotten exactly right
19:28:04 <darobin> ... we can make the method membrane isomorphic to postMessage, using the method name as a string
19:28:15 <darobin> ... so it's not necessarily a bigger surface than postMessage
19:28:39 <darobin> [LUNCH]
19:29:04 <ArtB> RRSAgent, make minutes
19:29:04 <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/11-webapps-minutes.html ArtB
19:29:05 <smaug> thanks all
19:29:14 <Zakim> -smaug
20:09:00 <BenjamP_> topic: shadow dom
20:09:00 <adrianba> scribe: BenjamP 
20:09:00 <sicking> rniwa: hey, sorry i didn't make it down today
20:10:00 <sicking> something came up
20:10:00 <BenjamP_> dglazkov: let's spend time on imperative api
20:10:00 <sicking> rniwa: imperative API ++
20:11:00 <dglazkov> https://gist.github.com/dglazkov/ce96f673b0b2ce7b8c55
20:14:00 <BenjamP_> the following is based on the doc linked above- Distribution Callback section.
20:14:00 <BenjamP_> dglazkov: we don't know when to run the callback
20:15:00 <BenjamP_> ... this has to do with how the box trees compose. Previously, we don't have to compute style until later, we can defer it. But problem is we have to run it the callback when you query the property.
20:16:00 <BenjamP_> rniwa: I think it's worse
20:17:00 <BenjamP_> dglazkov: we have an array or add/remove methods. The array can be the filter. The problem is the author has to implement the distribution algorithm by hand. <details> has to set a mutation observer.
20:18:00 <BenjamP_> ... another (bad) idea is selector-based routing. Insert children based on selector
20:18:00 <dglazkov> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429#c4
20:19:00 <BenjamP_> ... this bug shows combination of passive array and selector-based rounting
20:19:00 <BenjamP_> ... so 4 total ideas here. Looking for thoughts
20:19:00 <BenjamP_> rniwa: let's have a list of candidates and notify author when it changes.
20:20:00 <BenjamP_> dglazkov: we could get stuck in 2-resolution loop
20:22:00 <BenjamP_> rniwa: not necessarily. Distribution doesn't need to be synchronous. We could instead compose at the end and notify all. It's okay because we won't paint during the micro-task
20:23:00 <BenjamP_> dglaskov: we don't want it to return 0 because it hasn't rendered. [in steps], what is offset top? Would be zero. This gives ability to reason about what's happening when things are added to the DOM, and you'll see them later.
20:24:00 <BenjamP_> ... author won't know if it has run or not
20:24:00 <BenjamP_> rniwa: similar to custom elements unresolved state
20:24:00 <BenjamP_> ...don't want to expose timing in engine. Synchronous costs perf, async we'll have times when things aren't up to date
20:25:00 <BenjamP_> dglaskov: this doesn't matter for routing
20:25:00 <BenjamP_> ... conceptual model is css
20:26:00 <BenjamP_> ... run it at the end of micro-task. I don't think that's unreasonable. But let's make sure we not confusing users mental model
20:26:00 <BenjamP_> rniwa: selector-based routing has an expensive query, doesn't address random element use case
20:27:00 <BenjamP_> dglaskov: random is solved by selectors. When you create a router you define random
20:28:00 <BenjamP_> rniwa: you have to listen to mutations of your children
20:28:00 <BenjamP_> dglaskov: no you don't
20:29:00 <BenjamP_> rniwa: inserting elements should not break the selection
20:29:00 <BenjamP_> dglaskov: valid point
20:30:00 <BenjamP_> ... you'll sometime have ocasional inconsistency with imperative. That's okay.
20:30:00 <BenjamP_> ... style resolution after callback?
20:31:00 <BenjamP_> ... you could trigger it, but it doesn't typically need to run before callback
20:31:00 <BenjamP_> rniwa: there are times you want to stay in sync and have them happen at the same time
20:33:00 <BenjamP_> dglaskov: insertion point needs an onDistrobution event
20:34:00 <BenjamP_> rniwa: I agree it's weird to get wrong offsetTop, but our options are limited
20:35:00 <BenjamP_> hayato: it's a tough issue
20:35:00 <BenjamP_> dglaskov: if you choose imperative, it may be difficult, but that's ok
20:35:00 <BenjamP_> ... not sure if this is a problem in real life
20:36:00 <BenjamP_> ArtB: something about potatoes
20:36:00 <krisk> +Bacon please
20:37:00 <ArtB> s/something about potatoes/carbos for lunch syndrome/
20:37:00 <BenjamP_> topic: imports
20:37:00 <dglazkov> https://gist.github.com/omo/9986103
20:37:00 <BenjamP_> dglaskov: let's talk about blocking rendering
20:38:00 <ArtB> https://gist.github.com/omo/9986103 -> HTML Imports: Discussion over Async/Progressive Loading
20:38:00 <BenjamP_> ... imports are modeled after stylesheets
20:39:00 <BenjamP_> ... trying to enable asynchronous loading, but sometimes we have to block
20:40:00 <BenjamP_> ... if you have a script block in you doc, your loading imports will be sync with script.
20:41:00 <BenjamP_> ... without <script> it will load in parallel, and will then block on paint
20:41:00 <BenjamP_> Alex: this is not a rule
20:41:00 <BenjamP_> dglaskov: right, but everyone does this
20:41:00 <slightlyoff> BenjamP_: s/dglaskov/dglazkov/
20:42:00 <BenjamP_> dglazkov: *pounds fist*
20:43:00 <BenjamP_> dglazkov: async loading makes other elements change. We've only had sync loading until now, so we didn't see this
20:44:00 <BenjamP_> ... example: twitter doesn't want to block. So we invented async
20:44:00 <BenjamP_> ... still some disagree about default sync/async
20:45:00 <BenjamP_> Alex: speaking for pro-async. Agree that there are 2 different types of users- own the whole page or don't
20:45:00 <BenjamP_> ... even for not-own-whole-page: makes sense to enable doc fade-in. What does it take to achieve? With sync/async: you have little control so you write your own staging code. Works around sync/async order
20:46:00 <BenjamP_> rniwa: what are you ordering?
20:47:00 <BenjamP_> Alex: if building an app: need to pull in code, elements, etc, have an early moment when I want to control (inline script), then pull in dependencies (async). Should we paint early while it's loading, and then paint again when all is available?
20:48:00 <BenjamP_> ... if you're small part of the doc, you want to be able to say when you're ready and provide a placeholder
20:48:00 <BenjamP_> rniwa: 3 state: unresolved, resolved, final
20:48:00 <BenjamP_> ... which part are you talking about?
20:48:00 <BenjamP_> Alex: they're all related
20:49:00 <BenjamP_> ... blocking causes you to have to choose what you are targeting
20:50:00 <slightlyoff> e.g., how would you reason about a hierarchy of things that all need resolution? As Jake Archibald phrases it, the "deeply resolved question"
20:51:00 <BenjamP_> dglazkov: example- if I'm a framework, you have to load basic concepts quickly and do first paint (loading screen?). Then do more things because I've notified the users I'm getting ready. With HTML imports you have 1 sync import that does the quick first paint.
20:51:00 <BenjamP_> ... I want to allow developers to draw a line and say "i want to paint here". Everyone has a 2 phase approach
20:51:00 <BenjamP_> rniwa: this isn't unique to imports
20:51:00 <slightlyoff> one way to think about this is trying to provide explicit API for defining resolution
20:52:00 <BenjamP_> dglazkov: the problem is that they have to fall off the html train right away
20:52:00 <BenjamP_> ... let's think abou this. we won' t solve it here
20:53:00 <BenjamP_> Alex: we're missing a primitve, We want to define resolution. sync/async allow us to create 2 moments- now and later. You're now missing the ability to describe what happens when you get to the resolution
20:53:00 <BenjamP_> rniwa: waiting is a special case; normal state is the final state.
20:54:00 <BenjamP_> Alex: there is a final moment that we should be able to reason about in the code. We don't have resolved/unresolved except for custom elements.
20:54:00 <BenjamP_> ... we don't have a way to talk about dependencies
20:55:00 <BenjamP_> rniwa: if you implement a custom image element, the browser can't reason about when it's ready
20:55:00 <BenjamP_> ... maybe we should load a pseudo element?
20:55:00 <BenjamP_> dglazkov: I'm fine letting developers solve this first and learn from it
20:56:00 <BenjamP_> Alex: decision at first paint needs developer control. Should be able to delay paint until dev is ready
20:57:00 <dglazkov> esprehn!!!
20:57:00 <esprehn> dglazkov: :)
20:58:00 <slightlyoff> scribenick slightlyoff
20:58:00 <BenjamP_> rrsagent,generate minutes
20:59:00 <slightlyoff> dglazkov: I forgot something about imports...will need to bring it up on the list
21:00:00 <slightlyoff> (discussion about next topic, perhaps inheritance)
21:00:29 <RRSAgent> RRSAgent has joined #webapps
21:00:29 <RRSAgent> logging to http://www.w3.org/2014/04/11-webapps-irc
21:00:31 <Zakim> -anssik
21:00:52 <Zakim> + +1.301.460.aaaa
21:00:55 <xiaoqian> rrsagent, make minutes
21:00:55 <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/11-webapps-minutes.html xiaoqian
21:01:02 <slightlyoff> rniwa: one problem we found with the current inheritance model is that if you have an element, say a <random-> element, if you have a subclass that wants to use a different distribution...the <random-> element wants to show the name it's subclassed distribution
21:01:22 <slightlyoff> rniwa: you don't have a way to add an insertion point in shadow DOM that's only available in the subclasses
21:01:43 <krisk> * looks like no logs since after lunch...
21:01:55 <slightlyoff> rniwa: if I have some bit of content that needs to be transcluded in the shadow dom to the subclass from the parent class, how do you do that?
21:02:02 <slightlyoff> dglazkov: you have all the tools....
21:02:13 <slightlyoff> rniwa: how do I set an insertion point that's only for the subclass?
21:02:15 <RRSAgent> I'm logging. I don't understand 'this meeting span midnight', Yves.  Try /msg RRSAgent help
21:02:22 <slightlyoff> dglazkov: that will be coming from the light dom?
21:02:36 <slightlyoff> rniwa: no, it's coming from the subclass
21:03:09 <slightlyoff> rniwa: the way to do it today is to replace the entire shadow dom and place your own things inside it
21:03:31 <ArtB> RRSAgent, make minutes
21:03:31 <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/11-webapps-minutes.html ArtB
21:03:36 <slightlyoff> dglazkov: yes, you have to make sure that your concrete subclasses aren't of other concrete classes
21:04:17 <slightlyoff> rniwa: even if you use an abstract class, the selectors that might match aren't constrained
21:05:17 <krisk> * I can send you a text file, what is your email yves?
21:06:22 <slightlyoff> rniwa: if you have a <uniformally-random> element and a <gaussian-random> element, and the superclass has a distributionName, you can't make sure that you only handle the property in the shadow dom of hte subclass, not the parent class
21:06:29 <slightlyoff> (esphren joins)
21:06:42 <slightlyoff> dglazkov: (revisiting distribution question since we have esphren)
21:07:17 <slightlyoff> esprehn: my issue with the delayed distribution is that it doesn't describe what <details> does
21:07:36 <slightlyoff> esprehn: today if you append to it and then query offsetTop, we'll give you answer immediately
21:07:50 <slightlyoff> esprehn: we only do this at recalc-style time
21:08:43 <slightlyoff> slightlyoff: we have a "takeRecords()" in O.o and Mutation Observer,s why istn't that model workable here?
21:09:04 <slightlyoff> esprehn: we don't have a defined time in the platform for this
21:09:36 <slightlyoff> slightlyoff: so we're missing an API for this kicking off callbacks?
21:09:47 <slightlyoff> dglazkov: so appendChild() is when thigns become real
21:10:13 <slightlyoff> esprehn: we'd need to make sure that children of the <details> element don't have layout information until rAF time
21:10:56 <slightlyoff> esprehn: we have a strong guarantee about shadow roots being unobservable, which isn't true today, and we'd be making it observable
21:11:28 <slightlyoff> esprehn: if we allow scripts to do arbitrary things, we need to define a time for it
21:11:44 <slightlyoff> slightlyoff: are those things (offsetTop, etc.) bugs or features?
21:11:56 <slightlyoff> esprehn: I'd like to make sure that <details> isn't magical
21:12:04 <slightlyoff> slightlyoff: agreed
21:12:15 <Zakim> - +1.301.460.aaaa
21:12:48 <slightlyoff> (discussions of topics and group stamina)
21:12:50 <esprehn> sorry I have to run, but I'm happy to discuss further in the future
21:14:04 <slightlyoff> dglazkov: next issue: 3 quick bugs
21:14:50 <slightlyoff> dglazkov: in my opinion, all of the import documents should be forced to be UTF-8
21:15:06 <slightlyoff> dglazkov: we don't have the usual issues around legacy, so we'll just assume UTF-8...what say we?
21:15:11 <ArtB> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21275 -> [Imports]: Force utf-8
21:15:29 <slightlyoff> dglazkov: developers get unhappy about needing to include explicit including
21:15:35 <slightlyoff> s/including/encoding
21:15:52 <slightlyoff> (charset meta)
21:16:04 <slightlyoff> dglazkov: we'd like to be able to assume UTF8
21:16:28 <slightlyoff> MikeSmith: we're going to fallback to windows 1252 if you don't specify something else, which is wrong
21:16:35 <sicking_> sicking_ has joined #webapps
21:16:47 <slightlyoff> hober: it's a bit weird because it's inconsistent, and the existing behavior isn't something we like...I can see this going either way
21:17:01 <slightlyoff> rniwa: what about XHR?
21:17:22 <slightlyoff> rniwa: matching behavior with XHR might be good. If this is truly odball, it might be confusing
21:18:02 <slightlyoff> dglazkov: (quotes annevk): "UTF8 should be used for anything new"
21:18:39 <slightlyoff> (HTML, a celebration of inconsistencies)
21:18:49 <slightlyoff> hober, MikeSmith: no objection in the room
21:19:02 <ArtB> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24349 -> [imports]: Import documents should always be in no-quirks mode
21:19:02 <slightlyoff> rniwa: I'm not sure I'd object
21:19:11 <slightlyoff> hober: webvtt is already always UTF8
21:19:21 <slightlyoff> adrianba: it's not HTML
21:19:35 <slightlyoff> MikeSmith: I'd recommend that if you feel strongly, participate in the bug
21:19:54 <slightlyoff> slightlyoff: (looking at bug history) when will this be resolved?
21:20:18 <slightlyoff> dglazkov: next topic: import documents should always be in no-quirks-mode
21:20:39 <slightlyoff> (not exactly resolved, 'because we can't do that)
21:21:11 <slightlyoff> dglazkov: next topic: blocking DOMContentLoaded while imports load
21:21:12 <ArtB> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23526 -> [imports]: blocking DOMContentLoaded while HTML imports are loaded
21:21:20 <slightlyoff> morrita: not sure about the context either...
21:21:42 <slightlyoff> morrita: some folks are using this event without waiting for things like <img>
21:21:53 <slightlyoff> morrita: there's no event that's similar to imports already
21:22:04 <slightlyoff> rniwa: presumably this is only for the sync case?
21:22:06 <slightlyoff> morrita: yes
21:22:19 <slightlyoff> dglazkov: I only got context on this recently and I don't know...do we need a new event?
21:23:09 <slightlyoff> slightlyoff: don't want to design a feature here, but I can see both cases
21:23:34 <slightlyoff> rniwa: <script defer> does block DOMCOntentLoaded
21:23:39 <slightlyoff> rniwa: this is similar to that
21:23:50 <slightlyoff> rniwa: in that sense, blocking it on imports seems right in the sync case
21:24:07 <slightlyoff> (starting gun fires)
21:24:56 <slightlyoff> ArtB: thanks to dglazkov for taking the time
21:25:07 <slightlyoff> dglazkov: I'll be getting back to spec work shortly, thank you
21:25:26 <slightlyoff> thanks to Brad Hill for hosting
21:25:28 <slightlyoff> (applause)
21:25:43 <slightlyoff> Topic: conclusion
21:26:19 <MikeSmith> yeah much thanks to Brad and to PayPal for hosting
21:26:27 <MikeSmith> RRSAgent, make minutes
21:26:27 <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/11-webapps-minutes.html MikeSmith
21:27:13 <BenjamP_> BenjamP_ has left #webapps
21:30:51 <Zakim> -[Paypal]
21:30:53 <Zakim> IA_WebApps()12:00PM has ended
21:30:53 <Zakim> Attendees were anssik, [Paypal], +1.301.460.aaaa
22:01:14 <sicking> sicking has joined #webapps
22:10:14 <chaals> chaals has joined #webapps
22:48:33 <sicking> sicking has joined #webapps
22:57:07 <chaals> chaals has joined #webapps
23:14:05 <dglazkov> THANK YOU EVERYONE!!!
23:14:10 <dglazkov> I <3 YOU!!!
23:29:07 <skddc> skddc has joined #webapps
23:44:05 <Zakim> Zakim has left #webapps
00:24:31 <trackbot> trackbot has joined #webapps
00:32:57 <tantek> tantek has joined #webapps
00:42:44 <lmclister> lmclister has joined #webapps