| 00:01 | <TabAtkins> | bga_: We (subset of Chrome team working on this stuff) want something very similar to that. |
| 00:04 | <bga_> | i need time to implement it |
| 00:35 | <bga_> | lol http://www.firefoxwithbing.com/ |
| 01:20 | <Hixie> | anne: need your input on http://www.w3.org/Bugs/Public/show_bug.cgi?id=14284 |
| 07:39 | <bitgod> | hello? |
| 09:53 | <zcorpan> | http://doctype.com/figure-used-background-images |
| 09:53 | <annevk> | ah, Mike must be traveling |
| 09:54 | <annevk> | I guess I should write a weekly |
| 09:54 | <annevk> | hmm |
| 09:59 | <annevk> | hsivonen, what did you implement for http://www.w3.org/Bugs/Public/show_bug.cgi?id=14284 ? |
| 09:59 | <annevk> | hsivonen, I don't really mind either way |
| 09:59 | <annevk> | hsivonen, it seems sicking feels somewhat strongly for lots of sniffing though he has no figures to back that up... |
| 10:00 | <annevk> | hsivonen, I would personally be fine with the simple rules or GTFO |
| 10:01 | <erlehmann> | hahaha |
| 10:01 | <erlehmann> | tha attribute styling stuff is COMEDY GOLD |
| 10:04 | <annevk> | erlehmann: ? |
| 10:06 | <hsivonen> | annevk: I implemented the following: |
| 10:06 | <erlehmann> | annevk, Jukka K. Korpela <jkorpela⊙ctf> suggested using <div type="nav"> instead of <nav> for IE compatibility. |
| 10:06 | <erlehmann> | and then simon pieters was like “<div type="nav"> is not stylable in IE6 because it doesn't support |
| 10:06 | <erlehmann> | attribute selectors.” |
| 10:06 | <erlehmann> | i pooped a little. |
| 10:06 | <hsivonen> | text/html in non-default, non-document modes works like an unknown type |
| 10:07 | <hsivonen> | annevk: in the default and document modes, for text/html first honor HTTP, failing that BOM, failing that <meta> within the first 1024 bytes |
| 10:08 | <hsivonen> | annevk: if we have to look for <meta>, stall output until the parser has seen the <meta> or received 1024 bytes |
| 10:08 | <hsivonen> | if the parser sees 1024 bytes without a <meta> (and without BOM or HTTP-level charset), use UTF-8 |
| 10:08 | <hsivonen> | annevk: HOWEVER |
| 10:08 | <hsivonen> | annevk: doing this breaks our mochitests |
| 10:09 | <hsivonen> | annevk: specifically, we have something that tests redirects and tries to read the resource body of a redirect response |
| 10:09 | <hsivonen> | which is marked text/html without an explicit charset |
| 10:09 | <hsivonen> | annevk: so this stuff may not be entirely done yet |
| 10:10 | <hsivonen> | annevk: I've been pondering the idea of not stalling as long as the data before the <meta> is in the printable ASCII range |
| 10:11 | <hsivonen> | annevk: not stalling responseText that is |
| 10:11 | <annevk> | ow |
| 10:11 | <annevk> | that sounds tricky |
| 10:11 | <roc> | hsivonen: are you just worried about the test, or are you worried that the same pattern is likely to show up in real life? |
| 10:11 | <hsivonen> | annevk: I'll analyze the situation and see if it's reasonable to try to change the test |
| 10:12 | <hsivonen> | roc: so far, only a test |
| 10:15 | <annevk> | hsivonen: did you consider completely disabling the <meta> thing? |
| 10:16 | <annevk> | hsivonen: Hixie: I updated the bug saying we're waiting for implementation experience from Gecko |
| 10:17 | <annevk> | the CSS WG decided to not change vm/vw |
| 10:17 | <annevk> | grmbl |
| 10:26 | <hsivonen> | annevk: I considered it briefly after Hixie suggested it, but disabling <meta> altogether would mean deviating even more from what sicking wanted and I'm in principle uncomfortable with not supporting all conforming documents |
| 10:33 | <annevk> | http://www.w3.org/html/wg/wiki/ChangeProposals/av_param o_O |
| 10:34 | <annevk> | insanity is prevailing it seems |
| 10:34 | <annevk> | hsivonen: fair enough, sounds good to me generally |
| 10:39 | <boblet> | annevk: quick q about HTML5 diffs doc. It mentions absent elements "are not in HTML5". I thought they were obsolete (not for author use) but still covered by HTML5 (=in the spec with guidance for implementors) |
| 10:39 | <boblet> | it’s re: https://github.com/html5doctor/diveintohtml5/issues/1 |
| 10:40 | <roc> | who's behind av_param? |
| 10:41 | <annevk> | Glenn Adams |
| 10:41 | <annevk> | he contracts for some unnamed entity I believe |
| 10:41 | <roc> | Samsung |
| 10:42 | <annevk> | yeah, but also an unnamed entity |
| 10:42 | <boblet> | for me using obsolete elements in HTML5 doesn’t break the doc, just the validation. maybe I need to read defn of obsolete… |
| 10:42 | <roc> | he was involved in a large furore on the wwww-font list |
| 10:43 | <annevk> | and apparently co-chair of the Timed Text WG at some point |
| 10:43 | <annevk> | boblet, you should tell the guy that HTML4 is obsolete |
| 10:44 | <boblet> | annevk: you’re not helping :p |
| 10:44 | <boblet> | purist vs pragmatist, fight! ;) |
| 10:44 | <annevk> | boblet: just saying how it is |
| 10:45 | <annevk> | boblet: anyway html5-diff is written towards authors primarily |
| 10:45 | <annevk> | boblet: as they seem to find it most useful, and for authors, the elements are absent |
| 10:45 | <boblet> | annevk: for me Mark’s sentence is correct, but from an author perspective (if there are obsolete elems/attribs) maybe not so much huh |
| 10:48 | <annevk> | you should not read books like you read specs man |
| 10:49 | <annevk> | specs you can read in an anal-retentive way, maybe even should |
| 10:49 | <annevk> | books not so much |
| 10:49 | <annevk> | I would link to a blog entry where Mark explains this, but it's no longer up :( |
| 10:51 | <boblet> | annevk: agree. can u give me a rough title or keywords re: Mark's article? might check archive |
| 10:52 | <annevk> | boblet: ietf, cat pictures, w3c |
| 10:53 | <annevk> | boblet: maybe specs or standards |
| 10:54 | <boblet> | annevk: thanks as always yo |
| 11:15 | <karlcow> | annevk: http://web.archive.org/web/20110514114618/http://diveintomark.org/archives/2004/08/16/specs ? |
| 11:21 | <annevk> | no |
| 11:23 | <akamike> | Amusing to read though |
| 11:25 | <annevk> | he has written many great posts |
| 11:34 | <hsivonen> | I wonder how much YouTube's autocaptioning has been tested with different accents. it fails pretty hard with a typical Finnish accent (when speaking English that is) |
| 11:36 | <zcorpan> | i tried it on a presentation timj held. it pretty much failed |
| 11:37 | <hsivonen> | zcorpan: the WebGL developer? |
| 11:37 | <zcorpan> | yes |
| 11:37 | <hsivonen> | zcorpan: is he from Finland (his English sounded more like spoken by a Finn that like spoken by a Swede) |
| 11:38 | <zcorpan> | no |
| 11:41 | <annevk> | pointer? |
| 11:42 | <zcorpan> | http://www.youtube.com/watch?v=BnVy_uCk_es |
| 11:43 | <hsivonen> | annevk: http://www.youtube.com/watch?v=K6QjOjgwuWk particularly between 1:00 and 1:20 shows the speech recognition failing pretty hard |
| 11:46 | <zcorpan> | it transcribed "firefox" correctly but "chrome" became "croats" |
| 11:46 | <zcorpan> | (4:30) |
| 11:48 | <zcorpan> | "fragment shaders" -> "pregnant shakers" :) |
| 11:52 | <boblet> | annevk: “There are no exceptions to Postel’s Law”? http://web.archive.org/web/20110514120305/http://diveintomark.org/archives/2004/01/08/postels-law |
| 11:53 | <hsivonen> | it's nice that Mark didn't request archive.org to hide his writings |
| 11:54 | <hsivonen> | btw, did I miss something that I should have mentioned in http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/0266.html ? |
| 12:00 | <annevk> | boblet: good find |
| 12:00 | <annevk> | zcorpan: haha |
| 12:03 | <hsivonen> | I wonder if anyone has fed yesterday's Nokia Lumia 800 announcement to a text to speech engine to see how often the said "800" in a way that sounded like "Android" |
| 12:03 | <hsivonen> | doh. speech to text |
| 12:07 | <annevk> | hsivonen: looks accurate |
| 12:07 | <annevk> | hsivonen: blog post worthy |
| 12:09 | <hsivonen> | annevk: ok. thanks. I might copy and paste it to my blog later. |
| 12:13 | <hsivonen> | sigh. so we have a separate parsing algorithm for WebVTT but make it treat Form Feed as white space for consistency. FAIL. :-( |
| 12:18 | <hsivonen> | whoa. a thread about "Signed XHTML". XML tech rathole warning! |
| 12:19 | <annevk> | hsivonen, we can remove the FF handling |
| 12:19 | <annevk> | hsivonen: should we? |
| 12:19 | <hsivonen> | annevk: my gut says we should |
| 12:19 | <hsivonen> | space, tab, cr and lf is the One True set of space characters |
| 12:20 | <annevk> | what does CSS have? |
| 12:20 | <annevk> | and why does HTML have FF? |
| 12:20 | <hsivonen> | HTML has FF due to beliefs about legacy |
| 12:21 | <hsivonen> | dunno how real the need to have FF in HTML is |
| 12:22 | <hsivonen> | CSS has FF. :-( |
| 12:22 | <annevk> | seems better to just keep FF around then |
| 12:22 | <hsivonen> | :-( |
| 12:23 | <annevk> | it's not very sad, it just means it's 5 true whitespace characters instead of 4 |
| 12:27 | <hsivonen> | I failed to resist replying to the signature thread |
| 12:55 | <zcorpan> | annevk: FF after signature would be inconsistent with cache manifests |
| 13:02 | <annevk> | maybe we should update those too then |
| 13:21 | <annevk> | http://www.firefoxwithbing.com/ is all kinds of odd, but it also makes sense I suppose |
| 13:36 | <hsivonen> | annevk: odd how? |
| 13:40 | <annevk> | Microsoft promoting the usage of a non-Microsoft browser in order to more successfully compete in the search market |
| 14:06 | <erlehmann> | annevk, bing even uses webm ;) |
| 14:06 | <erlehmann> | btw, do you know a good minimalistic contentEditable editor? |
| 14:54 | <hsivonen> | erlehmann: where does Bing use WebM? or did I misunderstand the smiley? |
| 14:56 | <hsivonen> | annevk: does Microsoft promote the firefoxwithbing.com site somewhere to users who aren't already seeking to download Firefox? |
| 14:56 | <erlehmann> | hsivonen, here? http://www.bing.com/?scope=web&setmkt=en-US&setlang=match&FORM=W5WA&uid=879B42B5 |
| 14:57 | <hsivonen> | erlehmann: cool |
| 14:59 | <miketaylr> | unless you're using Opera, then you get a static image |
| 14:59 | <miketaylr> | yay |
| 15:02 | <AryehGregor> | MS was never against WebM, they just don't want to ship the codecs. |
| 15:02 | <AryehGregor> | For liability reasons. |
| 15:03 | <AryehGregor> | Shipping an encoder or decoder is presumably a lot more likely to expose you to liability than providing a file. |
| 15:04 | <AryehGregor> | I guess patents are likely to cover the encoding or decoding process, not the file format itself. |
| 15:06 | <erlehmann> | AryehGregor, that is what they want you to believe. |
| 15:06 | <AryehGregor> | Plus, your liability for distributing one file has got to be more limited than your liability for distributing a codec that lets users view zillions of files. |
| 15:06 | <AryehGregor> | erlehmann, I've seen nothing to indicate that Microsoft is anything but honest in its reasons for non-support of WebM. |
| 15:07 | <erlehmann> | AryehGregor, non-support of vorbis? |
| 15:07 | <AryehGregor> | Everything they've said and done accords with their explanation that they're only concerned about patent liability. |
| 15:07 | <AryehGregor> | . . . Vorbis I don't know. I haven't seen any statements by them on that. |
| 15:07 | <AryehGregor> | People seem to not talk about the audio part much, mostly video. |
| 15:08 | <erlehmann> | i am interested in audio. i sometimes do podcasts. |
| 15:08 | <erlehmann> | also, streaming vorbis (well, anything in ogg) is easy. |
| 15:08 | <gsnedders> | AryehGregor: They already ship VP8. |
| 15:08 | <gsnedders> | AryehGregor: In Skype. |
| 15:08 | <AryehGregor> | gsnedders, typical. One hand doesn't know what the other is doing . . . |
| 15:08 | <erlehmann> | http://en.wikipedia.org/wiki/Microsoft_PlaysForSure#Criticisms |
| 15:08 | <AryehGregor> | Like how they argued fiercely against OTF embedding while Silverlight supported it. |
| 15:08 | <gsnedders> | AryehGregor: They only officially owned Skype a few days ago |
| 15:09 | <erlehmann> | >The license prohibited makers of portable devices compatible with Windows Media Player from using non-Microsoft audio encoding formats. |
| 15:09 | <gsnedders> | AryehGregor: But the risk is now their's |
| 15:09 | <AryehGregor> | Oh, so MPEG LA's patent search has come up with something. I didn't notice that when it happened. |
| 15:09 | <AryehGregor> | gsnedders, oh, well, that's different. |
| 15:09 | <AryehGregor> | That does change things, though. |
| 15:09 | <gsnedders> | AryehGregor: Different, yes, but the liability is their's. |
| 15:09 | <gsnedders> | AryehGregor: And it's only really the liaibility that matters. |
| 15:10 | <AryehGregor> | Yes. |
| 15:10 | <erlehmann> | AryehGregor, i have one question. if a vendor has already paid or is part of the patent consortium, what is to fear, legally, by including free codecs? |
| 15:10 | <jgraham> | AryehGregor: |
| 15:10 | <AryehGregor> | Of course, they might decide to phase out VP8 from Skype. But if they don't, it seems hard to understand why they wouldn't allow WebM in IE too. |
| 15:10 | <gsnedders> | AryehGregor: MPEG LA's H.264 portfolio is meant to be about 20% bogus, but the cost of going through and proving prior art for all of them is considered more costly than paying the fee |
| 15:11 | <gsnedders> | AryehGregor: the number of units sdhipped would have an affect on any fine. IE ships more units than Skype. |
| 15:11 | <AryehGregor> | erlehmann, the MPEG LA has separate patent pools for different formats. If you're paying into the H.264 patent pool, that doesn't mean you get licenses to VP8 patents, even from the same parties. |
| 15:11 | <gsnedders> | *shipped |
| 15:11 | <gsnedders> | *effect |
| 15:11 | <AryehGregor> | gsnedders, damages, I think, not fine. But that's true. |
| 15:11 | <erlehmann> | AryehGregor, to obstruct the web as a platform, of course. in before do not assume malice. |
| 15:11 | <gsnedders> | AryehGregor: What legally it is is rather non-important here :P |
| 15:12 | <annevk> | Since the initial argument Microsoft bought Skype |
| 15:12 | <AryehGregor> | erlehmann, I think there's decent evidence here of non-malice. |
| 15:12 | <AryehGregor> | Such as, they support WebM if you install the codec, which they don't do for any other format. |
| 15:12 | <AryehGregor> | And they publicly pledged that they'll support it if Google agrees to indemnify them. |
| 15:12 | <erlehmann> | they don't? isn't directShow like quicktime, supporting everything installed? |
| 15:12 | <gsnedders> | erlehmann: They whitelist it. |
| 15:13 | <AryehGregor> | Right. |
| 15:13 | <gsnedders> | erlehmann: To stop things like WMV from being used with video. |
| 15:13 | <erlehmann> | gsnedders, did not know that. |
| 15:13 | <AryehGregor> | Because a lot of codecs are dodgy and they don't want them exposed to the web. |
| 15:13 | <gsnedders> | erlehmann: The only video codecs they allow are H.264 and WebM. |
| 15:14 | <erlehmann> | how unfortunate for theora (hey, my laptop is from 2007). |
| 15:14 | <AryehGregor> | My prediction: MPEG LA announces a patent pool. Google either buys out the patents, or declares they're blatantly invalid/inapplicable and offers to indemnify Microsoft and Apple against them, or changes VP8 to avoid them. |
| 15:14 | <erlehmann> | wellr, i am a behaviourist. actions speak louder than words, particularly regarding software. |
| 15:14 | <AryehGregor> | Microsoft and Apple will then support WebM. |
| 15:14 | <AryehGregor> | But I'm speculating here. |
| 15:15 | <gsnedders> | AryehGregor: That wouldn't make Opera/Mozilla/any other browser vendor happy. |
| 15:15 | <AryehGregor> | Which part? |
| 15:15 | <gsnedders> | Especially anyone wanting to move into the browser market, as they'd have a alrger risk than anyone else. |
| 15:15 | <erlehmann> | AryehGregor, even more so than microsoft, apple is not a friend of open formats when there is a position to hold. |
| 15:15 | <gsnedders> | AryehGregor: indemification |
| 15:16 | <erlehmann> | gsnedders is a very clever person. |
| 15:16 | <gsnedders> | erlehmann: I am? Okay. :D |
| 15:17 | <AryehGregor> | gsnedders, I'm guessing they'd either offer indemnification to Mozilla too, or only offer the indemnification secretly and require Microsoft/Apple to not admit to it, only say "Hey, Google convinced us to support it". |
| 15:17 | <AryehGregor> | I doubt they'd care about Opera. |
| 15:17 | <AryehGregor> | Opera will be forced to support it regardless if everyone else does. |
| 15:17 | <gsnedders> | AryehGregor: Then why both having us as one of the initial impls at WebM's original announcement? |
| 15:17 | <AryehGregor> | They want to have everyone possible. |
| 15:18 | <AryehGregor> | They also had, like, Grab Networks. |
| 15:18 | <AryehGregor> | I have no idea what that even is. |
| 15:18 | <AryehGregor> | . . . Actually, I don't see Opera here. |
| 15:18 | <AryehGregor> | Oh, I see. |
| 15:18 | <gsnedders> | AryehGregor: Håkon was there |
| 15:18 | <AryehGregor> | Opera gets called out in the start with Mozilla/Opera/Google Chrome/Adobe. |
| 15:19 | <AryehGregor> | Well, whatever. |
| 15:19 | <gsnedders> | At Google I/O. |
| 15:19 | <gsnedders> | AryehGregor: Also, if they care about mobile, not caring about us would be silly. |
| 15:19 | <AryehGregor> | That's very different from offering a potentially large sum of money to fight legal battles for you. |
| 15:19 | <AryehGregor> | http://www.mpegla.com/main/pid/vp8/default.aspx |
| 15:19 | <AryehGregor> | Feh, no details. |
| 15:19 | <AryehGregor> | Oh well. |
| 15:19 | <gsnedders> | We could just go down the road of not wanting to run the risk and just support H.264 on mobile. |
| 15:22 | <AryehGregor> | If MS and Apple support WebM, then congrats, you'd no longer be web-compatible. |
| 15:24 | <erlehmann> | AryehGregor, you are speculating. I bet two mozarella cheeseburgers with fried egg that in 6 months, neither Apple nor Microsoft will deliver a desktop or moible web browser supporting any of the following: Ogg. Vorbis, Theora, Matroska, VP8. |
| 15:24 | <AryehGregor> | erlehmann, I doubt this will take anywhere close to as short as six months. There are lawyers involved. |
| 15:24 | <AryehGregor> | I'd guess more like within three years. |
| 15:25 | <erlehmann> | 18 Months. |
| 15:25 | <erlehmann> | And four mozarella cheeseburgers. |
| 15:25 | <AryehGregor> | Eighteen months is possible, but I wouldn't bet on it. |
| 15:25 | <erlehmann> | See? |
| 15:25 | <AryehGregor> | I'd bet a modest sum on three years. |
| 15:25 | <AryehGregor> | Not cheeseburgers, though, they aren't kosher. In fact, I'm not even allowed to have any benefit from them. If you gave me one I'd have to throw it out. |
| 15:25 | <erlehmann> | Wat. |
| 15:26 | <AryehGregor> | Yus. |
| 15:26 | <erlehmann> | they don't mix milk and patties! |
| 15:26 | <erlehmann> | it is a fat blob of fried mozarella instead of meat. |
| 15:26 | <erlehmann> | in fact, i might just go out and get one. |
| 15:26 | <erlehmann> | now. |
| 15:26 | <erlehmann> | ha. |
| 15:27 | <erlehmann> | or write on some part of my blog engine. |
| 15:27 | <erlehmann> | hmm. |
| 15:27 | <AryehGregor> | Oh, that does sound appetizing. |
| 15:30 | <jgraham> | Fried mozarella? |
| 15:31 | <jgraham> | That sounds like a bad idea... |
| 15:32 | <AryehGregor> | It sounds extremely unhealthful, which makes it right up my alley. |
| 15:38 | <jgraham> | I was more concerned with the logistics of frying mozarella. It should melt! |
| 15:38 | <jgraham> | Also, this is the worst network I have ever been on |
| 15:39 | <annevk> | Is that the Avatar hotel? |
| 15:39 | <wilhelm> | I've seen worse. But yes, this high speed broadband really isn't. |
| 15:39 | <jgraham> | No, Hotel Zico |
| 15:39 | <jgraham> | I have like 50% packet loss |
| 15:40 | <annevk> | How is the weather? |
| 15:40 | <wilhelm> | 12-20° and no clouds. |
| 15:46 | <annevk> | not too bad |
| 15:52 | <annevk> | do you need to update ESTA each time you go to the US? |
| 15:52 | <annevk> | I guess I better do it just in case |
| 16:40 | <dglazkov> | good morning, Whatwg! |
| 16:42 | <annevk> | good afternoon, dglazkov! |
| 16:44 | <dglazkov> | I just realized that the Whatwg cabal is slowly converging upon the San Francisco Bay Area |
| 16:45 | <annevk> | terrorists with the intent of slowing down development of the web would do good striking next week |
| 16:45 | <dglazkov> | one can easily visualize the map with red arrows punching through the georgraphy, WW2 style |
| 16:45 | <annevk> | hehe |
| 16:58 | <bfrohs> | Is there any chance of the label element receiving :valid, :invalid, :required capabilities in CSS? Use cases: 1) Adding an asterisk or other symbol after the text in a label that uses the for attribute. 2) Targeting elements that come after a label with an input child (<p>Label <label><input></label> <small>Text</small></p>) |
| 17:00 | <bfrohs> | 3) Formatting the text in a label accordingly (e.g. different color or weight) |
| 17:04 | timeless | wants to see that map |
| 17:05 | <annevk> | bfrohs, I think the idea is to have a selector that allows selecting the associated label |
| 17:06 | <dglazkov> | timeless, jgraham should do it. He's already arrived, barely has any Internets -- perfect time for doodling. |
| 17:07 | <bfrohs> | annevk, that would be ideal. I guess I was just thinking that it would fall under the "can't have parent selectors" argument and would be easier to just set it on the label when setting it on the input. |
| 17:09 | <timeless> | heh |
| 17:28 | <TabAtkins> | bfrohs: "?label /for/ :invalid" |
| 17:29 | TabAtkins | likes combining together multiple crazy selectors. |
| 17:30 | <hober> | TabAtkins majored in crazy selector combinatorics |
| 17:30 | <TabAtkins> | Well, it was a minor with honors. |
| 17:30 | <hober> | ahh, fair enough |
| 17:31 | <bfrohs> | TabAtkins: Yeah, that's the general idea. Those are just hypothetical though, right? Not used in any browser? |
| 17:31 | <TabAtkins> | bfrohs: They exist only in spec right now. No implementations yet. |
| 17:32 | <bfrohs> | TabAtkins: Have a link to said spec? So you guys can spend time on improving everything even more, instead of looking things up for me? ;) |
| 17:32 | <TabAtkins> | http://dev.w3.org/csswg/selectors4 |
| 17:32 | <bfrohs> | Thank ya much :) |
| 17:33 | <TabAtkins> | Specifically http://dev.w3.org/csswg/selectors4/#subject and http://dev.w3.org/csswg/selectors4/#idref-combinators |
| 17:36 | <TabAtkins> | jgraham: You've never had a fried cheesestick before? |
| 17:37 | <bfrohs> | TabAtkins: http://dev.w3.org/csswg/selectors4/#subject -- Paragraph 3: "with or without the dollar sign" - should be "with or without the question mark", shouldn't it? |
| 17:37 | <jgraham> | TabAtkins: My arteries are clogging just thinking about it |
| 17:37 | <TabAtkins> | bfrohs: Yes, it was originally a dollar sign until we made fantasai change it. |
| 17:38 | <TabAtkins> | jgraham: Go to any low-budget italian place in america. |
| 17:38 | <TabAtkins> | Or a fair. |
| 17:38 | <bfrohs> | TabAtkins: Saving dollar sign for vars, perhaps? :) |
| 17:39 | <TabAtkins> | bfrohs: We *were*, but now we're shifting gears to a different design. |
| 17:52 | <zcorpan> | so uh, where's the webm video on bing's front page? |
| 17:53 | <hsivonen> | zcorpan: in Firefox--not in Opera :-( |
| 17:55 | <zcorpan> | i don't see it in firefox either |
| 17:59 | <hsivonen> | zcorpan: do you see a woodpecker on the front page? |
| 17:59 | <hsivonen> | zcorpan: do you have an en-US version of Firefox? |
| 18:00 | <hsivonen> | zcorpan: having you chosen United States as your Bing locale? |
| 18:00 | <hsivonen> | s/having/have/ |
| 18:02 | <hsivonen> | it seems you need to choose United States to see a woodpecker |
| 18:02 | <hsivonen> | and then Opera gets a still woodpecker and Firefox gets a video of a woodpecker |
| 18:03 | <zewt> | it's pining for the fjords |
| 18:07 | <zcorpan> | hsivonen: needed to change the bing locale to US |
| 18:07 | <zcorpan> | hsivonen: i can mask as firefox in opera to get the video |
| 18:12 | <zcorpan> | hmm the bing home page used a lot of cpu for me (in both firefox and opera) |
| 18:25 | <bfrohs> | TabAtkins: Just realized that the code you gave me ("?label /for/ :invalid") won't work for use case #2: Targeting elements that come after a label with an input child (<p>Label <label><input></label> <small>Text</small></p>) |
| 18:26 | <TabAtkins> | bfrohs: Correct. This is why I don't like the subject indicator very much. It would be better to use :has(). |
| 18:26 | <TabAtkins> | bfrohs: "label:has( :scope /for/ :invalid ) + small |
| 18:26 | <TabAtkins> | Alternately, use Hierarchies to get the same functionality (this is silly, though): |
| 18:26 | <zcorpan> | can:has(cheezeburger) |
| 18:27 | <TabAtkins> | "?label /for/ :invalid { & + small { <properties go here> } } |
| 18:27 | <bfrohs> | But won't both :has and nesting with subject specified lead to parent relationships that vendors have said no to for years due to performance issues? |
| 18:28 | <TabAtkins> | The subject indicator all by itself leads to those problems. |
| 18:28 | <TabAtkins> | But yes. We're trying to push on it to see if they're usable in practice these days. |
| 18:28 | <bfrohs> | Well, to an extent, but it isn't in a loop |
| 18:29 | <bfrohs> | Once you add nesting (and force them to use the subject, rather than the normal hierarchy), or add :has(), it will have a loop that will cause *more* of an issue. |
| 18:29 | <bfrohs> | I think that's been the main reason behind it (but only one deep isn't as bad). |
| 18:30 | <bfrohs> | Whereas if :invalid and all of that was also available to label, this could be avoided |
| 18:30 | <bfrohs> | I think it would be an easier idea for vendors to accept, but I could be wrong. |
| 18:32 | <mbatle_> | anybody knows if any browser is implementing mediagroup property in media elements ? |
| 19:01 | <AryehGregor> | jgraham, proposed testharness patch for review: http://pastebin.com/1MLYd24H |
| 19:02 | <AryehGregor> | Currently the specs say RangeException shouldn't exist, and there are new exception types added to DOMException that browsers don't implement yet, so the preexisting code was incorrect. |
| 19:03 | <AryehGregor> | E.g., if INVALID_NODE_TYPE_ERR is supported on DOMException, then assert_throws("INVALID_NODE_TYPE_ERR", ...) will expect that, but if it's not, it will expect a RangeException. |
| 19:04 | <AryehGregor> | This means that Gecko incorrectly passes many tests in http://w3c-test.org/webapps/DOMCore/tests/submissions/Ms2ger/Range-selectNode.html that WebKit fails, because WebKit implements the new INVALID_NODE_TYPE_ERR. |
| 19:04 | <hsivonen> | I probably should have saved a pre-HTML5 parser WebKit-based browser somewhere... |
| 19:04 | <AryehGregor> | Why? |
| 19:05 | <hsivonen> | I wonder if Android has an outdated WebKit |
| 19:05 | <hsivonen> | AryehGregor: for testing |
| 19:05 | <AryehGregor> | Why would you want to test browsers that have rapidly become so obscure? |
| 19:06 | <AryehGregor> | Chrome that old is massively irrelevant, and Safari/other WebKit that old must have tiny market share by now. |
| 19:06 | <hsivonen> | AryehGregor: to figure out if we changed something in HTML5 |
| 19:07 | <hsivonen> | turns out that WebKit in Android 3.1 is too fresh. (I'm surprised. The Android stock browser has a reputation of being behind the times.) |
| 19:08 | <AryehGregor> | Is othermaciej on vacation or something? I haven't seen him say anything for a long time now. |
| 19:08 | <AryehGregor> | Oh, he talked yesterday. |
| 19:08 | <AryehGregor> | Okay, so he still exists. |
| 19:12 | <smaug____> | hsivonen: are you still trying to test document.close() handling |
| 19:13 | <smaug____> | hsivonen: and sorry, I was offline for some time. What was the reason to append EOF and not insert it? |
| 19:14 | <hsivonen> | smaug____: I'm testing my reimplementation of the buffer queue management at this point. I think the code I have for document.close() doesn't need more testing today |
| 19:14 | <hsivonen> | smaug____: the reason for appending is that you can do: |
| 19:14 | <hsivonen> | doc.open(); |
| 19:14 | <hsivonen> | doc.write("<script src=whatever.js></script>); |
| 19:14 | <hsivonen> | doc.write("something else"); |
| 19:15 | <hsivonen> | doc.close(); |
| 19:15 | <hsivonen> | and have "something else" appear in the document |
| 19:16 | <smaug____> | well, I would assume doc.write("<script src=whatever.js></script>); would insert something to stream and keep the stream "open" until the script is executed. After that "Something else" would be inserted |
| 19:16 | <smaug____> | and then doc.close |
| 19:16 | <smaug____> | since that is the order of insertion |
| 19:17 | <hsivonen> | smaug____: okay, better example: assume the doc.write("something else"); statement is in whatever.js instead |
| 19:18 | <smaug____> | and ? |
| 19:18 | <smaug____> | that would insert "something else". |
| 19:18 | <hsivonen> | smaug____: in that case, document.write("something else"); executes after document.close();, but you still want "something else" to appear in the document |
| 19:19 | <smaug____> | right |
| 19:19 | <smaug____> | but that document.write() would insert something to be before the EOF |
| 19:19 | <hsivonen> | smaug____: yes |
| 19:20 | <smaug____> | so that would work just fine |
| 19:20 | <hsivonen> | smaug____: oh, you meant why document.close() appends when called from a nested script |
| 19:20 | <smaug____> | well, in any case |
| 19:20 | <hsivonen> | smaug____: I'm going to go with "that's the way document.close() works" |
| 19:20 | <smaug____> | why it doesn't insert EOF but appends |
| 19:21 | <smaug____> | hsivonen: ok |
| 19:22 | <smaug____> | hsivonen: do you know if this behavior was actually defined based on how browsers behave |
| 19:22 | <hsivonen> | smaug____: I don't recall anymore |
| 19:22 | <smaug____> | k |
| 19:22 | <hsivonen> | let's see what my clashtest does in Firefox 3.5 |
| 19:23 | <smaug____> | would be interesting to know what IE6-8 do |
| 19:23 | <hsivonen> | smaug____: HTML5 specs old Firefox-style document.write() |
| 19:23 | <hsivonen> | IE8 was different |
| 19:23 | <smaug____> | hsivonen: but this is about document.close, not document.write ;) |
| 19:25 | <hsivonen> | AryehGregor: see this is what old browsers are kept around for |
| 19:26 | <hsivonen> | smaug____: IE8 hangs |
| 19:26 | <hsivonen> | w00t. I have discovered two ways to hang IE8 today |
| 19:26 | <hsivonen> | smaug____: Firefox 3.5 behaves like HTML5 says |
| 19:30 | <smaug____> | that doesn't mean I like what the spec defines |
| 19:30 | <hsivonen> | smaug____: would it be possible to define document.write and document.close in a likeable way? |
| 19:31 | <smaug____> | document.close could insert EOF |
| 19:31 | <smaug____> | not append |
| 19:31 | <smaug____> | but, again, I'm not very familiar with parsing, so perhaps there is some reason for the current behavior |
| 19:31 | <hsivonen> | smaug____: I'd rather rock the boat based on aesthetics and stick to something that's known to be successful on the Web |
| 19:32 | <smaug____> | it is strange that some data can be inserted to document after document.close() |
| 19:32 | <smaug____> | hsivonen: yeah, I guess I don't care too much |
| 19:32 | <hsivonen> | I'd rather *not* rock the boat |
| 19:33 | <hsivonen> | smaug____: the possibility of calling document.write() on a document.open()ed doc from scripts that are neither the one that called open() nor scripts that are in the open()ed doc bothers me more |
| 19:33 | <hsivonen> | smaug____: particularly that those other scripts can run from nested event loops |
| 19:35 | <AryehGregor> | TabAtkins, does something define how to determine the actual value for numeric markers? E.g., saying what number to display if you have <ol><li style=display:none>abc<li>def</ol>, or style=list-style:none, or whatever? |
| 19:36 | <AryehGregor> | It seems changing the display causes it to be skipped, at least in Gecko and WebKit, but I didn't see that in a glance at the spec. |
| 19:40 | <hober> | AryehGregor: yes, that's in the lists module; let me try to find the spot |
| 19:41 | <TabAtkins_> | AryehGregor: Yes, 2.1 defines that. |
| 19:41 | <hober> | AryehGregor: http://dev.w3.org/csswg/css3-lists/#declaring-a-list-item |
| 19:42 | <hober> | AryehGregor: "To declare a list item, the 'display' property must be set to 'list-item' or 'inline-list-item' (defined later in this section). This, in addition to generating a ::marker pseudo-element and enabling the properties described below for that element, causes that element to increment the list item counter 'list-item'." |
| 19:42 | <AryehGregor> | Ah, I see. |
| 19:42 | <AryehGregor> | Thanks. |
| 19:42 | AryehGregor | was looking at the TR -- of course -- but it says the same thing |
| 19:45 | <TabAtkins_> | AryehGregor: I intend to work on fixing 'display', such that the special behavior of "list-item" can be triggered independently of the layout. |
| 19:46 | <AryehGregor> | Yes, that would be awesome. |
| 19:46 | <TabAtkins_> | Since "list-item" is really just "block with magic" |
| 19:46 | <AryehGregor> | Things like inline-block really need to die. |
| 19:47 | <hober> | well, display-inside and display-outside need to happen |
| 19:47 | <TabAtkins_> | Yup. |
| 19:47 | <AryehGregor> | While we're talking about CSS, can someone explain to me why there's an extra line break after the steps with comments here in Gecko but not WebKit? http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#methods-to-query-and-execute-commands |
| 19:48 | <AryehGregor> | Like after steps 3 and 4 at the top there. |
| 19:48 | <AryehGregor> | I remember I tried to figure it out once before and gave up. |
| 19:49 | <TabAtkins_> | AryehGregor: It's because the exact treatment of the (currently implicit) ::marker is undefined. |
| 19:49 | <AryehGregor> | Oh. |
| 19:49 | <AryehGregor> | Great. |
| 19:50 | <TabAtkins_> | Firefox treats it as an inline element, which creates a linebox, and forces the block (<div> element) below it. |
| 19:50 | <TabAtkins_> | (The behavior now defined in Lists matches Chrome here. More propertly, it's almost exactly IE's behavior, which is the sanest of anyone.) |
| 19:51 | <AryehGregor> | I can't seem to easily come up with a minimal test-case, though. |
| 19:51 | <TabAtkins_> | I came up with plenty during testing. One sec. |
| 19:51 | <AryehGregor> | Also, IIRC, IE displayed them like Gecko. |
| 19:53 | <jgraham> | Hmm, I wonder what the lowest-hanging fruit is in terms of untested stuff in HTML5 |
| 19:54 | <jgraham> | And by "untested" I mean "wihout a test in the offical repo" |
| 19:56 | <AryehGregor> | jgraham, good grief, practically nothing is tested. Just start at page one. |
| 19:56 | <jgraham> | AryehGregor: Yeah, I know :) |
| 19:57 | <jgraham> | I just want something that is both stupidly simple and useful |
| 19:57 | <jgraham> | It is the "simple" part that is difficult |
| 19:57 | <jgraham> | "useful" can be determined by sticking a pin in the spec at random and assuming there are no tests |
| 19:59 | <TabAtkins_> | Hm, I'm having trouble reducing a testcase too. >_< |
| 20:00 | <TabAtkins_> | Oh man, Firefox has a native inspector now! |
| 20:00 | <TabAtkins_> | It's not very good yet, but still. |
| 20:01 | <gsnedders> | jgraham: Do you mean simple as in to test the whole feature? |
| 20:01 | <AryehGregor> | It's had one for a while. |
| 20:02 | <AryehGregor> | jgraham, I don't know why you use the word "assume" there. |
| 20:04 | <smaug____> | strange that in Gecko and Presto <a> can be used in place of <area>. Don't know about old IEs |
| 20:05 | <jgraham> | gsnedders: Not really |
| 20:06 | <jgraham> | Alhough if that was possible it would be double plus good |
| 20:06 | <smaug____> | oh, cvs commit says this is because of HTML4 ... |
| 20:07 | <smaug____> | or no |
| 20:08 | <timeless> | smaug____: i presume you're going to tpac? |
| 20:09 | <smaug____> | I'm not |
| 20:10 | <timeless> | aww |
| 20:10 | <jgraham> | timeless: No need to assume; http://www.w3.org/2002/09/wbs/35125/TPAC2011/registrants |
| 20:11 | <AryehGregor> | TabAtkins_, okay, so sometimes refreshing the exact same document repeatedly in Gecko will change whether the effect occurs. |
| 20:11 | <timeless> | jgraham: i don't suppose there's a ?groupby=sponsor |
| 20:12 | <jgraham> | timeless: Not that I know of |
| 20:12 | <AryehGregor> | TabAtkins_, I strongly suspect that in the case of my page, it's a timing issue, because the floated buttons are created by script. |
| 20:12 | <smaug____> | oh, Gecko and Presto do actually work per HTML4 spec |
| 20:12 | <timeless> | > Virginie GALINDO <virginie.galindo⊙gc> () : attending Thursday, Friday |
| 20:12 | <timeless> | is interesting, how did that person end up w/o content in ()? |
| 20:12 | <AryehGregor> | If they're created fast enough, it seems to be fine. |
| 20:12 | <smaug____> | I wonder how support for <a> got removed from HTML spec |
| 20:13 | <AryehGregor> | Including if they're in the original DOM. |
| 20:15 | <timeless> | AryehGregor: hey, i'm looking for someone @google who can pass along a bug report about gmm |
| 20:15 | <AryehGregor> | timeless, I'm not @google. |
| 20:15 | <AryehGregor> | In any meaningful sense, other than that they give me money occasionally. |
| 20:15 | <timeless> | i'm open to suggestions :) |
| 20:16 | <timeless> | oh, TabAtkins ? |
| 20:16 | timeless | pokes |
| 20:18 | <AryehGregor> | TabAtkins_, got it! http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1237 |
| 20:19 | <AryehGregor> | It seems like it reserves space for the thing and then doesn't reflow properly when it moves. |
| 20:22 | <AryehGregor> | That's why it was so hard to track down. |
| 20:22 | <smaug____> | Hixie: do you remember the reason why HTML spec removes coords and shape from <a> element, and also removes support for <a> inside <map> ? |
| 20:22 | <wilhelm> | Agenda for the testing meeting tomorrow: http://lists.w3.org/Archives/Public/public-test-infra/2011OctDec/0014.html |
| 20:26 | <AryehGregor> | Ooh. Now it doesn't reproduce properly anymore. |
| 20:26 | <AryehGregor> | Of course. |
| 20:27 | <AryehGregor> | . . . |
| 20:27 | AryehGregor | doesn't know what to do now |
| 20:27 | <AryehGregor> | It repros consistently in Live DOM Viewer, but not in a data URL. |
| 20:28 | <Hixie> | smaug____: only firefox implemented it |
| 20:28 | <smaug____> | also Opera |
| 20:29 | <Hixie> | and nobody used it |
| 20:29 | <smaug____> | that is possible |
| 20:29 | <smaug____> | I'm trying to decide whether to remove support for it |
| 20:29 | <Hixie> | i vote yes :-) |
| 20:30 | <AryehGregor> | Oooh, I think I see. |
| 20:30 | <smaug____> | but it was basically random removal based on that IE didn't support it |
| 20:30 | <AryehGregor> | It must be something to do with margins. |
| 20:30 | <smaug____> | but yeah, I think it should be ok to remove it |
| 20:30 | <Hixie> | smaug____: it's not a compelling feature, very few people use it, and the feature it's a part of (image maps) is itself not a compelling feature |
| 20:30 | <Hixie> | smaug____: but it has a non-trivial level of complexity |
| 20:30 | <AryehGregor> | Well, it should still not be dependent on how the DOM was created. |
| 20:30 | <Hixie> | smaug____: so imho it's a good candidate for removal |
| 20:31 | <Hixie> | smaug____: we don't get many :-( |
| 20:31 | <smaug____> | yup |
| 20:31 | <smaug____> | I think I'll add a warning that the feature is deprecated |
| 20:31 | <smaug____> | and remove it later |
| 20:31 | <Hixie> | seems reasonable |
| 20:31 | <Hixie> | does mozilla have any way of instrumenting how often a warning triggers? |
| 20:32 | <smaug____> | I could add a telemetry probe |
| 20:32 | <smaug____> | but telemetry is opt-in |
| 20:32 | <smaug____> | ofc |
| 20:32 | <Hixie> | btw when i was doing research on this i found it was used extremely rarely in image maps, but that a number of authoring tools would put the attributes on <a> with their default values |
| 20:32 | <Hixie> | so you might see an elevated number of <a shape="rect" coords=""> elements despite them not being part of actual image maps |
| 20:33 | <smaug____> | right |
| 20:33 | <Hixie> | which is to say, if you do set up telemetry, i'd make sure to distinguish <a>s actually used in image maps from those just with those attributes for no good reaosn |
| 20:34 | <Hixie> | hsivonen: yt? |
| 20:34 | <Hixie> | hsivonen: re defining the term "xhtml document", an alternative is for me to drop all usage of the term. Would that be acceptable, or do you prefer a definition? |
| 20:35 | <Hixie> | hsivonen: if the latter, do you want it to refer to the byte stream, or to the DOM structure? |
| 20:40 | <Hixie> | annevk: i think we may have to seriously consider renaming the terms "html document" and "xml document" so that they don't get confused with references to text/html documents and text/html documents. |
| 20:43 | <AryehGregor> | Okay, can other people reproduce my minimal test-case here with various Firefox versions, or am I just insane? https://bugzilla.mozilla.org/show_bug.cgi?id=697793 |
| 20:44 | <AryehGregor> | annevk, does anything still throw a WRONG_DOCUMENT_ERR, or should it be marked historical? |
| 20:47 | <AryehGregor> | annevk, filed a bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=14576 |
| 21:01 | <smaug____> | AryehGregor: Gecko seems to use that still in Range code |
| 21:01 | <AryehGregor> | smaug____, the spec says it shouldn't, though, AFAIK. Where does it use it? |
| 21:01 | <AryehGregor> | Generally we prefer to silently adopt the node. |
| 21:01 | <AryehGregor> | It's friendlier. |
| 21:02 | <smaug____> | AryehGregor: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-range-ispointinrange |
| 21:02 | <smaug____> | "WrongDocumentError" |
| 21:02 | <AryehGregor> | Aha. |
| 21:02 | <AryehGregor> | I was searching for the wrong string. |
| 21:02 | <AryehGregor> | Duh. |
| 21:02 | <AryehGregor> | Thanks. |
| 21:02 | <smaug____> | and that is, IMO, a valid use case |
| 21:03 | <AryehGregor> | It actually seems friendlier to just return false in that case, IMO. |
| 21:03 | <AryehGregor> | But it's reasonable, yeah. |
| 21:03 | <AryehGregor> | (I mean, if it's in a different tree, it's not in the range, right?) |
| 21:05 | <smaug____> | but it is not quite outside the range either |
| 21:05 | <smaug____> | it is just invalid state for the parameter or something |
| 21:06 | <smaug____> | so a case when throwing is ok |
| 21:06 | <smaug____> | though, I guess specs aren't consistent |
| 21:06 | <smaug____> | node.contains() doesn't throw |
| 21:06 | <AryehGregor> | If I were writing it from scratch, I'd return false. Seems less surprising. But it's okay as-is, if that's what browsers do. |
| 21:07 | <AryehGregor> | I didn't write or test that method, so I dunno. |
| 21:09 | <hsivonen> | Hixie: I think it's good to have a definion for an XHTML document, because we've spent years saying that HTML5 has an XML flavor called XHTML5 |
| 21:09 | <AryehGregor> | smaug____, data:text/html,<!doctype html><script>try {document.createRange().isPointInRange(document.createElement("a"), 0); throw "No exception"} catch(e) {alert(e)}</script> alerts "No exception" for me in both Gecko and WebKit. |
| 21:09 | <Hixie> | hsivonen: see the bug, i checked in some changes |
| 21:15 | <smaug____> | AryehGregor: oh, indeed |
| 21:15 | <smaug____> | AryehGregor: but comparePoints throws in Gecko |
| 21:16 | <AryehGregor> | That makes sense. |
| 21:16 | <AryehGregor> | There's no sensible return value for that case. |
| 21:19 | <AryehGregor> | Oh, I think I found an infinite loop in my spec. |
| 21:19 | <TabAtkins_> | AryehGregor: I suspect it's a stale painting bug, then. |
| 21:19 | <AryehGregor> | Yippee! |
| 21:19 | <Hixie> | don't you hate that |
| 21:22 | <annevk> | Hixie, we could have a "HTMLness flag" |
| 21:22 | <Hixie> | yeah |
| 21:22 | <annevk> | Hixie, because that's essentially what it comes down to anyway |
| 21:22 | <Hixie> | though frankly i'm a little scared of changing this |
| 21:23 | <Hixie> | because it would mean going through the whole spec changing zillions of little sentences |
| 21:23 | <annevk> | for the DOM it's relatively straightforward |
| 21:23 | <Hixie> | and would surely lead to mistakes |
| 21:23 | <annevk> | I'm willing to review the result |
| 21:23 | <Hixie> | maybe one day |
| 21:23 | <annevk> | k |
| 21:27 | <annevk> | TabAtkins, /for/ does not cover all <label> scenarios |
| 21:28 | <annevk> | TabAtkins, I guess the other one is covered by ?label input but it's annoying that you have to spell it out like that |
| 21:29 | <Hixie> | wtf is ?label |
| 21:35 | <AryehGregor> | Hmm. |
| 21:37 | <TabAtkins_> | Hixie: ? is the "subject indicator", which changes the subject of a selector. |
| 21:37 | <AryehGregor> | What should commands like insertOrderedList do if the editing host is an inline element? |
| 21:37 | <TabAtkins_> | annevk: I agree. |
| 21:37 | <AryehGregor> | Insert a list anyway, or refuse to do anything, or what? |
| 21:37 | <Hixie> | TabAtkins_: aw man, i thought we'd done away with the idea of selecting anything but the end of the selector years ago |
| 21:37 | <Hixie> | TabAtkins_: how did that make a comeback? |
| 21:38 | <AryehGregor> | Gecko seems to refuse to do anything, even if it would make sense to do something. WebKit seems to just eat the editing host. |
| 21:39 | <TabAtkins_> | Hixie: It's a persistent author request. |
| 21:39 | <AryehGregor> | Opera behaves somewhat sensibly, for once. |
| 21:39 | <AryehGregor> | TabAtkins_, I thought it will kill perf. |
| 21:39 | <Hixie> | TabAtkins_: doesn't :matches() take care of it? |
| 21:39 | <AryehGregor> | ?foo bar = ancestor selector. |
| 21:39 | <TabAtkins_> | AryehGregor: That's the fear. We're pushing to see if we can get around that, or at least make it "good enough". |
| 21:39 | <Hixie> | or :has()? |
| 21:39 | <TabAtkins_> | Hixie: ? is equivalent to :has(), if you limit :has() to the end of the selector. |
| 21:39 | <TabAtkins_> | (I prefer :has().) |
| 21:40 | <AryehGregor> | TabAtkins_, how is it even conceptually possible to support ?foo bar without killing perf? |
| 21:40 | <Hixie> | TabAtkins_: so why '?" |
| 21:40 | <TabAtkins_> | AryehGregor: Shrug. Browsers be crazy. |
| 21:40 | <Hixie> | wow i got confused with punctuation there |
| 21:40 | <Hixie> | let me try that again |
| 21:40 | <Hixie> | TabAtkins_: so why "?"? |
| 21:40 | <TabAtkins_> | Hixie: Because fantasai prefers that, and she's the Selectors editor. |
| 21:40 | <Hixie> | aah |
| 21:40 | <Hixie> | well that makes sense |
| 21:40 | <Hixie> | ok |
| 21:41 | AryehGregor | would prefer a :thingie(), to avoid more cryptic punctuation in CSS |
| 21:41 | <AryehGregor> | What does :has() do? |
| 21:41 | <TabAtkins_> | AryehGregor: Matches an element if it has something. |
| 21:41 | <AryehGregor> | Meaning? |
| 21:41 | <AryehGregor> | Like a descendant or something? |
| 21:41 | <TabAtkins_> | So, to match a label that has an invalid input, do "label:has( :scope /for/ :invalid )" |
| 21:41 | <Hixie> | :has() is like :matches() except that the selector is assumed to start with a simple selector that selects the element on which the pseudo is |
| 21:41 | <AryehGregor> | That sounds like it would suffer from the same horrible perf issues. |
| 21:41 | <AryehGregor> | What's wrong with :for()? |
| 21:42 | <AryehGregor> | Could we keep syntax simple here? |
| 21:42 | <Hixie> | and yes, :matches, :has, and ? are all horrible for perf |
| 21:42 | <Hixie> | i'm surprised browsers are ok with any of them |
| 21:42 | <TabAtkins_> | AryehGregor: :for() only goes one way. |
| 21:42 | <TabAtkins_> | Hixie: Nobody's implemented one yet. ^_^ |
| 21:42 | <AryehGregor> | I doubt anyone will, based on past statements. |
| 21:42 | <TabAtkins_> | AryehGregor: In general, /foo/ is a reference combinator, following the idref named in the combinator. |
| 21:42 | <AryehGregor> | Except perhaps for querySelector(). |
| 21:43 | <TabAtkins_> | We don't yet have an established syntax for functional combinators. |
| 21:43 | <TabAtkins_> | Though perhaps we should invent one. |
| 21:44 | <annevk> | the /idref/ thing is crazy though, because it also works for elements that do not have a predefined relationship |
| 21:47 | <Hixie> | annevk: no different from how [foo~=bar] also works for attributes that don't exist or don't take a space-separated list |
| 21:52 | <hsivonen> | I see "This might be overkill." in the commit message for "palpable content". No kidding. |
| 21:52 | hsivonen | mumbles about the time when Opera ignored empty paragraphs thanks to HTML4 |
| 21:53 | <Hixie> | heh |
| 21:53 | <Hixie> | at least this text clearly only applies to conformance checkers, or even not those but to linters. |
| 21:58 | <ojan> | Hixie: webkit and gecko have implemented :matches, but as :any |
| 21:58 | <ojan> | Hixie: why is :matches bad for perf? |
| 21:59 | <TabAtkins_> | ojan: Hixie's talking about something else that happens to have the same name. |
| 21:59 | <ojan> | oh |
| 21:59 | <Hixie> | ojan: what does :any() do? |
| 21:59 | <ojan> | um...ok |
| 21:59 | <TabAtkins_> | ojan: His old proposal, basically identical to :has(), was called :matches(). |
| 21:59 | <TabAtkins_> | Hixie: :any() takes a list of selectors, and matches any of them. |
| 21:59 | <ojan> | TabAtkins_: oh, that's totally different |
| 21:59 | <ojan> | nm |
| 21:59 | <TabAtkins_> | Hixie: It can be thought of as a selector macro. |
| 21:59 | <Hixie> | simple selectors, or selector chains? |
| 22:00 | <Hixie> | as in, are combinators involved? |
| 22:00 | <ojan> | Hixie: it's currently specced as "a sequence of simple selectors" i believe |
| 22:00 | <TabAtkins_> | Hixie: ":any(ul,ol) :any(ul,ol) {}" is equal to "ul ul, ul ol, ol ul, ol ol". |
| 22:00 | <ojan> | Hixie: currently no |
| 22:00 | <Hixie> | ah ok |
| 22:00 | <Hixie> | so basically just an "or" |
| 22:00 | <ojan> | Hixie: yeah |
| 22:00 | <TabAtkins_> | Hixie: Yeah, no combinators. List of compound selectors. |
| 22:00 | <TabAtkins_> | Using the current Selectors4 terminology. |
| 22:00 | <ojan> | even with combinators it would still just be an "or" no? |
| 22:00 | <annevk> | Hixie, true enough, not sure how much sense that made |
| 22:00 | <ojan> | any(div > span, #foo) |
| 22:00 | <TabAtkins_> | ojan: It's less clear what's going on if combinators are involved, unless you define it basically as a macro. |
| 22:01 | <ojan> | TabAtkins_: i don't see what's unclear about it |
| 22:01 | <TabAtkins_> | (I think it *should* be defined that way.) |
| 22:01 | <ojan> | TabAtkins_: I guess I only see one way to define it |
| 22:02 | <ojan> | TabAtkins_: conceptually, when seeing if a element matches the selector, you evaluate each selector in the list and it matches if any of them do. |
| 22:02 | <ojan> | TabAtkins_: what am i missing? |
| 22:02 | <TabAtkins_> | ojan: Another way to define it is to match an element to any of the selectors within. It's somewhat less clear what that means if you have complex selectors. |
| 22:03 | <ojan> | TabAtkins_: i don't understand the difference |
| 22:03 | <TabAtkins_> | ojan: You *can't* just say "does the element match 'div span' or 'p' in ':any(div span, p)'?". |
| 22:03 | <TabAtkins_> | "foo :any(bar baz, qux)" is equivalent to "foo bar baz, foo qux", not "foo bar baz, foo qux, bar foo baz". |
| 22:04 | <TabAtkins_> | There's an ordering constraint in there. |
| 22:04 | <Hixie> | wow that's confusing |
| 22:04 | <ojan> | TabAtkins_: yes, i don't see how that's controversial |
| 22:04 | <ojan> | or confusing |
| 22:04 | <ojan> | it seems to me like the obvious meaning |
| 22:04 | <ojan> | Hixie: which one is confusing? |
| 22:04 | <TabAtkins_> | ojan: If you define it as just "does the element match any of the arguments?", it's unclear which of those interpretations you want. |
| 22:05 | <TabAtkins_> | I think it's obvious, yes, but you have to define it properly. |
| 22:05 | <Hixie> | ojan: that :any(...).a > :any(...).b might match a situation where .a and .b are not parent and child respectively |
| 22:05 | <TabAtkins_> | Hixie: No, you misunderstand. |
| 22:05 | <ojan> | TabAtkins_: sure, but if you define it the obvious way, what is the perf problem? |
| 22:06 | <ojan> | Hixie: i don't see how |
| 22:06 | <TabAtkins_> | Hixie: In ".a :any(.b .c, .d)", if you go with the 'simple' interpretation of "does the element match any selector, when evaluated globally?", the following are equivalent: |
| 22:06 | <TabAtkins_> | .a .b .c, .b .a .c, .a.b .c, .a .d |
| 22:07 | <TabAtkins_> | Because the unrestricted "does it match?" question loses the constraints you want. |
| 22:07 | <Hixie> | TabAtkins_: so what does :any(q r, s).a > :any(w x, y).b expand to? |
| 22:07 | <TabAtkins_> | In the *proper* way of doing it, or the sillier way I just talked about? |
| 22:07 | <ojan> | TabAtkins_: lets just talk the proper way |
| 22:08 | <ojan> | TabAtkins_: the silly way is clearly crazy |
| 22:08 | <Hixie> | TabAtkins_: whatever you think is the right way |
| 22:08 | <TabAtkins_> | In the proper way, it's "q r.a > w x.b, q r.a > y.b, s.a > w x.b, s.a > y.b". |
| 22:08 | <Hixie> | ok so like i said, it means :any(...).a > :any(...).b might match a situation where .a and .b are not parent and child respectively |
| 22:08 | <TabAtkins_> | Huh? |
| 22:08 | <TabAtkins_> | How did you get that? |
| 22:09 | <Hixie> | it can match in a situation where <r class=a> is the grandparent of <x class=b> |
| 22:09 | <TabAtkins_> | Oh, yes. |
| 22:09 | <TabAtkins_> | If you allow complex selectors, not just compound. |
| 22:10 | <ojan> | Hixie: oh i see...meh. i don't see the problem with that. |
| 22:10 | <ojan> | Hixie: it's a contrived example that you wouldn't really hit in the real world |
| 22:10 | <Hixie> | on what do you base that? |
| 22:10 | <TabAtkins_> | Hixie: Right now, though, we restrict it to taking compound selectors. |
| 22:11 | <ojan> | Hixie: let me rephrase.... |
| 22:11 | <TabAtkins_> | So the .a and .b elements will always have a parent-child relationship. |
| 22:11 | <ojan> | Hixie: what TabAtkins_ said...there is always a parent-child relationship there... |
| 22:11 | <Hixie> | come gain? |
| 22:11 | <ojan> | Hixie: which, if you were to write it without :any would have the same problem |
| 22:11 | <TabAtkins_> | ojan: No, Hixie's right given the higher-powered version of :any |
| 22:12 | <Hixie> | now i'm really confused :-P |
| 22:12 | <ojan> | Maybe i'm not understanding.... |
| 22:12 | <TabAtkins_> | ojan: It's just that, in the current spec, we have a lower-powered version that doesn't have the problem. |
| 22:12 | <Hixie> | but we may be talking at cross-purposes |
| 22:12 | <ojan> | we need a DOM for this example |
| 22:12 | <TabAtkins_> | "problem" |
| 22:12 | <Hixie> | anyway |
| 22:12 | <ojan> | TabAtkins_: i get that the current version doesn't have the issue |
| 22:12 | Hixie | goes back to picketing for his original :matches(), despite the perf isues |
| 22:12 | <ojan> | in either case, there's no perf issue if we allow combinators |
| 22:12 | <ojan> | it's just a question of whether the semantics are confusing |
| 22:13 | <TabAtkins_> | Hixie: You really need to stop calling it "matches". It confuses everyone else. ^_^ |
| 22:13 | <TabAtkins_> | ojan: Yes, that's right. |
| 22:13 | <ojan> | =TabAtkins_ |
| 22:13 | <ojan> | :matches is way overloaded now |
| 22:13 | <Hixie> | TabAtkins_: hey, dude, i made it up first. :-P |
| 22:13 | <TabAtkins_> | Hixie: Too bad! |
| 22:13 | <Hixie> | TabAtkins_: plus, :matches() is _exactly_ what it does |
| 22:13 | <ojan> | I still would like to see the selectors4 spec s/matches/any/ |
| 22:13 | <Hixie> | TabAtkins_: the other one should be renamed :or() |
| 22:13 | <AryehGregor> | Can anyone else reproduce this? http://code.google.com/p/chromium/issues/detail?id=101791 |
| 22:14 | <ojan> | I'd be fine with :or or :any |
| 22:14 | <TabAtkins_> | Hixie: :or() is confusing, because we're used to "or" coming *between* options, rather than being the name of a function that precedes the options. |
| 22:14 | <TabAtkins_> | ojan: Agreed that :any() is better. |
| 22:14 | <Hixie> | :any() wfm too |
| 22:14 | <ojan> | Hixie: you have a pointer to your :matches proposal? |
| 22:14 | <ojan> | i saw it ages ago, but i don't remember how it worked now |
| 22:14 | <TabAtkins_> | AryehGregor: wfm (no sad tab) |
| 22:15 | <AryehGregor> | TabAtkins_, what version/platform? |
| 22:15 | annevk | also thought renaming it to :matches was weird |
| 22:15 | <TabAtkins_> | ojan: Linux 64bit, Chrome 15 beta. |
| 22:15 | <TabAtkins_> | I mean AryehGregor in that last line. |
| 22:15 | <AryehGregor> | It's a regression. |
| 22:15 | <Hixie> | ojan: not off-hand, it'll be in www-style around 2002 or so. But in principle, :matches(...) takes a selector that must be matched by the eelement on which the pseudo is given |
| 22:15 | <AryehGregor> | Only started in Chrome 16, I think. |
| 22:15 | <AryehGregor> | It used to work for me too. |
| 22:15 | <TabAtkins_> | Ah, kk. Let me upgrade. |
| 22:16 | <Hixie> | ojan: so p:matches(.a .b) is equivalent to .a p.b |
| 22:16 | <AryehGregor> | Thanks. |
| 22:16 | <Hixie> | ojan: but p:matches(.a .b):matches(.x .b) is equivalent to saying that the p.b element must have as ancestor both a .x and a .a, though it doesn't matter if they're the same or if not which is the deeper ancestor |
| 22:17 | <ojan> | Hixie: why is this better? |
| 22:17 | <Hixie> | ojan: (the only other aspect is that you can use "#" in the :matches() selector to say where the pseudo's element is to match, as in p:matches(a # b) is equivalent to "a p b") |
| 22:17 | <Hixie> | ojan: better than what? |
| 22:17 | <ojan> | than :any |
| 22:17 | <TabAtkins_> | ojan: Don't try and compare it to the Selectors4 :matches. They're not the same thing. |
| 22:17 | <Hixie> | ojan: :any and :matches are unrelated |
| 22:18 | <TabAtkins_> | Completely different function. |
| 22:18 | <ojan> | oh...so they're not mutually exclusive |
| 22:18 | <ojan> | i see |
| 22:18 | <ojan> | what's the use-case for Hixie's :matches? |
| 22:18 | <TabAtkins_> | ojan: The same use-case as :has() or the subject indicator. |
| 22:18 | <Hixie> | ojan: (:any() would complement :matches() quite well in fact) |
| 22:18 | <Hixie> | ojan: :has() is basically :matches() but always starting with the # |
| 22:18 | <Hixie> | ojan: as in :has(foo) is equivalent to :matches(# foo) |
| 22:19 | <ojan> | i see |
| 22:19 | <Hixie> | ojan: :matches() basically solves almost all the limitations of selectors in one simple (and performance-impacting) swoop. |
| 22:19 | <Hixie> | well, not all the limitations |
| 22:19 | <Hixie> | it doesn't help with grouping |
| 22:19 | <Hixie> | but all the limitations of being able to reference ancestors, descendants, etc |
| 22:19 | <ojan> | oh i see...because it gives one syntactic way of doing all the things we're adding extra stuff for (e.g. parent combinators) |
| 22:20 | <Hixie> | yeah |
| 22:20 | <ojan> | makes sense to me |
| 22:20 | <ojan> | and it gives one thing to tell web devs not to ever use because it's crazy slow |
| 22:20 | <Hixie> | yeah |
| 22:20 | <ojan> | instead of a dozen tthings |
| 22:20 | <ojan> | i buy it |
| 22:20 | <Hixie> | mind you, it really does make it _crazy_ slow |
| 22:21 | <ojan> | i expect it does in degenerate cases |
| 22:21 | <ojan> | but i haven't really thoguht it through |
| 22:21 | <AryehGregor> | This is why I'm so much more interested in filing bugs against Gecko than any other piece of software I know about: https://bugzilla.mozilla.org/show_bug.cgi?id=697793 |
| 22:21 | <Hixie> | :matches(# .foo) -- matches every element that has a .foo descendant. imagine a 5mb doc like the html spec. |
| 22:21 | <Hixie> | for every element, you have to crawl the entire subtree |
| 22:21 | <AryehGregor> | It should be fine for querySelector(), right? |
| 22:22 | <Hixie> | AryehGregor: well it'd still be slow, but it wouldn't have to happen every time the mouse moved, at least |
| 22:22 | <AryehGregor> | I mean, it might be slow, but authors have the tools to notice that. |
| 22:22 | <Hixie> | (:focus:matches(# :hover) *shudder*) |
| 22:22 | <ojan> | Hixie: ok...you've sold me. :matches makes sense to add and what's currently :matches should really be :any. |
| 22:22 | <Hixie> | sweet |
| 22:22 | <Hixie> | i wasn't even trying to sell you :-) |
| 22:23 | <AryehGregor> | Allowing such a thing in actual CSS files sounds like a seriously bad idea. |
| 22:23 | <ojan> | AryehGregor: we should either allow none of them, or add something generic like :matches |
| 22:23 | <annevk> | Hixie, cache manifests don't seem to allow for FF, maybe it should simply be banned from text/vtt? |
| 22:23 | <ojan> | AryehGregor: what we seem to be doing currently is adding a bunch of one-offs |
| 22:23 | <Hixie> | AryehGregor: it's certainly better than $ or ? or < or :has(), so if we're adding any of those, we should just do :matches(), imho |
| 22:24 | <ojan> | =Hixie |
| 22:24 | <Hixie> | annevk: *shrug* |
| 22:24 | <ojan> | I'd also be OK with not adding any of them. |
| 22:24 | <annevk> | Y U NO CARE |
| 22:25 | <ojan> | annevk: will you be in town for TPAC? |
| 22:25 | <Hixie> | bbiab, meeting |
| 22:25 | <hober> | ojan: annevk: there will be beers involved (re: tpac) |
| 22:26 | <ojan> | it'll be nice to meet everyone in person |
| 22:28 | <annevk> | I'm coming on Sunday |
| 22:28 | <annevk> | and yes, I'm looking forward to meeting everyone too :) |
| 22:29 | <ojan> | annevk: are you staying in SF or the south bay while you're here? |
| 22:29 | <annevk> | and beers :) |
| 22:29 | <annevk> | I'm staying in Santa Clara but might go to SF in the weekend |
| 22:30 | <annevk> | after not sure yet, leaving the ninth |
| 22:30 | <ojan> | annevk: k. i'll probably only be at tpac monday and tuesday, but i live/work in SF. |
| 22:31 | <annevk> | ah, in the Google SF office? |
| 22:31 | <ojan> | annevk: yeah |
| 22:31 | <annevk> | cool |
| 22:31 | <ojan> | annevk: you're welcome to come for lunch here one day |
| 22:31 | <annevk> | might take you up on that :) |
| 22:31 | <wycats> | Hixie: hey... I was wondering why the new validation events don't bubble |
| 22:32 | <wycats> | there's an open thread on the jQuery Standards list about it :) |
| 22:32 | <ojan> | annevk: a lot of the chromium folk who work on webkit work in SF |
| 22:33 | <ojan> | annevk: we should chat in person about the various dom creation proposals |
| 22:33 | <wycats> | ojan: what do you think about the Element constructor proposal? |
| 22:33 | <ojan> | wycats: which one? |
| 22:34 | <wycats> | I guess the one that takes an object of attributes and children? |
| 22:34 | <ojan> | wycats: there are things i really like about it and things i like less... |
| 22:34 | <ojan> | wycats: well...there are multiple such proposals... |
| 22:35 | <annevk> | ojan, yeah that'd be nice |
| 22:35 | <ojan> | wycats: the one i really like is the one annevk suggested with the funky json/array syntax |
| 22:35 | <ojan> | wycats: the thing i really like about that is that in theory, you can construct DOMs much faster than you could if you needed to parse HTML |
| 22:35 | <wycats> | ojan: I like it too |
| 22:35 | <ojan> | wycats: on the other hand, it's not terribly readable |
| 22:36 | <wycats> | ojan: the fact that new DivElement straight up doesn't work today is pretty broken |
| 22:36 | <wycats> | ojan: I was thinking that allowing a tagName as first param might make it more readable |
| 22:36 | <wycats> | new Element("div", { id: "zomg" }) |
| 22:36 | <ojan> | i've slowly come to believe that the quasis approach may be the best |
| 22:36 | <ojan> | wycats: yeah, it's hard to come up with a syntax that works better than what annevk suggested |
| 22:37 | <wycats> | ojan: I think the only thing I could improve over annevk would be allowing new Element instead of new FooElement |
| 22:37 | <ojan> | wycats: because i think it's important we maintain that passing just a string can get you a text node |
| 22:37 | <wycats> | ah interesting |
| 22:37 | <wycats> | even to new Element |
| 22:37 | <wycats> | I guess the problem is that new Element wouldn't return a direct instance of Element |
| 22:37 | <ojan> | maybe not...but then what do you for the children case |
| 22:37 | <wycats> | you would want new Element("div") to return a DivElement |
| 22:38 | <ojan> | new Element(tagName, attributes, children...) |
| 22:38 | <wycats> | new Element("div", { id: "foo" }, [ new Element("span"), "some text" ]) |
| 22:38 | <ojan> | Needing to repeat "new Element" when constructing the children is too bloated IMO |
| 22:38 | <ojan> | it's less readable and just too much typing |
| 22:38 | <wycats> | ojan: you could allow a hash, I guess? |
| 22:38 | <ojan> | remember the thing we're competing with is innerHTML here |
| 22:39 | <wycats> | new Element("div", { id: "foo" }, [ { span: { id: "hi", children: ["string", { em: ["some text"] }] } } ]) |
| 22:39 | <ojan> | if i could have my cake and eat it too, right now I'd want to see us implement *both* annevk's array-based proposal and quasis with a native "html" function. |
| 22:39 | <ojan> | they're not actually mutually exclusive in any way |
| 22:40 | <TabAtkins_> | ojan: Yes, both are complementary for different things. |
| 22:40 | <ojan> | and actually meet different use-cases, althought there is certainly overlap |
| 22:40 | <ojan> | and annevk's array-based proposal is really straightforward to spec and implement, so it doesn't really present a burden on browser vendors |
| 22:41 | <ojan> | annevk: i liked the E4H proposal at first, but people have convinced me that quasis are a better solution...we can chat about it in person next week |
| 22:42 | <wycats> | ojan: the most useful thing for jQuery would be the ability to do fragment.innerHTML = "<tr><td>hi</td></tr>" |
| 22:42 | <wycats> | essentially have a way to make HTML nodes where the root nodes don't care about their context |
| 22:43 | <wycats> | we jump through major hoops in jQuery to make $("<tr><td>hi</td></tr>").appendTo("table") work |
| 22:43 | <ojan> | wycats: yeah...i agree it's totally balls |
| 22:43 | <ojan> | wycats: but all of these proposals address that use-case fine |
| 22:43 | <wycats> | ojan: not really |
| 22:43 | <wycats> | because the jQuery API is "gimme string" |
| 22:43 | <wycats> | not "gimme some structure" |
| 22:44 | <wycats> | I see the new APIs as competing with document.createElement more than innerHTML tbh |
| 22:44 | <kennyluck> | Is there any problem if browsers ignore media type of a manifest? I think this was probably discussed to death but I would be grateful if someone reminds me again. |
| 22:44 | <ojan> | wycats: but if you implement $("<tr><td>hi</td></tr>") in terms of the new API, it should just work, no? |
| 22:44 | <wycats> | how do we do that? |
| 22:45 | <wycats> | parse the HTML manually? |
| 22:45 | <ojan> | hm...i guess you're right...this doesn't help jquery at all. |
| 22:46 | <wycats> | "[ |
| 22:46 | <wycats> | :p |
| 22:47 | <ojan> | wycats: i think it's an orthogonal issue...erik arvidsson made a proposal recently to whatwg@ make createContextualFragment do what you want if the range is in a detached context |
| 22:47 | <wycats> | ojan: nice |
| 22:47 | <ojan> | wycats: i'm still pro that as the solution to your problem |
| 22:47 | <wycats> | ojan: do you know what the subject line is? |
| 22:47 | <wycats> | ojan: I think right now that case throws an error |
| 22:48 | <ojan> | wycats: yeah, so it's probably backwards compatible to change it... |
| 22:48 | <ojan> | wycats: "createContextualFragment in detached contexts" |
| 22:48 | <wycats> | ojan: I'll go +1 |
| 22:48 | <wycats> | it would save a ton of work in jQuery |
| 22:48 | <wycats> | I was able to make jQuery a lot faster in the case of $("table").append("<tr><td>...</td></tr>") |
| 22:49 | <wycats> | because I have a context for a contextual fragment in that case |
| 22:58 | <hober> | Hixie: thanks for the Emacs examples in r6773 :) |