| 00:14 | <sicking> | Hixie: how so? |
| 00:14 | <Hixie> | sicking: can't do both that an [ArrayClass] |
| 00:14 | <Hixie> | and |
| 00:15 | <sicking> | Hixie: that is indeed a problem. But so is not inheriting from EventTarget |
| 00:16 | <Hixie> | yeah, i know |
| 00:16 | <Hixie> | i'm just joshing you |
| 00:16 | <Hixie> | but i did say there would be _something_ else that we wanted interfaces to be |
| 00:16 | <Hixie> | just didn't know what at the time :-) |
| 00:16 | <sicking> | Hixie: indeed. You were right :) |
| 00:20 | <Hixie> | good lord, the multipage problems are getting worse and worse |
| 00:20 | <Hixie> | now not only is it not updating, it's missing entire pages |
| 00:20 | <Hixie> | what's going on here |
| 00:24 | <WeirdAl> | !seen annevk |
| 00:25 | <Hixie> | he's on vacation for a few more days |
| 00:25 | <Hixie> | ok i got the pages back |
| 00:25 | <Hixie> | still out of date though |
| 00:25 | <Hixie> | i wonder if that's an issue my end |
| 00:28 | <Hixie> | ok well i've found one problem |
| 00:29 | <Hixie> | it's not splitting the spec i'm giving it |
| 00:29 | <Hixie> | wonder what that's about |
| 00:30 | <Hixie> | aha, yes, the problem is that anne is no longer fetching the spec before splitting it |
| 00:30 | <Hixie> | i get no hits from him to get the spec to split |
| 00:31 | <Hixie> | anyone want to write an article for IEEE about HTML? |
| 00:42 | <divya> | hhahah will this be a 'whitepaper' presented at some symposium? |
| 00:47 | <Hixie> | no, for IEEE Spectrum or whatever their magazine is called |
| 00:50 | <divya> | ohh k |
| 00:51 | <Hixie> | if anyone _is_ interested, drop me a mail or ping me here, i'll hook you up (they're looking for someone) |
| 01:55 | <MikeSmith> | https://twitter.com/#!/grorgwork/status/164445742981844994 |
| 02:05 | <davidb> | is |
| 08:01 | <zcorpan> | huh, what does chrome do with the attributes here? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1318 |
| 10:11 | <smaug____> | mouseenter/leave seem to be tricky to understand |
| 10:11 | <smaug____> | perhaps it was a mistake to implement them in Gecko |
| 10:12 | <smaug____> | (and accept them i nD3E) |
| 16:30 | <jgraham> | http://www.readwriteweb.com/mobile/2012/01/how-lanyrd-uses-html5-for-a-gr.php is mildly interesting. We should make sure to get their feedback on the offline stuff |
| 16:37 | <AryehGregor> | Does it take a while for CSS drafts on dev.w3.org to update? |
| 16:40 | <AryehGregor> | It seems so. |
| 16:40 | <AryehGregor> | Sigh. |
| 16:45 | <Ms2ger> | CVS *sigh* |
| 16:47 | <karlcow> | cvsigh |
| 17:00 | <JohnAlbin> | CVS? ouch. |
| 17:02 | <dglazkov> | good morning, Whatwg! |
| 17:02 | <AryehGregor> | Argh, bugzilla.mozilla.org is slow. >:( |
| 17:06 | <AryehGregor> | I never thought my math background would come in so useful for standards: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15610#c2 |
| 17:08 | <Berge> | Hi! I'm trying to stream (not psuedo-stream, it's a live broadcast) h.264 video to browsers with <video> support, but it's not proving too easy. What muxes are supported in various browsers? |
| 17:10 | <Berge> | (The encoding box hasn't got enough CPU power to encode VP8 in addition to the HD and SD h.264 streams.) |
| 17:11 | <AryehGregor> | Firefox/Opera don't support H.264 in any form. |
| 17:11 | <Berge> | The spec lists some examples, but my encoder can't mux MP4 to IP streams (only files), and I haven't found anyone able to do that, so it seems very file-only. |
| 17:12 | <Berge> | AryehGregor: I know. We've got flash fallback. |
| 17:12 | <Berge> | (And multicast!) |
| 17:12 | <AryehGregor> | Okay. Then I probably don't know enough to be helpful. :) |
| 17:13 | <Berge> | But even if I did encode VP8, what mux, container format and MIME type should I deliver it in? |
| 17:14 | <Velmont> | Hmm. The chromium ubuntu-ppa is not new enough it seems. Chromium 17, but 18 is the thing now. So trying this new chrome dev thing instead then. |
| 17:16 | <Velmont> | Berge: I've been streaming Ogg Theora + Vorbis, with Java applet fallback for non-opera, non-fx, non-chromium. |
| 17:17 | <Berge> | Theroa is inferior quality-wise, though. |
| 17:17 | <Berge> | Theora, even. |
| 17:18 | <Velmont> | Well. Depends on what you're streaming. I've been doing conferences, and it's good there. Especially the newer versions. The old ones were terrible. |
| 17:18 | <Velmont> | It's easy to encode at least, doesn't require all that much horse power. |
| 17:19 | <Berge> | True, but x264 encoding h.264 is really a different world in bits vs quality. |
| 17:19 | <wilhelm> | Java applet, not Flash? |
| 17:20 | <Velmont> | wilhelm: Flash can't decode theora. - And I'm evil enough to let people who absolutely want to use either IE or Safari bite the bullet and get the Java applet :-) |
| 17:20 | <Velmont> | But it actually works rather well. |
| 17:20 | <Velmont> | Berge: Yes, -- but other h264 encoders and Theora is not really a huge difference. |
| 17:21 | <Berge> | Velmont: Probably, but there's a reason why I use x264 (-: |
| 17:21 | <Berge> | IME, it's loads better than even rather expensive hardware solutions. |
| 17:22 | <Velmont> | Berge: Yep. I wouldn't use anything else if I'd need to encode h264. No contest. |
| 17:22 | <Velmont> | Berge: But Theora encoder got many of the good parts of x264 in the latest iterations. |
| 17:22 | <Berge> | Velmont: Hm, that's good news. |
| 17:22 | <Velmont> | Berge: Sadly, the WebM announcement put a halt to much of the good Theora work. |
| 17:22 | <Berge> | For better or worse, I guess. |
| 17:23 | <Berge> | VP8 is pretty good, but encoders need some love. |
| 17:23 | <Velmont> | The lowest hanging fruit was done, -- but lots of small improvements were in the pipeline :-) |
| 17:23 | <Berge> | I'm told they're getting better as well, though. |
| 17:23 | <Velmont> | Berge: I'm waiting for some toolchain-stuff that's still not there though. --- BUT! Yesterday, there was an announcement of a WebM-patch for Icecast. So I can probably start looking at WebM soonish. :] |
| 17:24 | <Berge> | Yes, see, this is why this whole stream-video-without-flash is a bit tricky right know. |
| 17:24 | <gsnedders> | Berge: I can't think of any streaming container supported cross-browser for <video> |
| 17:24 | <Berge> | We've already patched VLC twice for this project. |
| 17:24 | <Berge> | And the kernel(!) |
| 17:25 | <Berge> | gsnedders: Doesn't have to be all that cross browser, really. Most viewers will be more happy with VLC. |
| 17:25 | <Berge> | Or Flash fallback, for that matter. |
| 17:25 | <Berge> | The <video> part is mostly for fun. |
| 17:25 | <Velmont> | Berge: That's why I'm still using Theora, -- live streaming works reliably in Opera, Firefox and Chromium. And all the toolchain is there and it's easy to use and set up. |
| 17:25 | <Berge> | Velmont: It's all very pick-your-poison. |
| 17:26 | <Velmont> | Ah, it also works nicely in IE, because IE and Java is quite OK-ish friends. -- But, I agree Berge, pick your poison :-] |
| 17:26 | <Berge> | But since I don't really follow web development closely; is the world slowly moving towards VP8 support? |
| 17:27 | <gsnedders> | Except for MS and Apple, it is at least. |
| 17:27 | <Berge> | Then it's not. |
| 17:27 | <gsnedders> | No idea what happened about support in Flash. |
| 17:27 | <gsnedders> | Berge: On mobile at least it's happening. |
| 17:27 | <Berge> | gsnedders: At least if we forget Windows PHone? |
| 17:27 | <Velmont> | And on an unrelated note... Seems like WebKit hasn't updated its IndexedDB support as I thought it had after reading the mailing lists. |
| 17:27 | <Berge> | (I'm happy to, of course (-: ) |
| 17:28 | <gsnedders> | Berge: Windows Phone 7 has minimal marketshare, iOS is the bigger issue. |
| 17:28 | <Velmont> | http://tests.velmont.net/IndexedDB/testrunner.htm << I've ported Microsofts IDB tests. |
| 17:29 | <gsnedders> | Velmont: ported to what? |
| 17:29 | <Ms2ger> | Velmont, hey, I know that UI :) |
| 17:29 | <Velmont> | gsnedders: New spec, and better error reporting. -- So using testharness.js as it's supposed to be used. |
| 17:29 | <Velmont> | Ms2ger: Hehe, yes, thanks :P |
| 17:30 | <Ms2ger> | Does it work well? :) |
| 17:30 | <Velmont> | Ms2ger: I use it for all tests I write for Opera. |
| 17:30 | <Ms2ger> | \o/ |
| 17:30 | <gsnedders> | So, like, I still don't get why so few people understand "this" in JS. |
| 17:31 | <TabAtkins_> | Because 'this' is really confusing. |
| 17:31 | <TabAtkins_> | Largely because it (a) doesn't soft-bind, and (b) gets shadowed when you use higher-order functions. |
| 17:31 | <jgraham> | gsnedders: It's not that people don't *understand* |
| 17:31 | <gsnedders> | "this" is just another argument for function calls. Once you accept that, it's simple. |
| 17:32 | <jgraham> | It's that the semantics are braindead |
| 17:32 | <jgraham> | because they are easy to forget about |
| 17:32 | <Ms2ger> | gsnedders, oh, it's like Python? |
| 17:32 | <Velmont> | Python has it explicit at least. Easier to understand :] |
| 17:32 | <TabAtkins_> | Velmont: Agreed. |
| 17:32 | <jgraham> | It's not just that it's explicit in python |
| 17:33 | <gsnedders> | The only confusing part is that it is *implicit* in JS. |
| 17:33 | <jgraham> | It's also that it is bound to the function |
| 17:33 | <jgraham> | gsnedders: The only confusing part is that it's confusing? |
| 17:33 | <jgraham> | the only tautological part is that it's tautological, much? |
| 17:34 | <TabAtkins_> | gsnedders: The fact that it doesn't soft-bind - that is, "var x = foo.bar; x();" doesn't do the same thing as "foo.bar()" if the function relies on 'this'. |
| 17:44 | <AryehGregor> | TabAtkins_, so what's the procedure for proposing that we unprefix everything related to CSS Transforms? |
| 17:44 | AryehGregor | guesses teleconference >:( |
| 17:52 | <Ms2ger> | AryehGregor, nice out-trigonometring smfr :) |
| 17:53 | <hober> | AryehGregor: 2d is ready to unprefix, but 3d isn't, and they share the same property names. so even with 2d ready i don't think unprefixing is a good idea. |
| 17:53 | <AryehGregor> | My high school calculus teacher had a policy that if you gave him an answer involving trig functions that he didn't think was the same as what he got, he'd give you credit if you submitted a proof that they were the same. |
| 17:53 | <hober> | (and i say that as someone who would love to unprefix this stuff) |
| 17:54 | <AryehGregor> | hober, 1) We could unprefix only 2D, by having (e.g.) transform: scale3d(5); be a parse error. Browsers could either support only -webkit-transform: scale3d(5), or also support transform: -webkit-scale3d(5) (substitute prefixes as appropriate). |
| 17:55 | <AryehGregor> | hober, 2) We don't have great interop on 3D yet, but the syntax is almost completely settled. There's almost no difference in how Gecko and WebKit interpret 3D syntax, they just have different sets of bugs. |
| 17:55 | <AryehGregor> | I.e., non-syntax-related bugs. |
| 17:55 | <TabAtkins_> | AryehGregor: It's "get the fucker to CR". |
| 17:55 | <AryehGregor> | The syntax bugs I've found are minor, e.g., WebKit accepting perspective(5) to mean perspective(5px), or treating certain things as identity transforms instead of parse errors. |
| 17:56 | <divya> | wasnt this discussed at the seattle F2F? |
| 17:56 | <divya> | same problems |
| 17:56 | <AryehGregor> | TabAtkins_, the CSSWG seriously requires prefixing everything until the spec formally reaches CR? Even if the syntax is totally stable? |
| 17:56 | <TabAtkins_> | Argh, really? perspective(5) is parsed as 5px? That doesn't even make *sense*. |
| 17:56 | <hober> | divya: yes |
| 17:57 | <AryehGregor> | TabAtkins_, originally WebKit didn't even accept perspective(5px), AFAIK . . . on the other hand, Gecko accepts matrix(1,0,0,1,5px,0). |
| 17:57 | <hober> | AryehGregor: yeah, and 2d is ready to enter cr, at least in my opinion. |
| 17:57 | <TabAtkins_> | AryehGregor: No, but it's still desirable. This being a special case probably means it's fine to drop prefixes early. |
| 17:57 | <hober> | AryehGregor: but trying to have the behavior you describe above for the split 2d-unprefixed/3d-prefixed would be gross to implement for little benefit |
| 17:57 | <TabAtkins_> | But really, 2d should be cr-ready now that it's getting a bit of bugfix attention paid to it. |
| 17:58 | <hober> | TabAtkins_: yeah, it pretty much is. i think there's one open issue marked in the spec |
| 17:58 | <AryehGregor> | 2D is definitely CR-ready. |
| 17:58 | <hober> | i really don't want to do some frankensteinian unprefixing |
| 17:58 | <AryehGregor> | It's almost PR-ready, in fact. |
| 17:59 | <TabAtkins_> | Good., |
| 17:59 | <AryehGregor> | hober, hasn't it been pointed out often enough that the prefixing situation we have in these cases is horrible for authors? |
| 17:59 | <hober> | indeed it is |
| 17:59 | <divya> | point out to death |
| 17:59 | <TabAtkins_> | Take it through LC while finishing the test suite, and then CR will just be a formality as impls change to pass the suite. |
| 17:59 | <hober> | which is why we should try to get 3d to cr as quickly as we can |
| 17:59 | <AryehGregor> | TabAtkins_, the test suite is basically finished, IMO. |
| 17:59 | <TabAtkins_> | Cool, then. |
| 17:59 | <AryehGregor> | . . . meaning, the one I wrote in the last month or so. |
| 18:00 | <TabAtkins_> | Yeah. |
| 18:00 | <AryehGregor> | I'm sure there are some gaps. |
| 18:00 | <hober> | so that we can drop prefixes on transform and transform-origin in a clean way |
| 18:00 | <AryehGregor> | And there are some spec bugs to be resolved. |
| 18:00 | <TabAtkins_> | There will need to be a review of the test suite, so it'll spend a little bit in CR. |
| 18:00 | <AryehGregor> | Sure. |
| 18:00 | <AryehGregor> | If people add me as an editor of the combined transform spec and let me clarify the spec freely to match browsers, I bet I could resolve all spec issues and have a full test suite in less than a month. |
| 18:01 | <Ms2ger> | After LC, I guess you need WG approval for all changes in the CSSWG |
| 18:01 | <AryehGregor> | This stuff is way simpler than editing. |
| 18:01 | <AryehGregor> | Oh, wait, one thing: transitions and animations. |
| 18:01 | <AryehGregor> | There's no way to test those right now. |
| 18:02 | <AryehGregor> | Slight difficulty in getting to Pr. |
| 18:02 | <AryehGregor> | PR. |
| 18:03 | <TabAtkins_> | For now those'll probably have to be manual tests. :/ |
| 18:03 | <hober> | AryehGregor: but we can enter cr without a test suite, and we drop prefixes at cr-entering time, so there's that |
| 18:03 | <AryehGregor> | Right. |
| 18:03 | <AryehGregor> | TabAtkins_, how can you verify the timing functions are implemented properly even manually? |
| 18:04 | <TabAtkins_> | You can't do so exactly. |
| 18:04 | <AryehGregor> | (FWIW, I'm treating my reftests as manual tests; I wouldn't be surprised if they aren't all pixel-perfect in browsers, and IMO they shouldn't have to be) |
| 18:04 | <TabAtkins_> | But you *can* set up tests that can be eyeballed. |
| 18:05 | AryehGregor | tries to install Windows 8 Developer Preview in a VM inside Ubuntu |
| 18:05 | <TabAtkins_> | Only some properties can be eyeballed in this way. |
| 18:05 | <AryehGregor> | (so I can run IE10) |
| 18:19 | <Velmont> | AryehGregor: How is it going? If installing W8 devpreview is easy, I want to do it as well. To run the IE10, ofc. |
| 18:19 | <AryehGregor> | Velmont, still downloading the .iso. |
| 18:19 | <AryehGregor> | I've installed VirtualBox and set up a VM. |
| 18:19 | <AryehGregor> | Looks easy enough. |
| 18:19 | <AryehGregor> | But I don't know if it will work. |
| 18:19 | <AryehGregor> | (if it does, I can stop using EC2, which would be nice) |
| 18:20 | <bga> | http://www.onemorelevel.com/html-5-vs-flash-games/html5vsflash3.jpeg |
| 18:20 | <Velmont> | AryehGregor: EC2? Not to test IE10 I presume? |
| 18:21 | <AryehGregor> | Velmont, no, I was using it for IE9. |
| 18:21 | <AryehGregor> | Their Windows micro VMs are very cheap, and nowadays even free for the first year if you don't use them too much. |
| 18:24 | <Velmont> | AryehGregor: And you rdesktop to it? |
| 18:24 | <AryehGregor> | Velmont, yes. |
| 18:24 | <AryehGregor> | Much cheaper than a Windows license. |
| 18:25 | <Velmont> | Hmm. Well, my collegaue behind me has a Windows machine he never uses, so I just rdesktop to that one now. Although it throws me or him out, because seemingly windows 7 pro only support one user. |
| 18:28 | <jgraham> | That's how you know it's pro - all professionals get their *own* computer so multiuser support is unneeded |
| 18:28 | <Velmont> | jgraham: Ah. |
| 18:29 | jgraham | is disappointed that the unprefixing conversation was couched entirely in terms of the Process rather than end user benefit |
| 18:32 | <AryehGregor> | jgraham, precisely. |
| 18:32 | <AryehGregor> | I'm starting to get annoyed at the CSSWG. |
| 18:32 | <AryehGregor> | It seems much more bureaucratic and political, and less goal-oriented, than what I'm used to in HTML/DOM stuff. |
| 18:32 | <Velmont> | Hehe, starting sounds like an understatement. :] |
| 18:33 | <AryehGregor> | Oh well. |
| 18:33 | <AryehGregor> | As long as I'm doing useful work. |
| 18:54 | <AryehGregor> | Velmont, seems to be working so far. |
| 18:55 | <AryehGregor> | Good thing I have 8 GB of RAM . . . |
| 18:56 | <AryehGregor> | Ack, swapping! |
| 19:02 | AryehGregor | grumbles |
| 19:02 | <AryehGregor> | Too much memory usage. |
| 19:02 | <AryehGregor> | Shouldn't have tried compiz --replace, though. |
| 19:02 | <AryehGregor> | Even though compiz was using 1.9G resident . . . whatever. |
| 19:03 | <Hixie> | so on the whatwg list there are people asking for an API to help them create a browser hosted by a browser |
| 19:04 | <Hixie> | which is pretty crazy |
| 19:04 | <Hixie> | but then on public-webapps tbl suggests the same thing?! |
| 19:04 | <Hixie> | did we just go straight from january to april??? |
| 19:04 | <Ms2ger> | Isn't that what Mozilla is spending all its time on? |
| 19:12 | <Hixie> | assuming you mean "chromeless", my understanding is that they're not expecting that to just be something any site can just do |
| 19:19 | <AryehGregor> | Velmont, looks like it works fine. |
| 19:28 | <Velmont> | AryehGregor: Cool! Will try it tomorrow then :D |
| 19:58 | AryehGregor | is really, really confused by fixed backgrounds now |
| 21:03 | <roc> | AryehGregor: ping? |
| 21:03 | <AryehGregor> | roc, pong. |
| 21:03 | <roc> | suppose we have a CSS-transformed <span> containing a float |
| 21:04 | <AryehGregor> | roc, 'transform' has no effect on <span> per spec. |
| 21:04 | <roc> | ... oh |
| 21:04 | <AryehGregor> | Whatever question you were about to ask is probably a reason for that to be true. :) |
| 21:04 | <AryehGregor> | roc, https://bugzilla.mozilla.org/show_bug.cgi?id=722463 |
| 21:05 | <roc> | hmm |
| 21:05 | <roc> | will transforms be applicable to flexboxes? |
| 21:05 | <AryehGregor> | I have not the faintest idea. |
| 21:06 | <AryehGregor> | CSS seems like a house of cards to me, with everyone bolting on new features in different places without trying to model them in a unified way, so the interactions between different new pieces are impossible to reason about per spec. |
| 21:06 | <AryehGregor> | Everything has to be special-cased. |
| 21:06 | <AryehGregor> | We really need to remodel CSS from scratch to make it well-defined. |
| 21:07 | <roc> | I totally agree |
| 21:07 | <roc> | regions are the worst example of that right now |
| 21:07 | <hober> | AryehGregor: where will you find a hixie-clone to do that? |
| 21:08 | <roc> | they break existing assumptions in all kinds of ways and no-one seems to care |
| 21:08 | <Hixie> | i've been saying we need to do that for a while now |
| 21:08 | <AryehGregor> | hober, I'd volunteer if I were sure I'd keep working on a regular basis indefinitely (which I probably won't). |
| 21:08 | <AryehGregor> | I'm pretty sure I could do it. |
| 21:08 | <roc> | but this is understandable behavior given the market dynamics |
| 21:08 | <roc> | the market rewards shipping features and not much elese |
| 21:09 | <hober> | AryehGregor: why wouldn't you be working on a regular basis indefinitely? |
| 21:09 | <AryehGregor> | hober, because I'm starting school again soon, probably for a few years. Probably I'll start regular work after that. |
| 21:09 | <hober> | err, that sounded too much like eliza, sorry |
| 21:09 | <Hixie> | the biggest problem is that it'd be politically impossible to do it right now |
| 21:09 | <hober> | AryehGregor: ahh, ok |
| 21:09 | <Hixie> | since the csswg doesn't want to do it |
| 21:09 | <Hixie> | and doing it elsewhere would make the whatwg/htmlwg situation look like a birthday party |
| 21:10 | <AryehGregor> | Unfortunately, the CSSWG is a problem but not as much of one as an XHTMLWG, so it's probably not practical to work around it in the same way. |
| 21:10 | <roc> | I don't think the WG is opposed to it |
| 21:10 | <roc> | it's just that there's no-one to do it |
| 21:10 | <roc> | because everyone in the group either wants to work on new features instead, or is forced by market pressure to do so |
| 21:11 | <AryehGregor> | So for instance: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15834 |
| 21:11 | <gsnedders> | roc: I think some WG members would push back as it'd mean a bunch of things taking longer to REC in all probability |
| 21:11 | <Hixie> | i'm pretty sure that if you said you wanted to start over and define css from scratch, wg members would push back so hard you would find yourself out of the group |
| 21:11 | <AryehGregor> | I just proposed this text: "If the root element is transformed, the transformation applies to the entire canvas, including any background specified for the root element. Since the background painting area <http://dev.w3.org/csswg/css3-background/#background-painting-area>; for the root element is the entire canvas, which is infinite, the transformation might cause parts of the background that were originally off-screen to appear. For example |
| 21:11 | <AryehGregor> | , if the root element's background were repeating dots, and a transformation of scale(0.5) were specified on the root element, the dots would shrink to half their size, but there will be twice as many, so they still cover the whole viewport." |
| 21:11 | <AryehGregor> | That is such ridiculous hand-waving. |
| 21:12 | <AryehGregor> | If we had proper centralized definitions, that would be one short sentence. |
| 21:12 | <roc> | gsnedders: they'd have to be done in parallel. If you stop things going to REC, that just makes everything worse |
| 21:12 | <AryehGregor> | Hixie, I think they can't kick anyone out of the group, can they? But they can refuse to host the spec. |
| 21:13 | <roc> | Hixie: I don't, as long as you promise to be compatible, which if course you would |
| 21:13 | <gsnedders> | roc: Oh, certainly. But I still think there will be a kick-back as it'd divert discussion time and the like, which would thereby delay REC for other things. |
| 21:13 | <Hixie> | well we'll never know since as you say, we don't have a volunteer :-) |
| 21:14 | <AryehGregor> | gsnedders, it wouldn't divert discussion time if someone wanders into a cave for three years and comes back out with a big spec and test-suite that matches implementations and is vastly clearer. |
| 21:14 | <roc> | given the umpteen billion dollars being spent on Web browsers and apps, you'd think we could fund something as critical as this |
| 21:14 | <Hixie> | it's not a funding problem |
| 21:14 | <AryehGregor> | Hey, I'm willing to do it. Just I don't foresee having the time for the next few years. |
| 21:14 | <gsnedders> | AryehGregor: Oh, if you didn't change any conformance requirements, then I agree. |
| 21:15 | <roc> | Hixie: sure it is. With enough funding, we could make Aryeh do it :-) |
| 21:15 | <gsnedders> | But everytime anyone touches anything, from experience, they end up changing conformance requirements they disagree with. |
| 21:15 | <AryehGregor> | gsnedders, only because they don't have the attitude of people like Hixie or me. |
| 21:15 | <AryehGregor> | I.e., match implementations at all costs. |
| 21:15 | <AryehGregor> | Except if they don't agree anyway or are completely insane. |
| 21:16 | <gsnedders> | AryehGregor: Where has the CSS WG gone against that POV? |
| 21:16 | <AryehGregor> | gsnedders, I'm not saying it has. |
| 21:16 | <AryehGregor> | Example of current craziness: I just realized that <table> elements generate two boxes, an inner and an outer one. |
| 21:16 | <AryehGregor> | Thus, *every single thing* that refers to an element's box is ambiguous unless it special-cases tables. |
| 21:16 | <roc> | yeah, that's a good one |
| 21:17 | <roc> | everything that refers to an element's box is ambiguous for lots of reasons |
| 21:17 | <AryehGregor> | Argh. |
| 21:17 | <roc> | elements that have been broken across lines, columns or pages, for example |
| 21:17 | <gsnedders> | AryehGregor: Most things in CSS WG specs that diverge from impls are where impls intend on converging on that behaviour. |
| 21:17 | <roc> | oh, and regions, which introduce additional issues |
| 21:18 | <roc> | and of course, some elements have no box |
| 21:18 | <AryehGregor> | gsnedders, not if the transforms spec is anything to judge by. I've filed 30 bugs in the last month. |
| 21:19 | <gsnedders> | AryehGregor: That spec is in flux, and impls often don't match each other. |
| 21:19 | <AryehGregor> | Implementations match each other almost perfectly for 2D transforms. |
| 21:19 | <AryehGregor> | There are issues like rotate3d() being defined with the angle reversed compared to implementations. |
| 21:19 | <AryehGregor> | Or skew() not being defined at all. |
| 21:19 | <roc> | I am confident that the CSS WG is sold on the idea that specs must match implementations |
| 21:19 | <AryehGregor> | Or transform-origin being defined in two different contradictory ways. |
| 21:19 | <AryehGregor> | roc, yes, that's true. |
| 21:19 | <roc> | on the whole |
| 21:22 | <astearns> | roc: do you see additional breaking problems in regions that aren't already present in multicol? |
| 21:22 | <roc> | oh, in some cases elements generate multiple boxes due to bidi splitting |
| 21:22 | <AryehGregor> | Block elements or just inline? |
| 21:22 | <roc> | inline |
| 21:23 | <roc> | The CSS 2.1 spec recommended table headers and footers being replicated across pages, which leads to multiple boxes per element, but AFAIK no-one except Gecko implements that and we should just remove it |
| 21:23 | <roc> | since it's hellish |
| 21:23 | <gsnedders> | Prince does. |
| 21:23 | <astearns> | that is hellish, but it is something people want to use |
| 21:24 | <roc> | they don't handle DOM changes, which is where it *really* gets hellish |
| 21:24 | <roc> | oh, there's position:fixed elements that need to replicate across pages. I think that is implemented across browsers. More boxes per element |
| 21:25 | <AryehGregor> | In those cases the boxes at least have the same dimensions, right? |
| 21:25 | <AryehGregor> | Or maybe not, especially with transforms . . . |
| 21:25 | <gsnedders> | Yeah. that's implemented cross-browser. |
| 21:25 | <roc> | yes, as long as you don't support per-page styles |
| 21:25 | <gsnedders> | Both WebKit and Presto are buggy around it, though, AFAIK |
| 21:25 | <roc> | oh, but pages have different sizes |
| 21:25 | <roc> | so, no |
| 21:25 | <roc> | sorry :-) |
| 21:25 | <AryehGregor> | Yay. |
| 21:26 | <roc> | another case is block-in-inline situations |
| 21:26 | <AryehGregor> | If I followed my usual way of writing a spec, I'd write a CSS implementation in JavaScript using <canvas> in the course of writing the spec to verify it's correct. :) |
| 21:26 | <roc> | <span>A<div/>B</span> ... the span gets broken into an inline part, an anonymous block part, and an inline part |
| 21:26 | <AryehGregor> | Yeah, this is all fun times. |
| 21:26 | <roc> | you can think of that as a grotesque form of line breaking I suppose |
| 21:27 | <roc> | but it means your boxes don't even all have the same type |
| 21:27 | <roc> | OK, I think I'm done :-) |
| 21:27 | <roc> | astearns: yes |
| 21:28 | <roc> | regions are worse than multicol |
| 21:28 | <AryehGregor> | All of which suggests that I'm wasting my time trying to find corner cases where browsers disagree on exactly how to apply transforms, because it's shooting fish in a barrel and is just going to require zillions of special cases. |
| 21:28 | <roc> | astearns: in multicol, at least each column box has the same parent. with regions that doesn't hold |
| 21:28 | <AryehGregor> | It would be more worthwhile for me to finish up a basic transform test suite for both 2D and 3D, help work out any remaining kinks, and move on to something more productive than CSS until it's rewritten from scratch. |
| 21:29 | <hober> | nonono, your bug-filing on the transforms spec is super useful |
| 21:29 | <hober> | and the test suite work too |
| 21:29 | <roc> | AryehGregor: I think our goal here is to have enough interop and tests to progress to CR |
| 21:29 | <gsnedders> | AryehGregor: No, edge-cases are far more important in layout-land than DOM-land. |
| 21:29 | <roc> | the Web badly needs that |
| 21:29 | <AryehGregor> | hober, I know, but only up to a point . . . |
| 21:29 | <AryehGregor> | roc, well, who decides how many tests are needed for CR? |
| 21:29 | <hober> | s/for/to exit/ |
| 21:29 | <roc> | I'm willing to let you decide :-) |
| 21:30 | <hober> | obviously, only you can choose how to spend your time, but personally I'm very happy that you're making tests and filing bugs wrt transforms |
| 21:30 | <roc> | astearns: the current example I'm harping on is where you have an element that has 'opacity' and needs to get rendered as a single unit. It flows into two regions, and one of the regions is inside an element with its own 'opacity' |
| 21:31 | <AryehGregor> | roc, I spent the last two days or so finding more corner cases. |
| 21:31 | <roc> | astearns: how do you render that? The first element needs to be rendered as a single unit, but it can't be |
| 21:31 | <AryehGregor> | Some are just silly bugs, like Gecko and WebKit mangling transformed file inputs in some cases. |
| 21:31 | <hober> | roc: do two renders of the element with opacity and slice? |
| 21:31 | <AryehGregor> | But some are bugs that arise from the ambiguity of CSS. |
| 21:31 | <roc> | this can't happen with columns since two column boxes can't have different ancestor chains |
| 21:31 | <astearns> | roc: thanks - I don't think we have that as an issue, so I'll add it |
| 21:31 | <AryehGregor> | I grant that the stuff I've done so far remains useful. |
| 21:31 | <gsnedders> | (Bear in mind for CR the main aim is to prove that the whole spec can implemented) |
| 21:31 | <roc> | I've brought it up on the www-style list multiple times |
| 21:32 | <AryehGregor> | But does anyone really want me to file a bug on how browsers behave when a position: fixed element is repeated across multiple pages with different sizes and you transform it? |
| 21:32 | <AryehGregor> | That far doesn't seem very useful to me. |
| 21:34 | <roc> | astearns: forgive me if I come across as a self-righteous prat in the following ... but this is a pattern that I've seen repeated too many times |
| 21:34 | <AryehGregor> | I'd actually be really interested to see how hard it is to start writing a unified CSS spec. Start with just block and inline elements in normal flow with margin/border/padding, that kind of thing. |
| 21:34 | <AryehGregor> | I imagine no one will be willing to pay me to do that, though. :) |
| 21:35 | <jgraham> | Well that is an interesting and testable question |
| 21:35 | <jgraham> | Is nyone prepared to pay AryehGregor enough to rewrite CSS |
| 21:36 | <roc> | astearns: a) vendor(s) rush to implement a feature and "get it out there" (probably prefixed) b) lots of corner cases are ignored c) the Web starts to depend on the (prefixed) feature c) later spec writers and/or other implementors try to implement, discover feature makes no sense d) those people get to clean up the mess while implementors a) move on to the next feature |
| 21:36 | <AryehGregor> | Well, I don't have time to fully rewrite it just yet, only to do a very basic start. |
| 21:36 | <AryehGregor> | So it wouldn't be of much use to anyone. |
| 21:36 | <AryehGregor> | I hope someone will be willing to pay me to do it someday, if no one else beats me to it. |
| 21:36 | divya | starts a kikstarter project |
| 21:36 | <divya> | kickstarter even |
| 21:37 | <jgraham> | Well they would have to pay you enough that you were prepared to keep working on it rather than do whatever else you had in mind |
| 21:37 | <jgraham> | :) |
| 21:37 | <AryehGregor> | The problem is, my desire for money is finite relative to the other things I want to do. So you'd just encourage me to work fewer hours if you paid me more per hour. |
| 21:37 | <astearns> | roc: no worries, I agree with you. I want to get all the corner cases considered (and get implementation feedback from mozilla and opera) |
| 21:41 | <roc> | hober: that might work |
| 21:41 | <roc> | for opacity |
| 21:42 | <roc> | in fact, duplicating the rendering might work in general |
| 21:43 | <roc> | but it's hard to be sure |
| 21:46 | <jgraham> | In unrelated news, developing webaps seems to kind of suck. I mean there is lots of - what seems to be - accidential complexity. If you want to do something "simple" like sync the state of some controls with a server using ajax it isn't really obvious what the right choices are for storing the data, or for organising the code. |
| 21:47 | <divya> | its why people use frameworks |
| 21:47 | <jgraham> | Well yes |
| 21:48 | <jgraham> | But there is a major paradox of choice issue there |
| 21:48 | <divya> | yeah :( |
| 21:48 | <jgraham> | and it's not really clear what works with what other things |
| 21:49 | <divya> | yeah true enough, we have a surfeit of frameworks and not enough understanding of what does what and when |
| 21:53 | <jgraham> | The only thing that everyone seems to use is jQuery. Which is better than DOM I guess, but it does make me feel a bit... unclean, perhaps. Because everything seems to be based on magic and string manipulation. And having all these things that are sometimes wrapped in magic jQuery stuff and sometimes have the underlying implementation leak through |
| 21:53 | <astearns> | roc: bug stub at https://www.w3.org/Bugs/Public/show_bug.cgi?id=15835 (with your latest list comment) |
| 21:53 | <roc> | actually I think Vincent Hardy just responded to my email by filing his own bug :-) |
| 21:54 | <jgraham> | I guess my perspective on that is very unusual though since I know DOM rather well and jQuery rather poorly whilst most webdevs are the exact opposite |
| 21:54 | <astearns> | bah |
| 21:55 | <divya> | jgraham: ha true. but jQuery is hardly enough for these webapps |
| 21:55 | <roc> | yes, it's always good to check the latest messages on the mailing list before going off on a rant :-) |
| 21:57 | <astearns> | actually, they might be separate bugs. Vincent's is about stacking contexts, which could be specified without addressing opacity/filters directly |
| 21:57 | <roc> | ok |
| 22:07 | <jgraham> | divya: Right. That is tidying up the platform. The next level where there are relatively high-level primitives for writing complex applications seems to be missing |
| 22:08 | <jgraham> | This is not a new observation, obviously |
| 22:08 | <divya> | yeah everyone seems to have their own idea of what that would look like :( |
| 22:08 | <divya> | hence the fragmentation |
