| 00:06 | <Hixie> | rillian: does http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-January/038705.html still represent the current state of mozilla's metadata-in-video API work? |
| 00:08 | <rillian> | Hixie: yes |
| 00:09 | <Hixie> | thanks |
| 00:09 | <rillian> | which is to say, I haven't done further work on it |
| 01:58 | <zewt> | idb thread cc fail |
| 02:09 | <jgraham> | Ms2ger: yes, it is the reviewer's responsibility to reopen any issues that weren't actually addressed by the commit (although of course it is polite if the code author helps them out) |
| 02:12 | <jgraham> | zcorpan: I didn't really understand your use case, since it seems like you will always be inside another (async_)step when you might do the thing that returns the value you want. But it seems strictly better than the current API |
| 04:03 | <kochi> | MikeSmith: yt? |
| 09:01 | <zcorpan> | if i were to encode U+D800 as utf-8, ignoring that it's invalid, would it be: ED 9F C0 ? |
| 09:05 | zcorpan | finds http://mail.python.org/pipermail/python-dev/2009-April/089134.html |
| 10:25 | <Steve____> | FYI: there will be a bug opened by chaals against the html spec about changing the conformance requirments for @longdesc, could you deal with it? as I woul;d like to stay at arms length from it given my roles as a11y chair and the controversy surrounding it |
| 10:27 | <Steve____> | oops wrong window ;-) |
| 10:28 | <Steve____> | darobin_: thats for you |
| 12:10 | <MikeSmith> | kochi: here now |
| 12:35 | <MikeSmith> | anybody have a link to the draft that defines custom elements? |
| 12:35 | <MikeSmith> | for Web Components |
| 12:38 | <MikeSmith> | nm |
| 12:38 | <MikeSmith> | found it |
| 12:39 | <MikeSmith> | next question: Is there yet a spec that actually defines the <decorator> element? |
| 12:43 | <JohnAlbin> | MikeSmith: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html |
| 12:59 | <MikeSmith> | JohnAlbin: thanks |
| 12:59 | <MikeSmith> | but note, that's non-normative |
| 12:59 | <MikeSmith> | it seems Dimitri has yet to write the actual normative draft for it |
| 13:16 | <JohnAlbin> | I just happened to have that doc open in my browser. :-) |
| 13:27 | <zcorpan> | what is the correct output of new RegExp('').source per spec? |
| 13:30 | <zcorpan> | and new RegExp('/').source ? |
| 13:30 | <zcorpan> | "The source property of the newly constructed object is set to S.", ES5 says |
| 13:31 | <zcorpan> | two paragraphs above, it says S is to be escaped in some way, but isn't particularly exact |
| 13:31 | <zcorpan> | "For example, if P is "/", then S could be "\/" or "\u002F", among other possibilities" |
| 13:34 | <zcorpan> | http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.10.5 has the same text |
| 13:36 | <hasather> | zcorpan: V8 has a bug it seems, https://code.google.com/p/v8/issues/detail?id=1982 |
| 13:45 | <zcorpan> | well, sent an email to es-discuss |
| 13:49 | <hasather> | zcorpan: what's not clear by the spec? |
| 13:49 | <zcorpan> | hasather: what .source should be when Pattern is something that needs to be escaped, e.g. empty string, a slash, a newline |
| 13:50 | <hasather> | zcorpan: it says something about both those cases |
| 13:51 | <zcorpan> | hasather: the spec gives *two* examples of what to do for a slash, and no specific requirements |
| 13:53 | <hasather> | zcorpan: isn't "The characters / occurring in the pattern shall be escaped in S as necessary to ensure that the String value formed by concatenating the Strings "/", S, "/", and F can be parsed (in an appropriate lexical context) as a RegularExpressionLiteral that behaves identically to the constructed regular expression." a requirement? |
| 13:54 | <zewt> | that gives me interop twitches (why doesn't it specify exactly how to escape it?) |
| 13:54 | <zcorpan> | hasather: yes, it is, but it gives multiple choices |
| 13:54 | <zcorpan> | what zewt said |
| 13:55 | <zewt> | specs should specify what to do, not what the end result should be |
| 13:55 | <hasather> | zcorpan: zewt: right, it would be better if it just specified. Agreed. :) |
| 13:56 | <zcorpan> | not surprisingly, browsers suck in this area |
| 13:56 | <zcorpan> | when specs give a clear algorithm, browsers tend to implement the algorithm |
| 13:57 | <hasather> | zcorpan: apart from the V8 bug, do browsers differ in this specific case? |
| 13:57 | <zcorpan> | with text like this saying "yeah you should do the right thing, y'know!", the implementor probably goes "yeah whatever" and moves on to the next thing |
| 13:57 | <zcorpan> | for \n, opera/chrome/firefox all give a literal new line as .source even though it violates the requirement |
| 13:58 | <zcorpan> | so they don't differ, but they don't conform to the spec |
| 13:58 | <zcorpan> | for / and the empty string, they do differ, actually |
| 13:58 | <zcorpan> | firefox and opera returns empty string for empty string |
| 13:59 | <zcorpan> | opera and firefox return \/ for /, chrome returns / |
| 13:59 | <zewt> | my chrome gives \/ |
| 13:59 | <zewt> | for console.log(/\//.source) (checking that I'm looking at the right thing) |
| 14:00 | <zcorpan> | zewt: try new RegExp('/').source |
| 14:01 | <zewt> | yeah that does it ... why are they different? maybe /foo/ just copies in the actual literal |
| 14:02 | <zewt> | i guess that points to another thing that might be different and/or cause compat issues--is it okay to always re-escape from scratch in order to meet the requirement, or could changing it when you don't have to (resulting in new RegExp(x).source != x) cause compat issues somehow |
| 14:05 | <zewt> | also, this seems like some ancient hack to work around injection issues on sites, but that might be irrelevant to the constructor path anyway (especially if Chrome isn't doing it) |
| 14:07 | <zewt> | if the escaping could be killed for the ctor, then you might not need anything special for literals; just say "let .source be the exact literal", since the literal itself must have been escaped in the first place |
| 14:07 | <zewt> | anyhow, off to work |
| 14:46 | <darobin> | Ms2ger: I can close this without taking it, right? https://github.com/w3c/testharness.js/pull/13 |
| 14:46 | <darobin> | since I fixed it on the server |
| 14:48 | <Ms2ger> | darobin, yes |
| 14:48 | <darobin> | Ms2ger: cool |
| 14:51 | <jgraham_> | darobin: Can you mark your webidl parser issues somehow? I just endured several seconds of confusion :) |
| 14:51 | <darobin> | jgraham_: sorry man |
| 14:51 | <darobin> | I've just added a label |
| 14:52 | <darobin> | they're actually idlharness — the parser is in another repo |
| 14:52 | <jgraham_> | That also confused me :) |
| 14:53 | <darobin> | haha |
| 14:54 | <jgraham> | Ms2ger: You should drop http://critic.hoppipolla.co.uk/r/10 |
| 14:55 | <Ms2ger> | jgraham, I think I've done that |
| 14:55 | <zcorpan> | oh, i have to subscribe to es-discuss. |
| 14:55 | <jgraham> | perfect, thanks |
| 15:54 | <jwalden> | zcorpan: http://krijnhoetmer.nl/irc-logs/whatwg/20130318#l-708 btw |
| 15:54 | <zcorpan> | jwalden: yeah i saw it, thanks |
| 15:54 | <jwalden> | cool |
| 15:55 | <zcorpan> | i sent an email to es-discuss. annevk said it might have been decided in the last meeting already |
| 15:56 | <annevk> | I remember reading something about it in the conclusion bits of the minutes |
| 16:00 | <jwalden> | I can't find anything in March 12-14 or January 30 |
| 16:00 | <jwalden> | did see new Date(dateObj) is supposed to clone |
| 16:00 | <jwalden> | but that was the only date-ful stuff I noticed |
| 16:17 | <dglazkov> | good morning, Whatwg! |
| 16:36 | <jwalden> | morning |
| 16:38 | <zcorpan> | "somebody would need to develop a proposal that completely specifies the required escaping." - any takers? :-) |
| 16:38 | <zcorpan> | (re RegExp.source) |
| 16:55 | <Hixie> | btw, i posted https://plus.google.com/u/0/107429617152575897589/posts/iPmatxBYuj2 (re drm) |
| 16:57 | <annevk5> | Hixie: old news :p |
| 16:57 | <annevk5> | great post though |
| 17:19 | <TabAtkins> | zcorpan: What's the requirements for RegExp.source? The escaping, while not easy, isn't particularly difficult either. |
| 18:02 | <karlcow> | http://inessential.com/2013/03/18/brians_stupid_feed_tricks |
| 18:45 | <GPHemsley> | the formatting of TAG IRC logs is terrible |
| 18:52 | <marcosc> | jamesr: The scheme in the logo uri has been removed from all TR stylesheets. |
| 18:52 | <marcosc> | (you mentioned this as causing problems for http/https docs the other day) |
| 18:52 | <marcosc> | I asked the W3C to fix it, and they did :) |
| 18:53 | <marcosc> | see: https://www.w3.org/StyleSheets/TR/W3C-ED |
| 19:06 | <dglazkov> | annevk: you still around? |
| 19:06 | <annevk> | I'm alive |
| 19:06 | <dglazkov> | annevk: are we doing Event.path? |
| 19:06 | <annevk> | just minuted a session on httprange-14 |
| 19:07 | <annevk> | dglazkov: dunno, someone suggested it might not be needed if we introduce something else? |
| 19:07 | <dglazkov> | annevk: ok, let me look on bug |
| 19:07 | <annevk> | dglazkov: I'd prefer we get more usage data first with the whole component thing before we add a bunch of features we later regret |
| 19:07 | <dglazkov> | alright |
| 19:14 | <jamesr> | marcosc, cool! thanks |
| 19:15 | <jamesr> | marcosc, for the record, how did you asked the W3C to fix it? |
| 19:16 | <marcosc> | jamesr: because I have a bunch of specs that I figured would also be affected |
| 19:16 | <marcosc> | I saw this happen recently in Chrome |
| 19:16 | <jamesr> | yeah, but i'm wondering what you actually did. send an email to some alias? |
| 19:16 | <jamesr> | i dunno how to report a problem like this |
| 19:16 | <marcosc> | ah |
| 19:16 | <marcosc> | I just emails sysreq⊙wo |
| 19:16 | <jamesr> | aha! |
| 19:16 | <marcosc> | emailed* |
| 19:17 | <marcosc> | they are fairly responsive |
| 19:17 | <marcosc> | otherwise, just annoy MikeSmith or darobin :) |
| 19:17 | MikeSmith | wakes up |
| 19:17 | <MikeSmith> | whadda need fixing? |
| 19:19 | <jamesr> | MikeSmith, already been fixed, but the issue was w3c logos loading over http:// for specs hosted on https:// |
| 19:19 | <MikeSmith> | ah yeah |
| 19:20 | <MikeSmith> | so the general solution when you run into problems is to do what marcosc said |
| 19:21 | <MikeSmith> | that is, ping me or darobin (Robin Berjon) here |
| 19:21 | <MikeSmith> | or e-mail me at mike⊙wo |
| 19:21 | <MikeSmith> | mailing sysreq⊙wo works to but may take longer |
| 19:24 | <marcosc> | jamesr: syreq takes longer, but MikeSmith charges more |
| 19:24 | <marcosc> | :) |
| 19:24 | <MikeSmith> | I just thrive on the love |
| 19:25 | <marcosc> | :) |
| 19:26 | <jamesr> | sounds like a difficult choice |
| 20:42 | <MikeSmith> | dglazkov: if you're around, I wanted to ask if you have a normative draft for <decorator> yet |
| 20:42 | <MikeSmith> | and if not, when you might have one -- or maybe, who's going to write it? |
| 20:42 | <zcorpan> | TabAtkins: what needs doing is replacing http://krijnhoetmer.nl/irc-logs/whatwg/20130319#l-382 with an algorithm that states what to replace exactly |
| 20:43 | <MikeSmith> | dglazkov: maybe something that Dominic could work on? |
| 20:44 | <zcorpan> | TabAtkins: what i know so far is "" -> "(?:)", "/" -> "\\/", "\n" -> "\\n" (probably similar for all characters that JS considers as new line) |
| 21:31 | <rniwa_> | bot-watchers |
| 21:31 | <rniwa_> | ugh... |
| 23:43 | <TabAtkins> | zcorpan: Don't you want to escape *all* the \ characters, regardless of what they code for? |
| 23:43 | <TabAtkins> | /\n/ selects a newline, after all. It's a valid escape sequence. |