| 00:02 | <hiroshige> | Filed: https://github.com/whatwg/meta/issues/54 |
| 01:54 | <abarth> | hsivonen, zcorpan : yes |
| 01:54 | <abarth> | one of the goals was minimalism |
| 01:54 | <abarth> | which means have as narrow a pattern as required for web compat |
| 01:55 | <abarth> | BOM + pattern isn't required for web compat |
| 01:55 | <abarth> | so isn't in the algorithm |
| 02:02 | <MikeSmith> | hiroshige: thanks for reporting that ー will look into it (but it may need foolip to fix, once he gets on for the day) |
| 02:03 | <MikeSmith> | and thanks TabAtkins too 🐍 |
| 02:03 | <MikeSmith> | and thanks paul_irish for ops ☘️ |
| 02:04 | <MikeSmith> | and oh hello abarth |
| 02:05 | <MikeSmith> | TabAtkins: can you please check what IP address html.spec.whatwg.org is resolving to for you? |
| 02:07 | <MikeSmith> | it should be 165.227.248.76 |
| 02:08 | <MikeSmith> | if it’s instead 75.119.197.251 then that’s the problem |
| 02:08 | <MikeSmith> | we moved the DNS for it recently |
| 02:09 | <MikeSmith> | so you must be hitting a problem with cached DNS somewhere not getting invalidated |
| 02:10 | <MikeSmith> | (assuming you don’t have it hardcoded to resolve to 75.119.197.251 in /etc/hosts or whatever) |
| 02:27 | <MikeSmith> | but the workaround for now is to hardcode it in an /etc/hosts or equivalent |
| 02:27 | <MikeSmith> | add this line: |
| 02:28 | <MikeSmith> | 165.227.248.76 html.spec.whatwg.org |
| 02:28 | <TabAtkins> | It's working for me here at home, but it was failing for me and fantasai at work, so yeah, probably a DNS cache problem. |
| 02:28 | <MikeSmith> | yeah |
| 02:29 | <MikeSmith> | Hixie says he only make the DNS change about 3 hours ago |
| 02:29 | <TabAtkins> | And yeah, ping shows the good IP address here. |
| 02:29 | <MikeSmith> | k |
| 02:29 | <TabAtkins> | Ah, that would correspond pretty well to when I saw it. |
| 04:27 | <abarth> | hi MikeSmith |
| 05:09 | <annevk> | Thanks paul_irish, and yeah, I think you did 😊 |
| 09:30 | <TheWild> | hello |
| 09:30 | <TheWild> | what was the reason of removal of support for UTF-16 in TextEncoder? |
| 09:33 | <annevk> | TheWild: it was the only place in the web platform that exposed encoding UTF-16 |
| 09:33 | <annevk> | TheWild: and we're not a big fan of UTF-16, so |
| 09:34 | <TheWild> | so no support for UTF-16? What about those language where UTF-16 representation is more compact than UTF-8? |
| 09:35 | <TheWild> | languages |
| 09:36 | <annevk> | TheWild: given that there's usually markup involved in transporting such language, even ignoring compression, that argument is flawed |
| 09:37 | <annevk> | TheWild: see also https://annevankesteren.nl/2009/09/utf-8-reasons and in particular https://lists.w3.org/Archives/Public/www-style/2009Feb/0087.html |
| 09:37 | <annevk> | such a language* |
| 09:37 | <annevk> | TheWild: hope that helps |
| 09:37 | <annevk> | TheWild: oh, https://github.com/whatwg/encoding/issues/18 also has some relevant discussion and workarounds |
| 09:38 | <TheWild> | ok, let it be. I'll read later. Thanks annewk. |
| 09:45 | <TheWild> | thought my problem was to convert ArrayBuffer to string (so it can be used as a dictionary key) and back, without involving much conversion. Yeah, I can "cast" the ArrayBuffer to Uint16Array and use s += String.fromCharCode(x), but I thought there's faster, more "internal" way. |
| 09:47 | <annevk> | TheWild: use a Map? |
| 09:48 | <annevk> | TheWild: although I guess that depends what the dictionary is for |
| 09:48 | <annevk> | TheWild: but also, unless the ArrayBuffer contains valid UTF-16 you'd get data loss with such a conversion |
| 09:48 | <TheWild> | a = new Uint8Array([2, 3]); b = new uint8Array([2, 3]); in Map, a and b would be treated as different keys. |
| 09:49 | <annevk> | TheWild: ah yeah, doh |
| 09:49 | <annevk> | TheWild: I think what you want is something that isn't addressed by UTF-16 encoding, as you'd want to preserve lone surrogates |
| 09:50 | <annevk> | TheWild: you need an Uint16Array -> String thing which indeed seems like something that could be really fast |
| 09:50 | <TheWild> | since ArrayBuffer would hold just some binary data, correct UTF-16 codepoints aren't guaranted. (AFAIR 0xD800 - 0xDBFF and 0xDC00 - 0xDFFF were surrogates) |
| 09:51 | <annevk> | TheWild: indeed, encoding them would turn those into U+FFFD so you'd get data loss |
| 10:19 | <hsivonen> | abarth: OK. What's your opinion on using different patterns for file: URLs? that is, do you think it would be a) appropriate and b) worthwhile to sniff HTML with UTF-8 BOM but not .html in the file name as text/html when accessed using file: URL? |
| 10:19 | <hsivonen> | abarth: are there security considerations relevant to file: for not following the same sniffing as for network resources? |
| 10:24 | <JakeA> | annevk: If I have an options dict, can I access its properties "in parallel" or do I need to create variables for all the properties before going parallel? |
| 10:26 | <annevk> | JakeA: I would argue that you can, unless you end up manipulating objects on the main thread that way |
| 10:26 | <annevk> | JakeA: e.g., if they hold pointers |
| 10:27 | <TimothyGu> | TheWild/annevk: at least in case of V8 there are C++ APIs provided for working with 16-bit data as strings conveniently |
| 10:27 | <TimothyGu> | e.g. v8::String::NewFromTwoByte() which literally just wraps around the array (after copying) |
| 10:28 | <annevk> | TimothyGu: do you know if this came up in TC39 before? |
| 10:28 | <annevk> | TimothyGu: seems such an obvious thing to offer |
| 10:28 | <TimothyGu> | not sure |
| 10:28 | <JakeA> | annevk: cheers! |
| 10:28 | <annevk> | I guess I'll ask over in #tc39 |
| 10:28 | <TimothyGu> | I mean there's String.fromCharCode(..array) |
| 10:28 | <annevk> | I see |
| 10:30 | <JakeA> | annevk: one more question, is the best practice these days "|options|.{{FooOptions/bar}}" or "|option|'s {{FooOptions/bar}} member"? |
| 10:31 | <annevk> | JakeA: I think the latter and maybe |options|["bar"] works too these days if dictionaries are already defined in terms of ordered maps |
| 10:32 | <annevk> | JakeA: we discussed this recently somewhere |
| 10:32 | <JakeA> | annevk: ta! |
| 10:33 | <annevk> | JakeA: per https://github.com/heycam/webidl/issues/453 dictionary["member"] is defined already and the way to go |
| 10:45 | <annevk> | hsivonen: given those questions I'm inclined not to reply to https://bugzilla.mozilla.org/show_bug.cgi?id=1422889 for now |
| 10:47 | <annevk> | hsivonen: I tend to think it's best to be conservative there too and rely on the OS mapping given the number of subtle exploits with getting the user to run local files in their browser |
| 10:47 | <annevk> | hsivonen: it's rather unfortunate we still have to support that I think |
| 15:09 | <Domenic> | annevk: TheWild (who isn't here): it seems like this is a specific case of the fact that Maps don't have a good equality protocol besides === (well, actually SameValueZero). |
| 15:09 | <Domenic> | That would be the language-level change I would expect |
| 15:10 | <Domenic> | Reducing things to immutable values (whether they be strings or bigints) just so that they can serve as good map keys is a "hack" IMO. Although a very necessary one given the language as it is today. |
| 15:13 | <annevk> | I guess that's fair, representing strings as bytes and bytes as strings is only ever done as a workaround for something that's lacking |
| 15:24 | <Domenic> | MikeSmith: https://github.com/validator/validator/commit/d954e3c20f53a8015c4d2de06316c6b0fef23406 is nice :) |
| 15:43 | <a-ja> | is there a channel for css wg? looking to find fantasai on irc, about a possible hanging-punctuation issue |
| 15:45 | <a-ja> | if not, can email i guess. no hurry or anything...very edge-case |
| 15:47 | <Ms2ger> | #css on irc.w3.org |
| 15:50 | <a-ja> | Ms2ger, tks...not on there unfortunately. that's where i looked first before asking. |
| 15:51 | <Ms2ger> | That doesn't mean it's not the channel you're looking for :) |
| 15:52 | <a-ja> | true enough. or looking for the wrong nick. |
| 15:53 | <Ms2ger> | fantasai is in there, but you aren't? |
| 15:55 | <a-ja> | Ms2ger, doh...looking on freenode. tks |
| 16:18 | <abarth> | hsivonen: sounds like a tricky problem. I haven't thought about it in enough detail recently to have an informed opinion. Another thing to consider for file URLs is whether to use the file extension as input. That's what other programs use on commonly used operating systems (although obviously not for all operating systems). |
| 16:22 | <gsnedders> | I presume no browsers support xml:id for things like the id selector? |
| 16:33 | <annevk> | gsnedders: they must not |
| 16:44 | <gsnedders> | annevk: is that actually specified for Selectors? |
| 16:45 | gsnedders | somewhat suspects this is something that falls through the cracks with how Selectors is meant to be agnostic about what it's matching against |
| 16:50 | <annevk> | gsnedders: many things are not specified from that perspective |
| 16:50 | <annevk> | gsnedders: as I’ve complained about in the past |
| 16:53 | <annevk> | gsnedders: the way DOM deals with this is only giving id= power |
| 19:41 | <TabAtkins> | Selectors is indeed agnostic about this, intentionally. The host language defines (or *should* define) what concepts map to what in the Selectors data model. The DOM mapping is fairly intuitive, but if nothing in HTML specifies how xml:id works, it should. |
| 19:45 | <gsnedders> | TabAtkins: HTML just defers to DOM on what's an id |
| 19:45 | <gsnedders> | TabAtkins: (it doesn't define how xml:id in the same way it doesn't define how thisisbogus works) |
| 19:46 | <gsnedders> | TabAtkins: so DOM should define how the DOM tree maps to the Selectors data model, in your view? |
| 19:46 | <TabAtkins> | That's been the stated intention for well over a decade, yes. |
| 19:50 | gsnedders | files an issue and runs away |
| 19:50 | <gsnedders> | (https://github.com/whatwg/dom/issues/542) |