| 00:00 | <rniwa> | Domenic: the constructor's realm in not in the same realm as MyDocCreatedForHavingASeparateRegistry |
| 00:00 | <rniwa> | Domenic: so I think you DO need to get the global object out of [[Prototype]] internal slot |
| 00:00 | <rniwa> | Domenic: if you cared about that use case that is |
| 00:00 | <Domenic> | I see! |
| 00:01 | <Domenic> | Hmm so we're inside HTMLElement already |
| 00:01 | <Domenic> | I wonder if we can get the realm/global object of the currently running function |
| 00:02 | <Domenic> | I guess you kind of can but that might be hard to implement? |
| 00:02 | <rniwa> | Domenic: oh I see |
| 00:02 | <rniwa> | Domenic: yeah you can probably just get the realm of the callee |
| 00:04 | rniwa | is getting uncomfortably familiar with JS these days... |
| 00:05 | <Domenic> | rniwa: https://github.com/w3c/webcomponents/commit/73ae047c90529546ad61ccc43cb995edf3bfb14f |
| 00:06 | <rniwa> | Domenic: do we need \ in [[\GlobalObject]] ? |
| 00:06 | <Domenic> | rniwa: yeah it's a ReSpec thing. Doesn't show up in the output |
| 00:07 | <rniwa> | I see |
| 00:08 | <rniwa> | Domenic: oh funny, we're not using upgrading for document.createElement? |
| 00:09 | <rniwa> | Domenic: (I like that) |
| 00:10 | <Domenic> | rniwa: hmmmm good question. I think it ended up being observably the same, and annevk wanted to use upgrading for uniformity, maybe? And I just forgot that? |
| 00:10 | <rniwa> | Domenic: your document.createElement is missing the case where we create HTMLUnknownElement. |
| 00:10 | <rniwa> | Domenic: no, it's still observable if you construct yourself inside a constructor before calling super |
| 00:10 | <Domenic> | I think that is covered by "Let interface be the element interface for localName and the HTML namespace" like it always was. |
| 00:10 | <rniwa> | oh I see |
| 00:11 | <Domenic> | Hmmmm. Well it seems pretty reasonable to not use upgrading there but I'll add a line comment for annevk to check it out. |
| 00:11 | <rniwa> | Domenic: here's a "better" proposal that makes this completely non-observable: http://lists.w3.org/Archives/Public/public-webapps/2016JanMar/0114.html |
| 00:11 | <rniwa> | Domenic: it adds an extra environmental record and an argument to `Construct` |
| 00:11 | <Domenic> | rniwa: yeah... I tried to get my head around that and it seemed pretty intrusive to the JS engine... |
| 00:11 | <rniwa> | Domenic: but that can do away with all the stack nonsensee so that's nice |
| 00:12 | <rniwa> | Domenic: indeed but it might be useful in the long term though |
| 00:12 | <rniwa> | Domenic: nonetheless, the difference manifests in such an edge case (and results in unexpected behavior) that we can probably change it in the future |
| 00:12 | <rniwa> | Domenic: if we wanted to |
| 00:12 | <rniwa> | Domenic: so I'm not too concerned even if we went with the stack approach at least in v1 |
| 00:13 | <Domenic> | That's good to hear. Yeah, I'd be interested in trying to figure out a way to do that within existing ES spec constructs. |
| 00:13 | <rniwa> | Domenic: well, I think it's not too intrusive. |
| 00:13 | <Domenic> | I dunno an extra parameter to construct is pretty big |
| 00:13 | <Domenic> | Environment records are extensible though |
| 00:13 | <rniwa> | Domenic: the only problem is that it may not be too easy for each JS engine to support it |
| 00:13 | <rniwa> | Domenic: indeed, that's the biggest question for perf |
| 00:13 | <Domenic> | Yeah I tried to get ajklein to take a look at it but he hasn't had the time |
| 00:14 | <rniwa> | adding an extra argument in JS engine everywhere for this one edge case is such an over-engineering |
| 00:14 | <rniwa> | given the observable behavioral difference is so damn small |
| 00:14 | <rniwa> | having said that, it's a lot cleaner so I'll still put up for the future consideration |
| 00:15 | <Domenic> | 👍 |
| 00:15 | <rniwa> | Domenic: btw, you're missing one important thing in document.createElement |
| 00:15 | <rniwa> | Domenic: which is that you need to ensure whatever the constructor returned is indeed an Element |
| 00:15 | <rniwa> | Domenic: and probably best to return null or undefined or throw something in the case it isn't. |
| 00:16 | <Domenic> | rniwa: ah, great catch! |
| 00:16 | <Domenic> | The parser will also need that |
| 00:17 | <rniwa> | Domenic: yup |
| 00:17 | <rniwa> | Domenic: and create HTMLUnknownElement when it failed |
| 00:17 | <rniwa> | Domenic: since parser can't stop |
| 00:17 | <Domenic> | Yeah parser is going to be so much work :( |
| 00:18 | <rniwa> | Domenic: yup! I've been working on it for the last two weeks or so and boy, it's not fun. |
| 00:18 | <Domenic> | maybe you can spec it! i hear parsers in browsers follow the spec pretty closely... |
| 00:19 | <rniwa> | Domenic: it's actually not that much work in the spec. |
| 00:19 | <rniwa> | Domenic: it's more that our implementation of HTML5 parser isn't prepared to do these kinds of stuff |
| 00:20 | <Domenic> | hmm |
| 00:20 | <Domenic> | i just assume it'll require similar contortions to <script>. |
| 00:20 | <Domenic> | which is like most of the parsing spec |
| 00:20 | <rniwa> | Domenic: well, not really |
| 00:21 | <rniwa> | Domenic: the only reason we have to pause parser, etc... is because of the perf optimizations we have |
| 00:21 | <rniwa> | Domenic: and script has a bunch of legacy re-entrancy problems |
| 00:21 | <rniwa> | Domenic: but those things don't exist for custom elements (luckily) |
| 00:21 | <rniwa> | Domenic: but you're right that someone has to figure out how to update the spec... |
| 00:21 | <rniwa> | and make sure all details are covered |
| 00:24 | <rniwa> | Domenic: one more note: https://github.com/w3c/webcomponents/pull/405/files#r54660611 |
| 00:24 | <Domenic> | thanks, saw that. gtg food, will pick this up later tonight or maybe tomorrow. |
| 00:24 | <rniwa> | Domenic: okay! |
| 00:25 | <rniwa> | Domenic: great work! thanks a lot for doing this! |
| 00:25 | <Domenic> | :D |
| 00:26 | <rniwa> | Domenic: btw, we just added the support for ::slotted |
| 00:26 | <rniwa> | Domenic: and I'm half way there on adding the parser support |
| 00:26 | <Domenic> | \o/ |
| 00:26 | <rniwa> | Domenic: I'll let you guys know once the parser work is done because then you guys can play around with it |
| 00:26 | <rniwa> | ETA is like 1-2 weeks |
| 00:35 | <TabAtkins> | annevk: Heads-up, I spent today doing a lot of perf hacking, so you should see a *significant* decrease in built time. I've been testing against real specs while doing this, so I shouldn't have regressed behavior anywhere, but let me know if you hit anything bad. |
| 00:36 | <nox> | Domenic: Shouldn't Document.all use elements' IDs (as in "An element can have an associated unique identifier (ID)") rather than the id attribute? |
| 00:37 | <Domenic> | nox: I don't think there's a difference? I didn't touch that text I believe |
| 00:37 | <nox> | Oh right. |
| 00:38 | <nox> | Domenic: Reviewed. |
| 00:38 | <Domenic> | nox: thanks, good catch |
| 00:38 | <nox> | How do you not kill your eyes reviewing that stuff all the time? :P |
| 01:12 | <JonathanNeal> | If Elements is a subclass of Array, should concat/map/sort/etc return a new Elements object or a new Array? |
| 01:19 | <rniwa> | JonathanNeal: a new Elements in ES2015 |
| 01:19 | <Domenic> | although we might want to override map (and concat??) to return an Array instead |
| 01:20 | <Domenic> | the alternative is allowing Elements to contain non-elements and just ignore them when doing .query/.queryAll |
| 01:20 | <rniwa> | Is this Elements a new DOM/HTML interface we're adding? |
| 01:21 | <Domenic> | It's been in the spec for a while, but blocked on implementations supporting subclassing of Array. I guess that is probably not a blocker anymore. |
| 01:21 | <Domenic> | https://dom.spec.whatwg.org/#element-collections |
| 01:23 | <JonathanNeal> | I’m writing a polyfill. I’m hoping to match spec (best as one can). |
| 01:48 | <JonathanNeal> | Perhaps .concat is a bad thing to expect on Elements. |
| 01:51 | <JonathanNeal> | For instance, I would expect that queryAll('span').queryAll('span') on <span 1><span 2><span 3/></span></span> should only return [<span 2/>, <span 3/>] because I would expect it to sort the collections and remove duplicates. Is that a bad expectation? |
| 01:52 | <JonathanNeal> | And, if that is the case and .concat returns a new Elements collection, would it also sort and remove duplicates? |
| 01:54 | <JonathanNeal> | Domenic , TabAtkins, was this already worked out? |
| 06:20 | <annevk> | Domenic: rniwa: I was not against synchronous createElement. Maybe someone else? Don't think it matters much. Did you make the code reusable for the parser? |
| 06:21 | <annevk> | JonathanNeal: seems reasonable |
| 06:22 | <rniwa> | annevk: it is, other than the fact we need to swallow the exception and create a HTMLUnknownElement instead |
| 06:23 | <annevk> | Right, you do different things with the result |
| 08:19 | <MikeSmith> | zcorpan: they way you fixed the square-brackets problem with https://github.com/whatwg/wattsi/pull/23 is very nice |
| 08:20 | <zcorpan> | MikeSmith: thanks |
| 08:20 | <zcorpan> | Hixie_: want to have a quick look at the PR ^ ? |
| 08:21 | <MikeSmith> | it may seem obvious but to me at least it wasn’t, because when I saw that issue my first thought was instead, shit now I have to write a percent-encoder |
| 08:22 | <MikeSmith> | I had seen that MungeTopicToID function in the code but hadn’t bothered to pay attention to it |
| 08:22 | <MikeSmith> | lesson learned |
| 08:23 | <MikeSmith> | but glad you go to that before me, because I probably would have burned up time trying to write a percent-encoder and then ended up realizing that was not the right way |
| 10:04 | <Ms2ger> | Oh look, glazou found the webkit* events in the DOM spec |
| 10:06 | <annevk> | No fault in that reaction |
| 10:06 | <annevk> | Hopefully he recovers before noticing webkitMatchesSelector |
| 10:09 | <jgraham> | I think he will find it hard to read specs whilst passed out |
| 11:39 | <MikeSmith> | haha |
| 11:52 | <nox> | Ms2ger: Where is that? |
| 11:52 | <Ms2ger> | https://twitter.com/glazou |
| 11:53 | <nox> | Ah ah. |
| 11:53 | <Ms2ger> | annevk, btw https://twitter.com/glazou/status/700321457734356992 |
| 11:56 | <Ms2ger> | annevk, what should new Blob(undefined) do? |
| 11:56 | <annevk> | Ms2ger: it's ugly, but don't really have the same reaction to it as I used to |
| 11:57 | <annevk> | Ms2ger: hmm, throw? |
| 11:57 | <annevk> | Ms2ger: iirc that's equivalent to new Blob(), which throws |
| 11:57 | <Ms2ger> | new Blob() doesn't throw |
| 11:57 | <annevk> | oh right, well it should do that then |
| 11:58 | <Ms2ger> | Actually, (undefined) does throw :) |
| 11:58 | <annevk> | I don't understand why the first argument is not simply marked as optional |
| 11:58 | <annevk> | If I had time I'd clean up File API |
| 11:58 | <Ms2ger> | If the spec did use `optional`, you would have been right |
| 12:00 | Ms2ger | files an issue on webidl (sorry bz) |
| 12:00 | <nox> | Why sorry? |
| 12:00 | <annevk> | Ms2ger: the spec should use optional |
| 12:00 | <annevk> | Ms2ger: or is there some compat thing? |
| 12:01 | <Ms2ger> | I don't think so |
| 12:02 | <nox> | So passing undefined == omitting an optional parameter? |
| 12:02 | <annevk> | nox: yes |
| 12:02 | <Ms2ger> | But it's weird that the current code is not equivalent to `optional` |
| 12:03 | <nox> | An ECMAScript value V is converted to an IDL sequence<T> value as follows: |
| 12:03 | <nox> | If V is not an object, throw a TypeError.Ms2ger: Does it say that for sequence<T>, undefined == empty sequence? |
| 12:03 | <nox> | I can't copy-paste. |
| 12:03 | <Ms2ger> | https://heycam.github.io/webidl/#es-overloads |
| 12:03 | <annevk> | Ms2ger: nah, that's because of XMLHttpRequest |
| 12:03 | <nox> | "An ECMAScript value V is converted to an IDL sequence<T> value as follows: If V is not an object, throw a TypeError." |
| 12:03 | <annevk> | Ms2ger: search for "Unfortunately legacy content prevents treating the async argument being undefined identical from it being omitted." |
| 12:03 | <nox> | undefined isn't an object, right? |
| 12:04 | <Ms2ger> | nox, that happens before we get to "An ECMAScript value V is converted to an IDL sequence<T> value as follows" |
| 12:04 | <Ms2ger> | annevk, hmm |
| 12:04 | <annevk> | Ms2ger: so this seems like a File API issue |
| 12:04 | <nox> | I see, and the second argument is optional. |
| 12:04 | <annevk> | Ms2ger: unless you can figure out a way to make the File API IDL work while not breaking the XMLHttpRequest IDL... |
| 12:04 | <nox> | Ms2ger: But why would omitting a sequence argument be like the empty sequence? |
| 12:05 | <annevk> | (it does not seem ideal though, since it's rather magical) |
| 12:05 | <Ms2ger> | nox, it isn't |
| 12:05 | <nox> | Ah, I thought that's what you meant by "But it's weird that the current code is not equivalent to `optional`". |
| 12:06 | <Ms2ger> | https://github.com/w3c/FileAPI/issues/33 |
| 12:15 | <MikeSmith> | JakeA: http://stackoverflow.com/questions/35711724/progress-indicators-for-fetch |
| 12:15 | <MikeSmith> | annevk: ⬆ |
| 12:16 | <MikeSmith> | 「How would I write "a pass-through stream to monitor the bytes" sent?」 |
| 12:16 | <JakeA> | MikeSmith: will answer. We're waiting to see how streams pan out there, if not we'll have to find another way to manage progress |
| 12:17 | <JakeA> | There's a lot of weirdness here due to how uploads interact with redirects |
| 12:17 | <annevk> | Quite |
| 12:25 | <JakeA> | MikeSmith: http://stackoverflow.com/a/35747208/123395 |
| 12:26 | <MikeSmith> | JakeA: superーthanks |
| 13:13 | <ondras> | annevk: do I understand correctly that a cross-origin XHR with a custom Accept header must not be redirected (302)? |
| 13:21 | <Domenic> | I have a basic question about legacy single-byte encodings. What are the columns in https://encoding.spec.whatwg.org/index-windows-1252.txt ? |
| 13:23 | <ondras> | single-byte value, code point, unicode visualisation, description ? |
| 13:23 | <Domenic> | but what does this single-byte value actually represent |
| 13:24 | <Domenic> | it seems like there's a + 0x80 step? |
| 13:25 | <ondras> | apparently, as one-byte encodings differ only in 127-255 values? |
| 13:25 | <Domenic> | hmmm |
| 13:25 | <Domenic> | right ok |
| 13:28 | <ondras> | *128-255 |
| 13:43 | <Domenic> | Is there a name for the single-byte encoding that just encodes things as their equivalent unicode? |
| 13:43 | <Domenic> | So the byte 0x8B just goes to U+008B PARTIAL LINE DOWN |
| 13:44 | <Domenic> | I can't find any index table with that |
| 13:44 | <ondras> | well such encoding would have to be pre-dated by unicode, right? |
| 13:45 | <Domenic> | heh, yeah, i guess so |
| 13:45 | <Domenic> | V8 comes with one built in |
| 13:46 | <nox> | So UTF-8 but with lone code units interpreted as Latin-1? Or something like that? |
| 13:46 | <nox> | Domenic: ^ |
| 13:46 | <nox> | (Just curious about what you mean.) |
| 13:47 | <nox> | Or do you just mean Latin-1? oO |
| 13:48 | <ondras> | hmmh, https://en.wikipedia.org/wiki/Latin-1_Supplement_%28Unicode_block%29 ? |
| 13:49 | <nox> | Code point wise, Unicode is a superset of Latin-1, so maybe that's what you meant? |
| 13:53 | <Domenic> | nox: I don't think that's true. For 128-159, they mismatch |
| 13:53 | <Domenic> | nox: according to https://encoding.spec.whatwg.org/index-windows-1252.txt at least |
| 13:54 | <nox> | Domenic: https://en.wikipedia.org/wiki/ISO/IEC_8859#Relationship_to_Unicode_and_the_UCS |
| 13:54 | <Domenic> | e.g. 0x8B in latin1 is U+2039 ‹ (SINGLE LEFT-POINTING ANGLE QUOTATION MARK) |
| 13:54 | <nox> | Domenic: That is ISO 8859-1 no? |
| 13:54 | <Domenic> | nox: according to the Encoding Standard latin1 === windows-1252 === iso-8859-1, in browsers |
| 13:56 | <Domenic> | Whereas http://www.open-std.org/JTC1/SC2/WG3/docs/n411.pdf for ISO 8859-1 just fails to define what happens in the range 0-159 |
| 13:56 | <Domenic> | *128-159 |
| 14:03 | <annevk> | ondras: not per browsers, works per spec now |
| 14:03 | <gsnedders> | https://en.wikipedia.org/wiki/C0_and_C1_control_codes is a decent summary of C1 stuff |
| 14:05 | <annevk> | Domenic: working of tables is defined in spec, mostly a pointer to code point mapping |
| 14:05 | <Domenic> | annevk: yeah just got thrown off by the +/0 0x80 |
| 14:05 | <Domenic> | +/- |
| 14:08 | <nox> | Domenic: This is really confusing. |
| 14:09 | <nox> | Domenic: I think the Encoding Standard redefined that. |
| 14:10 | <ondras> | annevk: I am confused. The spec says that such redir is an error, no? |
| 14:10 | <ondras> | If the response has an HTTP status code of 301, 302, 303, 307, or 308 |
| 14:10 | <ondras> | Apply the cache and network error steps. |
| 14:10 | <Domenic> | nox: I think the Encoding Standard defined what browsers already do with meta charset="iso-8859-1" or the UI switcher toggling to iso-8859-1 |
| 14:10 | <Domenic> | browsers don't have the luxury of saying "welp, you used something between 128-159 which the spec doesn't define; better crash your page! |
| 14:11 | <nox> | Domenic: Sure but what is the Latin 1 in https://en.wikipedia.org/wiki/Latin-1_Supplement_%28Unicode_block%29#Latin-1_punctuation_and_symbols? |
| 14:12 | <nox> | Ah there is an explanation in https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Coverage |
| 14:14 | <nox> | 'ISO-8859-1 is (according to the standards at least) the default encoding of documents delivered via HTTP with a MIME type beginning with "text/" (however the HTML5 specification requires that documents advertised as ISO-8859-1 actually be parsed with the Windows-1252 encoding.[4])' |
| 14:14 | <annevk> | ondras: what spec? |
| 14:14 | <nox> | Domenic: So the name you are looking for is IANA ISO-8859-1 |
| 14:14 | <nox> | Domenic: Not HTML5 ISO-8859-1, nor ISO's ISO 8859-1. |
| 14:15 | <nox> | Erlang uses IANA ISO-8859-1. That's where I got the "it is a subset of Unicode". |
| 14:15 | <Ms2ger> | Can someone check http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3933 on Edge? |
| 14:15 | <Ms2ger> | annevk? |
| 14:15 | <nox> | Domenic: Are you satisfied by that answer? |
| 14:21 | <nox> | Or not. |
| 14:21 | nox | gives up, too many similar names everywhere. |
| 14:22 | <ondras> | annevk: https://www.w3.org/TR/cors/ |
| 14:28 | <gsnedders> | nox: browsers used ISO-8859-1 as Windows-1252 since forever ago. AFAIK IE always has, and I /think/ Netscape always has too. |
| 14:29 | <nox> | gsnedders: Yeah but then I would like to know where Erlang's definition comes from. :) |
| 14:29 | <nox> | But I got ISOitis and stopped looking for it. |
| 14:33 | <Ms2ger> | gsnedders, you don't have Edge? |
| 14:46 | <gsnedders> | Ms2ger: It's failing to auto-update to the latest version :\ |
| 14:47 | <Domenic> | Summarized encoding situation at https://github.com/nodejs/node/pull/5504#issuecomment-191266052 |
| 14:50 | <gsnedders> | nox: Erlang's definition came from ISO-8859-1 and ECMA-48 (IIRC), and is what most things outside of the web use the "iso-8859-1" label to mean. (Note the "latin1" label has a lot more variation) |
| 14:51 | <Ms2ger> | Still looking for someone who'll admit to having Edge around |
| 14:51 | <jgraham> | Ms2ger: https://dev.windows.com/en-us/microsoft-edge/tools/vms/linux/ |
| 14:52 | <Ms2ger> | Thank you, mr helpful |
| 14:52 | <Ms2ger> | You got one of those? |
| 14:52 | <nox> | gsnedders: Takk. |
| 14:52 | <jgraham> | Ms2ger: No, but you could have |
| 15:13 | <gsnedders> | Ms2ger: so yeah, I have Edge 20, and it claims there are no updates available. |
| 15:31 | <annevk> | Ms2ger: still no Edge |
| 15:31 | <annevk> | ondras: that's not the standard you're looking for |
| 15:32 | <annevk> | ondras: https://fetch.spec.whatwg.org/ |
| 15:34 | <ondras> | annevk: thanks, hmm, CORS specced within the fetch spec? |
| 15:34 | <ondras> | annevk: I am going to use XHR for this... |
| 15:37 | <annevk> | ondras: XHR sits atop Fetch |
| 15:38 | ondras | honestly confused by the rich list of 5.x chapters under "fetching" |
| 15:38 | <ondras> | now where does my question fit into this |
| 15:39 | <ondras> | http-redirect-fetch probably |
| 15:39 | <annevk> | ondras: step 4 of https://fetch.spec.whatwg.org/#http-fetch basically |
| 15:41 | <ondras> | I would say step 5 with |
| 15:41 | <ondras> | redirect status |
| 15:41 | <ondras> | but anyway, according to this spec, it should work |
| 15:41 | <ondras> | thanks |
| 15:41 | <ondras> | also, custom request headers are to be persisted across redirections, right? |
| 15:48 | <annevk> | ondras: yes |
| 15:48 | <annevk> | ondras: that should be very clear from the algorithm |
| 15:51 | <ondras> | fine fine, thanks for assistance |
| 16:37 | <miketaylr> | can we change the topic to "this entire API is a mysterious clusterfuck of legacy garbage" |
| 16:42 | <gsnedders> | that seems reasonable to me |
| 16:49 | <annevk> | Domenic: I was just told by baku why awb was correct |
| 16:50 | <annevk> | Domenic: MessageChannel has a queue, and the target MessagePort can switch realms before messages are actually delivered (when you invoke start()) |
| 16:50 | <annevk> | Domenic: so if you want to properly account for that, you need to serialize and deserialize |
| 16:50 | <Domenic> | annevk: makes sense |
| 16:50 | <annevk> | Domenic: and if SAB indeed wants varying behavior based on realm, we'd have to go there... |
| 17:08 | <annevk> | I feel sad now that I didn't know that ahead of time, oh well, SAB can wait a bit |
| 17:48 | <Domenic> | document.all is the worst. custom bindings are the worst. |
| 17:48 | <Domenic> | having to write test cases for elements with ids like "Infinity" "0x0", and "+0" is the worst. |
| 17:48 | <miketaylr> | haha |
| 20:26 | <annevk> | Domenic: will you get to https://github.com/whatwg/html/pull/783 today? It's not that big |
| 20:27 | <Domenic> | annevk: literally just clicked on that email |
| 20:27 | <annevk> | Domenic: and fixes the last "regression" |
| 20:27 | <annevk> | I see |
| 20:28 | <Domenic> | (as in, clicked on the email that i earlier flagged, as now i am reviewing it) |
| 20:32 | <annevk> | Domenic: I'm somewhat glad I accidentally discovered that even ordinary objects have internal slots |
| 20:32 | <annevk> | Domenic: which I kinda knew, but not actively, if that makes sense |
| 20:33 | <Domenic> | yeah that surprised me a bit |
| 20:37 | <annevk> | I thought https://twitter.com/glazou/status/705089928238125056 was advice from CSS |
| 20:38 | <annevk> | Is this the grownup version of the kid saying the other parent endorsed some plan? |
| 20:40 | <Domenic> | yep |
| 20:40 | <Domenic> | this is literally not a whatwg decision |
| 20:40 | <Domenic> | this is a tab and fantasai decision |
| 20:44 | <jsbell> | when you find out someone is using your polyfill via npm and you made an API-breaking change and forgot to bump the minor version |
| 20:46 | <annevk> | Domenic: https://twitter.com/rillian/status/705109214885126144 is relevant to your interests |
| 20:56 | <Domenic> | lol i just switched to win64 yesterday |
| 20:59 | <annevk> | hah |
| 21:02 | <TabAtkins> | annevk: Don't worry, glazou just got angry about the decision on the call today. |
| 21:03 | <TabAtkins> | (His entire argument is that the name "list-item" makes it seem a little confusing to apply to <summary>, which isn't a list item. He wasn't impressed by the reply that 'display' has no semantic value.) |