| 01:00 | <rniwa> | Hixie: yt? |
| 02:53 | <MikeSmith> | Hixie: can you please check again and see if cvs is still slow for you? |
| 05:57 | <annevk> | Hixie: your unrestricted double change looks wrong |
| 05:58 | <annevk> | Hixie: you removed the generic NaN/Inifity language and then changed double to unrestricted double (unrestricted double is the one that allows NaN and such) |
| 05:58 | <Hixie> | i only changed it for ones where the previous language didn't apply |
| 05:59 | <Hixie> | at least, that was my intent |
| 05:59 | annevk | looks again |
| 06:02 | <annevk> | Hixie: e.g. the scale() method on <canvas> has no language for it |
| 06:02 | <annevk> | Hixie: setLineDash does have language for it, but it seems better if we make that double |
| 06:03 | <annevk> | same for globalAlpha, if that's still feasible |
| 06:03 | <annevk> | and similar methods |
| 06:05 | <Hixie> | all the canvas ones have language because there's the default language, no? |
| 06:05 | <Hixie> | oh, i guess methods don't |
| 06:05 | <Hixie> | but for the transforms there's no need for language |
| 06:05 | <Hixie> | you just do the maths with infinities |
| 06:05 | <Hixie> | there's separate language for problematic transforms iirc |
| 06:06 | <Hixie> | i guess we should add text for NaNs for scale() |
| 06:06 | <annevk> | I went through the spec for Infinity and missed that then... |
| 06:07 | <annevk> | I only see it for linedash, gradients and globalAlpha |
| 06:07 | <annevk> | but maybe it does not need to be explicitly mentioned? |
| 06:07 | <Hixie> | filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=17468 for transforms |
| 06:08 | <Hixie> | please file other bugs for others |
| 06:08 | <Hixie> | gotta go |
| 06:09 | <annevk> | kk |
| 06:28 | <annevk> | so we're the Web Notification WG with http://www.w3.org/2010/web-notifications/ as home page |
| 06:28 | <annevk> | :) |
| 06:32 | <annevk> | jgraham: where is that email from bz to public-html? |
| 06:32 | <annevk> | jgraham: oh last month |
| 06:33 | <annevk> | jgraham: but that one cc'd whatwg |
| 08:26 | <zcorpan> | Hixie: the sync image load uses the state of the crossorigin attribute, but the potentially CORS-enabled fetch algorithm ignores the state of that attribute when the URL is same-origin |
| 09:19 | <annevk> | matjas: I guess theoretically you could add Registry-HTTP-headers to http://wiki.whatwg.org/wiki/Category:Registries |
| 09:19 | <annevk> | matjas: we haven't really invested effort into taking over that IANA stuff however |
| 09:20 | <annevk> | matjas: you could also try registering the header through IANA, but that process sucks balls |
| 09:20 | <matjas> | annevk: yeah, the latter option doesn’t sound like fun |
| 09:20 | <annevk> | (which is why everyone keeps minting X- prefixed headers instead; joy) |
| 09:21 | <matjas> | facebook spam: http://wiki.whatwg.org/wiki/Registry-HTTP-headers (by User:Kirayamato) |
| 09:21 | <annevk> | whoa |
| 09:23 | <annevk> | nuked |
| 09:48 | <matjas> | annevk: so can I just add an entry for X-UA-Compatible to the Registry-HTTP-headers page, or what? |
| 09:52 | <annevk> | well, 1) although IANA sucks our alternative has not really proved successful thus far (mostly due to lack of effort I think) 2) the HTML specification would need to be updated either way for the registration procedure 3) it would be interesting to hear what hsivonen_ has to say about this issue 4) you could start by adding it to http://wiki.whatwg.org/wiki/PragmaExtensions and mention it is widely used but you cannot be bothered to deal with the |
| 09:52 | <annevk> | pain that is IETF registration procedures for IANA registration |
| 09:57 | <matjas> | annevk: ok, done: http://wiki.whatwg.org/wiki/PragmaExtensions I’ll await hsivonen_’s feedback before I submit a spec “bug” |
| 10:01 | <karlcow> | there is an RFC against the proliferation of X-headers |
| 10:01 | <karlcow> | it is a similar story than and -vendor- extensions |
| 10:44 | <sm0lm> | Anyone know where the source code of the OPAL selectoracle can be obtained? |
| 10:46 | <Stevef> | [tm]: where are you at brotherman? |
| 11:04 | <jgraham> | Hixie: (mail sent) |
| 11:04 | <jgraham> | Also, I added some more tests for navigation in beforeunload and pagehide, which seem to work the same as in unload |
| 11:41 | <sm0lm> | Anyone know where the source code of the OPAL selectoracle can be obtained? |
| 11:53 | <annevk> | is http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsStandardURL.cpp Gecko's URL implementation? |
| 12:46 | <MikeSmith> | annevk: about the URL spec, Chris Weber has aggregated a bunch of tests at https://github.com/cweb/iri-tests |
| 12:47 | <MikeSmith> | and he has a report of some results at https://github.com/cweb/iri-tests/blob/master/results/uri-iri-results.xls |
| 12:52 | <annevk> | MikeSmith: reading that it sounds like he made the WebKit tests worse... |
| 12:52 | <MikeSmith> | oh |
| 12:52 | <MikeSmith> | how so? |
| 12:53 | <annevk> | removed e.g. <base> information |
| 12:53 | <annevk> | do you have pointers to Adam's original tests? |
| 12:54 | <annevk> | https://github.com/abarth/url-spec I guess |
| 13:11 | <annevk> | MikeSmith: pubrules throws a fit |
| 13:11 | <MikeSmith> | oh |
| 13:11 | <MikeSmith> | I will get those fixed |
| 13:12 | <MikeSmith> | and I will look from Adam's tests right now |
| 13:12 | <annevk> | I might have made a typo that threw pubrules into a fit |
| 13:13 | <annevk> | yeah was a typo |
| 13:17 | <annevk> | MikeSmith: so yeah, my plan is to work on URLs now |
| 13:17 | <MikeSmith> | ok |
| 13:18 | <MikeSmith> | the Webkit tests are at http://trac.webkit.org/browser/trunk/LayoutTests/fast/url I think |
| 13:18 | <MikeSmith> | not sure if those are essentially the same as Adam's github ones or not |
| 13:18 | <MikeSmith> | anyway, I will help with URLs as well |
| 13:28 | <MikeSmith> | annevk: about Notifications |
| 13:28 | <MikeSmith> | http://dvcs.w3.org/hg/notifications/raw-file/tip/TR.html is what we want to publish, right? |
| 13:28 | <annevk> | MikeSmith: yeah |
| 13:28 | <MikeSmith> | OK |
| 13:29 | <MikeSmith> | I will copy that to the dated TR URL |
| 13:29 | <annevk> | is there a problem? |
| 13:29 | <MikeSmith> | no |
| 13:29 | <annevk> | k |
| 13:29 | <MikeSmith> | just in your message to Denis, you had mentioned http://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.html |
| 13:31 | <annevk> | ah yeah, I did not have the TR copy at that point |
| 13:31 | <annevk> | just the editor's draft |
| 13:53 | <MikeSmith> | annevk: OK, I have it up at http://www.w3.org/TR/2012/WD-notifications-20120614/ |
| 13:53 | <annevk> | thanks |
| 13:53 | <MikeSmith> | and I'll work with Denis if anything more needs fixing for pubrules or whatever |
| 13:59 | <annevk> | Hixie: I want to change the email address for my account on the HTML spec |
| 13:59 | <annevk> | Hixie: to annevk⊙an |
| 14:02 | <annevk> | MikeSmith: IRI tests look nice too though |
| 14:02 | <MikeSmith> | yeah? |
| 14:02 | <MikeSmith> | I guess Chris did all those |
| 14:02 | <annevk> | MikeSmith: I was thinking of writing a URL parser in JavaScript and then using tests to compare it with browsers |
| 14:03 | <annevk> | MikeSmith: and then writing a spec based on the structure of that URL parser |
| 14:04 | <annevk> | MikeSmith: the current spec suffers from quite a few problems; e.g. "s<:s" is a relative URL, not a URL whose scheme is "s<" |
| 14:04 | <MikeSmith> | oh |
| 14:04 | <annevk> | so starting anew is probably best |
| 14:05 | <MikeSmith> | annevk: you might want to look at http://medialize.github.com/URI.js/ to see if you can repurpose some of it or get some ideas from it |
| 14:05 | <MikeSmith> | from Rodney Rehm |
| 14:05 | <MikeSmith> | https://github.com/medialize/URI.js |
| 14:11 | <annevk> | volkmar: "We are willing to discuss any detail of the API as long as we do not include any feature we believe are out of scope." seems somewhat poorly worded |
| 14:12 | <annevk> | MikeSmith: doesn't look that usable |
| 14:12 | <MikeSmith> | OK |
| 14:12 | <volkmar> | annevk: it might be indeed |
| 14:12 | <annevk> | but I should indeed look around first |
| 14:13 | <volkmar> | annevk: but I believe what I meant is undertandable (at least I hope) |
| 14:16 | <annevk> | volkmar: it seems kind of poor form to restrict the discussion to what you believe it should be restricted to |
| 14:29 | <AryehGregor> | annevk, [120612 17:30:48] <NeilAway> AryehGregor: I think it's Gecko's only URL type, yes, but we have several URI implementations too ;-) |
| 14:30 | <annevk> | AryehGregor: :( |
| 14:30 | <AryehGregor> | Are you surprised? |
| 14:31 | <annevk> | I blame the IETF |
| 14:31 | AryehGregor | blames Netscape |
| 14:31 | <volkmar> | annevk: it's indeed poorly worded, we doesn't want to block the discussion |
| 14:31 | <volkmar> | the idea is much more that unless proven useful, we don't want to handle those use cases |
| 14:32 | <annevk> | okay, cool |
| 14:41 | <annevk> | MikeSmith: why do backreferences not work in the URL spec? |
| 14:41 | <MikeSmith> | annevk: probably because I muffed something up |
| 14:42 | <MikeSmith> | I'll take a look right now |
| 14:43 | <MikeSmith> | "Uncaught TypeError: Object function Object() { [native code] } has no method 'push' dfn.js:26" |
| 14:56 | <gsnedders> | So, #whatwg, what should be done with Error.stack, given sites rely upon different JS engines having different strings? |
| 14:57 | <Philip`> | Add Error.stdStack |
| 14:57 | <Philip`> | which is standardised between browsers |
| 14:58 | <zcorpan> | gsnedders: [citation needed] |
| 14:58 | <Philip`> | (and which is much more convenient to use, e.g. not requiring you to do string parsing to extract data from it) |
| 14:58 | <Philip`> | (so that most people will start using that instead of Error.stack, and then nobody will care that Error.stack is inconsistently implemented) |
| 14:59 | <gsnedders> | zcorpan: Which part? |
| 15:00 | <gsnedders> | On the whole it looks like Error.stack won't be spec'd and a new API introduced that is sane |
| 15:02 | <annevk> | gsnedders: not sure what you want #whatwg to do here |
| 15:04 | <zcorpan> | gsnedders: what sites? |
| 15:09 | <gsnedders> | annevk: Is creating a new API the right way to go, or should most/all vendors break sites? |
| 15:10 | <zewt> | (the latter sounds unlikely) |
| 15:10 | <zewt> | little's more annoying than not being able to fix a bug because somebody broke your bug reporting :) |
| 15:11 | <annevk> | gsnedders: both sound annoying :) |
| 15:12 | <zewt> | creating a non-crappy API and ignoring the completely uninteroperable ones in there now seems the way to go |
| 15:28 | <AryehGregor> | gsnedders, that implies that there will indefinitely be a compat constraint on browsers that they have to implement the old .stack in whatever manner the legacy pages expect, but it won't be documented. That sounds like a very bad idea. |
| 15:30 | <jgraham> | AryehGregor: The compat constraint is something like "if you have the string 'webkit' in your UA, you must return a string formated like X. Otherwise, if you have the string 'gecko' in your UA header, you must return a string formatted like Y, otherwise..." |
| 15:31 | <jgraham> | (except probably more complex than that) |
| 15:31 | <AryehGregor> | jgraham, well, if that's really needed for site compat and people aren't willing to deploy site-specific workarounds, then that needs to be specced. You can't just have all these pages break in some random new browser that's written per spec. |
| 15:31 | <AryehGregor> | Better would be if browsers hacked around known bad pages to reduce compat impact enough that they could change to match the standard. |
| 15:32 | <gsnedders> | AryehGregor: the sites already do UA sniffing, so they're already broken in random new browsers. |
| 15:32 | <zewt> | can't blame pages for this, heh |
| 15:32 | <AryehGregor> | gsnedders, right, so new browsers have to clone an existing UA string, which is what they do in real life. |
| 15:32 | <jgraham> | gsnedders: Unless a random new browser implemented some other browser's US header exactly |
| 15:32 | <AryehGregor> | But they still need to know how to behave. |
| 15:32 | <jgraham> | *UA |
| 15:32 | <AryehGregor> | Given the UA string they picked. |
| 15:32 | <gsnedders> | Also it's unclear what to do given strict-mode and tail call optimization. |
| 15:33 | <gsnedders> | And overspecification could make TCO impossible, which would be bad. |
| 15:33 | <jgraham> | (it may not even be UA string based sniffing of course) |
| 15:33 | <zewt> | gsnedders: specify how to expose stack frames, but not what the stack frames will be (inlining could also cause frames to disappear, though that can probably be hidden by implementations with some effort) |
| 15:44 | <annevk> | meh |
| 15:44 | <annevk> | test://test.com/ |
| 15:44 | <annevk> | does this have a host or not? |
| 15:44 | <zcorpan> | "Nobody; OK to take it and work on it" |
| 15:45 | <annevk> | .host returns "" in Opera/Firefox; test.com in Safari |
| 15:46 | <zewt> | annevk: doesn't the former imply that you could never add new schemes without breaking compatibility? (for what that's worth--not like the addition of a new protocol itself wouldn't have bigger side-effects) |
| 15:53 | <annevk> | zewt: seems like it has not been a problem in practice when we added ws: and wss: |
| 15:54 | <Ms2ger> | Am I alone in reading "twss"? |
| 16:00 | <zcorpan> | annevk: ws: and wss: aren't supported in <a href> so the URL decomposition attributes should treat it as an unsupported scheme, i think |
| 16:04 | <Ms2ger> | Whoa, fantasai *and* Hixie on a replying spree is no good for my inbox |
| 16:06 | <AryehGregor> | Isn't it great how we have a generic URL standard so that you can parse URLs without having to know scheme-specific details? |
| 16:13 | <jgraham> | pimpmyspec.net will be down for a while |
| 16:15 | <zewt> | for additional pimping? |
| 18:15 | <Ms2ger> | ojan, I don't care much, but I don't think moving mailing lists gains us much |
| 18:16 | <ojan> | Ms2ger: yeah, maybe not. i find it frustrating that in practice i need to check both mailing lists anyways because enough threads are incorrectly started on www-dom |
| 18:16 | <Ms2ger> | correctly, you mean ;) |
| 18:16 | <ojan> | lol, yeah |
| 18:17 | <Ms2ger> | I bet Bj�rn will have a say about it |
| 18:17 | <ojan> | Ms2ger: i'm not gonna make a big deal of this, but if everyone agrees, then there's no harm |
| 18:17 | <ojan> | i certainly don't intend to have a long dicussion about this |
| 18:17 | <Ms2ger> | If you want to have a long discussion about it, have it over at public-html? :) |
| 18:23 | Ms2ger | hadn't seen someone use "L.S." for a while |
| 18:26 | <TabAtkins_> | What's that mean? |
| 18:28 | <Ms2ger> | It's Latin, you won't like it |
| 18:29 | <TabAtkins_> | Hey, I got nothing against Latin itself. Just against the ridiculous attachment that some grammar assholes from a century ago had to it. |
| 18:31 | <hober> | TabAtkins_: you are tilting at windmills. English is weird. Get over it. |
| 18:33 | <TabAtkins_> | Hey, the faux-latin bullshit started because of people tilting at windmills. ^_^ |
| 18:33 | <gsnedders> | TabAtkins_: On the other hand, there is a lot of English which has Romance influence, such as bases. ^_^ |
| 18:34 | <TabAtkins_> | English stole tons of words from romance languages, yeah. But not its grammar. |
| 18:35 | <Ms2ger> | Did you mean "not it's grammar"? |
| 18:35 | <gsnedders> | Ms2ger: the Genitive form of it is its. |
| 18:35 | <Ms2ger> | Troll succeeded |
| 18:36 | <gsnedders> | TabAtkins_: Where does grammar end and lexis begin? |
| 18:36 | <gsnedders> | Ms2ger: I thought that was probably what you were doing. |
| 18:37 | <gsnedders> | You can trivially argue that closed-word classes (pronouns, for example) are grammatical. |
| 18:37 | <TabAtkins_> | gsnedders: I'm only a casual linguist on the internet, so I'm not prepared to argue to that level of precision. |
| 18:39 | <gsnedders> | TabAtkins_: Certainly English grammar has to some extent been influenced by Latin (which isn't that surprising, given English's status for the most of the first two millenia) |
| 18:40 | <Philip`> | Did you mean "millennia"? |
| 18:40 | <gsnedders> | Yes. |
| 18:41 | <gsnedders> | (Though yes, the influence on the lexis was far greater) |
| 18:42 | <gsnedders> | Today's fun fact: "they" and "them" are derived from Old Norse and not Old English. |
| 18:43 | <AryehGregor> | gsnedders, "bases" is Greek, not Romance. |
| 18:43 | <AryehGregor> | Oh, it's both. |
| 18:43 | <AryehGregor> | Interesting. |
| 18:44 | <AryehGregor> | Although it apparently didn't enter English through Romance languages -- it came into Middle English through Latin directly, according to my dictionary. |
| 18:44 | <Philip`> | ("bases" as in plural of "base" or of "basis"?) |
| 18:44 | <gsnedders> | AryehGregor: Very little came from Greek directly. |
| 18:44 | <gsnedders> | Philip`: basis |
| 18:45 | <gsnedders> | AryehGregor: And Latin is a Romance language. |
| 18:46 | <AryehGregor> | gsnedders, not according to Wikipedia! |
| 18:46 | <Ms2ger> | Fix Wikipedia! |
| 18:47 | <AryehGregor> | "The internal classification of the Romance languages is a complex and sometimes controversial topic which may not have a unique answer. Several classifications have been proposed, based on different criteria." |
| 18:54 | <gsnedders> | I'd say the prototype of a language group is part of the group, *shrugs*. |
| 19:31 | <jgraham> | Italian must be a romance language, otherwise how would you explain Berlusconi |
| 19:33 | <sm0lm> | when are media fragment uris set to get widespread support? |
| 19:46 | <jgraham> | http://tools.ietf.org/html/draft-tbray-http-legally-restricted-status-00 |
| 19:48 | <micheil> | jgraham: how do I say that there's an issue in that document? |
| 19:49 | <micheil> | quoting: "The restrictions typically most directly affect the".. make's little sense |
| 19:52 | <jgraham> | micheil: I'm not really sure. Perhaps the link marked "email" at the top of the document? Otherwise work out which WG is working on it |
| 19:52 | <micheil> | :/ |