| 00:22 | <wanderview> | Mek: if you found a spec issue, please file a bug here: https://bugzilla.mozilla.org/enter_bug.cgi?format=guided#h=dupes|Core|DOM |
| 03:27 | <Domenic> | Well, if it's in reasonable ways, we could change the spec |
| 07:21 | <annevk> | Ms2ger: do you care about a clean merge for https://github.com/whatwg/html/pull/1181? Some more whitespace nits that I'm happy to fix while merging |
| 07:21 | <Ms2ger> | Go for it |
| 07:59 | <zcorpan> | hmm, the try/catch thing is something i hadn't considered before. http://blog.getsentry.com/2016/05/17/what-is-script-error.html |
| 08:00 | <zcorpan> | i wonder if there's still a good reason to mute runtime script errors |
| 08:00 | ondras | would like to ask the same |
| 08:02 | <zcorpan> | maybe if you manage to load a script file that you have no idea what it contains, you could learn things from onerror but not with try/catch (if you don't know what to call) |
| 08:02 | <annevk> | zcorpan: indeed, that is what is being protected |
| 08:03 | <annevk> | zcorpan: does the try/catch approach reveal line numbers and such though? That might be somewhat problematic |
| 08:10 | <Ms2ger> | zcorpan, isn't the point more when loading non-script files in script elements? |
| 08:15 | <zcorpan> | Ms2ger: yes, that's when you hit a compile-time script error. but the spec also protects runtime ones |
| 08:16 | <zcorpan> | if the external script uses (function() { ... })(); and doesn't expose any functions then there's nothing you can call with try/catch |
| 08:19 | <zcorpan> | annevk: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4210 |
| 08:21 | <annevk> | zcorpan: "@http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4210:5:3"; is what I get in Firefox |
| 08:22 | <annevk> | zcorpan: so I guess it's not really revealing then or really the same level of detail? |
| 08:23 | <zcorpan> | so firefox doesn't include the part of the stack that came from another origin |
| 08:23 | <annevk> | Part of the problem might be e.stack not being defined |
| 08:23 | <annevk> | But what Firefox does seems good |
| 08:24 | <annevk> | I wonder if that code in Firefox is also CORS-aware |
| 08:24 | <zcorpan> | i don't get cross-origin stacks in safari/chrome/opera |
| 08:26 | <annevk> | Good |
| 08:27 | <zcorpan> | CORS seems to reveal the stack (even without crossorigin="") http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4211 |
| 08:28 | <annevk> | Without crossorigin?! |
| 08:28 | <annevk> | Argh |
| 08:29 | <annevk> | How does that even make sense? Are you sending both credentials allowed and an explicit origin? |
| 08:29 | <annevk> | You are not, whoa |
| 08:29 | <annevk> | That is a bug |
| 08:29 | <annevk> | Security bug even |
| 08:30 | <zcorpan> | why is it a security bug? |
| 08:31 | <annevk> | zcorpan: because <script> requests are made with credentials, so if the cookies introduce user-sensitive data in the script, those can now leak |
| 08:31 | <annevk> | zcorpan: whereas the publisher of the script only wanted to share the script when it was requested without credentials |
| 08:32 | <zcorpan> | hmm ok |
| 08:32 | <annevk> | I don't know who did this, but CORS should really remain opt-in so there's one layer responsible for handling the security checks |
| 08:32 | <annevk> | This kind of adhoc thing is just dangerous |
| 08:44 | <annevk> | zcorpan: do you want to file security bugs or should I? |
| 08:44 | <annevk> | zcorpan: I guess I'll file one against Gecko and copy you for credit |
| 08:45 | <zcorpan> | annevk: you can file, i should start writing a presentation :-) |
| 09:31 | <nox> | Is there any spec that replaces the RFCs for CONNECT and HTTP requests made to proxies, btw? |
| 10:09 | <kochi1> | I'd like to have apple's feedback for https://github.com/w3c/webcomponents/issues/184 ... |
| 10:13 | <annevk> | kochi1: best to ping rniwa in the issue again |
| 10:16 | <annevk> | kochi1: btw, if you can nudge tyoshino to review https://github.com/whatwg/fetch/pull/298 that'd be appreciated |
| 11:22 | <hsivonen> | annevk: is the back and forth division and multiplication really the best way to encode a 4-byte gb18030 sequence? |
| 11:25 | <annevk> | hsivonen: I think it might depend on whether you care about memory or speed |
| 11:25 | <annevk> | hsivonen: but it's been a while |
| 11:25 | <annevk> | hsivonen: the algorithm in the specification optimizes for not storing a lot of data |
| 11:27 | <hsivonen> | annevk: do you mean it tries to minimize temporary values even if they'd fit in registers on a typical CPU? |
| 11:27 | <hsivonen> | (I care about speed as long as memory is "fits in registers") |
| 11:28 | <annevk> | hsivonen: I meant that you could have more comprehensive backing tables and less math |
| 11:28 | <annevk> | hsivonen: e.g., I don't think ICU's implementation uses the 127 entries trick |
| 11:29 | <hsivonen> | 127 entries? |
| 11:29 | <annevk> | 207 it seems, https://encoding.spec.whatwg.org/index-gb18030-ranges.txt |
| 11:30 | <hsivonen> | annevk: yeah, that part is fine |
| 11:30 | <hsivonen> | annevk: but when you have a ranges pointer, the way you go to 4 bytes looks on the surface like it'd benefit from the % operator |
| 11:31 | <hsivonen> | maybe |
| 11:31 | <hsivonen> | what I'm asking is if it really needs to be the way it's written |
| 11:31 | <annevk> | hsivonen: my bad, that could probably be done differently, yes |
| 11:32 | <annevk> | hsivonen: this is from the time when the specification didn't try to use those operators directly |
| 11:32 | <hsivonen> | if a pattern a = x / y; b = x % y; is hidden in there, it might be better to use that |
| 11:33 | <hsivonen> | ok. I guess I'll just make a note to revisit the math |
| 11:34 | <hsivonen> | By stated goals, I shouldn't care about the encoder speed for encoders other than UTF-8 anyway... |
| 11:36 | <annevk> | So yeah, http://source.icu-project.org/repos/icu/data/trunk/charset/data/xml/gb-18030-2000.xml has far less ranges, but that doesn't say much about the math of course |
| 12:02 | <hsivonen> | I have written code that assumes that gb18030 can encode all of unicode |
| 12:02 | <hsivonen> | that's wrong. there's one code point that it can't |
| 12:03 | <hsivonen> | looks like I will have to revisit the code where I made the assumption that gb18030 encodes all of Unicode |
| 12:03 | <Ms2ger> | Doh |
| 12:05 | <Cablegunmaster> | UTF8 does that right? :) |
| 12:05 | <jgraham> | Well, unless you are MySQL, yes |
| 12:06 | <jgraham> | But for hsivonen that's not really the point :) |
| 12:07 | <hsivonen> | Cablegunmaster: UTF-8 is the only encoding in the Encoding Standard whose output encoding can encode all of Unicode. |
| 12:09 | <annevk> | hsivonen: yeah, gb18030 was intended to be a UTF, but browsers messed that up |
| 12:09 | <hsivonen> | So next time you say that everyone should use Unicode in order to avoid data loss in form submission and a pedant says "What about gb18030?", you can answer "U+E5E5!!!!!" |
| 12:09 | <gsnedders> | what one code point can it not? |
| 12:09 | <hsivonen> | argh. s/Unicode/UTF-8/ |
| 12:09 | <gsnedders> | oh, that |
| 12:15 | <Cablegunmaster> | hsivonen, I love utf8 =) only one im using for my websites. |
| 12:16 | <Cablegunmaster> | always wondered why should there still be other unicodes out there? :o |
| 12:46 | <annevk> | Cablegunmaster: no good reason, but at some point the thought was that UTF-16 was going to be it |
| 12:47 | <annevk> | Cablegunmaster: not sure why they bothered with UTF-32 though |
| 12:47 | <annevk> | Cablegunmaster: anyway, UTF-8 is the only one with good ecosystem support so best to stick with that |
| 12:58 | <Cablegunmaster> | that be true as well annevk thanks for the clear answer :)! |
| 13:02 | <nox> | annevk: What's wrong with UTF-32? |
| 13:02 | <annevk> | nox: doesn't solve an actual problem? |
| 13:02 | <nox> | Cablegunmaster: Unicode is least worst encoding we have currently, but it's clearly Latin-centric and kinda bad for CJK. |
| 13:03 | <annevk> | Unicode is not an encoding... |
| 13:03 | <nox> | annevk: True, s/encoding/standard/ |
| 13:04 | <nox> | annevk: A friend of mine that lives in China explained to me that for texts with a lot of person names and old ideograms, it gets quite slow to decode UTF-8 and UTF-32 isn't much bigger in memory. |
| 13:05 | <annevk> | nox: slow to this day? Seems spurious |
| 13:05 | <annevk> | nox: that'd mean emoji slow down stuff too |
| 13:06 | <nox> | annevk: It was 3 years ago or so. |
| 13:06 | <nox> | annevk: Well they don't make things faster for sure, but yeah, didn't experience that myself. |
| 13:06 | <nox> | annevk: Wonder if http://emojitracker.com had to do anything fancy for decoding. |
| 13:06 | <annevk> | I can see how Han Unification is bad, but I don't think using four bytes for a code point is really that bad |
| 13:08 | <annevk> | nox: it doesn't seem to list emoji that use more than one code point |
| 13:08 | <nox> | annevk: That's a thing? ( ._.) |
| 13:08 | nox | cries. |
| 13:08 | <annevk> | nox: sure, e.g., all flags use two (and there's proposal for flags that use more) |
| 13:08 | <nox> | annevk: Oh, the ones with variant modifiers? |
| 13:09 | <annevk> | nox: you can compose families out of half a dozen code points, etc. |
| 13:09 | <nox> | Oh right I remember the flag drama. |
| 13:09 | <annevk> | I don't think it's a drama? It's a pretty neat design |
| 13:11 | <nox> | annevk: I remember that before this neat design, |
| 13:11 | <nox> | Taiwan wanted a code point for its flag, and China wasn't amused, or something like that. |
| 13:35 | <stennowork> | taiwan isn't really recognized by many countries |
| 14:38 | <TabAtkins> | UTF-8 is incredibly fast for something that clever. Slower than UTF-32 of course, because that's no decoding at all. |
| 14:39 | <TabAtkins> | But unless the page is *incredibly* text-heavy, UTF-8 gives significant space-savings even over 2-byte chinese-specialized encodings, let alone UTF-32. |
| 14:43 | <Ms2ger> | TabAtkins, and UTF-32 gives more memory traffic |
| 14:49 | <annevk> | I'd love to see some benchmarks |
| 14:49 | <annevk> | Ms2ger: and more IO-traffic too |
| 14:58 | <nox> | annevk: "emojitracker does support multiple code point emoji, just hasn't been updated for new emoji added in Unicode 8.0+" |
| 14:59 | <annevk> | nox: I didn't spot any flags, and those have been there since 6 |
| 14:59 | <annevk> | nox: didn't look carefully though |
| 15:00 | <annevk> | nox: never mind, spotted a flag just now |
| 15:00 | <nox> | :) |
| 16:37 | <Jackson_> | Hi, I had a question about `<script type="module">`. I've looked through the spec and saw this question: https://github.com/whatwg/html/pull/443#issuecomment-167904832 but wanted confirmation on something: If I have a `<script type="module" src="a.js">`, where "a.js" will `export` a module, and I also have `<script type="module" src="b.js">`, and "b.js" will `import "./a";`, will the same instance of the module created by the former |
| 16:37 | <Jackson_> | `<script type="module" src="a.js">` be used? |
| 16:38 | <annevk> | Jackson_: if they're in the same document, yes |
| 16:40 | <Jackson_> | annevk: Thanks. Do you know where that is stated in the spec? |
| 16:40 | <annevk> | Jackson_: it's part of the "module map" semantics |
| 16:41 | <annevk> | Jackson_: https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-single-module-script makes this quite explicit |
| 16:42 | <annevk> | Jackson_: I forgot if there's also an easier summary of this or an example of some sort |
| 16:43 | <annevk> | Jackson_: seems like the script element section could use an example that illustrates this... willing to contribute one? |
| 16:49 | <Jackson_> | annevk: Yeah, I can contribute one. To clarify further (this is what prompted me to ask this): In https://html.spec.whatwg.org/multipage/scripting.html#prepare-a-script, step 18, where "Fetch a module script tree" receives "settings": That is where a per-Document module map is provided to each `<script type="module">`, correct? https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-module-script-tree says the module map is |
| 16:49 | <Jackson_> | "optional," so I did know precisely where the module map came from. |
| 16:50 | <Jackson_> | * I did not know... |
| 16:50 | <annevk> | Jackson_: if "module map settings object" is not given, it uses the "fetch client settings object" |
| 16:51 | <annevk> | Jackson_: the settings object holds a reference to the actual "module map" |
| 16:51 | <annevk> | Jackson_: this setup is also used by workers, which is why the algorithms are rather abstract |
| 16:55 | <Jackson_> | annevk: So, the reason the modules are shared, is because the "fetch client settings object" is per-Document? (I did not see where the "fetch client settings object" was defined.) |
| 17:42 | <Domenic> | Jackson_: that will fail since "/.a" is a 404 |
| 17:43 | <Domenic> | Jackson_: but if you correct it to "./a.js" it will indeed use the memoized module map |
| 17:43 | <Domenic> | Jackson_: "fetch client settings object" is an argument to the algorithm, and passed in by all the call sites. It is per-Window. |
| 17:47 | <Jackson_> | Domenic: Thanks for these clarifications. |
| 20:08 | <jyasskin> | If folks are interested in the future web stuff Google's excited about, https://events.google.com/io2016/ has cwilso and fbeaufort live. |
| 21:18 | <wanderview> | Mek: thanks for filing the BroadcastChannel bug! |
| 21:18 | <wanderview> | bugs |
| 21:37 | <tantek> | LOL: https://twitter.com/shinypb/status/733302396995010561 |
| 21:38 | <tantek> | "When developers turn their problems into users' problems: AMP, following in XHTML's proud footsteps." cc: gsnedders |
| 21:38 | <tantek> | (see photo) |