| 10:02 | <kochi> | MikeSmith: removed <canvas> example in IME API spec: https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html |
| 10:11 | <annevk> | TabAtkins_: awake? |
| 11:49 | <Ms2ger> | OH "I'd hate to see a naked middle-aged man with pink hair, and I am one." |
| 12:16 | <gsnedders> | Ms2ger: brucel? |
| 12:16 | <Ms2ger> | Yeah |
| 12:16 | <jgraham> | Pretty sure I have seen him and he wasn't naked |
| 12:35 | <annevk> | Pretty sure I've seen pictures where he was a book away from that |
| 13:07 | <zcorpan> | should rel=discussion and rel=issues be registered? (or are they just not implemented in v.nu yet?) |
| 13:08 | <zcorpan> | tantek: hsivonen_: MikeSmith: ^ |
| 13:18 | <annevk> | I feel like a large part of Fetch is becoming an exercise in redefining vague parts of HTTP... |
| 13:19 | <annevk> | E.g. it now defines how to follow a redirect (that you include the same headers and such, how you parse the Location header), how to do HTTP authentication (again with including the headers, not doing it for CORS, that credentials are passed via the URL), ... |
| 13:21 | <annevk> | It's pretty close to just having "open a TCP connection, serialize this request object to an HTTP request, transmit it, parse response..." |
| 13:48 | <zcorpan> | annevk: just take that step :-) |
| 13:49 | <annevk> | that would get very bad with SPDY |
| 13:50 | <zcorpan> | why? |
| 13:50 | <annevk> | well it serializes differently, doesn't it? |
| 13:51 | <annevk> | keeps connections open longer, etc. |
| 13:52 | <annevk> | might even be possible to share connections across disconnected browsing contexts |
| 13:52 | <zcorpan> | i'm not familiar with spdy, but in any case it would be good with clear specs for http and spdy |
| 13:53 | <annevk> | what could possibly be taken over is all semantic-related requirements |
| 13:53 | <annevk> | maybe long term |
| 13:53 | <annevk> | after we bug the IETF about it again and show them what we need to build on top of their stuff to actually use it... |
| 13:55 | <zcorpan> | anyone have comments on http://html-differences.whatwg.org/#development-model ? |
| 13:56 | <annevk> | authors seem to dislike the term authors, so maybe we should start calling them developers? |
| 13:58 | <annevk> | zcorpan: might also want to introduce a switch in the abstract for HTML5/HTML |
| 13:58 | <annevk> | zcorpan: for the document title |
| 13:59 | <MikeSmith> | zcorpan: dunno about those rel values |
| 13:59 | <zcorpan> | annevk: i decided to have the same title |
| 13:59 | <MikeSmith> | zcorpan: will take a look |
| 13:59 | <annevk> | zcorpan: <title> is still different? |
| 14:00 | <zcorpan> | annevk: no? |
| 14:01 | <annevk> | zcorpan: sorry, cache :/ |
| 14:07 | <zcorpan> | annevk: thanks |
| 14:08 | <annevk> | zcorpan: oh, also just committed a small fix to xref you might want to integrate |
| 14:10 | <zcorpan> | ok |
| 14:13 | <zcorpan> | apparently today i've managed to procastinate documenting the changes on the w3c side :-P |
| 14:14 | <Redface> | such as? |
| 14:14 | <zcorpan> | Redface: you mean, what changes? or what? |
| 14:15 | <Redface> | yesyes |
| 14:15 | <Redface> | wat changes |
| 14:15 | <zcorpan> | that's what i haven't documented yet :-) |
| 14:15 | <zcorpan> | though e.g. <hgroup> being dropped |
| 14:17 | <Redface> | i see i see |
| 14:23 | <annevk> | ffffuuu |
| 14:24 | <annevk> | forgot to check www-authenticate header |
| 14:25 | <zcorpan> | Hixie: why this rule in http://www.whatwg.org/style/specification ? p + * > li, p + div.status + * > li, dd li { margin: 1em 0; } |
| 14:26 | <zcorpan> | Hixie: it makes some lists have spacing and others not, which looks weird (in html-differences at least) |
| 14:27 | <zcorpan> | Hixie: could the selector be changed to just `li` (and use a class where you don't want the spacing)? |
| 14:27 | <SteveF> | zcorpan: http://html-differences.whatwg.org/#development-model have some suggestions for the text re 5.1 should i file a bug? |
| 14:28 | <zcorpan> | SteveF: sure |
| 14:28 | <SteveF> | ok will do |
| 14:28 | <zcorpan> | (you can select text in the spec and a link should appear to file a bug) |
| 14:28 | <SteveF> | also noted some inaccuracies so will file bugs |
| 14:28 | <zcorpan> | thanks! |
| 14:30 | <zcorpan> | Hixie: (like the "brief" class which exists already) |
| 14:38 | <annevk> | SteveF: did you cc me or am I on the default cc list somehow? |
| 14:38 | <SteveF> | must be on default i just filed bugs |
| 14:40 | <annevk> | MikeSmith: can you remove me from that component? The one that reads "HTML5 differences from HTML4 (editor: Anne van Kesteren)" |
| 14:41 | <annevk> | MikeSmith: (before you decide to rename the component, you want to coordinate that with zcorpan) |
| 14:42 | <zcorpan> | i'm OK with renaming the component. "HTML differences from HTML4 (editor: Simon Pieters)" |
| 14:42 | <zcorpan> | oh this was about cc |
| 14:44 | <annevk> | yeah, renaming seems fine, but since the spec has direct links I thought I'd not ask about that :) |
| 15:07 | <MikeSmith> | annevk: zcorpan: ok, changed the component name and removed annevk from the Cc field |
| 15:08 | <MikeSmith> | the links I'll fix later |
| 15:08 | <annevk> | ta |
| 15:09 | <zcorpan> | MikeSmith: thanks. i can fix the links in html-differences |
| 15:14 | <MikeSmith> | k |
| 15:27 | <SteveF> | zcorpan:mike changing component name has broken the bug script a little |
| 16:22 | <dglazkov> | good morning, Whatwg! |
| 16:25 | <Redface_> | wow , heres 1:27am :) |
| 16:26 | <odinho> | And here it was 18:27 |
| 16:28 | <Redface_> | where yall live in? |
| 16:28 | <odinho> | dglazkov: Is in California/USA IIRC, I'm in Oslo/Norway. |
| 16:29 | <dglazkov> | we span globe like a boss |
| 16:29 | <Redface_> | Seoul/South Korea over here |
| 16:30 | <annevk> | London reporting in |
| 17:37 | <TabAtkins> | annevk: pong |
| 17:38 | <annevk> | TabAtkins: fixed the bit I was going to ask about as I got feedback from someone else (in the DOM Standard, last two commits) |
| 17:39 | <TabAtkins> | Cool. Looking into the threads, I'm not finding enough agreement to really justify asking you to change the resolve behavior quite yet. I'll be putting up an email in a few looking for final sign-offs on what I want. |
| 17:40 | <TabAtkins> | (Regarding automatically assimilating thenables.) |
| 17:48 | <annevk> | TabAtkins: look at the suggestion from Domenic and see if that could work for you |
| 17:48 | <TabAtkins> | Where? |
| 17:48 | <annevk> | TabAtkins: where we'd special case branded Futures |
| 17:48 | <annevk> | TabAtkins: don't have a pointer handy and in meeting |
| 17:48 | <TabAtkins> | kk |
| 17:49 | <TabAtkins> | If it's "single-level unwrap native/branded futures, recursively assimilate thenables, just accept everything else", then that's still not great for me: |
| 17:49 | <TabAtkins> | It's not *predictable*. "Thenable" is a category that is larger than "promise-like", and it means that you can accidentally trip into the "assimilate" case without wanting to, just because some API returns an object with a then() method unrelated to promises. |
| 17:52 | <TabAtkins> | I won't die if that's the behavior we settle on, I'll just be unhappy, because it means that to be predictable, you have to use Future.accept() to wrap the return value of any function that's not meant to return a future/thenable. |
| 17:52 | <annevk> | I agree it would be nicer to not special case "then". I don't think that's going to fly. |
| 17:53 | <TabAtkins> | Yeah, so I'm writing up an email to see if it's acceptable now. |
| 17:53 | <annevk> | My impression is that you're getting agreement from the monad-camp and everyone else is ignoring it. But hopefully someone speaks up now. |
| 17:55 | <TabAtkins> | Yeah, that's what I want to fix. |
| 18:38 | <tantek> | zcorpan rel-discussion is registered, I'm working on rel-issues |
| 18:52 | <tantek> | zcorpan, ok rel-issues registered and spec stubbed. |
| 18:52 | <tantek> | thanks for the heads-up. |
| 19:15 | <MikeSmith> | SteveF: which script? |
| 19:19 | <annevk> | MikeSmith: prolly the one running on html-differences.whatwg.org |
| 19:20 | <MikeSmith> | ah ok |
| 19:43 | <TabAtkins> | annevk: Your recent commits now leave the naming and behavior in an inconsistent state. |
| 19:44 | <TabAtkins> | You call the first argument to then an "acceptCallback", but it still uses the recursive resolve semantics. |
| 19:45 | <TabAtkins> | This means, for example, that it's impossible to provide an explicit callback with the same behavior as omitting the callback. |
| 19:46 | <TabAtkins> | Future.accept(Future.accept(5)).then(cb).then(alert) will, regardless of what "cb" is, alert a plain value, not a Future. |
| 19:46 | <TabAtkins> | While Future.accept(Future.accept(5)).then().then(alert) will alert a Future. |
| 19:50 | <SteveF> | MikeSmith: the script that makes it easier to file a bug |
| 19:57 | <annevk> | TabAtkins: the name of the callback indicates when it will be invoked |
| 19:58 | <annevk> | TabAtkins: futures don't have a "resolved" state, it's either "pending", "accepted", or "rejected" |
| 20:00 | <annevk> | Ah I see Domenic_ pointed that out already on the list |
| 20:17 | <TabAtkins> | annevk: I don't think you understand what I just said, because your response is a non-sequitur. ^_^ |
| 20:18 | <annevk> | TabAtkins: no it's not |
| 20:19 | <TabAtkins> | Remember earlier, when you said that "Future.accept(Future.accept(5)).then(function(x) { return Future.accept(x); }).then(alert)" would alert "<object Future>" rather than "5"? That is, it would only strip one level of Future-ness from the value? |
| 20:19 | <annevk> | yeah that was wrong |
| 20:19 | <TabAtkins> | Yes, and now you have a problem. |
| 20:19 | <annevk> | but that's orthogonal to the naming |
| 20:19 | <TabAtkins> | There is no possible function you can pass to .then() that is equivalent to not passing a function, and that's dumb. |
| 20:20 | <Domenic_> | relevant: https://github.com/slightlyoff/DOMFuture/issues/13 |
| 20:21 | <annevk> | TabAtkins: yeah, as I said to you earlier, we could introduce branding for that |
| 20:22 | <lecuyer> | TabAtkins: has there been a discussion around :has() as a pseudo class? |
| 20:22 | <TabAtkins> | lecuyer: Right now, the use-case for :has() is satisfied by :matches() and/or the subject indicator. |
| 20:25 | <lecuyer> | TabAtkins: ah, how did I miss the subject indicator? |
| 20:25 | <TabAtkins> | It's buried in a non-obvious section. ^_^ |
| 20:26 | <lecuyer> | the ! is new to level 4, right? I dont' see that in 3 |
| 20:26 | <TabAtkins> | Yes. |
| 20:27 | <TabAtkins> | foo:has(bar baz) is equivalent to :matches(!foo bar baz). |
| 20:27 | <lecuyer> | righto |
| 20:28 | <TabAtkins> | (I find :has() easier to read for its use-cases, though.) |
| 20:29 | <Domenic_> | subject indicator is going to be amazing |
| 20:31 | <TabAtkins> | Unfortunately, we've had to put it in the "complete" profile, so it'll only be available to JS APIs, not normal CSS selectors. |
| 20:31 | <Domenic_> | oh no why :( |
| 20:31 | <TabAtkins> | Because it's not fast. ^_^ |
| 20:33 | <Domenic_> | :(. Is there another way to solve the common "previous sibling" requirement than `!foo bar`? |
| 20:33 | <TabAtkins> | Doing *just* a "previous sibling" or "parent" thing isn't terrible, and can probably be done in the fast profile (according to bzbarsky). |
| 20:34 | <TabAtkins> | But we haven't done so yet. |
| 20:34 | <Domenic_> | siiiigh |
| 20:35 | <Domenic_> | maybe some genius on the blink or ie team will think of a way to make it fast and then everyone else will be pressured into adding it ^_^ |
| 20:35 | <Domenic_> | oh no the reference combinator is gone too, poor labels |
| 20:35 | <TabAtkins> | No it's not. |
| 20:36 | <fantasai> | Domenic_: There's ways to make it fast, it's just complicated and probably requires some sophisticated caching |
| 20:36 | <Domenic_> | it's under complete i mean |
| 20:37 | <TabAtkins> | Oh, right. That's a borderline case - we need implementor feedback for it. |
| 20:50 | <jgraham> | The Futures discussion is nice. I get to silently agree with TabAtkins and so neatly avoid the work of actually getting involved. |
| 21:00 | <TabAtkins> | jgraham: I wish more people *would* speak up. Even if I *am* a shining voice of reason in the darkness, if I'm the only one, it's easy for "the other side" to treat me like a lone objector and route around me. |
| 21:32 | <lecuyer> | TabAtkins: I think what you're asking is blazingly reasonable |
| 21:45 | <lecuyer> | crap, disregard the email I "sent", my client auto-sent when I closed the window :( |
| 21:48 | <Lachy> | fantasai, TabAtkins, thanks for dealing with the scoping stuff in selectors. I should be able to get back to doing some spec work next week. I can't do it this weekend as I'm busy moving apartment. |
| 21:48 | <Lachy> | though, note, hopefully the next time a spec with selectors api is published, it will be as part of the DOM spec, and not the independent selectors api 2 spec. |
| 21:49 | <TabAtkins> | No problem! |
| 22:11 | <tantek> | mailing lists might actually help with this: http://dilbert.com/strips/comic/2013-05-02/ |
| 22:30 | <TabAtkins> | Yay, I have Jonas agreeing with me so far! |
| 22:30 | <TabAtkins> | That's helpful. |
| 22:38 | <Domenic_> | is it just me or are my emails not threading correctly -_- |
| 22:38 | <TabAtkins> | Works for me. |
| 22:38 | <TabAtkins> | Also: ARRRRGH, I'm not intending my mails to read as "We made a spec and you didn't, so stfu". |
| 22:39 | <TabAtkins> | I was getting getting angry at Mark for pretending like there's a real spec for promises-in-his-head that we all have to defer to, so that whatever I say is irrelevant. |
| 22:39 | <TabAtkins> | I was, however, intending them to be read as "Shit or get off the pot." |
| 22:48 | <Domenic_> | TabAtkins: are you aware of his involvement in Promises/A+? |
| 22:48 | <TabAtkins> | Yes, definitely. |
| 22:48 | <TabAtkins> | But, to the best of my knowledge, he keeps referring to a tc39 promises spec, not the separate promises/a+ spec that you're in charge of. |
| 22:48 | <TabAtkins> | If I'm wrong, sorry, but he hasn't made this clear. ^_^ |
| 22:57 | <Domenic_> | I'm not sure that's what he's referring to, but it was my impression he was, because part of the Promises/A+ goal is to be something TC39 can build on, and his involvement has been toward that. |
| 23:05 | <TabAtkins> | My experience is that Mark is often unclear to the point of being obfuscatory. :/ It takes effort to make sure you actually know what he's talking about. |
| 23:05 | <TabAtkins> | But whatever, I'm just trying to get shit down, and don't mean to be rude to anyone. :/ |