| 00:19 | <MikeSmith> | WTF https://github.com/Semantic-Org/Semantic-UI/issues/1526 |
| 00:19 | <MikeSmith> | <div class="sixteen wide mobile eight wide tablet four wide computer column"> |
| 00:19 | <Domenic> | that's the new craze MikeSmith. |
| 00:21 | <MikeSmith> | Domenic: they're in for some good times with that stuff |
| 00:22 | <MikeSmith> | "'word order significant' class names" |
| 00:22 | <MikeSmith> | "For me the use of significant class order is an ideological stand." |
| 00:24 | <MikeSmith> | 「Otherwise as programmers how could we possibly define "right"ness, without acknowledging the importance of contextual significance, like "right aligned" or "right floated".」 |
| 00:24 | <MikeSmith> | semiotics |
| 00:24 | <MikeSmith> | Cours de linguistique generale |
| 00:28 | <MikeSmith> | https://github.com/AmpersandJS/amp/issues/52#issuecomment-69646723 |
| 00:28 | <MikeSmith> | 「I think an argument that "the standard says to do X or Y" acts as an appeal to authority and not necessarily an argument for validity. Just like an argument over the morality of the death penalty would be stopped short if we just relied on a de jure argument like, "Well its current (legal/illegal) in my country". 」 |
| 00:29 | <MikeSmith> | annevk: seems like a good candidate to recruit as a spec editor |
| 03:24 | <psynone> | algum brasilero aqui? |
| 05:24 | <annevk> | MikeSmith: to be fair, that is kind of the way we talk about REC |
| 05:25 | <annevk> | (maybe I'm stretching it a bit) |
| 05:28 | <MikeSmith> | annevk: yeah I get your point though maybe you are stretching it a bit |
| 05:28 | <MikeSmith> | personally I like stretching things a bit |
| 05:28 | <MikeSmith> | or even beating them into the ground |
| 05:29 | <MikeSmith> | sometimes great insights can emerge from it |
| 05:29 | <MikeSmith> | but if not, at least we get the lulz |
| 05:33 | <annevk> | At least we're not filling our mornings with ISO discussions like TC39 did apparently |
| 05:34 | <MikeSmith> | well I understand the strategy |
| 05:35 | <MikeSmith> | in that, the rest of the meeting can't get any worse than that |
| 05:35 | <MikeSmith> | who's the actual chair of TC39? Does it have a chair? |
| 05:35 | <MikeSmith> | as in, who runs the meeting and cuts people off when needed, etc. |
| 05:39 | <annevk> | MikeSmith: John Neumann is the official chair |
| 05:39 | <annevk> | MikeSmith: Brendan Eich de facto in my fairly limited experience |
| 05:40 | <MikeSmith> | ok |
| 05:40 | <annevk> | MikeSmith: but each meeting has a bit about Ecma and standards formality that mostly died in the nineties, but not in Ecma/TC39 |
| 05:40 | <MikeSmith> | that part seriously sounds like fun |
| 05:41 | <MikeSmith> | we don't have enough of that |
| 05:41 | <MikeSmith> | standards meetings should be a bit more like going to Catholic mass |
| 05:42 | <MikeSmith> | like there's the part in the mass where you have to turn around and shake hands with the people sitting behind you, and say, "Peace be with you." And they say, "And also with you." |
| 05:43 | <MikeSmith> | and the singing too |
| 05:43 | <MikeSmith> | DanC tried to introduce more singing |
| 05:43 | <MikeSmith> | to meetings |
| 05:44 | <MikeSmith> | and sorta hippie-ish guitar-playing |
| 05:44 | <MikeSmith> | I liked that |
| 07:59 | <annevk> | igrigorik: https://github.com/whatwg/fetch/issues/93#issuecomment-125770410 is nice, though worker is a ResourceType |
| 07:59 | <annevk> | igrigorik: and we need to distinguish the types of workers I think |
| 08:00 | <annevk> | igrigorik: Initiator makes sense to explain "form", but I'm not sure we need to to beyond that for now. "script" there seems dubious, is invoking new Image(src) script? Invoking <img>.setAttribute()? |
| 09:14 | <nox> | annevk: Pushed code to this issue #60. |
| 09:14 | <nox> | https://github.com/whatwg/dom/pull/60 |
| 09:43 | <annevk> | nox: thank you. You already checked for no observable differences, right? |
| 09:45 | <nox> | annevk: AFAIK there are none but you should check the transient observers step in replace. |
| 09:47 | <annevk> | nox: in remove? |
| 09:48 | <nox> | annevk: Oh yes but I'm commuting. The step about ancestors having subtree observers. |
| 09:49 | <nox> | Now the order of operations should be the same when appending or replacing all elements of a node without children. |
| 10:30 | <annevk> | smaug____: I'm trying to figure out https://github.com/whatwg/dom/issues/34 still |
| 10:31 | <annevk> | smaug____: per https://dom.spec.whatwg.org/#concept-node-remove-ext currently we only run that once |
| 10:32 | <smaug____> | so you go through the tree once, in tree order, and for each operation which might need scripts to run, post a nanotask to call the script? |
| 10:32 | <annevk> | smaug____: the change would be to run it for the inclusive descendants of /node/ during step 8 |
| 10:32 | <smaug____> | ah, right |
| 10:32 | <annevk> | smaug____: however, what should we call the arguments then? |
| 10:32 | <annevk> | smaug____: removedNode, oldAncestor, oldPreviousSibling? |
| 10:32 | <annevk> | smaug____: I can't find oldPreviousSibling as a thing in Gecko |
| 10:33 | <annevk> | smaug____: also, in relation to oldAncestor, oldPreviousSibling is an odd name |
| 10:34 | <smaug____> | http://mxr.mozilla.org/mozilla-central/source/dom/base/Element.cpp#1396 is the insertion case, http://mxr.mozilla.org/mozilla-central/source/dom/base/Element.cpp#1663 is the removing case |
| 10:34 | <annevk> | (I think another difference is that in Gecko UnbindFromTree is on the instance, not a standalone callback, but I'm not going to change that for now.) |
| 10:34 | <annevk> | smaug____: that's only for elements though, not nodes in general |
| 10:35 | <annevk> | smaug____: but yeah, that doesn't seem to keep track of oldPreviousSibling |
| 10:35 | <smaug____> | well, data nodes have similar bind/unbind |
| 10:35 | <smaug____> | annevk: right |
| 10:35 | <smaug____> | http://mxr.mozilla.org/mozilla-central/source/dom/base/nsINode.cpp#1679 |
| 10:35 | <annevk> | smaug____: and it calls it "oldParent", while it might not be the oldParent of the instance it was invoked on... |
| 10:35 | <smaug____> | annevk: so we call ContentRemoved before unbind |
| 10:36 | <annevk> | What's the difference? |
| 10:36 | <smaug____> | which means one can use nsIMutationObserver if one needs that information |
| 10:36 | <smaug____> | http://mxr.mozilla.org/mozilla-central/source/dom/base/nsIMutationObserver.h#257 |
| 10:37 | <annevk> | Interesting, so we have several internal callbacks |
| 10:37 | <smaug____> | well, nsIMutationObserver is the callback interface |
| 10:38 | <smaug____> | Bind/Unbind are the actual methods on nodes to do something |
| 10:38 | <smaug____> | I wouldn't call them callbacks |
| 10:38 | <smaug____> | (DOM) MutationObserver is implemented internally as an nsIMutationObserver |
| 10:40 | <annevk> | I think ideally specifications only use one of them |
| 10:41 | <smaug____> | Bind/Unbind set the .parentNode and iterate all the child nodes and so |
| 10:41 | <annevk> | And e.g. https://dom.spec.whatwg.org/#nodeiterator needs oldPreviousSibling |
| 10:42 | <smaug____> | NodeIterator in Gecko is also nsIMutationObserver http://mxr.mozilla.org/mozilla-central/source/dom/base/NodeIterator.h?force=1#25 |
| 10:43 | <smaug____> | Bind/Unbind implement a part of the node-insert/removal algorithm from the spec, and nsIMutationObserver is then closer to the callbacks we want to add |
| 10:43 | <annevk> | The problem is that mutation observers in Gecko can be synchronous, and the specification doesn't have such a concept |
| 10:43 | <smaug____> | right |
| 10:44 | <annevk> | I guess we could add that concept and some abstract language of using mutation observers here and there... |
| 10:45 | <annevk> | But I think that might be more confusing than always using "insertion steps" and "removing steps" for synchronous operations |
| 10:45 | <smaug____> | spec should talk about something else than "mutation observer", to not confuse with MutationObserver |
| 10:45 | <smaug____> | hmm, what you mean? |
| 10:45 | <annevk> | If the specification "removing steps" did get passed an oldPreviousSibling, is there anything that would be different? |
| 10:45 | <smaug____> | with sync ops? |
| 10:46 | <annevk> | smaug____: for everything where specifications want to react synchronously to the insertion or removal of some node |
| 10:46 | <annevk> | smaug____: e.g. <iframe> or Fullscreen |
| 10:46 | <smaug____> | so you mean nano task stuff |
| 10:46 | <smaug____> | not sync |
| 10:46 | <annevk> | no I don't mean that |
| 10:47 | <smaug____> | sync is something which can't run scripts, right? |
| 10:47 | <nox> | Are we still on insertion/removing steps? |
| 10:47 | <annevk> | smaug____: ideally |
| 10:47 | <annevk> | smaug____: simple example is NodeIterator |
| 10:47 | <smaug____> | ok, so this is spec level stuff |
| 10:48 | <annevk> | smaug____: if we change "removing steps" to be invoked for inclusive descendants, does that a) still work and b) how do we name the arguments sanely |
| 10:48 | <annevk> | smaug____: yeah |
| 10:48 | <smaug____> | I'm now not sure what we're talking about :) spec level sync stuff, or callbacks to JS |
| 10:48 | <annevk> | smaug____: though I suspect the nanotask stuff to come on top |
| 10:49 | <annevk> | smaug____: spec level sync stuff for now |
| 10:49 | <annevk> | nox: yes |
| 10:53 | <smaug____> | so Gecko does http://mxr.mozilla.org/mozilla-central/source/dom/base/nsINode.cpp#1679, so ContentRemoved is called first on the thing removed, and then UnbindFrom tree is called, and it calls itself recursively on child nodes, and for the removed node and each descendant ParentChainChanged is called separately http://mxr.mozilla.org/mozilla-central/source/dom/base/Element.cpp#1784 |
| 10:55 | <smaug____> | so when removing, in the spec, would it make sense to have spec level "callback" for node-removed, and then parentChainChanged for each descendants? |
| 10:55 | <annevk> | Right, I wonder if the simplistic concept the specification has now, combined with it being invoked for descendants, is sufficient even for the cases where Gecko might use a synchronous mutation observer to implement them. |
| 10:55 | <nox> | Aren't you having the same discussion than yesterday? |
| 10:56 | <annevk> | nox: similar, but not the same |
| 11:00 | <annevk> | smaug____: I'm not sure, would the first be invoked with oldPreviousSibling and the second not? Or some such? |
| 11:02 | <smaug____> | annevk: the second would just tell that parent chain has changed |
| 11:03 | <smaug____> | since for descendants siblings are still the same |
| 11:03 | <beverloo> | annevk, fair :) |
| 11:04 | <annevk> | smaug____: I guess that may be sufficient, I'm unfortunately not familiar with all callers :-/ |
| 11:04 | <annevk> | Well, all places that are hooked into this |
| 11:05 | <smaug____> | let me look at some UnbindFromTree implementations in Gecko. Some elements do override the default one and do something and then call the default one |
| 11:06 | <smaug____> | effectively to have the parentChainChanged call on them |
| 11:06 | <smaug____> | without implementing nsIMutationObserver |
| 11:06 | <smaug____> | nsIMutationObserver in Gecko is meant to be used by other elements or nodelists etc. when the change isn't happening on your object |
| 11:06 | <annevk> | So you're suggesting node::unbind(oldParent, oldPreviousSibling), node::ancestorUnbind() |
| 11:08 | <annevk> | Oh right, actually defining NodeList, now that would be something... |
| 11:10 | <smaug____> | sorry, network issues. /me kicks the over-the-forest-under-the-lake phone line |
| 11:11 | <smaug____> | annevk: yeah, unbind on the removed element only, and then parentChainChanged for that and for descendants. |
| 11:11 | <smaug____> | or just node::ancestorUnbind() for descendants |
| 11:12 | <smaug____> | but let me looks some Unbind impls |
| 11:12 | <annevk> | I'm going to email some Google folks too |
| 11:14 | <smaug____> | so UnbindFromTree overrides tend to check whether there is still parent and if not and elements behavior depends on parent, do something. Or, do something because the element isn't in document anymore |
| 11:14 | <smaug____> | so both those could be done based on the parentChainChanged information |
| 11:15 | <annevk> | yeah |
| 11:18 | <smaug____> | one thing some code seems to use is that when UnbindFromTree is called on element which ancestor was in document, the element itself has still the flag "in-document", and that flag is cleared during UnbindFromTree. |
| 11:18 | <Ms2ger> | https://github.com/emilbjorklund/svg-weirdness |
| 11:19 | <annevk> | smaug____: I've been wondering, is it actually "in-document" or "in-window-associated-document"? |
| 11:19 | <smaug____> | so maybe node::ancestorUnbind() should have a param telling whether the ancestor used to be in-document |
| 11:20 | <smaug____> | it is in-document in Gecko |
| 11:22 | <smaug____> | if you need to know in-window-associated-document, just check if(node.ownerDocument.defaultView) |
| 11:23 | <annevk> | that's why it might make sense to pass the ancestor |
| 11:23 | <annevk> | so you can just check it on ancestor |
| 11:26 | <smaug____> | why would you do that |
| 11:26 | <smaug____> | if you have the information on the node itself |
| 11:26 | <smaug____> | oh, one thing, Gecko calls Bind/Unbind on shadow elements too |
| 11:26 | <annevk> | "maybe node::ancestorUnbind() should have a param telling whether the ancestor used to be in-document" |
| 11:27 | <annevk> | smaug____: composed tree or just going into each attached shadow tree? |
| 11:31 | <smaug____> | oh, I see a bug there for multiple shadow roots |
| 11:31 | <smaug____> | anyhow, it accesses shadowroot and Bind/Unbind all the child nodes of shadowroot |
| 11:32 | <smaug____> | that is implementation detail that shadowroot doesn't need bind/unbind |
| 12:11 | <JonathanNeal> | Promise.race is similar to Array#every. Is there something like Promise.any similar to Array#some? |
| 12:13 | <beverloo> | Do you mean s/race/all/? |
| 12:20 | <jgraham> | It seems like .race should be similar to .some and .all similar to .every |
| 12:20 | <jgraham> | Unless the names are very misleading |
| 12:58 | <annevk> | mkwst: fyi: https://github.com/whatwg/fetch/issues/93 |
| 12:59 | <annevk> | smaug____: okay, so it's just going in without caring about whether the nodes are actually composed or not |
| 13:00 | <annevk> | smaug____: I guess it goes into shadow trees before first child/next sibling? |
| 13:03 | <hallvors> | jgraham: I can't remember seeing a single compat problem caused by error object's message.. |
| 13:35 | <smaug____> | annevk: in Gecko it goes into shadow tree after non-shadow tree children. Not sure which one should come first. |
| 13:38 | <annevk> | Making up words: inclusive shadow-tree-including-descendants in shadow-post-tree order |
| 13:41 | <smaug____> | annevk: in Gecko it goes into shadow tree after non-shadow tree children. Not sure which one should come first. |
| 13:41 | <annevk> | smaug____: you were online the first time :-) |
| 13:41 | <smaug____> | ahaa |
| 13:42 | smaug____ | switched network |
| 13:42 | smaug____ | reads log |
| 13:42 | <annevk> | I didn't say anything intelligent |
| 15:00 | <annevk> | smaug____: philipj: for mayCancel, I guess if we disable addEventListener() as well as preventDefault() there might be more of a fighting chance |
| 15:00 | <annevk> | smaug____: philipj: though in that case we need to be wary of events dispatching from the same task (or have the optimization take place inbetween or some such, if that even makes sense) |
| 15:01 | <smaug____> | disable addEventListener? |
| 15:05 | <annevk> | smaug____: otherwise a mayCancel listener can add a non-mayCancel listener during dispatch |
| 15:05 | <annevk> | (I hope we end up with a better name than mayCancel.) |
| 15:05 | <annevk> | ("passive" sounds rather good actually.) |
| 15:06 | <smaug____> | would it be horrible to make that throw |
| 15:06 | <smaug____> | inside mayCancel == false listener you could add only mayCancel == false listeners |
| 15:06 | <smaug____> | hm |
| 15:06 | smaug____ | doesn't like that |
| 15:07 | <annevk> | I would just make addEventListener throw |
| 15:07 | <smaug____> | any addEventListener call? |
| 15:07 | <smaug____> | or only for the currently dispatched event type? |
| 15:07 | <smaug____> | or what |
| 15:08 | <annevk> | Only for the passive callback |
| 15:08 | <smaug____> | don't understand |
| 15:08 | <annevk> | The UA can then make an optimization if it only sees passive callbacks |
| 15:08 | <annevk> | Without having to worry about passive callbacks adding new listeners that violate the passiveness |
| 15:08 | <smaug____> | what would throw and when? |
| 15:09 | <annevk> | preventDefault() and addEventListener() would throw during passive listener callbacks |
| 15:10 | <annevk> | Hmm, somehow post-callback microtasks should also be guarded, otherwise there's an escape |
| 15:10 | <smaug____> | addEventListener for any event type? |
| 15:10 | <annevk> | smaug____: I guess you could scope it |
| 15:11 | <annevk> | smaug____: haven't considered the details |
| 15:12 | <annevk> | smaug____: might depend a bit on how many events are typically dispatched together from one task, something we haven't specified :-( |
| 15:12 | <smaug____> | indeed |
| 15:13 | <annevk> | yay for "passive" meanwhile |
| 16:44 | <ccardona-work> | Good morning WHATWGians! o/ |
| 16:47 | <annevk> | morning ccardona-work |
| 16:48 | <ccardona-work> | annevk: Good morning *hat tip* 🎩 👽 |
| 16:49 | <annevk> | Domenic: humor me, the s/deterministic/consistency/ change would be because we could offer deterministic points in time to invoke the callbacks, but they would simply not be great? |
| 16:50 | <annevk> | johnme: beverloo: I wonder, is actions your just-before-going-home project? |
| 16:50 | <Domenic> | annevk: yeah, where "not great" is more precisely that when using createElement You have no children or attributes, but otherwise you do. |
| 16:51 | <Domenic> | (parsing could be either one; upgrades must have children and attributes) |
| 16:51 | <annevk> | I guess I should reword that so this remains a useful point of reference, thanks |
| 16:51 | <Domenic> | \o/ thanks |
| 16:59 | <johnme> | annevk: sorry, just happened to finish addressing the comments now :) |
| 17:00 | <annevk> | johnme: heh, I don't mind at all when you do it |
| 17:00 | <annevk> | Domenic: should be fixed now |
| 17:20 | <wanderview> | annevk: this is the XHR spec you updated for fetch? https://xhr.spec.whatwg.org/ |
| 17:26 | <annevk> | wanderview: that's the only XHR spec still getting updates to my knowledge |
| 17:26 | <annevk> | (yes) |
| 17:26 | <wanderview> | annevk: its the "still getting updates" thats hard for me to infer when searching online |
| 17:26 | <annevk> | "Last Updated 14 July 2015" |
| 17:27 | <wanderview> | annevk: yea... but when searching for a spec... I don't know if I just didn't see one with a newer date, etc |
| 17:27 | <wanderview> | finding "the right spec" kind of sucks |
| 17:27 | <wanderview> | for newbies like me |
| 17:27 | <annevk> | wanderview: I guess the other thing is that if it has spec.whatwg.org in the name, it's the one you want |
| 17:28 | <annevk> | wanderview: if it has TR/ in the name, highly unlikely |
| 17:28 | <annevk> | wanderview: anything else, proceed with caution |
| 17:28 | <wanderview> | annevk: I'll just use http://www.w3schools.com/xml/xml_http.asp |
| 17:39 | <tantek> | is linking to w3schools unironically considered trolling? |
| 17:42 | <wanderview> | tantek: I'm pretty sure I was trying to troll annevk |
| 20:36 | <JoWie> | should start a whatwgschools |
| 20:37 | <zcorpan> | whatschools |
| 20:43 | <caitp> | make it happen |
| 20:49 | <Domenic> | wanderview: https://github.com/mozilla/servo/wiki/Relevant-spec-links for the right spec is my go-to |
| 20:50 | <Domenic> | I guess XHR isn't there explicitly |
| 20:50 | <wanderview> | Domenic: thanks |
| 20:51 | <wanderview> | also, I would call it w2gschools |
| 21:00 | <tantek> | whatschools++ |
| 21:09 | <Ms2ger> | Domenic, you're welcome ;) |
| 21:10 | <Domenic> | :) |
| 21:22 | <gsnedders> | wtfschools |