| 00:01 | <AryehGregor> | jamesr, location.search? You can parse it with .split(). |
| 00:02 | <jamesr_> | AryehGregor, and parse all the = things myself and escape/unescape |
| 00:02 | <AryehGregor> | smaug____, some parts of the selection spec are quite solid and interoperable. |
| 00:03 | <smaug____> | AryehGregor: I didn't say it wouldn't be. But is it reviewed :) |
| 00:03 | <gsnedders> | jamesr_: Use split twice |
| 00:04 | <AryehGregor> | jamesr_, parsing & and = is just something like: var bits = location.search.replace(/^\?/, "").split("&").map(function(s){return s.split("=")}); |
| 00:04 | <AryehGregor> | Or something like that. |
| 00:04 | <AryehGregor> | As for encoding, have fun. IIRC, it's not interoperable. |
| 00:04 | <AryehGregor> | Nor am I sure it's even specified. |
| 00:04 | <gsnedders> | AryehGregor: Yeah, exactly that. |
| 00:04 | <gsnedders> | AryehGregor: Well, split("=", 2) |
| 00:04 | <AryehGregor> | Yeah, I'm sure it could be made more correct. |
| 00:04 | <gsnedders> | and you want to decodeURIComponent() each of the parts of that |
| 00:05 | <gsnedders> | But apart from that, that's exactly it |
| 00:06 | <jamesr_> | location.search.replace(/^\?/, "").split("&").map(function(s){return s.split("=", 2).map(decodeURIComponent);} |
| 00:06 | <jamesr_> | oh dear my semicolon has migrated to the left |
| 00:06 | <jamesr_> | but otherwise does that look close? |
| 00:06 | <TabAtkins> | jamesr_: No, that's mapping dUIRC across 2-arrays. |
| 00:06 | <jamesr_> | ah snap |
| 00:06 | <TabAtkins> | Or wait, I'm dumb. |
| 00:07 | <TabAtkins> | Never mind, you're good. |
| 00:07 | <jamesr_> | no wait it's mapping both strings |
| 00:07 | <TabAtkins> | Yes. |
| 00:07 | <gsnedders> | jamesr_: That's right. |
| 00:08 | <jamesr_> | location.search.replace(/^\?/, "").split("&").map(function(s){return s.split("=", 2).map(decodeURIComponent)}); |
| 00:08 | <jamesr_> | seems to work |
| 00:08 | <TabAtkins> | Yeah, that should be fine. |
| 00:08 | <jamesr_> | btw, MDN is accessing event.layerX/layerY, which are deprecated in WebKit |
| 00:08 | <gsnedders> | Kinda nice to get it into an object, but oh well. |
| 00:08 | <jamesr_> | throws a warning in the inspector |
| 00:08 | <jamesr_> | can some of y'all fix that? |
| 00:09 | <jamesr_> | guess i could map that into an object.... |
| 00:09 | <jamesr_> | or can you do that? |
| 00:09 | <TabAtkins> | gsnedders: That's easy. prepend "var query;", append ".map(function(x){query[x[0]]=x[1];})". |
| 00:10 | <AryehGregor> | Or .forEach? |
| 00:10 | <TabAtkins> | Alternately, define mapObject or something that expects you to return a 2-array. |
| 00:10 | <TabAtkins> | AryehGregor: Yeah, forEach would be better semantically. |
| 00:15 | <gsnedders> | Note that forEach and map and the like are likely to be fairly slow for at least another year or two |
| 00:16 | <TabAtkins> | Really? Why? |
| 00:16 | <gsnedders> | TabAtkins: In large part because of jumping between C++ and JS threads |
| 00:16 | <gsnedders> | s/threads/stacks/ |
| 00:17 | <TabAtkins> | Interesting. Where is the stack jump? In the function invocation or something? |
| 00:17 | TabAtkins | knows nothing about the interface between c++ and js. |
| 00:17 | <jamesr_> | heh, i doubt that'll matter at all in this case |
| 00:17 | <jamesr_> | are you talking about in a specific JS engine? |
| 00:17 | <jamesr_> | i thought map/forEach were implemented natively in v8 |
| 00:17 | jamesr_ | checks |
| 00:18 | <gsnedders> | Calling into C++ in the first case, then into the function, then out of the function, and then after doing those two a number of times back to JS |
| 00:18 | Philip` | notes that parsing a single query string is not a situation where performance is of any concern |
| 00:18 | <gsnedders> | jamesr_: I thought they originally were in V8 but aren't any more. |
| 00:18 | <jamesr_> | http://google.com/codesearch#OAMlx_jo-ck/src/v8/src/array.js&q=forEach&ct=rc&exact_package=chromium&cd=8&sq=&l=1039 |
| 00:18 | <jamesr_> | i'm not sure exactly what that is |
| 00:18 | <TabAtkins> | gsnedders: Is that because map is implemented in C++? |
| 00:19 | <TabAtkins> | Rather than as a JS for-loop? |
| 00:19 | <gsnedders> | TabAtkins: Right. |
| 00:19 | <TabAtkins> | kk |
| 00:25 | <gsnedders> | http://jsperf.com/map-builtin-v-js/5 is about as close as you can get with pure JS |
| 00:26 | <gsnedders> | In Chrome the native function is the quickest map impl because it has all its magic functions to optimize it better (IIRC some of them have specific low-level impls) |
| 00:26 | <jamesr_> | right, the built-ins aren't strictly speaking straight JS |
| 00:27 | <jamesr_> | but they don't have to make a full JS/C++ stack jump |
| 00:27 | <gsnedders> | jamesr_: Right |
| 00:27 | <jamesr_> | at least that's my understanding. i'm not a JS VM engineer, i just play one on IRC |
| 00:28 | <gsnedders> | jamesr_: That is the case, they don't have any stack jump, they're just another JS function from the engine's POV, it's just some things they call are magic |
| 00:28 | <gsnedders> | JSC I don't really know why it's perf is as it is, and SpiderMonkey is just a matter of how slow the JS impl is mainly, AFAIK |
| 00:30 | gsnedders | doesn't know enough about what's happened with JSC in the past year really, it's kinda sad |
| 00:33 | jgraham | will bear this in minf when he has to parse a million key vlue pairs out of the query string |
| 00:33 | <gsnedders> | Hey, it's a viable DoS attack, as has been proven recently! :P |
| 03:48 | <MikeSmith> | hmm |
| 03:48 | <MikeSmith> | when parsing a URL, how do you canonicalize the port? |
| 03:49 | <gsnedders> | On the basis of the scheme? |
| 03:49 | <gsnedders> | Or am I missing something? |
| 03:59 | <MikeSmith> | gsnedders: dunno |
| 03:59 | <MikeSmith> | it's missing from abarth URL parsing draft |
| 03:59 | <MikeSmith> | http://tools.ietf.org/html/draft-abarth-url-01#section-5 |
| 04:00 | <MikeSmith> | he has "If the canonicalized-port is non-empty and is not the default port for the scheme" |
| 04:00 | <MikeSmith> | which is the part you mean, I think |
| 04:00 | <MikeSmith> | so that's clear |
| 04:01 | <MikeSmith> | but that step is done after the port is "canonicalized" |
| 04:01 | <tantek> | port - one of the few pieces of a URL that people seem to agree on for the most part |
| 04:01 | <MikeSmith> | heh |
| 04:01 | <MikeSmith> | yeah |
| 04:01 | <tantek> | port or port number |
| 04:01 | <tantek> | or if you're a PHP person, SERVER_PORT |
| 04:01 | <tantek> | MikeSmith, you've seen this right? http://tantek.com/2011/238/b1/many-ways-slice-url-name-pieces |
| 04:02 | <MikeSmith> | so not clear to me, given just a port number without knowledge of the scheme, what exactly do I do to canonicize it? |
| 04:02 | MikeSmith | looks |
| 04:02 | <MikeSmith> | tantek: ah yeah |
| 04:02 | <MikeSmith> | that's quite a diagram |
| 04:03 | <MikeSmith> | abarth introduces the term "after-scheme" for all the stuff collectively that is not the scheme |
| 04:03 | <MikeSmith> | I like that |
| 04:03 | <tantek> | I have two more rows to add too |
| 04:04 | <MikeSmith> | oh? |
| 04:04 | <tantek> | oh great |
| 04:04 | <tantek> | make that 3 |
| 04:04 | <tantek> | then |
| 04:04 | <tantek> | is this an RFC track thing? draft-abarth-url-01 |
| 04:04 | <tantek> | in which case, maybe I'll wait until there's a permalinkable spec for it |
| 04:05 | <tantek> | since IETF doesn't seem to believe in permalinks for drafts |
| 04:05 | <tantek> | :P |
| 04:05 | <gsnedders> | the tools.ietf.org/html/ links are pretty much stable |
| 04:05 | <gsnedders> | The actual drafts vanish after 90 days, but they stay around there forever :P |
| 04:06 | <gsnedders> | GO LOGIC! |
| 04:06 | <MikeSmith> | that ID is being not being maintained any longer |
| 04:06 | <MikeSmith> | s |
| 04:06 | <MikeSmith> | so it won't move forward at the IETF |
| 04:06 | <tantek> | huh |
| 04:06 | <MikeSmith> | our plan is to put all the URL stuff into a single spec |
| 04:06 | <MikeSmith> | and publish it at W3C |
| 04:06 | tantek | will await a permalink for that spec then |
| 04:07 | <MikeSmith> | tantek: http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html |
| 04:07 | <MikeSmith> | I am working on it as we speak |
| 04:07 | <tantek> | a-ha ok |
| 04:08 | <MikeSmith> | just taking the work that abarth has already done and combining into it one doc, along with some bits from the HTML spec |
| 04:09 | <MikeSmith> | so the plan is for this doc to to have the definition of "URL" and "valid URL", then algorithms for dealing with URLs, then the URL API |
| 04:09 | <tantek> | ah - looks like the terms are a re-use of 1996 DOM window.location |
| 04:09 | <tantek> | so that's good, not a new terminology at least |
| 04:10 | <MikeSmith> | OK |
| 04:10 | <MikeSmith> | well, none of it is set in stone of course |
| 04:11 | <MikeSmith> | the main goal for now is to get it all in one place and then get it out for review |
| 04:11 | <MikeSmith> | and the high-level goal is to "get it right" |
| 04:11 | <MikeSmith> | including to have it actually reflect reality |
| 04:12 | <MikeSmith> | or realities plural |
| 04:12 | <MikeSmith> | in that the browser behavior for URL parsing it not completely interoperable |
| 05:35 | <annevk> | http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0023.html was reported before and I think it was concluded to not be a security issue |
| 05:35 | <annevk> | don't remember why though, abarth? |
| 05:36 | <abarth> | dunno |
| 05:36 | <abarth> | sounds like a server issue |
| 05:37 | <abarth> | we can't account for all manner of crazy transformations servers might do |
| 05:38 | <annevk> | yeah, and I sort of doubt even though would let Cotnent-Length be spoofed that way |
| 05:38 | <annevk> | because it's a higher-level library |
| 05:39 | <abarth> | you should see the proxies that permute letters in Referer :) |
| 05:40 | <annevk> | heh, I'll stay semi-naive about HTTP for now |
| 05:40 | <annevk> | encodings are enough fun as it is |
| 05:41 | <annevk> | also crazy |
| 05:44 | <Yuhong> | <annevk> that we're still figuring out document.write() |
| 05:45 | <Yuhong> | Someone mentioned before that it was invented in Netscape 2 |
| 05:45 | <Yuhong> | And as I said before, Netscape 2 did not parse HTML into a tree, instead it treated tags as commands. |
| 05:46 | <Yuhong> | I don't think async script loading was supported at all. |
| 05:48 | <Yuhong> | That was why it was considered a simple feature in Netscape 2 |
| 05:49 | <Yuhong> | And probably why Netscape 2 to 4 supported accessing only a limited type of elements. |
| 05:49 | <Yuhong> | IE4 actually parsed HTML into a tree, that was why it was able to invent document.all. |
| 05:50 | <annevk> | and then we had a lot of problems |
| 05:50 | <Yuhong> | Which is yea when the problems start. |
| 05:52 | <Yuhong> | The problem was made even worse with DOM Level 1 which allow full manipulation of the document tree. |
| 05:52 | <zewt> | gmail is sure going to lengths to make everyone acutely aware of the major inherent flaws of web apps |
| 05:52 | <zewt> | you like how things are? too bad, we're making everything worse and there's nothing you can do about it |
| 05:54 | <Yuhong> | For example, here is a 0-day security vulnerability reported in Mozilla as late as 2010: https://bugzilla.mozilla.org/show_bug.cgi?id=607222 |
| 07:50 | <annevk> | quite proud of http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#iso-2022-jp |
| 07:50 | <annevk> | waking up early works |
| 08:27 | <MikeSmith> | heh |
| 08:27 | <MikeSmith> | annevk: I checked in changes to http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html |
| 08:27 | <MikeSmith> | I think most of the necessary bits are all there now |
| 08:28 | <MikeSmith> | though lots and lots of TODOs |
| 08:30 | <MikeSmith> | annevk: also, the book is on the way to you |
| 08:31 | <annevk> | sweet |
| 08:39 | <annevk> | kind of a sad caption http://xkcd.com/1000/ |
| 08:40 | <annevk> | but the math joke is fun :) |
| 08:41 | <annevk> | MikeSmith: nice |
| 08:41 | <annevk> | MikeSmith: also, you didn't set all the id attributes :p |
| 08:42 | <MikeSmith> | eh? which ones needs set? |
| 08:42 | <annevk> | I rather you don't, but you let them generate automatically and I remember you didn't like that |
| 08:43 | <annevk> | (I tried making a joke :)) |
| 08:49 | <annevk> | there's a lot of RFCs btw attempting to define encodings |
| 08:49 | <annevk> | people put some BNF in there, a couple of words, and put a sticker on it |
| 10:38 | <Ms2ger> | P { font-size: 12pt ! legal "IATA regulations" } |
| 12:24 | <annevk> | Ms2ger: euh? |
| 12:24 | <Ms2ger> | http://www.w3.org/TR/WD-css1-951209.html#legal |
| 12:34 | <annevk> | well thank you |
| 12:34 | <annevk> | I never understood why CSS had such a silly !important thing and even less why it was exposed as "priority" in the OM |
| 12:45 | <annevk> | AryehGregor: how is http://w3c-test.org/webapps/DOMCore/tests/approved/Range-surroundContents.html approved with test errors? |
| 12:47 | <annevk> | AryehGregor: jgraham or Velmont might provide a patch I hear |
| 12:49 | <Ms2ger> | Because nobody actually reviewed |
| 12:49 | <annevk> | AryehGregor: other comment "and it doesn't seem like the test follows step 10 in the DOMRange.insertNode spec" |
| 14:59 | <jgraham> | So, as a totally experimental thing, I tried cloning the html testsuite repository onto github |
| 14:59 | <jgraham> | https://github.com/jgraham/html-testsuite/ |
| 14:59 | <jgraham> | Mainly for the possibility of code review |
| 15:00 | <annevk> | do you want @WHATWG to announce it somehow? |
| 15:00 | <annevk> | and if so, how? |
| 15:01 | <jgraham> | I have no strong desire for it to be announced |
| 15:02 | <jgraham> | More than I just did by writing on public, logged, irc, I mean |
| 15:02 | <jgraham> | Let me work out if it is useful first :) |
| 15:03 | <annevk> | k |
| 15:09 | <kennyluck> | Is Hixie on vacation? |
| 15:10 | <annevk> | well he's not here |
| 15:16 | <annevk> | Does anyone know about IE's support for big5 / big5-hkscs? Ideally based on what Windows 7 ships |
| 15:16 | <jgraham> | http://longsonr.wordpress.com/2012/01/06/svgtests-interface-implemented/ <- sigh |
| 15:16 | <annevk> | not interested in pre-Vista |
| 15:17 | <annevk> | jgraham: aah |
| 15:18 | <annevk> | jgraham: do we ship similar crap? |
| 15:20 | <kennyluck> | annevk, what do you mean by "here"? |
| 15:22 | <annevk> | standards world |
| 15:22 | <kennyluck> | oh well |
| 15:22 | <kennyluck> | a |
| 15:22 | <kennyluck> | n |
| 15:23 | <annevk> | hmm http://www.microsoft.com/hk/hkscs/ seems to suggest that via Unicode you get there, but not via big5-hkscs |
| 15:24 | <kennyluck> | annevk, what specific questions are you asking with regard to big5 / big5-hkscs ? |
| 15:25 | <annevk> | I think I found my answers already |
| 15:25 | <kennyluck> | ok |
| 15:26 | <annevk> | Windows has PUA-support for the characters HKSCS introduced and the label "big5-hkscs" means "big5" which uses PUA afaict |
| 15:26 | <annevk> | but then other browsers support "big5-hkscs" independently from "big5" (different encoding) and do not map to PUA |
| 15:26 | <kennyluck> | Yeah, that PUA story is quite famous. |
| 15:27 | <kennyluck> | I see. |
| 15:27 | <annevk> | so I guess if you are in HK you really want UTF-8 |
| 15:28 | <kennyluck> | I've not seen a big5-hkscs page but I am not in HK either. These characters are out of BMP right? |
| 15:30 | <annevk> | maybe? I've no idea |
| 15:35 | <erlehmann> | PUA support. |
| 15:35 | <erlehmann> | wait, what. |
| 15:36 | <jgraham> | annevk: I'm not sure. It wouldn't surprise me, but hopefully we're not *adding* that kind of crap years after it became obvious that it's a design anti-pattern |
| 15:38 | <kennyluck> | It's obviously odd if PUA in DOM can get displayed as normal text. |
| 15:41 | <annevk> | system fonts |
| 15:44 | <erlehmann> | You doom us all to inhuman toil for the One whose Name cannot be expressed in the Basic Multilingual Plane. |
| 15:49 | <annevk> | is the whole BMP full? |
| 15:50 | <kennyluck> | No I don't think so. |
| 15:50 | <gsnedders> | No |
| 15:50 | <annevk> | at least Thai has some space I just found out |
| 16:08 | <Workshiva> | "Our new years resolution should be at least 1920x1080" |
| 16:11 | <annevk> | neh |
| 16:12 | <annevk> | higher! |
| 17:05 | <dglazkov> | good morning, Whatwg! |
| 17:11 | <smaug____> | hyvää iltaa |
| 17:13 | <dglazkov> | I love umlauts. |
| 17:20 | <smaug____> | those aren't actually umlauts, but separate letters ;) |
| 17:22 | <michel_v> | letters with umlauts? |
| 17:22 | <smaug____> | ä is a letter itself |
| 17:23 | <dglazkov> | what is the pronunciation effect of two of them? |
| 17:24 | <smaug____> | You mean having two ä-letters? It is just longer sound |
| 17:24 | <smaug____> | Finnish is easy to pronounce |
| 17:25 | <dglazkov> | is it pretty much speak out each letter? |
| 17:25 | <dglazkov> | like Russian |
| 17:25 | <smaug____> | yeah |
| 17:26 | <dglazkov> | that's nice. What about grammar? |
| 17:27 | <smaug____> | well, you can put words almost in any order, so it is easy. |
| 17:28 | <smaug____> | but picking up the right form of some word can be tricky |
| 17:29 | <smaug____> | If I trust one source...it says there can be 2253 different forms of every noun |
| 17:29 | <smaug____> | sounds about right |
| 17:29 | <dglazkov> | o_O |
| 17:30 | <dglazkov> | but there's logic to that, right? You don't have to just memorize? |
| 17:30 | <smaug____> | yeah, there is quite simple logic |
| 17:31 | <smaug____> | http://en.wikipedia.org/wiki/Finnish_morphology#Noun_forms |
| 17:35 | <dglazkov> | ah! very similar to Russian: en.wikipedia.org/wiki/Russian_grammar |
| 17:36 | <AryehGregor> | annevk, the test bugs in surroundContents are due to changes in testharness.js after the test was written, which are in turn due to spec changes. |
| 17:36 | AryehGregor | fixes |
| 17:37 | <smaug____> | dglazkov: your letters make that all hard :) |
| 17:37 | <dglazkov> | :) |
| 17:38 | <AryehGregor> | annevk, hmm, so we throw InvalidStateError for two things in surroundContents? That's not good. |
| 17:39 | <dglazkov> | AryehGregor: do you have somewhere spec'd how window.getSelection() reacts to selections in iframes? |
| 17:40 | <AryehGregor> | dglazkov, seems not right now, no. I think I have feedback asking me to look into it, which I plan to do. |
| 17:41 | <dglazkov> | AryehGregor: cool. I'll just write up something that makes sense for shadow DOM (which is a similar situation). |
| 17:41 | <AryehGregor> | dglazkov, I think the current theory is there's one selection per window, so iframes have a different selection. |
| 17:41 | <dglazkov> | ah, so it's not similar. |
| 17:42 | <AryehGregor> | annevk, pushed a fix to the test bugs. |
| 17:42 | <AryehGregor> | Or not? |
| 17:42 | <AryehGregor> | Oh, right, the fix isn't approved. |
| 17:55 | smaug____ | is amazed how www-style can have such a long and silly discussion about using forums |
| 17:57 | <dglazkov> | yikes, why is getSelection on both window and document? |
| 17:57 | <smaug____> | historical reasons? |
| 17:58 | <dglazkov> | probably |
| 17:58 | <smaug____> | ""Deprecated method document.getSelection() called. Please use window.getSelection() instead."" was added to Gecko 2001 |
| 17:59 | <smaug____> | I think that warning has been removed |
| 18:00 | <dglazkov> | maybe AryehGregor knows |
| 18:00 | <AryehGregor> | dglazkov, I don't know the history. But that's what implementations do. |
| 18:01 | <AryehGregor> | Until a few months ago, Gecko implemented document.getSelection() as returning a string, but now I think we have interop. |
| 18:01 | <smaug____> | Apparently document.getSelection has been in Gecko since 1998, so it could be Netscapeism |
| 18:02 | <AryehGregor> | Yes, I'm pretty sure it dates to Netscape. |
| 18:02 | <AryehGregor> | Maybe it was originally on Document only, but then people realized it made more sense on Window. |
| 18:04 | <dglazkov> | fascinating |
| 18:05 | <smaug____> | window.getSelection was added to Gecko 2000 |
| 18:46 | <dglazkov> | smaug____: does Gecko support multiple-range selections? Or is this all deprecated? |
| 18:46 | <smaug____> | Gecko does support multiple selections |
| 18:46 | <smaug____> | I mean, multi-range |
| 18:47 | <dglazkov> | ok |
| 18:48 | <AryehGregor> | dglazkov, yes, it does. rniwa and I get ehsan to agree at some point that it shouldn't, but I dunno if the rest of Gecko is on board with that. |
| 18:48 | <dglazkov> | why are multi-range selections sucky? |
| 18:49 | <smaug____> | that is not clear to me |
| 18:50 | <smaug____> | but IIRC other browser vendors don't want to implement them |
| 18:54 | <dglazkov> | at least to me, multi-range selections are the thing that make selections work non-crazily with shadow DOM, so I am interested |
| 18:55 | <AryehGregor> | dglazkov, because 98% of the time there's only one Range, so authors do getSelection().getRangeAt(0) and expect it to be the only range in the selection, which breaks. |
| 18:56 | <AryehGregor> | If we need non-contiguous selections, a better API is required, like maybe one that returns all nodes contained in the selection instead of endpoints. One where the non-contiguous selection is not exposed as a special case in the API, because it's too rare for anyone to pay attention to. |
| 18:56 | <AryehGregor> | FWIW, Gecko itself internally has crazy bugs with multi-range selections. |
| 18:56 | <AryehGregor> | ehsan demoed some of them with execCommand(). It does pretty much random things when multi-range selections are involved. |
| 18:56 | <AryehGregor> | If Gecko engineers can't get multi-range selections right, do you expect web authors to? |
| 18:57 | <dglazkov> | I see. |
| 18:59 | <ehsan> | AryehGregor: smaug____: yeah, I meant to start that discussion at some point, but I held off on it cause I never had the time to rip them out |
| 18:59 | <ehsan> | and I didn't want the discussion to end with no results |
| 18:59 | <dglazkov> | AryehGregor: thanks, I need to think about this some more. |
| 19:00 | <AryehGregor> | Honestly, the Range API is way too complicated anyway. Like the fact that offsets are sometimes child numbers and sometimes offsets into CharacterData, and the way that you can have a zillion different boundary points that map to the same location. |
| 19:00 | <AryehGregor> | It's a PITA for authors to use. |
| 19:01 | <AryehGregor> | Author code is littered with simplifying assumptions like "there's only one range per selection" and "range endpoints are always in Element or Text nodes". |
| 19:01 | <AryehGregor> | Which they don't even realize are wrong. |
| 19:01 | <dglazkov> | damn authors! |
| 19:01 | <dglazkov> | why can't they be smarter! |
| 19:01 | <dglazkov> | :D |
| 19:02 | <smaug____> | AryehGregor: ehsan: I think mats has fixed most of the bugs related to multi-range selections |
| 19:03 | <smaug____> | er, possibly not related to execCommand |
| 19:03 | smaug____ | is not interested in execCommand :p |
| 19:03 | <ehsan> | smaug____: no, he hasn't :) |
| 19:04 | <smaug____> | multi-range selections is a nice way to implement spellchecking UI, IMO |
| 19:06 | <ehsan> | smaug____: that can be debated, but for the most part what we want is stop exposing them to the content |
| 19:07 | <ehsan> | I feel that the way we use multi-range selections to handle spell checking etc is not optimal |
| 19:07 | <ehsan> | but that's a different discussion |
| 19:19 | <kennyluck> | annevk, for big5, are you inclined to spec Gecko's big5 table or CP590 of others? |
| 19:26 | <bz_moz> | Is the idl from the html5 spec available somewhere without all the other verbiage? |
| 19:41 | <AryehGregor> | bz_moz, the source code of this has a copy-pasted version with a few tweaks: w3c-test.org/html/tests/submission/AryehGregor/interfaces.html I used this to generate it from the one-page WHATWG spec: var s = ""; [].forEach.call(document.getElementsByClassName("idl"), function(idl) { if (!idl.classList.contains("extract")) { s += idl.textContent + "\n\n"; } }); document.body.innerHTML = '<pre></pre>'; d |
| 19:41 | <AryehGregor> | ocument.body.firstChild.textContent = s; |
| 19:41 | <AryehGregor> | (see http://w3c-test.org/html/tests/resources/idlharness.js ) |
| 19:43 | <bz_moz> | AryehGregor: looking |
| 19:44 | <bz_moz> | AryehGregor: thanks, that's perfect |
| 19:44 | <AryehGregor> | :) |
| 19:44 | <AryehGregor> | It might be slightly out-of-date. |
| 19:45 | <bz_moz> | I just need the interface hierarchy |
| 19:45 | <bz_moz> | not the members |
| 19:45 | <bz_moz> | I doubt that's changed |
| 19:50 | <AryehGregor> | bz_moz, since transform-origin isn't inherited, the only way the computed value is detectable is through getComputedStyle(), no? Having different resolved and computed values is only meaningful for inherited properties, because it's the computed value that's inherited? |
| 19:50 | <AryehGregor> | Or is computed value used somewhere other than inheritance and getComputedStyle()? |
| 19:53 | <bz_moz> | AryehGregor: all properties can be inherited |
| 19:53 | <bz_moz> | AryehGregor: some are just not inherited by default |
| 19:53 | <bz_moz> | AryehGregor: anyone can always write "transform-origin: inherit" and boom! |
| 19:54 | <bz_moz> | AryehGregor: as long as your dimensions are different from your parent you can now tell whether the computed value was percent or pixels |
| 19:54 | <bz_moz> | AryehGregor: resolved value is a concept specific to getComputedStyle |
| 19:54 | <bz_moz> | AryehGregor: because UAs historically do weird shit there, because the CSS2 definition of computed value was .... odd |
| 20:46 | <Hixie> | i have returned! |
| 20:47 | <Hixie> | and won't be reading backlog, so if you asked me something, ask again or send mail :-) |
| 20:47 | <TabAtkins> | ...where did you go? |
| 20:47 | Hixie | has literally 1000s of e-mails to deal with |
| 20:47 | <TabAtkins> | ...when did you leave? |
| 20:47 | <Hixie> | TabAtkins: vacation |
| 20:49 | <bz_moz> | hixie: were you gone for more than 3 days? |
| 20:50 | <Hixie> | more like 3 weeks |
| 20:50 | <TabAtkins> | Wow. |
| 20:50 | <bz_moz> | hixie: then why do you need the "literally"? ;) |
| 20:50 | <TabAtkins> | I... guess it's a good thing I didn't notice? |
| 20:50 | <Hixie> | bz_moz: fair point! :-) |
| 20:50 | <Hixie> | TabAtkins: :-P |
| 20:50 | bz_moz | would figure that 2000/week is a good lower bound for email |
| 20:50 | <Hixie> | actually this is after my filters get rid of 90% of my mail |
| 20:50 | <TabAtkins> | bz_moz: Surely your silicon brain can handle more than that. |
| 20:51 | <bz_moz> | hixie: ah, heh |
| 20:51 | <TabAtkins> | Until I see you at SXSW and satisfy myself that your'e an organic, I'm going to continue to assume you're a supercomputing cluster in an MIT basement. |
| 20:51 | <bz_moz> | TabAtkins: my laptop can probably handle all sorts of mail volumes |
| 20:52 | <bz_moz> | heh |
| 20:52 | <bz_moz> | I have no evidence you're organic either |
| 20:52 | <TabAtkins> | Please. My effiency and work ethic is clearly organic. |
| 20:52 | <bz_moz> | plus, how would you tell apart a human from R Daneel Olivaw anyway? |
| 20:52 | <TabAtkins> | Invasive x-ray. |
| 20:53 | bz_moz | hopes sxsw passes on those |
| 20:53 | <TabAtkins> | I'm hoping I get it through airport security. |
| 20:53 | <bz_moz> | you'd have to catch me at the airport |
| 20:53 | <bz_moz> | heh |
| 20:53 | bz_moz | has taken to traveling with his kids |
| 20:53 | <bz_moz> | that way I go through the sane line |
| 20:53 | <TabAtkins> | Airport x-ray isn't invasive. It would be fooled by organic skin. |
| 20:53 | <bz_moz> | at least so far |
| 20:53 | <bz_moz> | TabAtkins: yeah, I know |
| 20:54 | <TabAtkins> | I just opt-out every time. 10 minutes wasting their time with a patdown and I'm good. |
| 20:54 | <bz_moz> | and as far as that goes, the TSA actually rolled back a dumb policy |
| 20:54 | <TabAtkins> | Unless, like last time, they detect explosives on me and call the cops. |
| 20:54 | <bz_moz> | TabAtkins: heh |
| 20:54 | <bz_moz> | TabAtkins: I've been under too much time pressure to do that the one time it came up. :( |
| 20:55 | <TabAtkins> | I've done a pornoscanner once in a similar timecrunch, but I usually ensure I have 1.5 hours so I can eat the time. |
| 20:57 | <bz_moz> | what I want is confirmation of ms2ger's humanity |
| 20:58 | <bz_moz> | but I may be out of luck. |
| 20:58 | <Ms2ger> | Which humanity? |
| 20:58 | <jgraham> | I want conformation he is non-human |
| 20:58 | <jgraham> | It would be way more interesting |
| 20:58 | <jgraham> | But less surprising |
| 20:59 | <Ms2ger> | Still passing my Turing test? |
| 20:59 | <AryehGregor> | bz_moz, ah, right. Thanks. |
| 20:59 | <bz_moz> | Ms2ger: oh, sure |
| 20:59 | <bz_moz> | Ms2ger: but at this point chatbots do _that_ |
| 20:59 | <bz_moz> | Ms2ger: (you do a bit better, because you comment on patches, which most chatbots can't) |
| 21:00 | <TabAtkins> | True. Cleverbot is pretty human most of the time. |
| 21:00 | <bz_moz> | tabatkins: more precisely the turing testers are not doing it right |
| 21:00 | <bz_moz> | tabatkins: imho |
| 21:00 | <Ms2ger> | bz_moz, hmm, I want a bot to complain about style issues in random people's patches :) |
| 21:00 | <TabAtkins> | Another 10 years, and the turing test will stop being useful for testing AI, because we'll just assume that making conversation is something that *of course* computers can do. |
| 21:01 | <TabAtkins> | (10y is a conservative estimate) |
| 21:01 | <bz_moz> | Ms2ger: http://beaufour.dk/jst-review/ |
| 21:01 | <Ms2ger> | bz_moz, yeah, but I want it to comment in bmo |
| 21:01 | <bz_moz> | TabAtkins: depends on conversation and demographic. random party conversation, sure |
| 21:01 | <bz_moz> | TabAtkins: which is why you have to find a common area of interest and specialize |
| 21:02 | <bz_moz> | TabAtkins: e.g. I'm pretty sure I could prove to myself that you're not a bot |
| 21:02 | <Ms2ger> | And it's not useful for me, because I deliberately don't rev uuids in patches I put up for review |
| 21:02 | <bz_moz> | TabAtkins: we'd just talk css specs |
| 21:04 | <TabAtkins> | Well, sure, because Texas doesn't have good AI research. |
| 21:04 | bz_moz | had no idea texas was involved |
| 21:04 | <TabAtkins> | It's where I was raised. |
| 21:05 | <bz_moz> | if we're talking that.... |
| 21:05 | <TabAtkins> | On the other hand, you're somewhere up in the northeast, where all the fancy universities are. |
| 21:05 | <bz_moz> | neither does dc |
| 21:05 | <bz_moz> | (amount of I in general there could be debated) |
| 21:20 | <Ms2ger> | zewt, thanks for your reply about encoding/XHR/json, that's why I wanted the guy to tell public-webapps about his bug :) |
| 22:31 | <TabAtkins> | matjas, matijsb: I forget which of you is which, so I'll just say: the CSS commits feed is back to working. It's not showing the diffs yet, but you don't need that for the Twitter feed. |
| 22:33 | <matijsb> | TabAtkins: hehe, this is matjas' |
| 23:17 | <zewt> | "This is an editor's draft of a spec, it's not a recommendation, so it's hardly a violation of anything." <- losing a lot of respect for webkit here |
| 23:17 | <Ms2ger> | timeless, "anyone have experience cajoling MXR into doing regexp searches? I'm trying to get it to search for '#\d+[#=]' (in Perl-speak), and I'm getting nowhere" |
| 23:17 | <Ms2ger> | cc jwalden |
| 23:18 | <Hixie> | zewt: url? |
| 23:18 | <Ms2ger> | public-webapps, the JSON thread |
| 23:18 | <zewt> | responseType "json" thread on webapps |
| 23:24 | <Hixie> | ah, i didn't read that thread |
| 23:24 | <gsnedders> | The HTML5 parser defines a context-sensitive language, right? Has anyone tried to do a formal definition of it? |
| 23:24 | <Hixie> | are you saying the HTML spec isn't formal? :-P |
| 23:25 | <gsnedders> | Yes. :P |
| 23:32 | <annevk> | bz_moz: you get too much email :) |
| 23:33 | <annevk> | bz_moz: having said that, I think in three months I had about 20000, so maybe you are right... depressing |
| 23:33 | <annevk> | three months away* |
| 23:33 | <gsnedders> | Hixie: Can you think of anything that stops it from being a CSG? |
| 23:34 | <annevk> | kennyluck: 950, which I thought is what Gecko implemented |
| 23:34 | <annevk> | AryehGregor: thanks |
| 23:35 | <annevk> | wb Hixie |
| 23:44 | <Hixie> | gsnedders: CSG? |
| 23:44 | <gsnedders> | Hixie: Context sensitive grammar |
| 23:44 | gsnedders | will be scared if it isn't |
| 23:44 | <Hixie> | document.write()? |
| 23:44 | <gsnedders> | Because if it isn't, you need a Turing machine to parse it. |
| 23:44 | <Hixie> | you do |
| 23:44 | <gsnedders> | Hixie: Assume scripting disabled |
| 23:45 | <Hixie> | oh |
| 23:45 | <gsnedders> | (Once you have JS involved, obviously a Turing machine is needed) |
| 23:45 | <Hixie> | do you mean conforming syntax only too? |
| 23:45 | <gsnedders> | No. |
| 23:45 | <annevk> | gsnedders: take a few classes off and figure it out |
| 23:46 | <annevk> | gsnedders: I'm sure mankind will thank you, and university might hand you a few credits |
| 23:47 | <Hixie> | gsnedders: i'm not familiar enough with the strict definition of CSG to say one way or the other |
| 23:47 | <Hixie> | gsnedders: certainly in the common case -- scripting enabled -- parsing can be non-deterministic |
| 23:47 | <gsnedders> | My gut says it is a CSG, but I don't have proof for it. |
| 23:47 | <gsnedders> | Hixie: Certainly. document.write guarantees that. |
| 23:49 | <Hixie> | gsnedders: does the fact that HTML streams can be unbounded make it not a CSG? |
| 23:50 | <TabAtkins> | No. |
| 23:50 | <Hixie> | wikipedia says a CSG can be parsed by an LBA, and an LBA assumes bounded input as far as i can tell |
| 23:50 | <gsnedders> | Hixie: No |
| 23:50 | <Hixie> | but here we are outside my area of expertise |
| 23:50 | <Hixie> | so... |
| 23:51 | <gsnedders> | Hixie: Even a regular grammar can handle unbounded input |
| 23:51 | <Hixie> | it seems wikipedia's definitions also has the key sentence "The only restriction placed on grammars for such languages is that no production maps a string to a shorter string." |
| 23:51 | <Hixie> | but i don't really understand what that means |
| 23:51 | <gsnedders> | e.g., a null-terminated string can be parsed with a regular grammar, but you don't know when, if ever, you'll reach the null byte. |
| 23:52 | <gsnedders> | So inevitably anything higher up in the hierarchy can be unbounded. |
| 23:52 | <Hixie> | k |
| 23:53 | <Hixie> | oh oh |
| 23:53 | <Hixie> | the AAA |
| 23:53 | <Hixie> | it can mutate previously-provided output |
| 23:53 | <Hixie> | does that violate some rule of CSGs? |
| 23:53 | <Hixie> | <html x> and <body x>, too |
| 23:54 | <Hixie> | and <table>x |
| 23:54 | <TabAtkins> | I'm somewhat concerned about the AAA. |
| 23:54 | <Hixie> | aren't we all |
| 23:54 | <TabAtkins> | What's the effect of <html x>? |
| 23:54 | <Hixie> | mutates the earlier <html> node |
| 23:54 | <Hixie> | iirc |
| 23:54 | <Hixie> | (adds attributes) |
| 23:55 | <TabAtkins> | Oh, is this because the parser has some special-case for <html>? |
| 23:55 | <gsnedders> | That's not an issue. You're still creating the html node. |
| 23:55 | <TabAtkins> | That adds the token first? |
| 23:55 | <Hixie> | <html><html a><html b> parses the same as <html a b> iirc |
| 23:55 | <Hixie> | where you can have any amount of content between each of those tags |
| 23:55 | <TabAtkins> | But yeah, the fact that AAA can move content an arbitrary distance past arbitrary content inside the table would probably break a CSG. |
| 23:56 | <TabAtkins> | Same with <html> attribute merging, yeah. |
| 23:57 | <TabAtkins> | Yeah, you'd need a two-stack DFA, which is turing-equivalent. |
| 23:57 | <gsnedders> | Is a two-stack DFA Turing-equiv? I thought you could do that with a CSG. |
| 23:57 | <TabAtkins> | Yes, it is. |
| 23:58 | <TabAtkins> | If i'm remembering my automata theory properly |
| 23:58 | <TabAtkins> | Shit, I meant PDA. |
| 23:58 | <TabAtkins> | A two-stack PDA. |
| 23:59 | <gsnedders> | Well, a PDA is basically just a one-stack DFA |
| 23:59 | <TabAtkins> | Hm. You may be able to get by with a nested-stack PDA, which is still a type 1 language. |