| 00:07 | <Hixie> | have CSS always be UTF-8 is fine, it's just its own language |
| 00:07 | <Hixie> | i think it's a lot easier to understand that CSS does it a different way than HTML, than it is that HTML does it differently than HTML |
| 00:13 | <zcorpan> | i'm not sure many people think in terms of "this is CSS" and "this is HTML" |
| 00:15 | <zcorpan> | anyway, past bed time |
| 01:57 | <gsnedders> | I guess someone should update the outliner after the changes. |
| 04:49 | <Hixie> | gsnedders: this causes a crash currently: <doctype html><title>T</title><h1>1...</h1><section>implied</section><figure>figure</figure><h2>2...</h2><h2>3...</h2> |
| 06:06 | <MikeSmith> | I'll update the outline feature in the validator |
| 06:23 | <MikeSmith> | Hixie: have you commented on Client Hints anywhere yet? |
| 07:01 | <MikeSmith> | push notifications. |
| 09:33 | <hsivonen> | annevk-cloud: considering how popular IE is in China, it would probably be relevent to test IE6...11. If you have a test page that automatically dumps the test result in a copy-pasteable form, I can run it in IE6...11 |
| 09:34 | <hsivonen> | annevk-cloud: anyway, seems awesome of we can use the kind of GB18030 decoder Firefox already has *and* have it be an UTF |
| 12:56 | <annevk-cloud> | The problem with my page is that it does not work in IE |
| 12:56 | <annevk-cloud> | I can fix that tomorrow so we can be thorough |
| 13:30 | <DeTeam> | Hey! Is there anyone who's familiar with http://www.w3.org/TR/css3-grid-layout ? :) |
| 13:31 | <Ms2ger> | itym http://dev.w3.org/csswg/css-grid/ |
| 13:31 | <jgraham> | Not that is likely to be awake at the moment, I think |
| 13:31 | <Ms2ger> | So TabAtkins |
| 13:31 | <jgraham> | But yes, also /TR/ -> out of date |
| 13:32 | <DeTeam> | wow, didn't know about the draft |
| 13:32 | <DeTeam> | we've got a huge timeshift, I guess |
| 13:33 | <DeTeam> | TabAtkins seem to be offline now :( |
| 13:34 | <DeTeam> | is there a huge difference between the TR and the draft? only three months gone |
| 13:37 | <jgraham> | Three months is a long time in web standards |
| 13:37 | <DeTeam> | Ms2ger: are you going to implement grids in servo? ;) |
| 13:37 | <jgraham> | Or can be at least |
| 13:37 | <Ms2ger> | I don't think so :) |
| 13:37 | <Ms2ger> | Will you? |
| 13:38 | <DeTeam> | I don't do rust (% |
| 13:38 | jgraham | looks forward to servo being the only browser that doesn't support forms, but does support grid |
| 13:38 | <DeTeam> | jgraham: got it.. so it's all about slow implementations |
| 13:38 | <zcorpan> | DeTeam: did you have a question about it? (i'm not really familiar with it, but here it might be best to just ask the question and then wait) |
| 13:39 | <DeTeam> | people don't need forms, grids are fine ) |
| 13:39 | <Ms2ger> | Forms are hard |
| 13:39 | <DeTeam> | zcorpan: yes, a few, the algorithm described in section 11 is not very clear for me |
| 13:39 | <Ms2ger> | Clearly we should get webcomponents first |
| 13:40 | <Ms2ger> | Then people can polyfill input type=text |
| 13:41 | <DeTeam> | I'll check the dev spec and the post my questions, thanks |
| 13:41 | <zcorpan> | DeTeam: it's just missing a reference to Your Imagination. T. Atkins. |
| 13:46 | <DeTeam> | zcorpan: http://dev.w3.org/csswg/css-grid/#function-ResolveContentBasedTrackSizingFunctions-algorithm step 1 says the we should filter out items with span>1 (e.g. 2) and cross a flex-sized grid track. In any direction (both rows, cols) or depending on current direction (if so - how)? |
| 13:46 | <DeTeam> | http://dev.w3.org/csswg/css-grid/#adapting-to-available-space - shouldn't the big area in fig 2 and 3 be excluded? |
| 14:01 | <zcorpan> | DeTeam: i'd recommend you file bugs https://www.w3.org/Bugs/Public/enter_bug.cgi?product=CSS&component=Grid+Layout |
| 14:03 | <DeTeam> | Not sure those a bugs, just wondering how things should work (before trying to implement that grid layouting) |
| 14:03 | <DeTeam> | those are* |
| 14:04 | <DeTeam> | zcorpan: mb I should wait for Tab to get online |
| 14:04 | <zcorpan> | DeTeam: it's a bug that the spec isn't clear to you :-) |
| 14:06 | <DeTeam> | zcorpan: hm, may be. I'll do this after chat with Tab or other authors |
| 14:06 | <gsnedders> | Ms2ger: Oh please do imploement web components first. It would be beautiful. |
| 14:15 | <DeTeam> | gsnedders: is there webcomponents introduction talk, the one from google i/o? |
| 14:20 | <gsnedders> | DeTeam: No idea :) |
| 14:32 | <Ms2ger> | gsnedders, patches welcome :D |
| 14:34 | <rdebeasi> | DeTeam, this one? https://www.youtube.com/watch?v=fqULJBBEVQE |
| 14:34 | <DeTeam> | rdebeasi: seem so |
| 14:37 | <darobin_> | DeTeam: depending on what you're looking for there's also the explainer document |
| 14:37 | <darobin_> | (though it's more or less 50% science fiction and 50% out of date :) |
| 14:38 | <DeTeam> | darobin: doc on css grids? |
| 14:38 | <darobin> | DeTeam: no, sorry, I meant for Web Components |
| 14:39 | <darobin> | IIRC there are several docs on CSS grids but they're all out of date with this week's version :) |
| 14:39 | <DeTeam> | darobin: ah, heard about it for the first time, just scheduling stuff to read/watch later |
| 14:39 | <darobin> | DeTeam: there's this http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html |
| 14:40 | <DeTeam> | darobin: yeah, already found it, thanks ;) |
| 15:32 | <jgraham> | darobin: You look bored! How about some code review? ;) |
| 15:32 | <darobin> | oh dear |
| 15:32 | <darobin> | jgraham: which one? |
| 15:33 | <jgraham> | https://critic.hoppipolla.co.uk/r/440 |
| 15:34 | <Ms2ger> | Or 368 |
| 15:35 | <Ms2ger> | Yes, I know the number by now |
| 15:36 | <jgraham> | 364, 368, 440: the holy trinity of review requests |
| 15:43 | <darobin> | jgraham: on the face of it it looks good, but you know I'm no Python wizz |
| 15:44 | <darobin> | but from a quick scan it looks sane and seems to DTRT |
| 15:44 | <jgraham> | darobin: Hmm, I guess I will get someone else to review in more detail then :) |
| 15:44 | <jgraham> | Thanks |
| 15:44 | <darobin> | jgraham: yeah, I mean, I'm happy to review things but I can only do so sensibly in terms of use cases really |
| 15:45 | <darobin> | and this seems to be the tool I'd want to use |
| 15:45 | <jgraham> | BTW, if you actually *are* bored at any point maybe you would consider improving the test runner in the jgraham/runner branch |
| 15:45 | <darobin> | but if you're doing something stupid in Python, it's not obvious to me :) |
| 15:45 | <jgraham> | (no review yet) |
| 15:45 | <darobin> | I am bored, but sadly it's with something I have to do |
| 15:45 | <darobin> | I hope to get rid of it today though, so I might be the right kind of bored tomorrow :) |
| 15:46 | <Ms2ger> | Run away? |
| 15:46 | <darobin> | I need to get the runner working for HTML anyway |
| 15:47 | <jgraham> | Well I think it works, it just needs polish |
| 15:47 | <jgraham> | Someone that doesn't produce eye-bleedingly awful designs |
| 15:50 | <Ms2ger> | So at least you copied the design from me? :) |
| 15:50 | <jgraham> | I may even have made it worse :) |
| 15:50 | <Ms2ger> | That sounds implausible :) |
| 15:52 | <jgraham> | I dunno, I don't think you will like the way that reftests work now, for example. The Grand Design requires that there are keyboard shortcuts, but I didn't get as far as implementing them |
| 15:52 | <Ms2ger> | Did you put the runner online somewhere? |
| 15:53 | <Ms2ger> | Though I guess I already managed to checkout the branch |
| 15:53 | <Ms2ger> | Oh, hrm |
| 15:53 | <jgraham> | It uses the local server |
| 15:54 | <Ms2ger> | And your manifest, I guess |
| 15:54 | <jgraham> | Yes |
| 15:54 | <jgraham> | Thats just another reason r/440 needs some lovw |
| 15:54 | <Ms2ger> | Does it support running a subset of the tests? |
| 15:54 | <jgraham> | *love |
| 15:55 | <jgraham> | Yes, you can specify a url prefix to match |
| 15:55 | <jgraham> | e.g. /workers |
| 15:55 | <Ms2ger> | Okay, not going to bother setting it up locally right now, then |
| 15:57 | <jgraham> | Yeah, this will be easier once the three reviews above land. That's why I didn't even create a review for the test runner yet |
| 16:01 | <darobin> | I really like the number of times I can get PhantomJS to crash by having it run through the test suite |
| 16:56 | <MikeSmith> | annevk-cloud: is there a mozilla bug for the Streams API other than https://bugzilla.mozilla.org/show_bug.cgi?id=891286 |
| 17:01 | <MikeSmith> | or Mozilla discussion somewhere about Domenic's draft? |
| 17:02 | <MikeSmith> | Domenic_: ↑ |
| 17:03 | <MikeSmith> | Domenic_: or discussion anywhere else I might have missed? a Chrome bug? |
| 17:04 | <MikeSmith> | I guess I need to look back at the public-webapps discussion |
| 17:05 | MikeSmith | finds https://code.google.com/p/chromium/issues/detail?id=240603 |
| 17:05 | <Domenic_> | MikeSmith: marcosc is involved, since e.g. he's using whatwg/streams in Serial API and I think one other place. |
| 17:05 | <MikeSmith> | Domenic_: OK |
| 17:06 | <Domenic_> | MikeSmith: we still need to have everyone get together and have a conversation and iron out some differences... |
| 17:08 | <MikeSmith> | Domenic_: as far as ironing out the differences, it seems like the approach in Yoshino-san's draft and yours aren't reconcilable, right? |
| 17:10 | tobie | wishes we could just pave the node cow-path here (learn from their initial mistakes) and move on. |
| 17:11 | <Domenic_> | MikeSmith: agree... but, would be better not to have two competing standards. |
| 17:11 | <Domenic_> | tobie: yeah, that's what whatwg/streams tries to do. |
| 17:12 | <tobie> | yeah, let's turn that into a whatwg/w3c conversation. Sounds super productive. :D |
| 17:14 | <Domenic_> | that's kind of the problem, is that i've flippantly said unpolitic things in that direction, hurting whatwg/streams credibility :( |
| 17:15 | <jgraham> | I'm not sure that's the actual problem |
| 17:15 | <Domenic_> | well, it's a problem, and at least one that i feel bad about |
| 17:15 | <Domenic_> | but yes, probably not the problem |
| 17:15 | <annevk-cloud> | MikeSmith: not that I know |
| 17:15 | <tobie> | Should we have a task force to determine what the nature of the problem is? |
| 17:16 | <Domenic_> | tobie: w3c task force or whatwg task force? |
| 17:16 | <annevk-cloud> | Are you serious? |
| 17:16 | <tobie> | shit. Hadn't thought about that. |
| 17:16 | <annevk-cloud> | Because Task Forces… |
| 17:16 | <MikeSmith> | Domenic_: I don't think you've hurt the credibility of it all. I think implementors are going to judge it on its merits just like everything else |
| 17:17 | <Domenic_> | MikeSmith: that's the dream; glad to hear you think so :) |
| 17:17 | <annevk-cloud> | I tend to agree with that as well, let the best standard win |
| 17:17 | <tobie> | Maybe a workshop is more appropriate, then. |
| 17:17 | <annevk-cloud> | Dude! |
| 17:18 | <MikeSmith> | tobie has become trollbie |
| 17:18 | <tobie> | well, now that anne lives in the cloud, I thought why not? |
| 17:18 | <annevk-cloud> | I have a hard time reading the troll |
| 17:18 | <annevk-cloud> | I guess tobie wins |
| 17:18 | <Domenic_> | i thought the word "task force" was a good giveaway |
| 17:19 | <Domenic_> | would this task force be doing any internet engineering? |
| 17:19 | <tobie> | More seriously, though, glad to hear there's a sensible proposal on the table. |
| 17:21 | <jgraham> | I though usually the wiining standard was the one that Apple shipped unannounced before refusing to implement anything else |
| 17:22 | <Domenic_> | hmm one of my college friends works at apple... |
| 17:22 | <tobie> | OK, this is getting way out of hand. |
| 17:23 | <tobie> | The last thing the web needs is streams implemented as meta tags. |
| 17:23 | <jgraham> | tobie: All the people that hate js would love it though |
| 17:24 | <jgraham> | (I guess event source is almost that…) |
| 17:24 | <tobie> | ^ true |
| 17:58 | <Ms2ger> | What's next, Dart.NET? |
| 18:02 | <Domenic_> | DScript comes first I believe |
| 18:26 | <odinho> | Tell me, a XHR request which set some custom requestheader (content-type), -- when it follows a 301/302 redirect, should that request header be sent to the new redirected location? |
| 18:29 | <odinho> | (this also with cors, but simple request) |
| 18:29 | <odinho> | It seems to be re-using the request object. |
| 18:29 | <odinho> | 4. Return the result of performing a fetch using request, with the CORS flag set if set. |
| 18:29 | <odinho> | Which is what I expect. So I would expect the content-type to get to the redirected cors-domain. |
| 18:33 | <odinho> | Btw, neither presto, gecko or blink seem to follow this: http://xhr.spec.whatwg.org/#dom-xmlhttprequest-overridemimetype |
| 18:33 | <odinho> | If the state is LOADING or DONE, throw an "InvalidStateError" exception. |
| 18:33 | <odinho> | Seems none do. |
| 22:50 | <zcorpan> | hsivonen: didn't gecko change to not load non-JS <script>? <http://www.w3.org/mid/52B076A1.2020408⊙me>; |
| 23:19 | <Hixie> | sicking: man, this messageport thing is tough. let me think on it some more. |
| 23:20 | <sicking> | Hixie: i've shot some promises people an email to see if we're abusing promises. |
| 23:20 | <sicking> | Hixie: it's still unclear to me when promises are ok and when they are not, so it's a very good question |
| 23:20 | <sicking> | Hixie: Dominic has said that they are only appropriate as return values for asynchronous functions, which isn't the case here |
| 23:20 | <Hixie> | sicking: the problem with the promise solution is it prevents the page from bfcaching in the case of a long-lived notification-style channel (as opposed to a channel just used for query-response), which i'd really like to avoid if we can |
| 23:21 | <sicking> | Hixie: i don't think solving the bfcaching is an interesting use case to solve in v1 |
| 23:21 | <Hixie> | sicking: (and also, i think it's kind of weird to have two entirely different parts of the app be in charge of rejecting and resolving the same promise, let alone the UA and the author) |
| 23:21 | <sicking> | Hixie: it's something that needs to be very explicitly opted in to |
| 23:22 | <Hixie> | sicking: if we can find a solution that doesn't put the feature at risk like onsuspend does, and yet doesn't prevent bfcache at all like the promise does, i think it'd be great. |
| 23:22 | <sicking> | Hixie: the problem is that bfcaching was intended to be an optimistic and transparent feature. Anything that breaks that is not going to be interesting for us to implement since it's so unlikely that devs are going to know about bfcaching |
| 23:22 | <Hixie> | sicking: right |
| 23:27 | <Hixie> | heh, i just thought of a way that even browsers without a bfcache could get onresume in my (flawed) proposal in my last e-mail |
| 23:27 | <Hixie> | suppose an iframe has one end of a port |
| 23:27 | <Hixie> | and the other end is far away in some other process, and has onsuspend/onresume attached |
| 23:28 | <Hixie> | now the iframe is navigated away, but before doing so, it passes a reference to its port up to its parent (just a reference, it doesn't transfer ownership) |
| 23:28 | <Hixie> | the navigation causes the port to stop receiving messages, so onsuspend is sent (though actually, come to think of it, the parent could still _send_ messages, it's only receiving them that's blocked) |
| 23:28 | <Hixie> | now, the parent takes this port, and _transfers it to itself_, via a newly cearted MessageChannel |
| 23:29 | <Hixie> | created |
| 23:29 | <sicking> | Hixie: syntax aside, I think we need a signal that says "other side has gone away" (of course). But always enabling such a signal disables GCing. Hence we need a signal that says "I'm interested in the gone-away signal" and "i'm no longer interested in the gone-away signal". If you additionally want to solve bfcaching (which i'm not sure that you'll find any implementation interest in), you separately need three signals for "i can handle |
| 23:29 | <sicking> | bfcaching", "other side was bfcached" and "other side is back from bfcache" |
| 23:29 | <Hixie> | the port that comes out the other end is no longer owned by a "dead" Document, so the other end-point would suddenly get an onresume event :-) |
| 23:30 | <Hixie> | sicking: yeah. i'm hoping there's some other way of looking at this that doesn't force us to block GCing or bfcaching. |
| 23:30 | <Hixie> | sicking: especially since, in principle, we're saying that almost any sane use of ports should really be listening for these states to be well implemented. |
| 23:30 | <sicking> | Hixie: i'm fairly sure that it's probaly impossible |
| 23:31 | <Hixie> | it's possible, but before we chop our arm off i want to really be absolutely sure i've exhausted every idea i can come up with :-) |
| 23:31 | <sicking> | have at it |
| 23:37 | <sicking> | Hixie: and to be cleaer, even if you did specify a mechanism to enable bfcaching, i'm not sure that we would implement. There are other features that prevent bfcaching of *way* more pages, and yet we have not implemented APIs to enable bfcaching those pages. |
| 23:45 | <Hixie> | sicking: i wouldn't propose an API that enables it. i would just be looking for an API that didn't preclude it (while not putting bfcaching implementations at risk the way onsuspend does) |
| 23:45 | <Hixie> | (though see notes above about how even non-bfcaching UAs could still get onresume) |