| 00:20 | <benjamingr> | Domenic: noob question here - why would you use an ID in a specification like that instead of keeping the object alive in an algorithm like that? If it leaks endless promises or endless IDs the leak is there all the same. |
| 00:21 | <Domenic> | benjamingr: numbers don't leak |
| 00:21 | <Domenic> | benjamingr: objects do! |
| 00:22 | <benjamingr> | What do you mean? If I have a list of numbers and that list keeps growing doesn't that leak memory? Eventually the list will consume all my heap - it'll just take longer, won't it? |
| 00:24 | <Domenic> | benjamingr: yes, fair. But numbers---especially "small/medium integers" (smis) in modern VMs---consume much less memory than a whole promise object. |
| 00:24 | <Domenic> | benjamingr: and it's not an ever-growing list we're concerned about, it's a fluctuating-in-size list |
| 00:25 | <benjamingr> | Right, so your process would crash later but it would crash nontheless. |
| 00:25 | <Domenic> | having that fluctuation be between 0 and x is much better than between 0 and 10x |
| 00:25 | <Domenic> | sure, if you actually leak, you crash |
| 00:25 | <benjamingr> | So the reason these are numbers and not objects is not not to leak it's to conserve memory? |
| 00:26 | <Domenic> | yeah, i guess "leak" is imprecise. More "don't keep the object alive". |
| 00:26 | <Domenic> | For anyone who wonders what we're talking about, it's https://gist.github.com/domenic/9b40029f59f29b822f3b#promise-error-handling-hooks-rough-spec-algorithm ... conversation started in #promises |
| 00:27 | <benjamingr> | Domenic: Yeah, I figured I'd ask here and not in #promises since I'm wondering about a specification issue and how you specified it rather than about promises (do let me know if you rather have this discussion in #promises) |
| 00:27 | <Domenic> | nah here seems good :) |
| 00:30 | <benjamingr> | Oh, so it's really an observable map of `id => reason` where the id can/should be removed if a potential rejection is handled and items are added when a new potentially rejection happens. I guess that makes more sense than storing the promises anyway since there is no sync inspection API in native promises. |
| 00:32 | <benjamingr> | Thanks, that totally clarified why there are IDs there :) |
| 00:33 | <Domenic> | benjamingr: hmm yeah not sure why I didn't use the word "map" and related concepts more in that document. Would be better. |
| 00:34 | <benjamingr> | Well, you're probably more used to spec terminology than me, I'm assuming people more involved would have a lot less trouble reading it. |
| 08:17 | <annevk> | MikeSmith: do you think there's any chance for W3C Bugzilla to gain "needsinfo"? |
| 08:17 | <annevk> | MikeSmith: when you really want someone to answer a question, it's rather effective |
| 08:20 | <MikeSmith> | annevk: will see if I can add it right now |
| 08:20 | <annevk> | MikeSmith: no rush :-) |
| 08:20 | <MikeSmith> | the rush is that if I don't do it now I'll just forget :D |
| 08:25 | <MikeSmith> | annevk: wait there's already a resolved=NEEDSINFO status |
| 08:26 | <annevk> | MikeSmith: there's this feature in Mozilla Bugzilla where you can ask more information from a given Bugzilla user |
| 08:26 | <MikeSmith> | ahh |
| 08:26 | MikeSmith | peruses the parameters to see if there's a setting for it in our instance |
| 08:27 | <annevk> | MikeSmith: the UI phrase is "Need more information from" |
| 08:27 | <MikeSmith> | ok |
| 08:27 | <MikeSmith> | still looking |
| 08:32 | <Ms2ger> | annevk, MikeSmith, might be an extension |
| 08:32 | <MikeSmith> | yeah there's no feature for that in v4.4.8 as far as I can see |
| 08:32 | <MikeSmith> | but agreed it's a really useful feature |
| 08:32 | <MikeSmith> | so we should add it |
| 08:33 | <Ms2ger> | <glob> Ms2ger, its an extension, but under the hood it's a normal bugzilla flag |
| 08:34 | <MikeSmith> | I don't have root to install it but I could sweet talk somebody who does into installing it probably |
| 08:34 | <MikeSmith> | that's assuming I need shell access to the environment to install extensions |
| 08:35 | <MikeSmith> | I otherwise have full admin perms in the Web UI |
| 08:36 | <Ms2ger> | <glob> https://github.com/mozilla/webtools-bmo-bugzilla/tree/master/extensions/Needinfo |
| 08:36 | <Ms2ger> | <glob> hrm, although the recent addition of our mentor may have broken that claim. if that's the case it'll be easy for us to update/fix |
| 08:39 | <Ms2ger> | MikeSmith, sounds like you do need root, poke glob on moznet if you have issues :) |
| 08:39 | <MikeSmith> | Ms2ger: hai |
| 09:32 | <MikeSmith> | plz-install-this-extension sysreq filed |
| 14:09 | <bkardell> | smaug____: you here? |
| 14:10 | <smaug____> | bkardell: yes |
| 14:11 | <bkardell> | Hold on let me switch machines |
| 14:14 | <bkardell> | smaug____: You do see that .component is definitely not the same thing, right? In terms of CSS it matches existing combinators and requires perfect coordination at all times |
| 14:14 | <smaug____> | yes, and >>> needs perfect coordination too if enabled by default everywhere |
| 14:15 | <smaug____> | I agree using .component would be more annoying, but you can still achieve pretty much the same |
| 14:15 | <smaug____> | bkardell: let me ask differently.. |
| 14:15 | <smaug____> | why you want >>> to be enabled by default to all the components? |
| 14:15 | <bkardell> | right, and you *can* in theory totally avoid accidents in real life, but that is not reality |
| 14:16 | <bkardell> | so your main concern is that it should be plausible to say "your selectors are always irrelevant to me" |
| 14:17 | <bkardell> | is that right? |
| 14:18 | <smaug____> | yes, component should be able to say that |
| 14:18 | <bkardell> | mostly for styling or also for qsa and friends? |
| 14:18 | <smaug____> | but it should be also possible to say, "hey, I'm fine that you style my content " |
| 14:18 | <smaug____> | both |
| 14:18 | <bkardell> | hmm |
| 14:19 | <smaug____> | qsa is probably the more scary part |
| 14:19 | <bkardell> | more scary in terms of...? |
| 14:19 | <smaug____> | since if qsa can select shadow dom |
| 14:20 | <smaug____> | in terms of that the JS will probably then do something with the result |
| 14:20 | <smaug____> | like, it could move elements around there |
| 14:20 | <smaug____> | and break how the component works |
| 14:20 | <caitp> | what if it needs to |
| 14:20 | <bkardell> | ok, let me try this |
| 14:21 | <smaug____> | caitp: if the outside world needs to change the content of component, the component should give the permission |
| 14:21 | <caitp> | angular 1.x uses qsa to find the root element of an app to set everything up, but angular 2 has everything in components, so if the bootstrapping works the same way, it would have to be able to traverse shadow dom |
| 14:21 | <caitp> | it probably doesn't work the same way, but imagining it did :> |
| 14:21 | <bkardell> | to start, imagine you had just what I listed as the kind of bare minimum |
| 14:21 | <smaug____> | it is somewhat similar private: and such in many programming languages |
| 14:22 | <smaug____> | if the component doesn't let you to do what you need to do with it, don't use the component |
| 14:22 | <bkardell> | all css problems that come 'out of the box' with existing css goes away, it becomes safe |
| 14:22 | <caitp> | no i expect the angular-defined components have some hook for bootstrapping |
| 14:22 | <bkardell> | if you wanted to prevent outside meddling, that's up to the component and they can easily trump |
| 14:23 | <bkardell> | !important, on the element or even just ganging up some id-based :not() |
| 14:24 | <bkardell> | seems that offers some pretty reasonable protections and room to grow - it's all more or less explainable with one 1 new thing |
| 14:24 | <jgraham> | Making encapsulation opt-in doesn't seem like a great design |
| 14:25 | <bkardell> | if we wanted to add something like "you may NEVER reach inside here for any purpose via tree walking of any kind" |
| 14:25 | <caitp> | if I use qsa from the devtools console, I don't want to be limited by the shadow barrier :p |
| 14:25 | <jgraham> | caitp: devtools can do whatever it wants |
| 14:25 | <caitp> | but in practice, they don't |
| 14:25 | <caitp> | in practice they're using the same DOM api :( |
| 14:26 | <bkardell> | jgraham: I dont think you want dev tools to do something diff than code |
| 14:26 | <jgraham> | devtools can already do lots of things that DOM APIs can't |
| 14:26 | <caitp> | well, a few things |
| 14:26 | <jgraham> | There's no DOM API to set a breakpoint, for example |
| 14:26 | <caitp> | like simulating pseudo selectors |
| 14:26 | <bkardell> | smaug___: how do you explain the you may never part - is it in DOM? it's unnamed? |
| 14:27 | <bkardell> | I guess if your combinator required a name that could maybe work |
| 14:27 | <bkardell> | is that what you're getting at in that email? |
| 14:28 | <gsnedders> | jgraham: DebugStatement? |
| 14:29 | <bkardell> | caitp: simulating a state is different, it's a super power - doesn't change an API |
| 14:29 | <caitp> | i thinkn we were talking about devtools superpowers |
| 14:29 | <caitp> | think* |
| 14:29 | <jgraham> | In any case, it's pretty clear that better, larger, web applications are going to require locality of reasoning; the ability to understand one small part of an application and treat the rest as a black box. This requires encapsulation by default and the ability to expose specific APIs for extension |
| 14:32 | <caitp> | do you think qsa should be able to traverse <content> elements inside a shadow tree |
| 14:32 | <caitp> | (does it already? it probably does) |
| 14:34 | <smaug____> | that is an interesting question |
| 14:34 | <smaug____> | I assume it doesn't |
| 14:36 | <smaug____> | or what does your question mean |
| 14:36 | <smaug____> | caitp: the contents of <content> ? |
| 14:36 | <smaug____> | like, all the stuff distributed there? |
| 14:37 | <caitp> | yeah |
| 14:38 | <smaug____> | well, those elements aren't children of <content> |
| 14:38 | <jgraham> | <content> defines an explicit extension point, so I think it isn't obviously wrong that the content is qsa-able, but it should at the very least be in the component's control |
| 14:38 | <smaug____> | what selector would find then |
| 14:38 | <smaug____> | them |
| 14:38 | <smaug____> | do we need some new selector there? |
| 14:38 | <caitp> | they're basically child elements of the component proper, which is weird since you can have multiple content elements |
| 14:38 | <caitp> | and you wouldn't be able to specify which one |
| 14:47 | <bkardell> | smaug___: replied to your post |
| 14:49 | <smaug____> | will read after lunch |
| 14:50 | <bkardell> | pretty short |
| 14:51 | smaug____ | reads |
| 14:52 | <smaug____> | k |
| 14:52 | <bkardell> | smaug___: in short, I think the name thing is actually pretty good... it's sensible |
| 14:53 | <bkardell> | its a really minor tweak and easily explained |
| 14:53 | <smaug____> | trying to recall what TabAtkins thought about it |
| 14:53 | <bkardell> | has clear value |
| 14:54 | <bkardell> | did you discuss it here? |
| 14:54 | <bkardell> | I'm curious as to what you could really have against it |
| 14:55 | <smaug____> | I think I mentioned some of this earlier here too, when I was horrified to find /deep/ in a spec draft :) |
| 14:55 | <bkardell> | hmm |
| 14:56 | <bkardell> | something like :deep(*) would match any with a name, right? |
| 14:56 | <smaug____> | right |
| 14:57 | <bkardell> | I mean, it seems like a pretty simple safety to split the danger |
| 14:57 | <bkardell> | it seems really sensible to me actually |
| 14:57 | <smaug____> | * should make it clear to the reader that "yes, I really want all the public mounts" |
| 14:58 | <bkardell> | ..... "that I can actually reach because they said it is ok" |
| 14:58 | <bkardell> | hmm |
| 14:58 | <bkardell> | actually... |
| 14:58 | <bkardell> | would this answer a question for us that we've been lacking... |
| 14:58 | <smaug____> | I said "public" |
| 14:59 | <bkardell> | like - could you almost realistically explain something like input type=slider native now if you had that |
| 14:59 | <bkardell> | the mount isn't public |
| 14:59 | <smaug____> | well, you couldn't still explain the dom side |
| 14:59 | bkardell | waves hand and says "pay no attention to the DOM behind the mount" |
| 14:59 | <bkardell> | lol |
| 15:00 | <bkardell> | but I mean, this seems to get us closer |
| 15:00 | <bkardell> | because we had no way of explaining that there were shadows you couldn't reach into (native ones) |
| 16:04 | <bkardell> | Domenic: "I hope others can address the question of why custom element callbacks are useful" wdym? alternative? |
| 16:12 | <Domenic> | bkardell: wtf you left already? Anyway in that thread rniwa was questioning whether custom element callbacks are useful so I was hoping someone would explain that to him. |
| 16:12 | <bkardell> | oh I see |
| 16:13 | <bkardell> | hey did you see smaug's post on www-style / reply? |
| 16:13 | <bkardell> | I think it seems sensible |
| 16:14 | <bkardell> | I dont think there is precedent for a combinator taking an argument, that's the only thing really - but there's no precedent of a combinator doing something with a non-element either, so... |
| 16:31 | <Domenic> | bkardell: I still don't really understand why there's such insistence on truly-encapsulated stuff being the default. Seems to miss the point of your post about friendly fire etc. I haven't seen authors asking for that kind of thing (the cases that do want it, such as ads or social buttons, are happy with <iframe>s), and the only use case I can see for it is |
| 16:31 | <Domenic> | HTML as Custom Elements. Which is important, but seems backward in priority of constituencies. |
| 16:32 | <Domenic> | bkardell: kind of comes down to whether shadow DOM is an authoring aid (= composition) or an implementation strategy (= encapsulation). |
| 16:32 | <smaug____> | composition as such can be done without shadow DOM |
| 16:33 | <bkardell> | I agree that I doubt it will be the common case, but I can imagine some where I want to be kind of explicit about it because it is just too fundamental to my function - a graphing control maybe, for example |
| 16:33 | <smaug____> | and I think the complexity of shadow DOM doesn't quite make sense if all it gives is helping with composition |
| 16:34 | <jgraham> | It seems to me that techniques that allow you to reason about less of a system at once are authoring aids |
| 16:35 | <jgraham> | That is the central benefit of encapsulation. |
| 16:35 | <bkardell> | I explcitly tried to not use the term shadow dom because I'm talking about minimal - not event retargeting, not projection, etc -- just one simple primitive that can host a subtree and provide a new 'not quite an element'... that doesn't actually seem that complex |
| 16:37 | <smaug____> | anyhow, I could possible live with default-to-public-visibility in the CSS case. It is error prone, but if someone can actually think of good reasoning for it, fine. |
| 16:38 | <Domenic> | jgraham: yes, fair. But perhaps when I say "composition" I mean "Java-style encapsulation"---still available with reflective APIs, but not by default. |
| 16:38 | <smaug____> | bkardell: yeah, sorry if I've been talking in shadow DOM terms |
| 16:39 | <bkardell> | Domenic: the ad is really minimal, it makes sense conceptually and the delta in implementation is primarily about what a combinator matches and doesn't. We can theorize and debate all day, but isn't it better to just say "ok, if people think that could be useful, there's really no harm and it might be good to give a tool which also helps explain more of |
| 16:39 | <bkardell> | native and gives authors one more lever to experiment with" |
| 16:39 | <Domenic> | jgraham: in that sense I am talking about mostly-encapsulation as an aid for composing parts of the system, precisely because you can reason about less of the system at once (and can assume that if someone is messing with you they really know what they're doing) |
| 16:39 | <dglazkov> | smaug____: I am curious how you reached this conclusion on composition primitives being unimportant. In my experience, all of the evidence that I see points at nearly the opposite. |
| 16:39 | <dglazkov> | it's okay if this is just a hunch |
| 16:40 | <smaug____> | dglazkov: where have I said they are unimportant |
| 16:40 | <Domenic> | dglazkov: yeah, I saw "They could simply use their own framework or library" as "They could simply switch to another platform" -_- |
| 16:40 | <dglazkov> | but if you look at the stuggles of modern libraries, _all_ of them are primarily trying to solve composition |
| 16:40 | <smaug____> | I'm saying they aren't important enough to legitimate the complexity of shadow DOM |
| 16:41 | <dglazkov> | again, how do you draw the line in the sand? |
| 16:41 | <dglazkov> | what _is_ important enough? |
| 16:42 | <smaug____> | well, shadow DOM is in all levels very complicated (specs and implementation issues are a good signs of that). To legitimate that all I sure hope it brings in some new functionality to the platform, not just help script libraries a bit to let their implementation to be a tad simpler. |
| 16:42 | <dglazkov> | as far as I can see, style composition is one the largest unsolved problems in the web platfrom |
| 16:43 | <dglazkov> | smaug____: I see. So if this is not a new capability, it's not as interesting? |
| 16:44 | <bkardell> | hmm.. I honestly dont mean to sound dismissive of anyone's claims here, and I dont get the sense that smaug___ meant it quite as bluntly as he initially stated it, but in my experience dismissing the composition problem as "kinda easily" solvable with todays powers strikes me as out of touch and I'd hope we could avoid stating it that way (because it was |
| 16:44 | <bkardell> | just done again on www-style) |
| 16:44 | <smaug____> | it can be interesting still, but as I said, shadow DOM is very complicated. Makes implementations and specs more complicated (and a bit slower too) |
| 16:45 | <smaug____> | so it all it gives is some small aid... then is it really worth |
| 16:45 | <smaug____> | s/it/if/ |
| 16:45 | <dglazkov> | smaug____: it seems you're pre-judging the size of the aid? |
| 16:45 | <smaug____> | maybe |
| 16:45 | <dglazkov> | you don't really have to go far, just look at the state of CSS testing for web apps |
| 16:45 | <jgraham> | Domenic: I don't think we should start by designing a system that gives full control to anyone who thinks that they know what they are doing. It seems like a better approach to start with something that provides more encapsulation and figure out how to turn off the safety catches later. |
| 16:46 | <dglazkov> | today, it's basically a lost cause |
| 16:46 | <jgraham> | In general I think when we have done that in the past it's been a better outcome than when we have taken an open system and tried to band-aid on extra constraints with features like CSP |
| 16:46 | <Domenic> | jgraham: I guess I just disagree. I think we should start by designing a system useful to the majority and then maybe design a system for the smaller case. E.g. I don't think Java ever got around to designing a reflection-proof private, which speaks to how important that problem really is. |
| 16:47 | <dglazkov> | jgraham: I completely disagree |
| 16:47 | <dglazkov> | I don't think we should start with a goal of designing a system open or closed |
| 16:47 | <jgraham> | You disagree that places where we have enforced e.g. the cross origin policy have aged better than places where we did not and are trying to fix it up with opt-ins afterwards? |
| 16:48 | <dglazkov> | it should be driven by how the system helps the developer |
| 16:49 | <dglazkov> | jgraham: I genuinely don't know if CSP in particular is going to be harmful or useful on the long run. |
| 16:53 | <dglazkov> | shadow dom started pretty closed up. Then we actually asked devs to use it and the first thing to go were the hard boundaries. |
| 16:53 | <jgraham> | On its own that doesn't say anything |
| 16:53 | <dglazkov> | anytime you want to introspect anything, hard boundaries are just unnecessary obstructions |
| 16:54 | <dglazkov> | annevk, Domenic: changing subject a tiny bit -- have we considered how importNode and cloneNode work with almost-sync constructors? |
| 16:54 | <jgraham> | Right, but there's a difference between e.g. being able to inspect things and being able to change them |
| 16:55 | <dglazkov> | jgraham: yes. However, we don't really have a concept of read-only DOM in the platform today |
| 16:55 | <dglazkov> | jgraham: smaug____ is complaining about complexity already, imagine how much more complexity it would be to add something like that. |
| 17:08 | <annevk> | dglazkov: that's a good question |
| 17:08 | <annevk> | dglazkov: it would be easy for the parser, but for the DOM... |
| 17:08 | <annevk> | dglazkov: (though parser-wise, sync would be easy, not sure about almost-sync) |
| 17:09 | annevk | is behind on everything, will try to catch up tomorrow |
| 22:52 | <TabAtkins> | Why is everyone named Glen weird? |
| 22:52 | <TabAtkins> | Apologies to people named Glen here, BUT STILL. |
| 22:53 | <hober> | maybe we need namespaces to disambiguate glens |
| 22:54 | <caitp> | why apologize? that's like the highest compliment |
| 22:54 | <caitp> | glen would be honoured I'm sure |
| 22:57 | <tantek> | this whole channel is weird |
| 23:00 | <dglazkov> | DNS |
| 23:00 | <dglazkov> | I am so sorry |