| 08:13 | <hsivonen> | https://groups.google.com/d/msg/comp.infosystems.www.authoring.html/M1pz9cJJdxE/_OzpCv8dwwgJ |
| 08:13 | <hsivonen> | "I _don't_ recommend what I'm about to say. However, it is sort-of |
| 08:13 | <hsivonen> | theoretically respectable." |
| 08:13 | <davve> | hel |
| 08:14 | <davve> | oops, wrong window. |
| 08:15 | <odinho> | :] |
| 08:32 | <Ms2ger> | wowser developers, eh |
| 08:35 | <MikeSmith> | is there spec yet for Mozilla data-store API that's been discussed in the sysapps WG? |
| 08:38 | <Ms2ger> | I'd be surprised |
| 08:39 | <MikeSmith> | Ms2ger: do you remember who's pushing for it? |
| 08:40 | <MikeSmith> | I assume it's something wanted for b2g |
| 08:40 | <Ms2ger> | I'll guess... sicking |
| 08:40 | <MikeSmith> | but I vaguely remember hearing that it was mainly wanted for stoarge for the messaging API |
| 08:40 | <MikeSmith> | Ms2ger: ok |
| 08:41 | <MikeSmith> | https://wiki.mozilla.org/WebAPI/DataStore I guess |
| 08:41 | <MikeSmith> | who's Baku? |
| 08:44 | <Ms2ger> | Andrea |
| 08:46 | <Ms2ger> | (If that helps :)) |
| 09:07 | <hsivonen> | Ms2ger: "wowser" means Netscape that ignored SGML thruth |
| 09:07 | <Ms2ger> | That's from before my time :) |
| 09:08 | <hsivonen> | right now, I'm pretty annoyed at Netscape developers who came up with the idea of supporting x-user-defined |
| 09:08 | <hsivonen> | s/thruth/truth/ even |
| 09:10 | <hsivonen> | aargh. this whole "Arial AM" thing happened after Armenian was already in Unicode 1.0. so sad |
| 10:16 | <hsivonen> | annevk-cloud: check http://hsivonen.com/test/moz/x-user-defined/test-2-unknown-or-alias.htm out in Chrome |
| 10:16 | <hsivonen> | annevk-cloud: Is my conclusion that Chrome aliases x-user-defined to windows-1252 correct? |
| 10:39 | <zcorpan> | hsivonen: it says <meta charset="windows-1252"> not 51 |
| 10:41 | <hsivonen> | zcorpan: good typo catch. Thanks. |
| 10:41 | <hsivonen> | zcorpan: even though my testing was wrong, I still found out about a Blink/WebKit quirk: https://bugs.webkit.org/show_bug.cgi?id=18270 |
| 10:41 | <hsivonen> | https://mxr.mozilla.org/chromium/source/src/third_party/WebKit/Source/core/fetch/TextResourceDecoder.cpp#139 |
| 10:41 | <zcorpan> | data:text/html;charset=x-user-defined,%C3%A5 is interesting in firefox |
| 10:43 | <hsivonen> | zcorpan: what's interesting about it? |
| 10:45 | <zcorpan> | hsivonen: for me it renders a glyph for U+F7C3 followed by a "5" |
| 10:46 | <zcorpan> | hsivonen: but if i copy the text and paste into live dom viewer, the 5 becomes U+F7A5 |
| 10:47 | <zcorpan> | hsivonen: anyway, a simpler test is <meta charset=x-user-defined><meta charset=utf-8>å (in utf-8) |
| 10:48 | <zcorpan> | hsivonen: and compare with <meta charset=unknown><meta charset=utf-8>å |
| 10:50 | <zcorpan> | hsivonen: same conclusion. same result in presto, too |
| 10:53 | <zcorpan> | hsivonen: except presto says x-user-defined in your test |
| 10:58 | <zcorpan> | "My understanding is that IE treats x-user-defined differently based on some Registry settings" (from the bug above) |
| 11:03 | <hsivonen> | zcorpan: good idea to test it like that: http://hsivonen.com/test/moz/x-user-defined/baseline.htm |
| 11:03 | <hsivonen> | zcorpan: good idea to test it like that: http://hsivonen.com/test/moz/x-user-defined/test.htm |
| 11:04 | <hsivonen> | the latter shows that x-user-defined decodes those bytes like windows-1252 on en-US IE11 but is a distict encoding |
| 11:04 | <hsivonen> | such a mess |
| 11:09 | <zcorpan> | hsivonen: it seems weirder to special-case <meta> than to special-case XHR, imo |
| 11:09 | <zcorpan> | hsivonen: presto decodes as windows-1252 for both http header and <meta> |
| 11:10 | <zcorpan> | hsivonen: i wonder what web pages expect that declare x-user-defined in http |
| 11:11 | <Ms2ger> | Do any? :) |
| 11:18 | <zcorpan> | none in webdevdata.org-2013-09-01-201332 |
| 12:02 | <hsivonen> | zcorpan: I agree it's weirder, but I'd rather make Gecko consistent with Blink that try to get Blink to change |
| 12:03 | <hsivonen> | it's bad enough that WebKit made stuff up like that. making up *different* weird stuff would be even worse, IMO. |
| 12:04 | <jgraham> | Kind of sad if we are reduced to treating blink as an immovable rock though |
| 12:04 | <annevk> | hsivonen: do you want to make me file a bug on HTML? |
| 12:15 | <zcorpan> | hsivonen: i think it shouldn't be too hard to get this changed in blink if there are tests |
| 12:18 | <hsivonen> | annevk: that would be nice, yes, unless you think it's worthwhile to make Blink&WebKit invert what they special-case |
| 12:19 | <hsivonen> | jgraham: well, it's easier for me to clone the WebKit/Blink quirk and forget about this than to go around telling WebKit *and* Blink devs they should change something as obscure as this to make it make more sense |
| 12:19 | <hsivonen> | jgraham: that is, it's easier to just leave my sense of logic at the door and not fight the WebKit/Blink quirk |
| 12:21 | <hsivonen> | it's really sad, though, that some x-user-defined sites "improve" their state by using @font-face instead of migrating to UTF-8 |
| 12:21 | <hsivonen> | as if doing things the right way was so terrible that it has to be avoided |
| 12:21 | <hsivonen> | not surprising for the Web, of course |
| 12:35 | <Ms2ger> | "High level sincerity！" |
| 12:36 | <hsivonen> | Ms2ger: ? |
| 12:37 | <Ms2ger> | hsivonen, http://www.w3.org/mid/CA+-d5Zr8E=WpH9sTACm3XBmopGn_VeJvVcy3Yx2oKvLGvFvaFQ⊙mgc |
| 12:51 | <zcorpan> | hmm, meta refresh support is optional in the spec. i'll assume that browsers aren't going to have it off by default so i can let the test fail (or time out) if it doesn't navigate |
| 13:08 | <annevk> | hsivonen: okay, on it |
| 13:11 | <annevk> | hsivonen: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23940 |
| 13:31 | <zcorpan> | it seems meta refresh doesn't work in firefox if it's inserted by a script |
| 13:31 | <zcorpan> | is that intentional? i think the spec says it should work |
| 13:33 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2667 |
| 14:31 | <MikeSmith> | "User agents are encouraged to expose parse errors somehow." |
| 14:32 | <jgraham> | We choose to expose them by encoding them in the initial state of the universe |
| 14:33 | <Ms2ger> | That's why we hired jgraham, in fact |
| 14:36 | <MikeSmith> | I encourage annevk to somehow work the phrase "with extreme prejudice" into his next specification |
| 14:36 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2668 - does the close() cause 'load' to be fired? |
| 14:37 | <zcorpan> | write() implies open() which mutes the iframe's load event that was going to be fired because the browsing context came into being |
| 14:37 | <jgraham> | zcorpan: Yes |
| 14:40 | <jgraham> | zcorpan: Where is the stuff about document.open muting load events?\ |
| 14:42 | <zcorpan> | jgraham: i thought it was step 20 but i see now that only applies while handling a load event |
| 14:43 | <gsnedders> | hsivonen: I suppose if you're used to the only way of getting stuff rendered is custom fonts, the obvious next step is @font-face, not looking for alternate ways (like re-encoding stuff). |
| 14:44 | <jgraham> | zcorpan: Yeah, that's to stop you getting more than one load event |
| 14:45 | <zcorpan> | jgraham: but in my case the flag is false so i think the spec says two load events should be fired |
| 14:46 | <zcorpan> | "When an iframe element is inserted into a document, the user agent must create a nested browsing context, and then process the iframe attributes for the "first time"." #the-iframe-element |
| 14:47 | <zcorpan> | which will "Queue a task to run the iframe load event steps." |
| 14:52 | <jgraham> | zcorpan: So this is the question of how the initial about:blank document loads, right? |
| 14:52 | <zcorpan> | jgraham: not quite |
| 14:53 | <zcorpan> | i'll file a bug |
| 14:53 | <jgraham> | Well nearly |
| 14:53 | <jgraham> | If the initial about:blank was loaded synchronously, you wouldn't see that event |
| 14:55 | <zcorpan> | why not? |
| 15:09 | <jgraham> | I thought that where the load was synchronous the event was too |
| 15:09 | <jgraham> | But maybe I am misremembering this stuff |
| 15:10 | <zcorpan> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=23942 |
| 15:13 | <zcorpan> | hmm, stop parsing fires load on the window, not on the iframe |
| 15:18 | <Ms2ger> | Sounds like someone is writing tests ;) |
| 15:32 | <hsivonen> | MikeSmith: as in "implementations MUST NOT support UTF-32, with extreme prejudice"? |
| 17:18 | <MikeSmith> | hsivonen: that sounds sensible |
| 17:26 | <MikeSmith> | speaking of sensible, best combination of sentences found in my inbox so far today: "I see two possibilities to improve the specification. First the syntax should be defined in an EBNF." |
| 17:30 | <jgraham> | MikeSmith: That makes sense. Assuming that the real problem with whatever specification this is is that the editor is full of crazy and someone is looking for a way to say "look at the counterproductive things s?he is spending h[er|is] time on, we should remove them" |
| 17:35 | <MikeSmith> | jgraham: I can see you've played knifey spoony before |