| 05:32 | <TabAtkins> | hallvors: Protip, submodules are the devil and nobody should ever use them. |
| 05:33 | <TabAtkins> | git-subtree is a little better, but I'm honestly doing fine with "just git clone the other project in, then delete its .git folder" |
| 07:33 | <annevk> | MikeSmith: if it's possible to close a component for new bugs, would be good for WebAppsWG/Fullscreen |
| 07:33 | <annevk> | MikeSmith: Fullscreen is GitHub-only now |
| 08:09 | <MikeSmith> | annevk: OK, the Fullscreen component should be closed for new bugs now |
| 08:20 | <annevk> | Anyone else update https://wiki.whatwg.org/wiki/Specs/todo from time to time? |
| 08:20 | <annevk> | I added SVG since it's apparently not maintained much |
| 08:22 | <MikeSmith> | annevk: I don't update that but can help with it going forward |
| 08:23 | <annevk> | MikeSmith: cool |
| 08:23 | <MikeSmith> | annevk: I'd imagine heycam|away might not agree SVG should be included there. Or ed either |
| 08:24 | <MikeSmith> | I thought they were actually somewhat actively working on an sorta living SVG spec these days |
| 08:25 | <MikeSmith> | annevk: https://svgwg.org/svg2-draft/ |
| 08:25 | <MikeSmith> | and https://svgwg.org/specs/paths/ |
| 10:34 | <annevk> | I wrote a summary of the custom elements meeting: https://annevankesteren.nl/2015/07/shadow-dom-custom-elements-update |
| 10:34 | <annevk> | I would add some links but I didn't see any links to minutes come by |
| 10:35 | <annevk> | Aww, missed the twelve year anniversary of my blog |
| 10:51 | <MikeSmith> | annevk: congrats on that 12-year milestone |
| 10:52 | <MikeSmith> | annevk: minutes from the f2f at at https://docs.google.com/document/d/1KSwKrTU2d0uJCf55tV-jur_0sYxCNMuM7Dl3vqb0bu4/edit?pli=1 |
| 10:52 | <MikeSmith> | and at https://www.w3.org/2015/07/21-webapps-minutes.html |
| 10:52 | <MikeSmith> | and I think maybe also at https://www.w3.org/2015/07/22-webapps-minutes.html |
| 10:52 | <MikeSmith> | or for the W3C links, http instead of https |
| 10:54 | <annevk> | I guess the "spans midnight" command was forgotten |
| 10:54 | <MikeSmith> | yeah |
| 10:55 | <MikeSmith> | but there's not much in that https://www.w3.org/2015/07/22-webapps-minutes.html anwyay |
| 10:55 | <MikeSmith> | annevk: "several focus events that fire synchronously"? |
| 10:58 | <annevk> | MikeSmith: in some browsers anyway you can get blur events fired when a focused element is removed from the tree |
| 10:59 | <annevk> | MikeSmith: same for focusout and there should be some trick for getting that with focusin/focus |
| 11:03 | <MikeSmith> | annevk: ok |
| 11:06 | <annevk> | nox: regarding https://github.com/whatwg/dom/issues/59#issuecomment-124966988 |
| 11:06 | <annevk> | nox: how can the previous sibling change if node === child? |
| 11:07 | <Ms2ger> | One of these is adopted, so loses its siblings? |
| 11:08 | <annevk> | Ms2ger: say we have X, Y, Z as siblings, in order |
| 11:08 | <annevk> | Ms2ger: if Y == node == child |
| 11:08 | <annevk> | Ms2ger: X is the previous sibling |
| 11:08 | <annevk> | Ms2ger: Z is the reference child marker |
| 11:08 | <annevk> | Ms2ger: Y is removed |
| 11:08 | <annevk> | Ms2ger: then Y is inserted before Z |
| 11:08 | <annevk> | Ms2ger: why would X change? |
| 11:09 | Ms2ger | looks at the issue |
| 11:10 | <annevk> | Oh you are correct |
| 11:10 | <annevk> | We need to set the marker before adopting |
| 11:10 | <annevk> | Thanks, that seems to be all |
| 11:11 | <Ms2ger> | Np :) |
| 11:18 | <annevk> | Ms2ger: have you not hit the problem in Servo where the DOM Standard has basically the wrong internal notifications for remove/insert? |
| 11:18 | <annevk> | Ms2ger: https://github.com/whatwg/dom/issues/34 |
| 11:19 | <Ms2ger> | Yeah |
| 11:19 | <Ms2ger> | But that's all a mess in Servo anyway, sadly :/ |
| 11:19 | <annevk> | Maybe I better fix that then so it doesn't become a problem |
| 11:19 | <annevk> | Oh |
| 11:19 | <annevk> | That's more like it! |
| 11:20 | <annevk> | Is CSS basically the only aspect of Servo that's saner than contemporary browsers? |
| 11:21 | <Ms2ger> | I think the DOM isn't that bad, overall, but there's a lot of work still |
| 11:22 | <annevk> | I guess I should start looking into 34 since it keeps coming up with custom elements too |
| 11:22 | <annevk> | Seems higher priority than merging in parts of Shadow DOM |
| 11:40 | <nox> | DOM is getting better and better in Servo. |
| 11:48 | <annevk> | Ms2ger: nox: could you review https://github.com/whatwg/dom/issues/34#issuecomment-125571750 perhaps? Although I guess I should ask bz to be sure |
| 11:48 | <annevk> | I didn't realize that was such a "trivial" issue to fix |
| 11:49 | <nox> | annevk: I'm not sure I get what it is about. |
| 11:49 | <nox> | annevk: Is it about insertion/removal steps? |
| 11:49 | <annevk> | nox: about them not running for descendants at the moment |
| 11:50 | <nox> | I'm not sure we want that. |
| 11:50 | <annevk> | You need it if you want to implement e.g. <iframe> properly |
| 11:50 | <annevk> | Say you have <p><iframe></iframe></p> |
| 11:50 | <annevk> | I remove <p> |
| 11:50 | <nox> | <iframe> doesn't use insertion/removing steps. |
| 11:50 | <annevk> | Yes it does |
| 11:51 | <annevk> | You now need to destroy the <iframe>'s document and global object |
| 11:51 | <nox> | It does things on insertion/removal, but IIRC it doesn't explicitly mention this thing. |
| 11:51 | <annevk> | For that <p>'s descendants need to be modified |
| 11:51 | <annevk> | notified* |
| 11:51 | <nox> | Of course, my Internet doesn't want to work… |
| 11:51 | <nox> | Why is it always when conversations are interesting that the thing breaks? |
| 11:52 | <annevk> | Heh |
| 11:53 | <nox> | annevk: <iframe> links to https://html.spec.whatwg.org/multipage/infrastructure.html#remove-an-element-from-a-document |
| 11:53 | <nox> | That's not DOM's removing steps, AFAICT. |
| 11:53 | <annevk> | nox: eventually it will be |
| 11:53 | <annevk> | nox: how else would the world be tied together? |
| 11:53 | <nox> | What do yomou vimean |
| 11:53 | <nox> | Wow, what do you mean*? |
| 11:53 | <annevk> | nox: a bunch of HTML is basically monkey patching DOM due to missing stuff |
| 11:54 | <nox> | Mmmh… |
| 11:54 | <nox> | I'm pretty sure there are occurences of insertion steps that you don't want as descendants. |
| 11:55 | <annevk> | nox: I'm not sure what that means, but tell me this, how would you implement the "removed from a document" requirements using the current set of primitives in the DOM? |
| 11:55 | <nox> | annevk: <img> for example, |
| 11:55 | <nox> | annevk: I would keep current "insertion steps" as "insertion steps in a parent", |
| 11:55 | <nox> | and I would introduce the concept of "insertion steps in a document". |
| 11:55 | <nox> | The latter being called on all inclusive descendants. |
| 11:55 | <annevk> | nox: that's effectively what this is |
| 11:56 | <annevk> | nox: just not scoped to documents, because the notifications in browsers aren't either |
| 11:56 | <nox> | I don't understand what you mean. |
| 11:56 | <annevk> | nox: if you internet connection is up you might want to follow the links at the top of the issue |
| 11:57 | <annevk> | nox: you have both Gecko and Blink folks explaining their internal callbacks |
| 11:57 | <nox> | annevk: My problem with this is that you then need to sometimes check whether the node in the insertion and removal steps is actually a top-level node. |
| 11:57 | <nox> | That's why I would rather have two different things. |
| 11:59 | <annevk> | nox: given that's more complicated and doesn't match existing browsers I doubt that's a better setup |
| 12:00 | <annevk> | nox: is this based on the subset of the DOM Servo implements today? |
| 12:01 | <nox> | annevk: For example, I care that an <img> was removed as a descendant because I might take this as an opportunity to free memory or whatnot, but I care for different reasons if it is actually removed directly because I might need to do some things if it is removed from a <picture>. |
| 12:01 | <nox> | annevk: Currently Servo has bind_to_tree and unbind_to_tree and children_changed. |
| 12:02 | <nox> | The first two sound the same as in the first link in the issue, the latter behaves more or less like childList mutations. |
| 12:02 | <annevk> | nox: yeah, bind_to_tree / unbind_to_tree are what this bug is about |
| 12:02 | <annevk> | nox: children_changed is that mutation observers give |
| 12:03 | <nox> | I know, I'm saying they should correspond to "inserted/removed from a document" and that "insertion/removing steps" should be something else. |
| 12:03 | <annevk> | I don't see why we'd have four concepts where Servo and every other browser has two |
| 12:03 | <nox> | annevk: "The element's parent is a picture element and a source element is inserted as a previous sibling." That sounds complicated to implement if you always need to check in bind_to_tree whether the node as a parent or not. |
| 12:04 | <nox> | If a removed <source> element has still a parent when calling unbind_to_tree on it, that means it was removed as a descendant, |
| 12:04 | <nox> | if it doesn't have a parent anymore, it was the actual node removed. |
| 12:04 | <nox> | Won't conflating the two still need to repeat that every time when actually specifying the steps? |
| 12:05 | <annevk> | Some algorithms might need such a check, sure |
| 12:05 | <nox> | That's why I don't think it's a good idea to conflate them. |
| 12:07 | <annevk> | If that's your only concern I think we'll manage |
| 12:07 | <nox> | annevk: How would you reformulate "If a source element is inserted as a child of a media element that has no src attribute and whose networkState has the value NETWORK_EMPTY, the user agent must invoke the media element's resource selection algorithm." when conflating the two? |
| 12:07 | <annevk> | We can always separate node and descendant notification later on... |
| 12:08 | <nox> | "If the parent passed to insertion steps is equal to the parent of the <source> inserted element, and the parent is a media element (…), the user agent must invoke (…)"? |
| 12:08 | <annevk> | seems reasonable |
| 12:08 | <nox> | Seems confusing to me. |
| 12:08 | <annevk> | if it's common I imagine we might have a shorthand for such a check |
| 12:09 | <annevk> | I don't think it's super common though |
| 12:09 | <annevk> | the more common case is about document / out-of-document |
| 12:10 | <annevk> | Which makes me wonder, anyone know how fast the "in composed tree" check is with the new slots proposal? |
| 12:12 | <nox> | annevk: "Specifications may define insertion steps for all or some nodes. The algorithm is passed newNode as indicated in the insert algorithm below." |
| 12:12 | <nox> | Then that needs to change too and be passed the parent like in removing steps. |
| 12:12 | <nox> | Otherwise you will never know if the node was directly inserted or only as a descendant. |
| 12:13 | <annevk> | nox: yeah, it needs an inclusiveAncestorNode |
| 12:14 | <nox> | Why inclusive? |
| 12:14 | <nox> | annevk: I would just mimic "Specifications may define removing steps for all or some nodes. The algorithm is passed removedNode, oldParent, and oldPreviousSibling, as indicated in the remove algorithm below." |
| 12:15 | <nox> | Without oldPreviousSibling because I don't think that's useful for insertion steps. |
| 12:16 | <nox> | So "Specifications may define insertion steps for all or some nodes. The algorithm is passed newNode and parent as indicated in the insert algorithm below." |
| 12:17 | <annevk> | nox: why do you need parent actually? wouldn't that just be newNode.parent? |
| 12:17 | <nox> | annevk: No, |
| 12:17 | <nox> | annevk: if I insert a <picture> with an <img> inside, |
| 12:18 | <nox> | I don't want that to be considered as a "relevant mutation" for the <img> node. |
| 12:18 | <annevk> | nox: <img> would get a callback for being inserted |
| 12:18 | <nox> | But it shouldn't change the state of the <picture>. |
| 12:19 | <annevk> | nox: that's why browsers hand out these notifications twice I think |
| 12:19 | <nox> | I don't understand what you mean. |
| 12:19 | <nox> | annevk: If I remove a form from a document, |
| 12:20 | <nox> | I don't want the form-associated elements to trigger the parts of their removing steps that alter the form. |
| 12:20 | <nox> | I need to know whether an element was inserted/removed itself or as a descendant. |
| 12:20 | <nox> | Just passing newNode to the insertion steps doesn't allow that. |
| 12:20 | <annevk> | nox: how would that work for a descendant <iframe> of the <form>? |
| 12:21 | <nox> | annevk: I don't see how that is related. |
| 12:21 | <annevk> | nox: I don't see how insertion steps are related to removing a form |
| 12:21 | <nox> | Forget about the form, I'm trying to find a better example. |
| 12:21 | <kochi> | annevk: thanks for the comment on 'delegatesFocus' issue. What's your feeling about how 'delegatesFocus' thing fits in shadow DOM v1? |
| 12:22 | <nox> | annevk: https://html.spec.whatwg.org/#relevant-mutations |
| 12:22 | <annevk> | kochi: dunno, it wasn't really discussed in the meeting |
| 12:22 | <annevk> | kochi: UI input in general is kind of a mess :/ |
| 12:22 | <nox> | annevk: Am I correct in saying this link does not say anything about inserting in/removing from a document, right? |
| 12:23 | <nox> | annevk: If I remove a <picture> that has an <img> child, |
| 12:23 | <nox> | Err, |
| 12:23 | <nox> | If I insert a <picture> that has an <img> child in a document, |
| 12:24 | <nox> | how do I not update the image data of the <img> when its insertion steps are invoked, given I can't know whether they were invoked because the <img> itself was inserted or because its <picture> parent was? |
| 12:24 | <annevk> | kochi: and given that most of focus stuff is unexplained when it comes to composed trees... seems hard to add something new |
| 12:26 | <nox> | annevk: Let's say I have an element <foo> which insertion steps say "foo inserted in bar" should be logged to the console if its new parent is a <bar> element, |
| 12:26 | <annevk> | nox: if <img>'s callbacks run removedNode would be <picture>, which is still <img>'s parent so it has no reason to do anything? |
| 12:26 | <nox> | I insert "<bar><foo/></bar>" in the document, |
| 12:26 | <nox> | if the insertion steps are invoked for all descendants with only the node, "foo inserted in bar" will be logged and that would be wrong. |
| 12:27 | <nox> | annevk: I'm talking about insertion here. |
| 12:27 | <nox> | The removal steps can distinguish the two because they are passed oldParent. |
| 12:28 | <annevk> | nox: are you assuming the callback needs to be passed the this object? |
| 12:28 | <nox> | I don't understand what you mean. |
| 12:28 | <annevk> | nox: that it needs a reference to the element for which it was invoked? |
| 12:28 | <nox> | I'm saying insertion steps, like removing steps, should be passed the parent of the actually-inserted/removed node. |
| 12:29 | <annevk> | why isn't passing the actually-inserted node enough? |
| 12:29 | <kochi> | annevk: yeah, currently shadow DOM spec says focus is based on tree-of-trees, not explained in terms of composed tree. |
| 12:29 | <nox> | Because of what I just explained. |
| 12:29 | <annevk> | you can just query its parent, no? |
| 12:29 | <nox> | "Let's say I have an element <foo> which insertion steps say "foo inserted in bar" should be logged to the console if its new parent is a <bar> element, I insert "<bar><foo/></bar>" in the document, if the insertion steps are invoked for all descendants with only the node, "foo inserted in bar" will be logged and that would be wrong." |
| 12:29 | <nox> | I'm saying that insertion steps as defined currently aren't good enough to be invoked on all descendants. |
| 12:30 | <nox> | Because contrary to removing steps, you can't include a step that disambiguates insertion-as-actually-inserted-node from insertion-as-descendant-of-actually-inserted-node. |
| 12:31 | <annevk> | In your case <foo> is the object for which the callback is invoked, newNode is <bar>, so <foo> knows it's not inserted since then newNode would be <foo> |
| 12:32 | <nox> | What? |
| 12:32 | <nox> | Aren't we talking about running these steps for all the descendants? |
| 12:32 | <annevk> | Yes, but newNode wouldn't change |
| 12:32 | <nox> | annevk: Insertion steps have no context object currently AFAICT. |
| 12:33 | <nox> | It's just "Run the insertion steps with newNode." |
| 12:33 | <annevk> | Yeah, hence I asked before if you were saying that "it needs a reference to the element for which it was invoked?" because that I agree with |
| 12:33 | <nox> | Ok. If we actually have two bits of data that makes sense, |
| 12:33 | <nox> | now I get why you mentioned "inclusive ancestor node". |
| 12:34 | <nox> | annevk: All is right with the world then. :) |
| 12:34 | <annevk> | Good :-) |
| 12:34 | <nox> | annevk: I'm not sure we want a context object though, judging from how it's currently written, |
| 12:34 | <annevk> | Just waiting for a +1 from bz at this point |
| 12:34 | <nox> | I was under the impression that DOM allows you to have some global insertion steps, |
| 12:34 | <annevk> | nox: yeah, new parameter is probably better |
| 12:35 | <nox> | like something that describes insertion steps whichever the combination of inserted node and parent. |
| 12:36 | <annevk> | nox: since in the custom element story these callbacks are per element in the registry and not necessarily associated with instances |
| 12:36 | <nox> | annevk: So no context object right? |
| 12:37 | <annevk> | nox: I would imagine we pass "currentNode" and "newNode" or some such; I don't think parent makes much sense, since that's newNode.parent |
| 12:37 | <annevk> | nox: but I guess I should study what existing libraries do |
| 12:37 | <nox> | annevk: I'm not sure we would ever need newNode, and it would keep the symmetry with removing steps. |
| 12:37 | <nox> | That's why I suggested a parent, but either way it's fine with me. |
| 12:38 | <annevk> | I see |
| 12:38 | <nox> | annevk: Given you are cleaning this, might as well clean the order of mutation observers as I mentioned in #60. :P |
| 12:38 | <nox> | Oh wait, didn't see your reply on this commit. |
| 12:38 | <annevk> | nox: you sure we don't need oldPreviousSibling? |
| 12:39 | <nox> | annevk: Not sure, but I will explain why I said that: |
| 12:39 | <annevk> | nox: I'm happy to make that change myself |
| 12:40 | <nox> | annevk: I was under the impression that the removing steps always let you get oldNextSibling too (given nodes were removed between the two), |
| 12:40 | <nox> | but I forgot that nodes might have been added through replaceChild, |
| 12:41 | <nox> | anyway, I don't see why you would ever need the previous sibling in the case of insertion, but I guess it wouldn't hurt to be really symmetric. |
| 12:42 | <annevk> | I don't think browsers have it for insertion (and there you can just get it). I'm pretty sure it's there for removal though |
| 12:44 | <nox> | annevk: I'll try my hand at fixing #60, I'm curious and want to use bikeshed. |
| 12:45 | <annevk> | cool |
| 12:46 | <annevk> | Such a relieve that fixing insertion/removal is actually this trivial. I was preparing myself for a multiple-days-long-rewrite... |
| 12:47 | <kochi> | annevk: I was told from Hayato that the focus navigation order of distributed trees were changed to document order rather than composed tree order to explain <details> <summary>. https://bugs.webkit.org/show_bug.cgi?id=92050 |
| 12:50 | <annevk> | kochi: okay, but does that mean that shadow tree elements cannot have focus at all? |
| 12:50 | <annevk> | kochi: because that seems unlikely |
| 12:50 | <annevk> | kochi: and that would need to be explained in some way |
| 12:51 | <kochi> | annevk: I don't understand your question... maybe I should have said 'tree-of-trees' order rather than 'document order'? |
| 12:53 | <annevk> | kochi: maybe, although tree-of-trees kind of indicates you can focus nodes not rendered anywhere, but maybe that is already true? |
| 12:54 | <kochi> | annevk: I think inert nodes are not focusable, and will not be visited via TAB navigation. |
| 12:55 | <annevk> | maybe tree-of-trees -> "shadow-including document" at some point |
| 12:55 | <annevk> | tree-of-trees is rather weird |
| 12:56 | <annevk> | kochi: anyway, either way the current focus model doesn't accommodate shadow trees, agreed? |
| 12:57 | <annevk> | kochi: reviewing https://html.spec.whatwg.org/multipage/interaction.html#focus nothing seems to consider them anyway |
| 12:58 | <kochi> | annevk: currently in shadow DOM spec, "focus navigation" and "active element" is patched against HTML spec, what do you think is missing still? |
| 12:59 | <annevk> | kochi: how does http://w3c.github.io/webcomponents/spec/shadow/#focus-navigation patch HTML? |
| 13:01 | <kochi> | annevk: so you want the shadow DOM spec to be actually patcheable to HTML spec? say, patch to HTML spec "6.4.5 Sequential focus navigation"? |
| 13:02 | <annevk> | kochi: yes |
| 13:03 | <annevk> | kochi: the goal here is that ShadowRoot et al become just as normal as Text |
| 13:03 | <annevk> | kochi: this requires a massive amount of changes since introducing a new kind of node is expensive |
| 13:04 | <annevk> | kochi: but if we want to write tests and build new things on top, this is what we have to do |
| 13:06 | <kochi> | annevk: hmm, let me understand the goal more. currently ShadowRoot is a DocumentFragment, and "Text" is a text node, right? |
| 13:07 | <annevk> | kochi: yup |
| 13:08 | <annevk> | I can phrase it differently perhaps. We have a bunch of specifications and algorithms that assume there is no Shadow DOM. Now there is Shadow DOM. We need to update the bunch of specifications and algorithms to take that into account. |
| 13:09 | <kochi> | annevk: ah yeah, the "in a document" thing that Hayato has been working on is a part of it. |
| 13:09 | <annevk> | Yeah, Hixie proposed a set of changes for that one too I believe |
| 13:10 | <annevk> | Another thing is firing "scoped events" vs firing "unscoped events" |
| 13:12 | <kochi> | annevk: so then preparing a rewrite of some sections of HTML spec (esp. 6.4.5 Sequential focus navigation et al.) to take shadow DOM into account to see how the "diff" from the current version is the step that I can take? |
| 13:13 | <kochi> | to see how the "diff" from the current version look like |
| 13:13 | <annevk> | kochi: yeah, first explain how Shadow DOM focus works in general |
| 13:13 | <annevk> | kochi: then introduce a new feature on top |
| 13:14 | <kochi> | annevk: okay, let me try. |
| 13:15 | <kochi> | I'm not sure how difficult it is, as focus in the HTML spec is already a beast :) |
| 13:16 | <annevk> | That is kind of why I would like to see HTML + Shadow DOM focus explained before we add a new feature on top |
| 13:18 | <kochi> | annevk: now I think I understand "ShadowRoot et al become just as normal as Text" a little bit more :) |
| 13:19 | <kochi> | it's hard to become a first-class citizen. |
| 13:20 | <kochi> | annevk: thanks for your help! |
| 13:20 | <annevk> | kochi: thanks for taking it on :-) |
| 13:25 | <annevk> | MikeSmith: https://twitter.com/kubosho_/status/625978108189880320 |
| 13:58 | <johnme> | https://heycam.github.io/webidl/#dfn-create-frozen-array seems to only provide shallow immutability - if it contains e.g. dictionaries, their contents can be mutated freely. Is that a bug? Should it freeze recursively? |
| 14:01 | <annevk> | johnme: not sure, Domenic or heycam|away or bz (not in this channel) might be able to help |
| 14:01 | <annevk> | johnme: prolly easiest way for a quick response is to file a bug |
| 14:02 | <johnme> | annevk: thanks, I'll do that |
| 14:02 | <annevk> | johnme: note also that frozen only ever freezes properties, this is really a bit of a hack |
| 14:03 | <johnme> | it seems the goal of FrozenArray was to be able to expose objects in an immutable manner, e.g. so that the same object can be returned each time |
| 14:04 | <johnme> | so it seems it would make more sense if the immutability was recursive |
| 14:06 | <annevk> | johnme: it doesn't make the objects immutable though, so it's unclear whether this trick works for other kind of objects |
| 14:06 | <nox> | Given objects aren't immutable in a FrozenArray, why would dictionaries? |
| 14:07 | <johnme> | is it too late to change the spec so that objects in a FrozenArray are immutable? |
| 14:07 | <annevk> | It's not clear how you'd spec it other than restricting what kind of objects you can put in there |
| 14:08 | <annevk> | Or only allowing primitives... |
| 14:10 | <johnme> | annevk: I guess I was hoping objects in a FrozenArray would themselves be frozen (have non-writable properties), though that begs the question of whether to freeze objects that can be accessed from the object's properties/methods |
| 14:10 | <johnme> | annevk: and if so, how many levels deep this should apply |
| 14:10 | <nox> | johnme: Non-writable properties doesn't make them immutable, does it? |
| 14:10 | <annevk> | johnme: e.g. if you have a Headers object there, you'd still be able to invoke headersInstance.set(...) and such |
| 14:11 | <nox> | To me the change to FrozenArray just meant that you couldn't alter the array shape, not anything else. |
| 14:11 | <annevk> | johnme: freeze() is really for some security research from Mark Miller |
| 14:11 | <nox> | You don't remove stuff from it, you don't add more things into it, but the things inside you do whatever you want with them. |
| 14:11 | <annevk> | johnme: it was used here to make the array immutable, with the hope of later using an actual immutable array |
| 14:13 | <johnme> | my use case is adding a sequence of NotificationAction dictionaries to NotificationOptions, that I'd then like to expose on Notification as a FrozenArray<NotificationAction> |
| 14:13 | <johnme> | But I guess I'll have to split it into a NotificationActionInit dictionary and a NotificationAction interface with readonly attributes |
| 14:14 | <annevk> | johnme: filing a bug on IDL seems like the easiest first step |
| 14:14 | <johnme> | ok :) |
| 14:14 | <annevk> | johnme: but yeah, I thought Chrome/Blink folks also had some reluctance with returning plain objects, but maybe that changed |
| 14:21 | <jochen__> | annevk: is there an example idl for an reflected attribtue that is restrict to valid values only? |
| 14:21 | <annevk> | jochen__: usually that's just readonly attribute DOMString attrName; |
| 14:22 | <annevk> | jochen__: with invocation of that prose turning it into enum behavior |
| 14:25 | <annevk> | jochen__: https://html.spec.whatwg.org/multipage/forms.html#attr-keygen-keytype and https://html.spec.whatwg.org/multipage/forms.html#dom-keygen-keytype for a somewhat simple example |
| 14:32 | <jochen__> | thx |
| 14:33 | <jochen__> | annevk: for the referrer policy thing, we'd mark the attribute as reflected as well, right? |
| 14:33 | <annevk> | jochen__: yeah |
| 14:34 | <annevk> | jochen__: the only difference would be that it's the referrerPolicy IDL attribute reflecting the referrerpolicy content attribute (different names) |
| 14:35 | <jochen__> | mhm |
| 14:35 | <jochen__> | that sounds like something you'd put in prose, no? |
| 14:36 | <annevk> | jochen__: https://html.spec.whatwg.org/multipage/forms.html#dom-fs-formenctype |
| 14:36 | <annevk> | jochen__: yeah |
| 14:37 | <MikeSmith> | annevk: that tweet, the guy just seems to be describing the search syntax he uses when he wants to find out information about an html element |
| 14:38 | <annevk> | MikeSmith: yeah, figured, seems kind involved |
| 14:38 | <annevk> | kinda* |
| 14:38 | <MikeSmith> | yeah |
| 15:33 | <wanderview> | https://twitter.com/codepo8/status/626038604964364289 |
| 15:33 | <wanderview> | having a hard time seeing that post as anything but a troll |
| 15:33 | <gsnedders> | meh, it's typical ppk |
| 15:34 | <Ms2ger> | So you're in agreement |
| 15:34 | <wanderview> | sadly it seems to be working if the twitter threads starting up is any indication |
| 15:35 | <wanderview> | I guess I should stop looking at them |
| 15:36 | <gsnedders> | yes, there probably should be /more/ focus on fixing bugs in existing features… but that doesn't mean stopping development of stuff going forward |
| 15:37 | <annevk> | Domenic: if I want to check that something is in the range 0 to N and is not 5, should I use RangeError for both checks? |
| 15:40 | <jgraham> | wanderview: It's all irrelevant. One person saying "let's stop making more features" isn't enough to counteract the huge pressure to keep adding new features |
| 15:40 | <wanderview> | jgraham: yep... I'm suffering from "someone is wrong on the internet!" syndrome |
| 15:40 | <annevk> | Also, black-and-white positions rarely move the needle |
| 15:41 | <jgraham> | and his argument isn't even internally consistent; he cites "offline" as a "experience" thing when it's actually a "feature" thing at this stage |
| 15:41 | <Ms2ger> | Well, at least you haven't spent this time implementing new features |
| 15:41 | <jgraham> | Plus, I remember in 2007 people arguing that browsers should agree a common timeline on features that they would all polish before moving on |
| 15:41 | <jgraham> | I expect this will work as well now as it did then |
| 15:42 | <jgraham> | Except ppk will get a few more hits on his site |
| 15:42 | <Ms2ger> | I remember that Google was going to drop h264 |
| 15:42 | <annevk> | Domenic: I'm going to assume I should use a RangeError |
| 15:42 | <jgraham> | heh |
| 15:43 | <annevk> | I remember that Ms2ger was going to spec DOM Parsing & Serialization |
| 15:43 | <Ms2ger> | Lol |
| 15:45 | <gsnedders> | yeah, still think he should |
| 15:47 | <jgraham> | I imagine the promise looked like google.drop_h264().then(()=>Ms2ger.write_parsing_and_serialization()) |
| 15:48 | <gsnedders> | But we didn't support ES6 yet then so we just got a SyntaxError |
| 15:48 | <annevk> | Kind of confusing for an instance to start with a capital |
| 15:48 | <Ms2ger> | More like google.addEventListener("drop_h264", function() { Ms2ger.write_parsing_and_serialization() }), clearly :) |
| 15:49 | <wanderview> | I think the "multiple browsers have to implement to be a real standard" keeps things from moving forward too fast... real threat is if one browser has so much market share they can force others to implement things at a reckless pace |
| 15:49 | <jgraham> | annevk: Take that up with Ms2ger |
| 15:51 | <gsnedders> | wanderview: also different people have different views of reckless… is a few failing I-think-edge-cases-but-nobody-has-started-using-it-yet tests reason to withold shipping? is one or two more likely tests failing reason to, etc? |
| 15:52 | <wanderview> | yea... which is why the conditions for "at least 2 agree" consensus state is nice for throttling things |
| 15:54 | <smaug____> | we've had plenty of examples of shipping "recklessly" |
| 15:54 | <gsnedders> | definitely |
| 15:55 | <Domenic> | annevk: sounds good yes |
| 15:55 | <botie> | Domenic, at 2015-07-27 04:50 UTC, MikeSmith said: botie now understands "tell" |
| 17:01 | <annevk> | mathiasbynens: you want to study https://html.spec.whatwg.org/multipage/webappapis.html#dom-document-open |
| 17:01 | <annevk> | mathiasbynens: in particular look at the crazy that is step 15 |
| 17:01 | <annevk> | mathiasbynens: if you want to answer that Twitter conversation yourself |
| 17:21 | <wanderview> | nice: https://twitter.com/w3tmemes/status/626078922980110336 |
| 17:29 | <mathiasbynens> | annevk: woah. so both Chromium and WebKit are violating the spec here? |
| 17:30 | <Ms2ger> | Sure |
| 17:30 | <annevk> | mathiasbynens: not sure, they might do it slightly differently |
| 17:30 | <annevk> | mathiasbynens: replacing globals is rather involved... |
| 17:30 | <annevk> | mathiasbynens: would be interesting to figure out what everyone is really doing |
| 17:30 | <mathiasbynens> | i based ^ on the following quick test: data:text/html,<script>a=42</script> |
| 17:31 | <mathiasbynens> | and then using DevTools to `document.write(a)` |
| 17:31 | <mathiasbynens> | Fx is the odd one out |
| 17:32 | <annevk> | Well, I think both WebKit/Blink are doing some work on their Window object bindings, so you might just be observing that |
| 17:33 | <annevk> | Could also be something else, hard to say without more tests |
| 17:39 | <smaug____> | mathiasbynens: IIRC Gecko and Trident (and Presto) have followed the spec and Webkit (and then also blink) was against the spec |
| 17:46 | <beverloo> | annevk, does Firefox support SVGs? |
| 17:46 | <beverloo> | (In notification images) |
| 17:46 | <annevk> | beverloo: I'm not sure |
| 17:46 | <annevk> | beverloo: we support them for favicon finally |
| 17:47 | <beverloo> | annevk, interesting, I don't think we support that either |
| 17:48 | <annevk> | beverloo: yeah, WHATWG specifications look boring in Chrome |
| 17:48 | <annevk> | beverloo: except for HTML, probably because Hixie doesn't insist (yet) |
| 17:48 | <annevk> | beverloo: note that usage of SVG there predates Firefox supporting it |
| 17:49 | <beverloo> | annevk, sure. we do get a lot of feedback about wanting to generate icons on the fly in a Service Worker, SVG might be a solution for that |
| 17:49 | <annevk> | I suspect you'll get "WorkerCanvas" way before "WorkerDOM", but who knows |
| 17:49 | <beverloo> | yeah, that'd be great |
| 17:52 | <annevk> | beverloo: thanks for helping out with the review btw |
| 17:54 | <beverloo> | annevk, John sits right next to me, making it easy to chat :) |
| 18:04 | <beverloo> | annevk, svg in favicons is WontFix for IE: https://connect.microsoft.com/IE/feedback/details/782416/svg-favicon-support |
| 18:04 | <beverloo> | annevk, the Chrome bug is https://crbug.com/294179, WebKit bug http://wkbug.com/136059 |
| 18:05 | <beverloo> | annevk, supporting this in favicons is *very* similar for us to supporting it for notification images |
| 18:07 | <Domenic> | https://wpdev.uservoice.com/forums/257854-internet-explorer-platform/suggestions/6509196-svg-favicons seems like the new place to be |
| 18:10 | <beverloo> | Domenic, cheers! I updated our bug with the latest status |
| 20:14 | <annevk> | beverloo: meh, IE wontfixed "XHR2" too |
| 20:19 | <Domenic> | hehehe |
| 22:15 | <jyasskin_w> | Anyone have thoughts on portably testing exception messages? https://lists.w3.org/Archives/Public/public-test-infra/2015JulSep/0002.html |
| 22:45 | <MikeSmith> | jyasskin_w: Ms2ger does |
| 22:45 | <jyasskin_w> | Ms2ger: Is my proposal on that thread right? Is there a better way? |
| 22:45 | <MikeSmith> | and jgraham, as you know |
| 22:45 | <jyasskin_w> | Yep. |
| 22:46 | <jyasskin_w> | thx |
| 22:46 | <Ms2ger> | I'd rather spec the messages |
| 22:50 | <jyasskin_w> | Ms2ger: Interesting, but I'm not sure we can. Different platforms have different information available, and I'd like them to be free to help their developers as much as they can. |
| 22:51 | <jyasskin_w> | e.g. platforms may or may not expose the exact GATT error message. It'd be nice to let them show it if they have it, but conform if they don't. |
| 22:54 | <jyasskin_w> | slightlyoff says Chrome has a principled objection to specifying messages. |
| 22:55 | <smaug____> | if you don't spec something properly, web pages end up relying on the behavior of the browser the developer happens to use. /me agrees with Ms2ger |
| 22:56 | <slightlyoff> | specifically messages shown to end users |
| 22:56 | <jgraham> | These are API-accessible messages |
| 22:56 | <Ms2ger> | Well, then I have a principled objection against testing them |
| 22:56 | <slightlyoff> | we are likely to change them over time and won't spec UI |
| 22:56 | <slightlyoff> | oh... api accessible....hrm |
| 22:57 | <jyasskin_w> | We do have a way to send a different message to the user vs developer, but most of the messages are the .message field. |
| 22:57 | <jgraham> | But yeah, I don't think that you should simultaneously say they can't be interoperable and must be tested |
| 22:57 | <slightlyoff> | howso? |
| 22:57 | <jyasskin_w> | We must test UI, but UI isn't interoperable. |
| 22:57 | <slightlyoff> | (and that's OK) |
| 22:57 | <jgraham> | Right, but we don't test UI in web-platform-tests |
| 22:58 | <jyasskin_w> | And these messages are primarily UI. They do have to be API-accessible so they can be sent back to servers with onerror, but they're for developer consumption, not for testing. If there's a reason for folks to switch on them, that should be reflected in .name, not .message. |
| 22:58 | <jyasskin_w> | We're not going to write the web bluetooth tests twice, and we're going to test UI somewhere, so if we can't include the UI test in web-platform-tests, then the Web Bluetooth tests won't be upstreamed. |
| 22:59 | <jyasskin_w> | That would be sad. |
| 22:59 | <Ms2ger> | Your position makes no sense to me |
| 22:59 | <Domenic> | Sebmaster: annevk: web-platform-tests does not test the parsed href? |
| 22:59 | <Ms2ger> | Why bother testing if they're not supposed to be relied upon? |
| 23:00 | <jyasskin_w> | Ms2ger: We want the developer-facing UI to keep working. |
| 23:00 | <jyasskin_w> | Anything that's not tested won't keep working. |
| 23:00 | <Domenic> | jeeez it implicitly assembles the href using a different algorithm than the URL spec does !?! |
| 23:01 | <Sebmaster> | Domenic: test here: https://github.com/w3c/web-platform-tests/blob/master/url/a-element.html#L47 |
| 23:01 | <Sebmaster> | but yeah, it assembles somehow :D |
| 23:01 | <Domenic> | Sebmaster: https://github.com/w3c/web-platform-tests/blob/master/url/urltestparser.js#L18-L26 |
| 23:01 | <Domenic> | this is bad |
| 23:02 | <Domenic> | isn't the whole file bug about serialization not inserting the //s in the current spec? |
| 23:02 | <Sebmaster> | nah not serialization |
| 23:02 | <Domenic> | hmm no your patch is in parsing |
| 23:02 | <Sebmaster> | parsing i think |
| 23:02 | <Domenic> | hmm then i need to go find the failing test case again |
| 23:03 | <Sebmaster> | but i guess it'd rather fit into serialization |
| 23:04 | <jgraham> | jyasskin_w: FWIW you can't publish a spec at W3C in an actual WG without a testsuite |
| 23:04 | <jgraham> | So it seems likely you'll have to do that work at some point |
| 23:04 | <slightlyoff> | jgraham: there was of course no plan to |
| 23:04 | <Domenic> | Sebmaster: right so the failing test is parsing "/path/to/docroot/index.html" against "file:/path/to/docroot/index.html" |
| 23:05 | <Domenic> | Sebmaster: in whatwg-url that results in a href of file:/path/to/docroot/index.html |
| 23:05 | <slightlyoff> | jgraham: there's a smaller issue here; which is what we should do about developer-facing strings |
| 23:05 | <Domenic> | Sebmaster: whereas it should result in file:///path/to/docroot/index.html |
| 23:05 | <slightlyoff> | jgraham: which I don't have the same objection to as end-user-facing UI |
| 23:05 | <jyasskin_w> | slightlyoff: Ah, I misunderstood you then. |
| 23:05 | <slightlyoff> | no, I misunderstood |
| 23:05 | <slightlyoff> | my fault |
| 23:05 | <Domenic> | Sebmaster: seems like a serialization patch would be better (but there are no tests) |
| 23:05 | <Sebmaster> | Domenic: since the path in that case would just be /path/to/docroot/index.html, this should probably go into serialization |
| 23:05 | <Sebmaster> | yeah |
| 23:05 | <Domenic> | nooooo tesssssstsss -_- |
| 23:06 | <jgraham> | hallvors: Got any good examples of error message strings causing compat problems? |
| 23:07 | <slightlyoff> | I'd also like to understand the value of i18n of developer-facing strings |
| 23:07 | <slightlyoff> | I'm not sure it's something we do much of today |
| 23:07 | <slightlyoff> | but I'm ignorant there |
| 23:07 | <jgraham> | Yeah, I don't know either. |
| 23:07 | <Domenic> | sicking and I always had the idea to add some machine-readable unique standardized string |
| 23:08 | <Domenic> | error.cause === "could_not_parse_base_url" |
| 23:08 | <Domenic> | corresponding to 2.2 in https://url.spec.whatwg.org/#constructors |
| 23:08 | <Domenic> | or a guid |
| 23:09 | <jyasskin_w> | I don't think we can implement stable message strings in Chrome on multiple platforms without dropping lots of information. e.g. ChromeOS exposes different error conditions than MacOS. Neither documents their error conditions, either. |
| 23:10 | <jgraham> | Then it seems like you are going to end up changing your expectations here for every OS upgrade |
| 23:11 | <jyasskin_w> | Absolutely. That's why my first patch supported regular expressions, so we can keep the actual test somewhat stable over time. But skipping the message tests isn't going to stop developers from depending on them, either. |
| 23:14 | <jgraham> | Anyway, if you want to supply a patch that allows you to attach arbitary information to a particular test object and transfer it in the result; something like test.add_data(name, data) I guess I would accept that. You could output that data in expectation files in Chromium. But I think you're letting yourself in for a world of pain if later someone does the same thing for something that isn't stable in Chrome and can't be compared using expectation |
| 23:17 | <jyasskin_w> | jgraham: Thanks. I should go back to blink-dev to see if folks there have more thoughts. I'm not certain this is the right interface either, but I do think we need _something_. |
| 23:21 | <jgraham> | I think fundamentally if you want to do this you need your test harness to support test-specific logic that can be used to whitelist the cases where you want to compare the proprietary bits |
| 23:22 | <jgraham> | If the blink test harness just does byte-by-byte comparisons with expectation files, that's not good enough |
| 23:25 | <jyasskin_w> | Right, it'll break too often, including if we just have different-but-stable messages on two platforms. On the other hand, test.add_data(name, data) does give us the flexibility to write any assertions we need in the harness. |