| 11:15 | <annevk> | hsivonen: https://bugs.chromium.org/p/chromium/issues/detail?id=691985 Chrome erroneously defaulting to UTF-8 btw |
| 11:21 | <annevk> | hsivonen: it's rather frustrating they're not really doing anything about it |
| 12:37 | <XhmikosR> | Domenic: I'm interested in sorting this https://github.com/jsdom/jsdom/issues/2386 |
| 12:37 | <XhmikosR> | should I make a new issue in https://github.com/whatwg/html ? |
| 12:38 | <XhmikosR> | I couldn't find any related issue from a quick search, only for the `html` part's case |
| 12:38 | <annevk> | XhmikosR: that doesn't seem like something we can change the serialization for at this point |
| 12:38 | <annevk> | XhmikosR: or are you saying browsers do this differently? |
| 12:38 | <XhmikosR> | it works fine with lowercase `doctype` |
| 12:39 | <XhmikosR> | but the spec says uppercase |
| 12:39 | <annevk> | XhmikosR: yes, because that's how the API works today, right? |
| 12:39 | <annevk> | XhmikosR: we can't just change the API contract |
| 12:40 | <annevk> | XhmikosR: https://whatwg.org/working-mode might help |
| 12:42 | <XhmikosR> | I just find it weird that all browsers seem to work fine with lowercase `doctype` yet the specs say uppercase, so it seems like something that could be adapted, that is why I ask :) |
| 12:42 | <annevk> | XhmikosR: they work fine with uppercase too, but input isn't what this is about |
| 12:42 | <XhmikosR> | true |
| 12:42 | <annevk> | XhmikosR: this is about serialization and the question is what happens there and what tooling around that serialization might depend upon |
| 12:44 | <XhmikosR> | I don't know, when it comes to the W3C repos, I get lost :P |
| 12:45 | <XhmikosR> | anyway, just wondering if we can allow this or not, if not I guess I'll try to find a workaround so that I keep the `doctype` lowercase. It's just that more tools do this, even cheerio 1.x IIRC |
| 13:34 | <Domenic> | XhmikosR: annevk is right, serialization is not something we would change. For more on why parse/serialize rountrips never preserve the original, see https://github.com/inikulin/parse5/issues/261#issuecomment-401389295 |
| 13:35 | <XhmikosR> | yeah, I got it :) Too bad, I guess we are stuck with this |
| 13:50 | <zcorpan> | I don't understand. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6264 shows no button appearance in chrome on macOS. But if I open the "Rendered view" in a new tab it does! |
| 13:51 | <annevk> | zcorpan: identical on Canary |
| 13:52 | <annevk> | zcorpan: High Sierra though |
| 13:52 | <zcorpan> | I also have High Sierra |
| 13:52 | <annevk> | Sounds like you could use Canary :p |
| 13:53 | <zcorpan> | I get the same result in Canary |
| 13:54 | <zcorpan> | oooooh |
| 13:54 | <zcorpan> | I have non-100% page zoom |
| 13:55 | <annevk> | oh my |
| 14:11 | <zcorpan> | https://bugs.chromium.org/p/chromium/issues/detail?id=893597 |
| 15:16 | <lgrahl> | Domenic: "domenic seems to be fine with the pseudo-stream design." - not reading that out of your comment... quite the opposite? https://github.com/w3ctag/design-reviews/issues/303#issuecomment-422235381 |
| 15:19 | <lgrahl> | Or did I misinterpret something? |
| 15:26 | <annevk> | lgrahl: fine until they try to ship it |
| 15:26 | <annevk> | 😊 |
| 15:26 | <lgrahl> | annevk: Heh :) |
| 15:27 | <annevk> | And yeah, let’s not do another “we’re not convinced of your future so we’ll do our own API design” again |
| 15:29 | <lgrahl> | What I find quite funny is that they have just started refactoring their streams from bidirectional to unidirectional... guess which API |
| 15:32 | <lgrahl> | But since they just ignore my comments entirely... |
| 15:38 | <annevk> | I’m sorry, that sounds really bad |
| 15:38 | <annevk> | Is this on GitHub? |
| 15:47 | <lgrahl> | Ah, no worries, I'm just a bit fed up with them. You mean the unidirectional PR? It's here: https://github.com/w3c/webrtc-quic/pull/70 |
| 15:51 | <annevk> | Not seeing comments of you there and do see some signs of the Streams API |
| 15:51 | <annevk> | Ah, QUIC, prolly some ways away still |
| 15:55 | <lgrahl> | I'm not seeing signs of the Streams API? Or do you mean just general similarities? |
| 15:57 | <lgrahl> | (I haven't commented in the PR since there was no reaction to https://github.com/w3c/webrtc-quic/pull/53#issuecomment-420553744) |
| 16:44 | <annevk> | lgrahl: I might have read too much into the mention of ReadableStream |
| 16:46 | <annevk> | lgrahl: as long as https://github.com/w3c/webrtc-quic/issues/2 remains open I guess I’m not gonna say much |
| 16:46 | <lgrahl> | annevk: Not sure I like the "icebox" label though :) |
| 16:47 | <annevk> | lgrahl: I could add a comment there that Mozilla would highly likely object to any design that does not use them |
| 16:47 | <annevk> | I see |
| 16:47 | <annevk> | I guess I should comment tomorrow then 😟 |
| 16:49 | <lgrahl> | I mean, let's be honest, the advantages of the Streams API are obvious and many others will object to the current design. The only risk that I see is that they at some point say "But meh, the implementation is done and redesigning the API would take too long." |
| 16:51 | <lgrahl> | The QUIC API hasn't even been accepted by the WebRTC WG so far. I'm pretty sure Jan-Ivar would also reject it in its current state. |
| 16:58 | <lgrahl> | As you say, Mozilla will likely object to it and thus they are just making it hard for themselves. |
| 17:03 | <annevk> | Added a comment |
| 18:14 | <lgrahl> | annevk: Cheers! Just hope I haven't started a feud here... :) |