| 00:49 | <dglazkov> | monkey flies |
| 01:02 | <Philip`> | Do monkey flies like a banana? |
| 07:56 | <Hixie> | MikeSmith: did you still need me to regen the spec? i flushed my edit out finally. |
| 07:56 | <Hixie> | though it looks like i'm getting conflicts or something |
| 07:56 | <Hixie> | an the w3c side |
| 07:57 | <MikeSmith> | that's because I checked in some changes |
| 07:57 | <Hixie> | ah ok |
| 07:57 | <MikeSmith> | but please just overwrite them |
| 07:57 | <MikeSmith> | the changes were just stuff I needed for publishing the WD |
| 07:57 | <Hixie> | oh you just hard-psuhed it? k |
| 07:57 | <MikeSmith> | yeah |
| 07:57 | <Hixie> | that works too i guess! |
| 07:57 | <Hixie> | :-) |
| 07:58 | <MikeSmith> | :) |
| 07:58 | <MikeSmith> | anyway, there's no urgency on doing the regen -- I had just pinged you because I was prepping stuff for the WD publication |
| 07:59 | <MikeSmith> | but hey, before you do regen I guess we should flip the boilerplate back to ED |
| 07:59 | <MikeSmith> | so I will do that right now |
| 07:59 | <Hixie> | k |
| 07:59 | zcorpan | intends to leave the html5-differences ED as saying WD |
| 08:00 | <MikeSmith> | zcorpan: I don't think you're supposed to do that… |
| 08:01 | <zcorpan> | will something bad happen if i do? |
| 08:01 | <MikeSmith> | only to me |
| 08:02 | <zcorpan> | it's identical to the WD, i'll only make changes to it when the next publication is near |
| 08:02 | <MikeSmith> | hmm |
| 08:02 | <MikeSmith> | OK |
| 08:03 | <MikeSmith> | …until if/when plh or somebody tells me to change it |
| 08:03 | <zcorpan> | (it said WD before i edited it too) |
| 08:03 | <MikeSmith> | yeah, I know |
| 08:03 | <MikeSmith> | but that wasn't totally intentional |
| 08:03 | <zcorpan> | let me know if somebody whines, i'll change it |
| 08:03 | <MikeSmith> | hai |
| 08:10 | <Hixie> | MikeSmith: i'm going to bed now, will fix the conflicts in the morning |
| 08:10 | <MikeSmith> | ok |
| 08:11 | <MikeSmith> | I'll have the boilerplate changes checked in by your morning |
| 08:11 | <MikeSmith> | nn |
| 09:13 | <hsivonen> | another day, another RDFa advocacy namedropping debunked |
| 09:13 | <zcorpan> | lack of contact information or bug tracker, i'll whine here that http://checkmybrowser.appspot.com/index.html checks for 'manifest' in document.documentElement while the spec explicitly omits that IDL attribute |
| 09:15 | <hsivonen> | zcorpan: whoa! manual tests |
| 09:18 | <jgraham> | hsivonen: I wonder if it is even allowed to reply to the RDFa thing on the list |
| 09:22 | <jgraham> | But it it is interesting to note that if the contention that RDFa will be mostly generated bt machines is true (and I note that HTML is mostly generated by machines but is still all kinds of crazy), it suggests that just using raw URIs is fine |
| 09:24 | <hsivonen> | jgraham: indeed |
| 09:30 | <hsivonen> | jgraham: it is even more interesting considering that reasoning is supposed to be what RDF is all about |
| 11:01 | zcorpan | filed https://bugs.webkit.org/show_bug.cgi?id=58129 |
| 11:08 | <jgraham> | I wonder if those google tests are useful tests or just test for support of things without checking if it works |
| 11:09 | <jgraham> | In the former case it would be nice if they would contribute to the appropriate testsuite |
| 11:18 | <jgraham> | Looks like there could be some useful stuff there |
| 14:07 | <miGlanz> | hi guys, I have a question about WebSockets status |
| 14:08 | <miGlanz> | They were disabled in Firefox 4 and Opera because of security flaw in the protocol |
| 14:08 | <jgraham> | Yes, no |
| 14:08 | <miGlanz> | but mr Barth who described the vulnerability also proposed solution to the problem |
| 14:08 | <jgraham> | (I mean yes they were disabled, no I don't know of any timescales for implementation of the next version of the protocol) |
| 14:09 | <jgraham> | (which fixes the issue) |
| 14:09 | <jgraham> | (if that wasn't what you were going to say, please continue :) |
| 14:09 | <miGlanz> | so for now nobody knows when FF4 and Opera will support those, right? |
| 14:10 | <jgraham> | No |
| 14:10 | <bga_> | back to steel infinite iframe |
| 14:10 | <bga_> | :) |
| 14:10 | <miGlanz> | but in your opinion is it closer to 1 year or let's say 5 years? |
| 14:11 | <jgraham> | Closer to 1 year |
| 14:11 | <jgraham> | I hope |
| 14:11 | <gsnedders> | Some time within the next year, almost certainly |
| 14:12 | <jgraham> | gsnedders: That's youthful optimisim |
| 14:12 | <gsnedders> | jgraham: Hey, my birthday is in under two weeks. I'm getting older! |
| 14:13 | <jgraham> | There's a non-sequiter if ever I heard one |
| 14:13 | <miGlanz> | so one may simply use current Flash workaround and hope it gets native within reasonable timeframe |
| 14:13 | <miGlanz> | (of course, from what I understand, Flash solution is vulnerable too) |
| 14:14 | <jgraham> | Indeed. |
| 14:14 | <Philip`> | (I think you spelt secateur wrong) |
| 14:14 | <miGlanz> | OK, thanks guys, it doesn't sound great, but it's not that bad either |
| 14:18 | <bfrohs> | (or sequitur :P) |
| 14:19 | <jgraham> | gsnedders: He's no use whatsoever for pruning |
| 14:21 | <gsnedders> | :P |
| 14:26 | <hsivonen> | miGlanz: of course, Flash sockets can be used to exploit the same flaw in transparent proxies... |
| 14:31 | <miGlanz> | yes, I'm aware of this |
| 14:32 | <miGlanz> | hmm, but on the other hand, I'm curious why hasn't Google disabled WebSockets in Chrome yet? |
| 14:35 | <hsivonen> | dunno. maybe because it's no more dangerous than running with Flash. |
| 15:10 | <bga_> | is it possible to call xhr.send(partialData) multi time? i want to send big amount of data streamed and using only one connection |
| 15:47 | <Philip`> | "the HTML Working Group hereby adopts the "Defer to the Microformats community for cataloging HTML rel values" Proposal" |
| 15:48 | Philip` | objects to that proposal, on the basis that the word "cataloging" looks weird and ought to be spelt "cataloguing" |
| 15:49 | <hsivonen> | \o/ |
| 16:54 | <TabAtkins> | Philip`: Why are you spelling it "spelt"? It's spelled "spelled". Crazy irregular conjugations. |
| 16:57 | <gsnedders> | TabAtkins: en-gb normally uses "spelt" |
| 16:58 | <TabAtkins> | I repeat, "crazy irregular conjugations". |
| 17:07 | bfrohs | thinks someone needs to properly spec the English language |
| 17:08 | <TabAtkins> | I'll spec the 'Mrrican language. |
| 17:10 | <TabAtkins> | Sigh. This email I just sent has an average word length of, like, 8. |
| 17:10 | <TabAtkins> | When I can't be polite, I just turn technical. >_< |
| 17:10 | <TabAtkins> | /verbose |
| 17:13 | beowulf | collides a wet Salmonidae with TabAtkins upper rostral area |
| 19:18 | <Philip`> | "the HTML Working Group hereby adopts the "<u> should be conforming" Change Proposal" |
| 19:18 | <TabAtkins> | Sigh. |
| 19:18 | <Philip`> | "the HTML Working Group hereby adopts the "Consider inability to play at a given playback rate a hardware limitation and don't expose it via a dedicated API" Change Proposal" |
| 19:20 | <AryehGregor> | Yay! |
| 19:20 | <AryehGregor> | (to "<u> should be conforming") |
| 19:20 | <AryehGregor> | I bet that would be the result. |
| 19:20 | <TabAtkins> | Well, it woudl be weird to bet against yourself. |
| 19:20 | <AryehGregor> | No, it could have been that I thought I would lose but felt it necessary to try anyway just in case. |
| 19:22 | <Philip`> | It's always good to bet against yourself, because either you're right or you win, so you win both ways |
| 19:23 | <AryehGregor> | On this one I was pretty sure I'd win, since the arguments against were vague and not supported by specific evidence or reasoning. |
| 19:24 | <AryehGregor> | You've got to know how to game the system. The chairs strongly favor specific arguments and reasoning, and tend not to like arguments that amount to simply making disputed assertions. |
| 19:24 | <AryehGregor> | So when I object, I always make sure to dispute everything that doesn't have specific evidence in its favor (assuming I actually disagree with it). |
| 19:25 | <TabAtkins> | ...every single argument in <u>'s favor here can be applied equally to <font>, as far as I can tell. |
| 19:26 | <AryehGregor> | No, I specifically addressed that. |
| 19:26 | <AryehGregor> | 1) <font> is less of a length savings, 2) it uses behavior that's not fully specified by CSS. |
| 19:26 | <zewt> | what hardware is there that might support audio without having the horsepower for simple resampling, anyway |
| 19:26 | <AryehGregor> | Also, you don't have the argument of similarity to <b> and <i>. |
| 19:26 | <AryehGregor> | Also, maybe <font> should be made valid, that's not the question at hand (although I think it shouldn't because of the CSS incompatibility). |
| 19:27 | <AryehGregor> | (<font face=""> might be CSS-compatible, I guess. But not size or color.) |
| 19:27 | <TabAtkins> | Other than the legacy parsing concerns, why isn't @color css-compatible? |
| 19:27 | <TabAtkins> | And @size *almost* is. |
| 19:27 | <AryehGregor> | Because of the legacy parsing, that's the only reason. |
| 19:28 | <TabAtkins> | Man, that's basically a quirk. |
| 19:28 | <AryehGregor> | It has significant implications, like it doesn't support alpha. |
| 19:28 | <Philip`> | zewt: I think the issue is more about video than audio |
| 19:28 | <AryehGregor> | Size is totally not CSS-compatible, it uses an entirely different way of writing things. There's a mapping for all but one of the sizes to CSS sizes, but it's still different syntax. |
| 19:28 | <AryehGregor> | (plus there's no mapping for that last size, although I dunno why CSS doesn't just fix that) |
| 19:29 | <zewt> | oh right, that |
| 19:29 | <TabAtkins> | AryehGregor: <font color> certainly does support alpha in Webkit. |
| 19:29 | <TabAtkins> | Just put rgba() in it. ^_^ |
| 19:30 | <AryehGregor> | TabAtkins, then maybe the spec should be changed . . . http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#rules-for-parsing-a-legacy-color-value |
| 19:30 | <AryehGregor> | But the error handling would still be different. It's not just shorthand for CSS, it has additional processing rules. |
| 19:31 | <TabAtkins> | Likely so. Pretty sure we just hand the value to the CSS engine to parse as a color. |
| 19:31 | <AryehGregor> | If that's actually web-compatible, what the heck is up with the spec? |
| 19:31 | <AryehGregor> | You've got to at least do some preprocessing, no? |
| 19:31 | <TabAtkins> | At least, my patch to allow 4/8 hexit colors affected the parsing of <font>. |
| 19:32 | <AryehGregor> | Anyway, the only reason I support things like <u> is as shorthands, so it's not worth it nearly as much when it's <span style=color:red> vs. <font color=red>. |
| 19:32 | <AryehGregor> | At that point you may as well accept the slight increase in length for the sake of simplicity. |
| 19:32 | <TabAtkins> | We appear to support #-less hex colors. |
| 19:32 | <AryehGregor> | I did write all these arguments down, you know, and you were given a week to address them. |
| 19:32 | <AryehGregor> | What do you do with things like <font color=aaa> or <font color=aaaaaaaaa>? |
| 19:33 | <TabAtkins> | AryehGregor: I figured they were adequately answered by the consistency argument. |
| 19:33 | <TabAtkins> | aaa is gray, as is a{6+} |
| 19:33 | <AryehGregor> | I specifically addressed the consistency argument, at considerable length. |
| 19:33 | <AryehGregor> | In the CP I contributed to. |
| 19:34 | <AryehGregor> | Since I knew Hixie would object on the basis of consistency. |
| 19:34 | <TabAtkins> | And I disagree with how you did so. Shrug. |
| 19:34 | <AryehGregor> | Well, you had a chance to say why, and you didn't. Anyway, that's that. |
| 19:34 | <TabAtkins> | This is why I hate the decision process. I'm not *supposed* to say anything if I think my objection is already covered. |
| 19:35 | <AryehGregor> | Who covered it? |
| 19:35 | <TabAtkins> | Hixie. |
| 19:35 | <AryehGregor> | I didn't see anyone addressing my arguments in detail. |
| 19:35 | <AryehGregor> | Hixie wrote like three paragraphs. |
| 19:35 | <TabAtkins> | Because it's a silly issue that shoudl only need that much effort. |
| 19:35 | <AryehGregor> | The only detailed objection was the one about usability. |
| 19:35 | <AryehGregor> | Well, then I guess the ones who care about it more win. |
| 19:36 | <AryehGregor> | Long live presentational markup! |
| 19:36 | <TabAtkins> | Yup. Decision through exhaustion. |
| 19:36 | <TabAtkins> | You just haven't been established as a troll yet. ^_^ |
| 19:36 | <AryehGregor> | That's the great thing about the decision process, even trolls get to have their say. |
| 19:37 | <TabAtkins> | That's... not a great thing. |
| 19:37 | <AryehGregor> | We should totally argue that <title> needs to be invalid, and write a pages-long proposal that cogently addresses every possible objection. |
| 19:37 | <AryehGregor> | Debate club style, you know? |
| 19:37 | <TabAtkins> | I'll get right on that. |
| 19:37 | <AryehGregor> | I've never been very good at writing persuasive pieces that I don't actually agree with, sadly. |
| 19:38 | <AryehGregor> | (or maybe not sadly) |
| 19:38 | <AryehGregor> | (maybe it means I'm honest, could be a good thing) |
| 19:38 | <Philip`> | <marquee> is quite widely used and much simpler than any CSS equivalent - maybe it should be added next |
| 19:38 | <AryehGregor> | Philip`, does it have a CSS equivalent? |
| 19:38 | <TabAtkins> | Yes, the Marquee spec. |
| 19:38 | <AryehGregor> | Is it implemented? |
| 19:38 | <TabAtkins> | But <marquee> is *much* shorter. |
| 19:38 | <TabAtkins> | On some mobile phones, yes. |
| 19:38 | <Philip`> | http://www.w3.org/TR/css3-marquee/ |
| 19:39 | <AryehGregor> | I'd say it should be implemented first. |
| 19:39 | <AryehGregor> | Also, how often do people actually want to use marquees? |
| 19:39 | <AryehGregor> | I'd say we should make <marquee> invalid because the effect is annoying, like <blink>. |
| 19:39 | <Philip`> | In certain countries, very frequently |
| 19:39 | <AryehGregor> | Not to mention it's way, way, way more marginal than <u>. |
| 19:39 | <AryehGregor> | Ah, well, we have to be multicultural, right? |
| 19:39 | <TabAtkins> | I think <u> is annoying. :/ |
| 19:39 | Philip` | thinks it was probably .kr or something |
| 19:40 | <AryehGregor> | Sounds plausible. |
| 19:40 | <AryehGregor> | East Asian sites always seem to look more eye-smarting and flashy than I'm used to. |
| 19:40 | <AryehGregor> | Bright contrasting colors and such. |
| 19:41 | <Philip`> | Oh, no, it was .cn |
| 19:41 | <Philip`> | http://krijnhoetmer.nl/irc-logs/whatwg/20080320#l-733 |
| 19:42 | <Philip`> | <u> is on less than 10% of pages |
| 19:42 | <Philip`> | so <marquee> beats it easily in .cn, seemingly |
| 19:44 | <AryehGregor> | You need to check if <u> is used more often too, though. The Chinese are the ones who want it for semantic purposes, right? |
| 19:44 | <zewt> | the greatest thing javascript has given pages is the ability to create marquees, even when the user deliberately disables them in his browser |
| 19:44 | <zewt> | down with explicit user preferences! |
| 19:44 | <TabAtkins> | The argument was that, no, the Chinese dont' actually use <u> for sematnic purposes on the web. |
| 19:44 | <TabAtkins> | zewt: No, the greatest thing javascript has given us is the ability to create marquees *in the address bar*. |
| 19:45 | <zewt> | FFFFFFFFF |
| 19:45 | <AryehGregor> | . . . how does that work? |
| 19:45 | <zewt> | replaceState |
| 19:45 | <TabAtkins> | replaceState |
| 19:45 | <zewt> | ^5 |
| 19:45 | <AryehGregor> | Wow. |
| 19:45 | <zewt> | heh |
| 19:45 | <AryehGregor> | That's like Asteroids in your favicon. |
| 19:45 | <TabAtkins> | There are even browser games in the address bar now. |
| 19:45 | <AryehGregor> | Or whatever it was. |
| 19:45 | <AryehGregor> | :/ |
| 19:45 | <AryehGregor> | Link? |
| 19:46 | <zewt> | does FF4 still play animated gifs in tabs? that's seriously annoying when it happens, heh |
| 19:46 | <TabAtkins> | http://probablyinteractive.com/url-hunter |
| 19:46 | <Philip`> | AryehGregor: 377 pages in .cn: 101 have a <marquee>, 14 have a <u> |
| 19:47 | <Philip`> | (7 have <i>, 116 have <b>) |
| 19:47 | <AryehGregor> | TabAtkins, that has serious responsiveness problems in Chrome. Should I file this as a QoI issue in replaceState()? |
| 19:47 | <TabAtkins> | Yes. |
| 19:47 | <AryehGregor> | Philip`, I was about to say "interesting", but I think "frightening" is more apropos. |
| 19:47 | <AryehGregor> | TabAtkins, . . . I was joking. |
| 19:48 | <TabAtkins> | Do it anyway. |
| 19:48 | <Philip`> | These all seem to be distinct sites too, not just pages of a single site |
| 19:48 | <zewt> | browsers should pause any history-api-based changes to the address bar when the user focuses it, but I think many don't yet |
| 19:48 | <AryehGregor> | Firefox also does a lousy job. Only Opera works well. |
| 19:49 | <TabAtkins> | Yeah, I can't copy-paste from the url bar while the game is going. |
| 19:49 | <AryehGregor> | Go Opera! Paving the way in enabling gratuitous misuse of browser UI! |
| 19:49 | <AryehGregor> | I can in Opera. |
| 19:50 | <AryehGregor> | Opera also uses much less CPU. |
| 19:50 | <AryehGregor> | I'm impressed. |
| 19:51 | <AryehGregor> | This is surely the best completely useless advantage Opera has over other browsers that I've seen. |
| 19:51 | <AryehGregor> | Just goes to show their commitment to quality. |
| 19:52 | <Philip`> | http://www.forestry.gov.cn/ - they do seem to like random scrolling bits |
| 19:52 | <Philip`> | Also: boxes that bounce around the screen (!) |
| 19:52 | <zewt> | well, it also is better about making sure the history api doesn't interfere with the user trying to use the address bar--that's a very solid advantage |
| 19:52 | <AryehGregor> | Yes, that's true. |
| 19:53 | <AryehGregor> | Philip`, the thing is, I can't be sure I'm viewing it as it's intended to be viewed unless I use IE. |
| 19:53 | <AryehGregor> | . . . wow, it really does have a box bouncing around the screen for no apparent reason. |
| 19:53 | <TabAtkins> | Chrome does the marqueeing right, at least. |
| 19:54 | <AryehGregor> | I'd try to translate it, but of course, the text is an image. |
| 19:54 | <AryehGregor> | Nice how the site uses 100% CPU. |
| 19:54 | <Philip`> | That might be Flash |
| 19:54 | <AryehGregor> | And takes like 20 seconds to load. |
| 19:55 | <AryehGregor> | Wow, in Firefox it's totally broken. |
| 19:55 | <AryehGregor> | Oh, no it's not. |
| 19:55 | <AryehGregor> | It was just loading. |
| 19:55 | Philip` | missed out on the Flash lens-flare experience when first loading the page since he has plugins disabled |
| 19:55 | <AryehGregor> | Hmm, yes it is. The box doesn't bounce. :( |
| 21:07 | <TabAtkins> | Woo, just spent basically two days fully absorbing the SVG Compositing spec. |
| 21:08 | <TabAtkins> | But I think it produced some quality feedback. |
| 21:10 | <Hixie> | AryehGregor: i actually countered all your comments on www-archive |
| 21:10 | <AryehGregor> | Hixie, I didn't see. Apparently the chairs didn't either. |
| 21:10 | <Hixie> | no comment |
| 21:10 | <AryehGregor> | I'd go and look, but I've had enough of underline arguments for a while. |
| 21:10 | <Hixie> | (it was linked to from my poll answer) |
| 21:11 | <AryehGregor> | It was? Did you add it later? |
| 21:11 | <Hixie> | yeah |
| 21:11 | <AryehGregor> | Ah, okay. Maybe the chairs did see it and I just didn't recognize the quote. |
| 21:11 | <Hixie> | i haven't read sam's e-mail to see if he actually read any of it |
| 21:11 | AryehGregor | is actually in the middle of an entirely different underline argument, on www-style |
| 21:12 | <TabAtkins> | "Marketing Automation" is a pretty cool euphemism for "spam". |
| 21:12 | bfrohs | agrees |
| 21:12 | TabAtkins | just blocked a spammer who used that phrase in their twitter bio. |
| 21:17 | <TabAtkins> | AryehGregor: I'm playing with it a bit more in the live dom viewer. Our <font color> error-handling is totally weird, and doesn't match the spec basically at all. |
| 21:18 | <TabAtkins> | That's not quite accurate; we do match it in some ways. |
| 21:18 | <TabAtkins> | Oh, never mind, okay, I get it. |
| 21:19 | <TabAtkins> | The place where we part ways from the spec is in step 5 and 6. We just check if it's a valid CSS color at all - if so, we interpret it as such. If not, we toss it through the spec algorith (at least, as far as I can tell - I haven't tested all the algo corner cases) |
| 21:28 | <AryehGregor> | Does this cause any compat issues? If not, it would be nice if the spec could be changed to allow that. |
| 21:31 | <TabAtkins> | No clue. Presumably not very large, or else we would have changed it. |
| 21:31 | <TabAtkins> | I'll raise it on the list. |
| 21:44 | <AryehGregor> | TabAtkins, how often have you run into cases where underlines in CSS wind up being the wrong color and you'd have really preferred they match the color of the text they're under? |
| 21:45 | <AryehGregor> | (Apropos to the discussion on www-style. I'm asking you because you have a lot more design experience than me.) |
| 21:45 | <TabAtkins> | I've never underlined anything that isn't a link or a heading. In neither case have I ever had such a problem. |
| 21:45 | <AryehGregor> | k. |
| 21:46 | <AryehGregor> | I've sometimes linked things that are colored differently, so I got a blue underline under different-colored text. |
| 21:46 | <TabAtkins> | Neither my links nor my headings tend to have much structure inside of them, though. |
| 21:46 | <AryehGregor> | anolis does that by default for some reason, although actual anolis users seem to have mostly disabled it. |
| 21:46 | <AryehGregor> | Including HTML5. |
| 22:01 | <TabAtkins> | Aw, no fun. On the version of Chrome I have at home, using a partially-transparent color in svg (maybe just svg-in-html) makes the inspector report the color oddly, as an opaque color with an extra two hexits hanging off the end. |
| 22:02 | <TabAtkins> | Like rgb(255,0,0)80 for half-opaque red. |
| 22:02 | <TabAtkins> | But my work version doesn't do it. ;_; |
| 22:02 | <zewt> | heh |
| 22:02 | <zewt> | one of those embarrassingly-obvious bugs |
| 22:03 | <TabAtkins> | It was funny seeing it as #f0080. |
| 22:31 | <jgraham> | Hixie: The current outline spec really doesn't seem that amenable to easy selector implementation since you always have to consider the possibility of <h2>-<h6> changing the depth |
| 22:31 | <Hixie> | it can't change the depth of a <section> element |
| 22:31 | <jgraham> | I'm not saying I disapprove of the current spec, I just disagree with your statement |
| 22:32 | <jgraham> | No, but given an element it can change what outline depth it is at |
| 22:34 | <Hixie> | given an element other than a sectioning element an an <h1> element, absolutely. |
| 22:35 | <Hixie> | not much we can do about that if you want to be backwards compatible, but luckily there are few use cases for applying such a selector in those cases |
| 22:35 | <Hixie> | and there's an easy workaround |
| 22:35 | <Hixie> | (not using <h2>-<h6>) |
| 22:37 | <jgraham> | For the author, sure, not really for the browser implementor |
| 22:38 | <Hixie> | why would browser implementors need such a selector for anything other than <h1>? |
| 22:38 | <jgraham> | I mean you can special case <h1> but you still need a slow-case |
| 22:38 | <Hixie> | i don't understand |
| 22:38 | <jgraham> | I mean when implementing the selector |
| 22:38 | <jgraham> | It has to work for any author input |
| 22:39 | <Hixie> | oh, i see. i'm saying to not do that. just do a selector that counts the number of elements of a given type in the ancetor chain. |
| 22:39 | <Hixie> | there's no use case for a generic outline algorithm selector, don't even consider doing one |
| 22:39 | <Hixie> | it would be a perf disaster |
| 22:39 | <jgraham> | The use case seems obvious |
| 22:39 | <Hixie> | oh? |
| 22:40 | <jgraham> | Without it, there is very little use case for a generic outline algorithm |
| 22:40 | <Hixie> | the generic outline algorithm's use case is anolis |
| 22:40 | <Hixie> | that's about it |
| 22:40 | <Hixie> | (anolis and other such systems that generate tables of contents) |
| 22:40 | <Hixie> | certainly not styling |
| 22:40 | <jgraham> | In particular the classic example where you aggregate content from multiple sources on a single page |
| 22:40 | <TabAtkins> | Also: my blog, since I use h1-6 inside a post, and h1 outside. |
| 22:40 | <jgraham> | and they all use headings differently |
| 22:41 | <jgraham> | And you want consistent styling |
| 22:41 | <Hixie> | well that's an html4 issue, nothing to do with the new outlining algorithm |
| 22:41 | <jgraham> | Huh? |
| 22:42 | <Hixie> | if you want to be able to style the old-style <h2>-<h6> implied sections, then the perf issues of that were introduced years ago. in, like, tbl's "html markup" paper. |
| 22:42 | <Hixie> | that's why we introduced <section> and <h1>, so that you could style things |
| 22:42 | <Hixie> | since the perf issue of h2-h6 make them untractable |
| 22:43 | <jgraham> | That was never mentioned as a reason at the time |
| 22:43 | <jgraham> | Unless my memory has entirely failed |
| 22:44 | <Hixie> | the whole point of <section>/<h1> is that it lets the browser take care of styling the <h1> on the basis of the nesting level |
| 22:44 | <jgraham> | But use cases like aggregating content were extensivly discussed |
| 22:44 | <Hixie> | that's another way of phrasing the same use case |
| 22:44 | <jgraham> | Not at all |
| 22:45 | <jgraham> | It specifically requires that you can mix different styles of markup in the same document |
| 22:45 | <Hixie> | i don't really understand what we're arguing here. |
| 22:45 | <jgraham> | Not that you force a particular style for the CSS to work |
| 22:46 | <jgraham> | I'm arguing that selectors that work with the outline depth have to work with the full algorithm, even if they are only performant in special cases |
| 22:47 | <Hixie> | my main point here is that the outline depth algorithm is certainly not expected to be used in a perf-sensitive situation such as selectors, and that doing so is a lost cause; the algorithm is just designed to reflect the actual semantics of the page for semantic analysis like creating TOCs; and the design of that algorithm is constrainted by history. |
| 22:47 | <Hixie> | the new elements were specifically designed so that they could be styled in a performant manner |
| 22:47 | <Hixie> | that's all |
| 22:48 | <jgraham> | I agree with all but the first point |
| 22:48 | <TabAtkins> | So would you consider it okay to have a :heading(n) selector *only* pay attention to <section>/<h1>? |
| 22:48 | <TabAtkins> | Or top-level <h1-6>? |
| 22:48 | <Hixie> | i wouldn't consider :heading(n) to be a good idea regardless |
| 22:49 | <jgraham> | (I also think the "selectors can't be slow" thing has been overdone. Many other things that authors willingly do are slow. We don't have to refuse to provide selectors on the basis of perf. unless it is unreasonably slow) |
| 22:49 | <Hixie> | but then i consider the use case of styling content that uses h2-h6 at different depths in an aggregation context to be a lost cause itself |
| 22:50 | <Hixie> | better to use the outline depth algorithm in the aggregator to generate consistent headings |
| 22:50 | <Hixie> | and then just use regular css |
| 22:51 | <Hixie> | jgraham: slow selectors are a huge problem, because they are trivial to use in dramatically bad ways, and only UAs that implement them get screwed, and authors have no idea why. |
| 22:51 | <Hixie> | jgraham: and the problem only exhibits itself in real documents, not in test documents which the authors are using when writing their style sheets |
| 22:52 | <jgraham> | It seems quite like that applies to many kinds of scripts as well |
| 22:53 | <Hixie> | and we're going crazy trying to make js faster, to the point of introducing background workers |
| 22:53 | <Hixie> | and never introducing sync APIs |
| 22:53 | <Hixie> | there's only so much we can do about existing issues |
| 22:54 | <Hixie> | but we shouldn't introduce new ones |
| 22:54 | <jgraham> | None of that is really relevant to the fact that jQuery has a parent selector and CSS does not |
| 22:54 | <jgraham> | I mean a faster js engine will help a bit |
| 22:54 | <jgraham> | But it is mostly DOM speed |
| 22:54 | <AryehGregor> | jQuery doesn't have to evaluate selectors anywhere near as often as CSS. |
| 22:55 | <AryehGregor> | Browsers could have a parent selector for querySelector(), but not for actual stylesheets. |
| 22:55 | <jgraham> | It depends what you are doing with it |
| 22:55 | <AryehGregor> | Or so I've been told. |
| 22:55 | <AryehGregor> | Plus, parent selectors break incremental rendering arbitrarily badly. |
| 22:56 | <Hixie> | so does :last-child, to be fair |
| 22:56 | <AryehGregor> | (although I guess :nth-child with negative numbers can be pretty bad too) |
| 22:56 | <AryehGregor> | :last-child is fairly limited in the damage it can do. |
| 22:56 | <Hixie> | fair enough |
| 22:56 | <jgraham> | Anyway I am not arguing for parent |
| 22:57 | <Hixie> | you brought it up :-) |
| 22:57 | <jgraham> | I don't think outline selectors have the same level of problems |
| 22:57 | <Hixie> | well if you want to put the outline algorithm into a css selector implementation, be my guest :-) |
| 22:57 | <Hixie> | i don't think other UAs will rush to follow though :-) |
| 22:57 | <jgraham> | At least the mutations that affect them are rather constrained |
| 22:59 | <TabAtkins> | "section section h1" is a pretty bad selector to use instead of ":heading(3)". :/ |
| 22:59 | <jgraham> | But I could be wrong |
| 22:59 | <TabAtkins> | (Sorry I'm late with the response - I was shanghaid into a standards discussion.) |
| 23:00 | <Hixie> | TabAtkins: i'm thinking more something like h1:ancestor-count(:matches(section, article, nav, aside), 3) |
| 23:01 | <TabAtkins> | Holy jeezus, no wonder you're concerned about performance. |
| 23:01 | <Hixie> | (though not specifically that) |
| 23:01 | <Hixie> | actually that one would be really fast |
| 23:02 | <Hixie> | it just has to do a count on the ancestor chain, applying a cachable selector at each level |
| 23:02 | <Hixie> | that's amongst the fastest selectors we have |
| 23:02 | <TabAtkins> | It's as fast as a descendant selector is in anyone except current Webkit. |
| 23:02 | <Hixie> | my point re performance was regarding something that had to implement the outline algorithm, which is a whole different level of perf pain |
| 23:03 | <Hixie> | little slower that descendant selector, but trivially so probably, yeah |
| 23:03 | <TabAtkins> | Seems to be no more painful than namespaces. ^_^ |
| 23:03 | <Hixie> | well the above wasn't a concrete proposal |
| 23:03 | <Hixie> | i just meant that we should provide generic tools, not something hard-coded for HTML |
| 23:03 | <TabAtkins> | I think we should provide both. |
| 23:03 | <Hixie> | hard-coding for HTML is only a good idea when the alternative is completely out of control or impossible |
| 23:04 | <Hixie> | but anyway |
| 23:04 | <Hixie> | i trust y'all to do a good job here |
| 23:05 | <TabAtkins> | I submit that h1:ancestor-count(:matches(section, article, nav, aside), 3) is completely out of control. |
| 23:06 | <Hixie> | that was just an indication of the general intent, not a concrete proposal |
| 23:06 | <TabAtkins> | Dunno how you'd make a general ability substantially more consise. |
| 23:06 | <Hixie> | i'd have to look at common use cases to have an actual proposal to make |
| 23:30 | <Hixie> | othermaciej: can you confirm that i read the decision correctly on http://www.w3.org/Bugs/Public/show_bug.cgi?id=10066 ? |
| 23:31 | <Hixie> | man this makes a mess of ARIA |
| 23:32 | <othermaciej> | Hixie: sure, what should I check? |
| 23:32 | <Hixie> | last comment |
| 23:32 | <othermaciej> | I see, you have a comment |
| 23:32 | <othermaciej> | ok, lemme pull up the decision and CP to double check |
| 23:32 | <Hixie> | the reason i ask is that if i'm correct, sam's decision seems to leave the conformance requirements in a really inconsistent state |
| 23:33 | <Hixie> | e.g. <button> can be a menuitemradio, a menuitemcheckbox, a radio, but not a checkbox. |
| 23:33 | <Hixie> | and a <button> can be a link, which makes no sense but i presume is intentional |
| 23:34 | <Hixie> | similarly, <h1> can be a menuitemcheckbox and menuitemradio, but not a checkbox or a radio |
| 23:34 | <Hixie> | i don't really understand what school of language design these decisions would stem from |
| 23:34 | <othermaciej> | it looks like you have copied the changes and exclusions correctly |
| 23:34 | <othermaciej> | now checking the delta |
| 23:36 | <hober> | Hixie: I guess I should have said, in my response on that poll, that my list of crazy element/role combos wasn't intended to be complete |
| 23:36 | <hober> | http://www.w3.org/2002/09/wbs/40318/issue-129-objection-poll/results#xfigure |
| 23:37 | <Hixie> | ah, so the school of design sam followed is the "have no idea what you're doing and try to crib off someone else"? |
| 23:37 | <Hixie> | sigh |
| 23:38 | <Hixie> | in other news, anyone know how one goes about reverting a specific revision in svn? |
| 23:38 | <othermaciej> | Hixie: re reverting, best way is to reverse-apply the diff |
| 23:39 | <othermaciej> | Hixie: I think you have correctly captured what the decision says |
| 23:39 | <Hixie> | doesn't svn have a way to do a reverse merge or something that takes into account all the changes after the revision so that i get fewer conflicts, or something? |
| 23:40 | <Hixie> | othermaciej: ok. i guess i'll apply it and fork for whatwg? or maybe just apply it and fix it in a few years once people aren't paying attention anymore. |
| 23:40 | <othermaciej> | Hixie: some of the things you mention as inconsistent, I would guess Sam would have also listed as exclusions if anyone (e.g. Ted) had specifically objected to them as not being justified by practice, and probably <botton> being a radio or menu item would have reasonably fallen in that bucket |
| 23:40 | <othermaciej> | Hixie: at this point, though, someone would have to plead to reopen the decision based on new info to adjust those things |
| 23:42 | jgraham | loves Process |
| 23:42 | <hober> | sad face |
| 23:43 | <othermaciej> | for some reason I am reminded of http://programming-motherfucker.com/ |