| 00:11 | <TabAtkins> | ...huh. I'm not sure how this happened, but somehow an unsaved file persisted in my text editor across two reboots. |
| 00:22 | <TabAtkins> | People come up with the craziest hacks. I've got an email from somebody who is trying to avoid preloading all their slide images individually by first compiling them all into a video, one slide per frame, then drawing the video to <canvas> to extract the images back out. |
| 00:51 | <erlehmann> | TabAtkins, madness. you should start a blog, html5fail or something like that :> |
| 03:34 | <MikeSmith> | abarth: congrats on the RFC publication |
| 06:29 | <abarth> | MikeSmith: thanks! |
| 06:32 | <MikeSmith> | abarth: btw, tools.ietf.org doesn't seem to have the draft-abarth-url-01 yet |
| 06:32 | <abarth> | http://tools.ietf.org/html/draft-abarth-url-01 |
| 06:32 | <abarth> | works for me |
| 06:32 | <MikeSmith> | ah |
| 06:33 | <MikeSmith> | I was going to http://tools.ietf.org/html/draft-abarth-url-00 |
| 06:33 | <MikeSmith> | and expecting it to have an 01 link there |
| 06:33 | <MikeSmith> | after Versions: |
| 06:33 | <abarth> | i see the 01 link |
| 06:33 | <MikeSmith> | ah dammit |
| 06:33 | <MikeSmith> | caching |
| 06:34 | <MikeSmith> | yeah, wfm now too |
| 06:36 | <MikeSmith> | abarth: btw, I don't quite know what to make of Julian's comment about the draft not "having any resemblance to the kind of document the WG should deliver" |
| 06:36 | <MikeSmith> | http://lists.w3.org/Archives/Public/public-iri/2011Apr/0059.html |
| 06:37 | <MikeSmith> | I've not gotten the impression that others in the IRI group see it that way |
| 06:37 | <abarth> | he doesn't like the document because it's different from previous specs |
| 06:37 | <abarth> | it's not clear anyone besides browsers should care about this document |
| 06:38 | <MikeSmith> | well, both those things are somewhat true about a lot of recent specs |
| 06:39 | <MikeSmith> | I think the answer to the last one is, applications that what to interoperate with browser behavior should do know what browsers do, and do it too |
| 06:39 | <MikeSmith> | *want to interoperate |
| 06:39 | <abarth> | that's true |
| 06:39 | <abarth> | my plan is to just continue working on the doc |
| 06:39 | <MikeSmith> | good |
| 06:40 | <abarth> | i think there's a good chance that the working group won't like it in the end |
| 06:40 | <abarth> | or it will get knocked down to informational |
| 06:40 | <abarth> | or whatever |
| 06:40 | <abarth> | but that's all fine |
| 06:40 | <abarth> | the important part is to get it written down and get folks to improve their interoperability |
| 06:40 | <MikeSmith> | yes |
| 06:41 | <MikeSmith> | to and to have something that the HTML5 spec can reference |
| 06:49 | <Hixie> | wget should care about this document |
| 06:50 | <Hixie> | google's crawler should care about this document |
| 06:50 | <Hixie> | wysiwyg editors should care about this document |
| 08:45 | <MikeSmith> | touch events landed in mozilla central? |
| 08:46 | <MikeSmith> | does it need be enabled through a compile flag, or is it enabled by default? |
| 08:46 | <MikeSmith> | hmm, user pref? |
| 09:16 | <zcorpan> | should we add ownerWindow to everything so that we can do foo instanceof foo.ownerWindow.Bar ? |
| 09:18 | <zcorpan> | or call it defaultView to match up with document.defaultView |
| 09:18 | <jgraham> | zcorpan: That sounds mildly hideous |
| 09:19 | <zcorpan> | have a better suggestion? :) |
| 09:20 | jgraham | wonders if the model driven views people have thought of using attributes and elements for their templating rather than {{foo}} |
| 09:21 | <jgraham> | zcorpan: Realise it is an edge case you only hit when running tests and move on? |
| 09:21 | <hsivonen> | was the model-driven views thing a plan for a JS lib or for a Chrome feature_ |
| 09:21 | <hsivonen> | ? |
| 09:21 | <jgraham> | (as gsnedders pointed out it wouldn't help for ES builtins) |
| 09:21 | <jgraham> | hsivonen: AIUI it is a plan for a platform feature |
| 09:22 | <jgraham> | that has been demoed as a js lib |
| 09:22 | <zcorpan> | jgraham: i like that suggestion |
| 09:22 | <hsivonen> | jgraham: so why does it need to be a platform feature rather than a JS lib? |
| 09:22 | <MikeSmith> | jgraham: pimpmyspec is generating 2010 in the W3C copyright |
| 09:23 | <jgraham> | hsivonen: "FAQ item also coming for this. |
| 09:23 | <jgraham> | " |
| 09:23 | <jgraham> | MikeSmith: Umm, does that have anything to do with me? Where does it get that year from? |
| 09:23 | <MikeSmith> | from anolis |
| 09:23 | <MikeSmith> | doesn't it? |
| 09:24 | <MikeSmith> | oh wait |
| 09:24 | <jgraham> | No idea |
| 09:24 | <MikeSmith> | maybe my fault |
| 09:24 | <jgraham> | I just provide the hosting :p |
| 09:24 | <MikeSmith> | probably I have to change it in the boilerplate |
| 09:28 | <othermaciej> | hsivonen: the guy working on it thinks it should be a Web platform feature |
| 09:29 | <othermaciej> | not all folks in the WebKit community are necessarily in tune with his thinking |
| 09:29 | <othermaciej> | I asked him what is wrong with leaving it a library and he had a very short list of things that couldn't be made efficient from pure JS/DOM code |
| 09:29 | <othermaciej> | and I said, "why not just make a modest platform enhancement to fix those few things, so all the existing JS library templating systems can benefit" |
| 09:30 | <othermaciej> | he didn't really have a good argument except for his belief that his JS templating library that he just invented is better than all others ever written |
| 09:32 | <hsivonen> | othermaciej: I was guessing it was something like that. :-( |
| 09:33 | <othermaciej> | well, if other folks in the relevant standards body express similar views, then it will likely influence the direction of what gets standardized and/or implemented |
| 09:33 | <jgraham> | I haven't studied it in detail but it seems like something that is becoming increangly common, but might be a world of pain to implement in the browser |
| 09:34 | <othermaciej> | hsivonen: I even told him the parable of querySelector() and how it seems more important to make a feature that can be smoothly adopted by JS libs than one that aims to replace them through direct use |
| 09:34 | <othermaciej> | there's also the fact that this is similar to but not quite the same as XBL |
| 09:34 | <othermaciej> | I wasn't clear on why it needs to be separate |
| 09:35 | <jgraham> | Like all the special casing they seem to want for their stuff is freaking me out a bit |
| 09:37 | <jgraham> | Oh and they want magic comments :( |
| 09:45 | othermaciej | makes a mental note to read this thread |
| 09:57 | <othermaciej> | ok, replied to it |
| 10:19 | <zcorpan> | does transitioning between height:0 and height:auto work yet? |
| 10:21 | <jgraham> | I don't think so |
| 10:21 | <jgraham> | It really needs to though |
| 10:22 | <zcorpan> | yeah. truly annoying |
| 10:23 | <zcorpan> | that's basically the only thing i want to transition |
| 10:23 | <zcorpan> | well that and opacity |
| 11:56 | <hsivonen> | Has the Chrome team yet announced which Chrome release train will drop H.264? |
| 13:21 | <mpilgrim> | hsivonen: no. last i heard, google was still "working with partners" and get them to convert to webm or something |
| 13:22 | <mpilgrim> | not sure which partners, and i probably couldn't tell you even if i was in the loop, which i'm not |
| 13:23 | <hsivonen> | mpilgrim: I see. Thanks. |
| 13:23 | <mpilgrim> | but it's still in the cards, AFAIK |
| 13:23 | <mpilgrim> | "real soon now" :) |
| 13:25 | <jgraham> | I guess I was naive to assume it already happened months ago |
| 13:26 | <hsivonen> | It seems to me that in Finland, WebM-enabled browser have already surpassed H.264-enabled browsers in StatCounter usage share, but the numbers would be more impressive if Chrome didn't count towards both |
| 13:26 | <hsivonen> | *browsers |
| 13:27 | <MikeSmith> | hsivonen: really? that's pretty surprising |
| 13:28 | <hsivonen> | MikeSmith: Safari 3.1 or higher plus IE9: 9% |
| 13:29 | <hsivonen> | MikeSmith: Opera 10.6 or higher plus Firefox 4: 15% |
| 13:29 | <mpilgrim> | my dog is sleeping on my foot |
| 13:29 | <mpilgrim> | and now my foot is asleep |
| 13:29 | <mpilgrim> | the circle of life |
| 13:30 | <hsivonen> | MikeSmith: excludes phone browsers but includes iPad, AFAICT |
| 13:30 | <mpilgrim> | chrome 12.0.742.9 dev still supports H.264, that's the latest version i have |
| 13:34 | <hsivonen> | I'm now at the point with about:blank where I can't trust test cases because getElementsByTagName and getElementById stopped working |
| 13:34 | <jgraham> | ? |
| 13:35 | <hsivonen> | jgraham: I have no idea, either |
| 13:38 | <MikeSmith> | mpilgrim: I wishes I had a dog that falls asleep on my foot |
| 13:38 | <MikeSmith> | I want a french bulldog that slobbers all over everything |
| 13:39 | <MikeSmith> | hsivonen: I am struggling with this case of nested figure/figcaption and determining if the have text content that makes img alt required |
| 13:40 | <hsivonen> | MikeSmith: putting the flags on the stack node didn't help? |
| 13:41 | <mpilgrim> | i have a 48 lb. beagle/basset named Beauregard who slobbers all over everything |
| 13:41 | <mpilgrim> | he's awesome |
| 13:42 | <MikeSmith> | hsivonen: it helps but when I am in the characters method, I don't know how to check for text nodes only within the nested figure/figcaption, rather than all the way up through all the figure/figcaption in the tree |
| 13:43 | <MikeSmith> | mpilgrim: if I had a 48 lb dog in my apartment in tokyo, I would have little room left to move around |
| 13:44 | <MikeSmith> | the biggest living thing I've had staying in my apartment is Anne |
| 13:44 | <MikeSmith> | who's just slightly more than 48 lb. |
| 13:45 | <hsivonen> | MikeSmith: you need to walk up the stack and flip flags on all the figcaptions or figures on the stack if I've understood the requirements right |
| 13:45 | <MikeSmith> | ok |
| 13:45 | <MikeSmith> | dammit |
| 13:45 | <MikeSmith> | I thought that's what you were going to say |
| 13:45 | <MikeSmith> | this thing is a PITA man |
| 13:45 | <MikeSmith> | fwiw, I knew I hadn't addressed the nested case when I sent you the patch for review |
| 13:46 | <MikeSmith> | I just think the nested case if pathological |
| 13:46 | <MikeSmith> | but oh well |
| 13:47 | <MikeSmith> | it's not unique in that regard |
| 14:09 | <MikeSmith> | wilhelm_: ping |
| 14:11 | <wilhelm_> | MikeSmith: Pong. |
| 14:12 | <MikeSmith> | wilhelm_: are you in Sweden or in Oslo? |
| 14:13 | <MikeSmith> | I'm trying to figure out when would be the best time to visit to talk to you all about testing stuff |
| 14:14 | <MikeSmith> | and I can go to Oslo if needed, but going to Linköping would be easier |
| 14:15 | <wilhelm_> | MikeSmith: Oslo. |
| 14:15 | <wilhelm_> | Linkøping is in the neighbourhood, though. Doesn't matter much to me. (c: |
| 14:15 | <MikeSmith> | hmm |
| 14:15 | <MikeSmith> | you cats can just al come and visit me |
| 14:15 | <MikeSmith> | ok |
| 14:15 | <wilhelm_> | Oh, yes. An excuse to come to Japan? (c; |
| 14:16 | <MikeSmith> | yeah man |
| 14:16 | <MikeSmith> | come here and sweat the pounds away during the summer time |
| 14:17 | <gsnedders> | Talk about a hard sell. |
| 14:18 | <MikeSmith> | wilhelm_: basically, what I want to do is this summer is either get some kind of common testing framework set up -- cross-WG/ cross-spec -- or… |
| 14:18 | <MikeSmith> | the "or…" part I dunno |
| 14:19 | <MikeSmith> | Philippe will kick my ass if we don't manage to get something set up |
| 14:19 | <MikeSmith> | or maybe by that time I'll be working somewhere else anyway |
| 14:20 | <MikeSmith> | wilhelm_: gsnedders and jgraham have been a big help so far in getting some useful stuff set up |
| 14:21 | <MikeSmith> | so would really be great to see if we can get their help and yours on expanding things a bit further |
| 14:21 | <MikeSmith> | Peter Lins has also been doing great stuff with getting test automation set up for CSS specs |
| 14:22 | <MikeSmith> | so it would also make a lot of sense to take a look at what he's done and see if we can generalize it |
| 14:22 | <MikeSmith> | or whatever the proper term is |
| 14:24 | <wilhelm_> | MikeSmith: Sounds great. |
| 14:26 | <MikeSmith> | wilhelm_: OK, so please get approval for you and jgraham and gsnedders to fly to Tokyo this summer for a visit |
| 14:26 | <MikeSmith> | and also zcorpan |
| 14:27 | <jgraham> | Heh |
| 14:27 | <MikeSmith> | I'll make some arrangements for accomodations |
| 14:27 | <zcorpan> | wait what? |
| 14:27 | <MikeSmith> | heh |
| 14:28 | <MikeSmith> | zcorpan: you are coming to Tokyo! |
| 14:28 | <zcorpan> | oh! |
| 14:28 | <zcorpan> | nice! |
| 14:28 | <MikeSmith> | yes |
| 14:28 | <MikeSmith> | thanks to wilhelm_ |
| 14:28 | <MikeSmith> | we gonna have a great time |
| 14:29 | <zcorpan> | how are we gonna fit in your apartment if you can't fit a dog? |
| 14:29 | <MikeSmith> | you dudes are going to have to all curl up |
| 14:29 | <MikeSmith> | snuggle |
| 14:30 | jgraham | doesn't like this plan much now |
| 14:30 | <MikeSmith> | or we can sleep in the park |
| 14:30 | <MikeSmith> | it'll be like a camping trip |
| 14:31 | <MikeSmith> | is gsnedders planning to go to Linköping this summer? |
| 14:32 | <jgraham> | No, apparently |
| 14:32 | <jgraham> | Or at least not for much of the summer |
| 14:33 | <MikeSmith> | hmm |
| 14:33 | <MikeSmith> | well, that sucks |
| 14:33 | <MikeSmith> | what the hell is he doing that's so important? |
| 14:34 | zcorpan | has 5 open bugs on html-differences, all seem trivial |
| 14:36 | <MikeSmith> | zcorpan: glad to see you closed out a bunch of them a couple weeks back |
| 14:36 | <MikeSmith> | those other ones |
| 14:37 | <MikeSmith> | so, thanks for that |
| 14:38 | <gsnedders> | MikeSmith: Sex, drugs, rock and roll. |
| 14:39 | <MikeSmith> | word. |
| 14:39 | <froggy> | Hello |
| 14:39 | <gsnedders> | MikeSmith: tl;dr version: I'll be in Oslo 15th–30th June, and then Göteborg till 4th July. I'll probably also be in Oslo near the end of the summer. |
| 14:40 | <MikeSmith> | huh? |
| 14:40 | <jgraham> | gsnedders: Liquorice is not a drug |
| 14:40 | <MikeSmith> | why Göteborg ? |
| 14:41 | <MikeSmith> | will jgraham and zcorpan and wilhelm_ be in Göteborg then too? |
| 14:41 | <gsnedders> | jgraham: huh? |
| 14:41 | <gsnedders> | jgraham: Oh, duh |
| 14:41 | <MikeSmith> | gsnedders: btw, in place of "sex", you need to "nastiness" |
| 14:41 | <gsnedders> | MikeSmith: Iron Maiden are playing. I have ticket from when I planned to be in Lkpg over the summer. |
| 14:41 | <zcorpan> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=10036 - should i remove the pointer to public-html-comments altogether? |
| 14:41 | <jgraham> | MikeSmith: I will be in England |
| 14:42 | <jgraham> | When gsnedders is in Göteborg |
| 14:42 | <zcorpan> | and i may be in one of Örebro, Linköping or Göteborg |
| 14:42 | <jgraham> | Well I might not be in England |
| 14:43 | <jgraham> | But I won't be in Göteborg |
| 14:43 | <gsnedders> | But you will be in !Lkpg |
| 14:43 | <MikeSmith> | seeing Iron Maiden perform live trumps everything |
| 14:43 | <MikeSmith> | no joke |
| 14:44 | <zcorpan> | >> !Lkpg |
| 14:44 | <zcorpan> | false |
| 14:44 | <MikeSmith> | Bruce Dickison is a god walking the earth |
| 14:44 | <gsnedders> | MikeSmith: There's a slight temptation to just see them here instead, but the SCEE is a terrible venue. |
| 14:45 | <jgraham> | zcorpan right shifted by !Lkpg gives false? |
| 14:45 | <jgraham> | What kind of messed up type system do you have? |
| 14:45 | <MikeSmith> | zcorpan: about bug 10036 |
| 14:45 | <MikeSmith> | I don't know what t suggest |
| 14:46 | <MikeSmith> | other than, "use your discrection" |
| 14:47 | <MikeSmith> | jgraham: making it difficult for me |
| 14:48 | <MikeSmith> | I am personally very happy to be in the same place as you all at the same time |
| 14:48 | <MikeSmith> | … |
| 14:48 | <gsnedders> | :D |
| 14:48 | <MikeSmith> | if we can find a place and time |
| 14:48 | <gsnedders> | MikeSmith: Are you still limited to May, or what's the plan now? |
| 14:49 | <MikeSmith> | I have no limits |
| 14:50 | <MikeSmith> | other than, I may have to pay the flight costs from my own pocket |
| 14:50 | <gsnedders> | Ow. |
| 14:50 | <MikeSmith> | no |
| 14:50 | <MikeSmith> | I am happy to do that if we can actually get together f2f and talk |
| 14:58 | <gsnedders> | MikeSmith: From my POV anytime apart from the above dates (or over them, for that matter, but given those specific locations) and the few days following them WFM. |
| 15:00 | <MikeSmith> | gsnedders: "above dates" = what? |
| 15:01 | <gsnedders> | MikeSmith: 14:44 < gsnedders> MikeSmith: tl;dr version: I'll be in Oslo 15th–30th June, and then Göteborg till 4th July. |
| 15:03 | <gsnedders> | MikeSmith: Of course, if wilhelm_ gets us all to Tokyo, all the better :P |
| 15:03 | <MikeSmith> | no joke |
| 15:04 | <MikeSmith> | youse should all just come to Tokyo for a couple weeks |
| 15:04 | <MikeSmith> | you will learn something |
| 15:05 | <jgraham> | How to survive an earthquake? |
| 15:06 | <gsnedders> | How to train your dragon? |
| 15:06 | <MikeSmith> | heh |
| 15:08 | <MikeSmith> | anyway, wring i Japan, you can focus on developing products according to actual paying-customer requiremenrts (rather than vague notions about end-users needs) |
| 15:09 | <gsnedders> | Customers? Pff. |
| 15:10 | <MikeSmith> | exactley |
| 15:10 | <MikeSmith> | let them eat cake |
| 15:10 | <wilhelm_> | Mm. Cake. |
| 15:11 | <gsnedders> | MikeSmith: You know, saying that the week after Portal 2 came out… |
| 15:11 | <bfrohs> | The cake is a lie. |
| 15:11 | <Philip`> | That game's got almost nothing to do with cake :-( |
| 15:12 | <zcorpan> | Zarro Boogs found. |
| 15:12 | <zcorpan> | w00t |
| 15:12 | <jgraham> | Zarro Cake also |
| 15:12 | <jgraham> | :( |
| 15:13 | <zcorpan> | mmm, cake. reminds me, time to stop working, make coffee, wake up wife and eat cake |
| 15:13 | <jgraham> | I take it she is working quite strange hours? |
| 15:14 | <zcorpan> | she's a baker |
| 15:14 | <jgraham> | Otherwise it sounds a bit like Marie Anoinette |
| 15:14 | <jgraham> | Well yes, I know |
| 15:14 | <zcorpan> | not so strange hours if you're a baker :) |
| 15:14 | <gsnedders> | jgraham: Better than sounding like Othello, though |
| 15:15 | <jgraham> | zcorpan: Fair enough |
| 15:17 | <jgraham> | gsnedders: Get back to work! |
| 15:17 | <gsnedders> | jgraham: Yeah, true, I have an exam tomorrow. |
| 15:18 | <gsnedders> | jgraham: But I had to go and get a copy of Still Alive |
| 15:18 | <Philip`> | Tomorrow morning, or do you still have plenty of time? |
| 15:18 | <gsnedders> | Philip`: 9:30 tomorrow morning |
| 15:19 | <Philip`> | Ah, not so much then |
| 15:26 | <gsnedders> | Philip`: Also: Portal has *plenty* to do with cake. GLaDOS keeps promising me some. :'( |
| 15:28 | <Philip`> | But Portal 2 doesn't, because Valve are better at moving on from tired memes than the rest of the internet is :-p |
| 15:30 | <gsnedders> | Philip`: I have exams. I am avoiding playing Portal 2 until at least tomorrow afternoon. :P |
| 15:31 | <Philip`> | Pfft, you could start it now and finish it before going to bed |
| 15:31 | <gsnedders> | Philip`: I HAVE AN EXAM AT 9:30 TOMORROW MORNING. GO AWAY. |
| 15:33 | <Philip`> | (Might not have enough time for the co-op, though) |
| 15:34 | <jgraham> | gsnedders: YOU HAVE AN EXAM AT 9:30 TOMORROW MORNING. GO AWAY. |
| 16:41 | <erlehmann> | interesting idea: don't load full image information when scaling the image down. implementors, does something like this already exist? <http://freigeist.org/2011/04/28/interlaced-images-for-dynamic-image-sizes>; |
| 16:46 | <Philip`> | erlehmann: That seems non-ideal for quality, since it's effectively nearest-neighbour filtering |
| 16:49 | <erlehmann> | Philip`, it is more about bandwith anyway, i did not write that article. i suggest you comment there, if you think the idea is bogus – otherwise the poor soul might just implement it. ;) |
| 16:49 | <bfrohs> | On that note, what about sending a width and/or height header when fetching an image? |
| 16:49 | <TabAtkins> | Philip`: That's not necessarily true. You can use better interpolation methods than NN. |
| 16:50 | <erlehmann> | bfrohs, requires massive infrastructure change. range requests exist. |
| 16:52 | <Philip`> | TabAtkins: Not when using interlaced formats, since the point of interlacing is you receive one source pixel per NxN block, I think |
| 16:53 | <TabAtkins> | Philip`: Yes, I understand, but that's roughly identical to scaling up an image. We can and do perform more attractive scaling than NN. |
| 16:53 | <Philip`> | (Presumably progressive JPEG is different though, and not interlacing in image space) |
| 16:53 | <TabAtkins> | Oh, hm, wait, you're right. |
| 16:53 | <TabAtkins> | Never mind. |
| 16:54 | <Philip`> | I mean that if the browser has a whole 2x2 block it can use nice filtering to scale it to 1 pixel on the display, but the interlaced format only gives you one pixel so you have no choice |
| 16:54 | <TabAtkins> | I wasn't thinking correctly - when the iamge is smaller than normal and you just use enough of the interlaced data to fill the pixels you need, yeah, that's NN-based scale-down. |
| 16:55 | <TabAtkins> | I was caught on the idea that you can display a full-size image progressively with more attractive scaling than NN. |
| 16:55 | <TabAtkins> | Which is effectively a scale-up. |
| 17:30 | <zewt> | it's effectively nearest-neighbor with PNG, but it's more useful with JPEG, where reading fewer scans effectively just lowers the JPEG compression quality |
| 17:49 | <Workshiva> | So who enjoys reading the es5 spec? |
| 17:50 | <bfrohs> | No one? |
| 17:50 | <Workshiva> | I'm sure there's someone |
| 17:50 | <jgraham> | "enjoy"? |
| 17:51 | <jgraham> | Not really |
| 17:51 | <jgraham> | But what is the question? |
| 17:51 | <Workshiva> | I'm looking into the interaction between global namespace pollution from element ids and global variables |
| 17:51 | <Workshiva> | From my reading it looks like <div id=a></div><script>var a;</script> will leave a pointing to the div |
| 17:52 | <jgraham> | I have a feeling this is a aknown bug |
| 17:52 | <jgraham> | in HTML5 |
| 17:53 | <Workshiva> | Could be. Is there a known bug report too? |
| 17:54 | <jgraham> | Ah I am thinking of what bz said "The id lookup happens after all other property resolution in browsers (but NOT in the current spec text, note), so if you had <div id="location"> and accessed window.location you would get a Location object, not the <div>." |
| 17:54 | <Workshiva> | That's different |
| 17:54 | <jgraham> | Dunno if there is a bug |
| 17:54 | <Workshiva> | (Your case is global property first, then element appears. My case is element appears, then global property appears.) |
| 17:54 | <jgraham> | Because the order is different? |
| 17:55 | <jgraham> | Yeah |
| 17:55 | <Workshiva> | bz's case should actually work as expected I think |
| 17:56 | <Workshiva> | (Becauase HasProperty will be true when the named property for the element is attempted created) |
| 17:58 | <jgraham> | Yes WebIDL seems to have fixed up that case |
| 18:04 | <Workshiva> | I'm not sure how to fix the other case short of a willful violation |
| 18:07 | <jgraham> | Workshiva: How do you figure it's not supposed to work? |
| 18:08 | <jgraham> | Because the getter is [[Configurable]] false? |
| 18:09 | <Workshiva> | Variable declarations are parsed in es5 10.5. Step 8 says not to set the variable to undefined if it already exists. |
| 18:11 | <jgraham> | Does an accessor property count as a binding? It isn't really clear to me how ES5 interacts with WebIDL here |
| 18:11 | <jgraham> | I sort of think this can't happen in ES5 |
| 18:11 | <Workshiva> | WebIDL defines the accessor using [[DefineOwnProperty]] on the global object |
| 18:12 | <Workshiva> | And the global environment uses a object environment record based on the global object |
| 18:14 | <jgraham> | Is the text in [[DefineOwnProperty]] "Create an own accessor property named P of object O whose..." equivalent to creating a mutable binding? |
| 18:15 | <Workshiva> | Yes, CreateMutableBinding actually delegates to DefineOwnProperty |
| 18:15 | <Workshiva> | (10.2.1.2.2) |
| 18:15 | <jgraham> | Yes I just found that |
| 18:15 | <jgraham> | I was reading the wrong CreateMutableBinding |
| 18:17 | <jgraham> | OK, I agree this case doesn't work |
| 18:18 | <jgraham> | (I assume it *does* work in browsers?) |
| 18:19 | <Workshiva> | It fails in webkit, apparently |
| 18:19 | <Workshiva> | http://code.google.com/p/chromium/issues/detail?id=80591 |
| 18:21 | <jgraham> | Nice |
| 18:21 | <mven> | hixie you here ? |
| 18:24 | <Hixie> | mven: am now, what's up? |
| 18:24 | <mven> | hey was browsing the html5 spec |
| 18:24 | <mven> | particularly http://www.whatwg.org/specs/web-apps/current-work/#a-quick-introduction-to-html |
| 18:24 | <mven> | the part where it says n the following fragment, however, the attribute's value is actually "?art?", not the intended "?art© |
| 18:25 | <mven> | i think its missing the semicolon |
| 18:25 | <mven> | or i could be reading it wrong |
| 18:25 | <mven> | heh |
| 18:27 | <Workshiva> | Hixie: By the way, should I make a separate report for the outdated WebIDL terminology? |
| 18:28 | <bfrohs> | mven: That is referring to the example provided below that sentence where, in fact, © is provided *without* a semicolon. |
| 18:29 | <bfrohs> | mven: It's basically explaining why it's important to use & instead of just & |
| 18:30 | Workshiva | cries at non-multipage spec links |
| 18:31 | <Hixie> | mven: looking... |
| 18:31 | <mven> | ah so '©' is renders the same as '©' |
| 18:31 | <bfrohs> | http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#syntax-errors |
| 18:32 | <Hixie> | Workshiva: just add multipage/ to the URL |
| 18:32 | <Hixie> | Workshiva: or use a better browser |
| 18:32 | <bfrohs> | Under 'Errors involving fragile syntax contructs' |
| 18:33 | <Hixie> | mven: the fact that the semicolon is missing is the point :-) |
| 18:33 | <Hixie> | mven: i'll see if i can clarify this |
| 18:33 | <mven> | ah k. yea, I was a bit confused but it could've been just me. but thanks for clarifying. |
| 18:38 | <Hixie> | mven: reload, tell me if it's more clear now |
| 18:38 | <mven> | loading |
| 18:39 | <mven> | Yep. Much more explicit. Thanks! |
| 18:42 | <Hixie> | np |
| 18:43 | <Workshiva> | Want to fix "indexed for property retrieval" while you're at it? :) |
| 18:47 | <Hixie> | Workshiva: file a bug, i was only able to fix the other one because i was briefly in a state where i didn't have a major change ongoing :-) |
| 18:47 | <Hixie> | i thought i'd fixed all the "indexed for property retrieval" things to use the latest terminology, though |
| 18:47 | <Hixie> | did i miss one? |
| 18:48 | <Workshiva> | Oh, maybe I'm just reading the wrong terminology then |
| 18:49 | <Hixie> | i might well have missed one |
| 18:50 | <Workshiva> | Oh, I see. The indexing fragment refers to a different thing. |
| 18:50 | <Workshiva> | What I should have said is that "return the value obtained using the following steps" doesn't specify that it refers to "determine the value of a named property" |
| 18:51 | <Workshiva> | But that's minor |
| 18:51 | <Hixie> | file a bug :-) |
| 18:51 | <Hixie> | there's a litle widget in the spec to make it easy :-) |
| 18:51 | <Hixie> | easier even than irc :-P |
| 18:52 | <Workshiva> | Man, I have a bugzilla account, I feel like I'm doing it wrong when I use the widget :P |
| 18:52 | <Hixie> | i just got a question from a guy writing an html5 book asking me if html's syntax was strict like xml or loose like older versions of html |
| 18:52 | Hixie | has a little concern for the quality of said book |
| 18:53 | bfrohs | isn't surprised... sadly |
| 18:53 | <gsnedders> | Hixie: Just "a little"? |
| 18:53 | <Workshiva> | I'm still working on teaching all my team members that <html> is an optional tag |
| 18:56 | <Philip`> | That sounds like a waste of effort |
| 18:57 | <Philip`> | since usually you'll want to add a lang and can't make use of the optionality |
| 18:58 | <Philip`> | Better to just teach them that </head> is optional, because that's a rule you can always apply, and it's much more fun because it'll randomly break certain pages in old browsers |
| 18:59 | <AryehGregor> | Even if you add <body>? |
| 18:59 | <Philip`> | Hmm, probably not in that case |
| 18:59 | <Hixie> | </head> being optional is a pain when the first thing in the <body> is something that goes in <head> too (e.g. <script>) |
| 18:59 | <Philip`> | but only crazy people add <body> |
| 18:59 | <Hixie> | that's why the live dom viewer starts with "..." in the body :-) |
| 19:00 | <AryehGregor> | Philip`, MediaWiki adds about four million classes to <body>. |
| 19:00 | <AryehGregor> | Why it doesn't add them to <html>, I don't know. |
| 19:00 | <AryehGregor> | Probably too late to change. |
| 19:01 | <AryehGregor> | Will old browsers not auto-open <body> on hitting a <div> or something? |
| 19:02 | <Philip`> | They won't on hitting a <header>, I think |
| 19:03 | <AryehGregor> | Yeah, that's an issue. |
| 19:03 | <AryehGregor> | Where "old" means "IE8". |
| 19:03 | <AryehGregor> | Or maybe only IE7? |
| 19:05 | <Workshiva> | I'm too busy supporting IE5 to care |
| 19:06 | <Workshiva> | Hixie: The issue with fixing it in WebIDL isn't that heycam won't cooperate, it's that I don't see how WebIDL _can_ fix it |
| 19:06 | <mpilgrim> | you could always insert a div id=body to trigger the implicit body rule |
| 19:07 | <hober> | AryehGregor: <head class> was invalid in HTML4, so people used to use <body class> instead |
| 19:07 | <AryehGregor> | hober, you mean <html class> was invalid? |
| 19:07 | <hober> | sorry, yes |
| 19:07 | <AryehGregor> | That would explain it. |
| 19:07 | <hober> | <html> only took dir="" and lang="" |
| 19:08 | <mpilgrim> | don't forget xml:lang! |
| 19:08 | <Ms2ger> | Like style@class |
| 19:26 | <Hixie> | Workshiva: if a browser can implement it, it can be specced |
| 19:28 | <Workshiva> | Yeah, but I think it should be in HTML, not WebIDL |
| 19:29 | <Hixie> | why? |
| 19:31 | <Ms2ger> | Hixie, that's not a question I'd ever expected you to ask ;) |
| 19:31 | <Workshiva> | Because it's a caused by window == global object, which is also in HTML |
| 19:31 | <Hixie> | so it wouldn't happen on HTMLFormElement? |
| 19:32 | <Hixie> | if you made an HTMLFormElement be the ThisBinding of a function that had a 'var', you'd want different behaviour than if you did it for Window? |
| 19:33 | <Workshiva> | It's specific to object environment records, so it would have to be with (formel) {} |
| 19:33 | <Workshiva> | And when you're doing with (anything) you get that behavior |
| 19:35 | <Hixie> | i have no idea what what you just said means :-) |
| 19:35 | <Workshiva> | To put it another way, when using with people expect exactly that behavior |
| 19:35 | <Workshiva> | It's a problem with element id lookups because those pollute the global object from the outside |
| 19:36 | <Hixie> | oh, |with| |
| 19:36 | <Hixie> | sorry i didn't realise that was a keyword there |
| 19:36 | <Workshiva> | Ah. Yes. |
| 19:36 | <Hixie> | that made your sentences very hard to parse :-) |
| 19:36 | <Workshiva> | ... I can see that now. |
| 19:36 | <Hixie> | it doesn't have to be with |with| |
| 19:36 | <Hixie> | consider .apply() |
| 19:37 | <Hixie> | or even form.foo = function () { var x; ...; return x; }; form.foo(); |
| 19:37 | <Hixie> | no? |
| 19:37 | <Workshiva> | Functions use declarative environment records, not object environment records |
| 19:39 | <Workshiva> | If you have an object with a propery x, doing object.method(); requires you to do this.x, just x won't work so it can't collide with var x. |
| 19:39 | <Hixie> | ah |
| 19:39 | <Hixie> | well i don't really see what you want HTML to say |
| 19:40 | <Hixie> | it's the WebIDL algorithms that make this all happen, no? |
| 19:41 | <Workshiva> | jgraham summarized the wanted behavior neatly as "id lookup should happen after all other property resolution" |
| 19:41 | <Workshiva> | WebIDL tries to integrate it with the normal variable environment, but this doesn't work because that has no concept of two levels, so the necessary shadowing can't happen |
| 19:42 | <Workshiva> | I guess you could say the global environment actually has an outer environment which is the evil global namespace polluting element access environment |
| 19:43 | <Workshiva> | So to make this work, it would be necessary to define a deviation from es5 on that or a similar level |
| 19:44 | <Workshiva> | It's not specific to named property access, it just happens to manifest there |
| 19:44 | <Hixie> | it has to happen like webidl says it to some extent so that |'foo' in window| works, no? |
| 19:45 | <Workshiva> | Yeah |
| 19:45 | <Hixie> | i mean, it has to actually have a property |
| 19:45 | <Hixie> | i think the solution is just to have 'var' override the property in this case |
| 19:45 | <Hixie> | so whatever check 'var' does should not return true or whatever when it's being done for 'var' for these properties |
| 19:46 | <Workshiva> | That sounds like it would solve the problem, but there's no existing mechanism that gives that behavior |
| 19:47 | <Workshiva> | And we don't want this to happen when an object is used with |with|, so it can't be a general mechanism |
| 19:51 | <Hixie> | Workshiva: my suggestion would be for a mechanism like this to be added to WebIDL, keyed on some attribute i can put on Window, then |
| 19:51 | <Hixie> | or somethig like that |
| 19:51 | <Hixie> | unless you're saying Window shouldn't act like this ever for 'var' |
| 19:52 | <Hixie> | what browsers do what you want, again? is it just IE? or IE and Firefox? |
| 19:53 | <Workshiva> | IE, Firefox and Opera do it my way. |
| 19:54 | <Workshiva> | Safari and Chrome do it the other way. |
| 19:55 | <Hixie> | yeah so clearly we just need to make the spec match everyone but WebKit |
| 19:56 | <Hixie> | so post to public-webapps that we need to do this, get heycam to say how he thinks we should fix it, and then we'll fix it |
| 19:58 | <otherarun> | On another note, DOMException has lots of error codes on it, and some things should just be NOT_ALLOWED. I'm wondering whether we should have a separate exception called NotAllowedException and just throw that. |
| 19:59 | <otherarun> | In particular, for multiple reads (reader.readAsxxx) on the same Blob by the same FileReader |
| 20:00 | <Hixie> | i just use INVALID_STATE_ERR or similar in those cases |
| 20:08 | <otherarun> | Hixie, do you disagree with a separate exception? Would you prefer to reuse? |
| 20:09 | <Hixie> | personally i'm a fan of all of our APIs using only DOMException |
| 20:31 | <Hixie> | anyone know if anything is going on with the tab visibility api? |
| 21:03 | <jamesr> | Hixie: yeah |
| 21:03 | <jamesr> | Hixie: the web perf WG added it to its charter and has a draft up |
| 21:03 | <jamesr> | http://www.w3.org/2011/04/webperf.html |
| 21:03 | <jamesr> | Hixie: i was gonna reply to the thread |
| 21:07 | <jgraham> | jamesr: No, the right response was "Tab has his own API now?" |
| 21:16 | <jwalden> | AryehGregor: if you want to have cross-window-safe-instanceof, you could take your exception, walk the prototype chain to Object.prototype with Object.getPrototypeOf, grab a function off that, get the Function constructor from that, evaluate (Function("return this")()), then extract the relevant interface constructor from that |
| 21:16 | <AryehGregor> | . . . wow. |
| 21:16 | <jwalden> | AryehGregor: although that's going to fail in Firefox right now, I think, for the cross-window case, in some cases |
| 21:16 | <AryehGregor> | Um, good to know? |
| 21:16 | <jwalden> | bug 631135 |
| 21:16 | <AryehGregor> | jgraham, ^^ |
| 21:20 | <jwalden> | this makes a fair handful of assumptions and/or requirements on what tests must not do |
| 21:21 | <jwalden> | but no test should be mutating a prototype chain with __proto__ = ..., tests shouldn't be deleting Function.prototype.constructor (or such tests could probably be made to not use this method), and tests probably generally wouldn't delete a DOM constructor from the global object and then need to test with it |
| 21:21 | <jwalden> | or something |
| 21:46 | <zcorpan> | Philip`, Hixie: including </head> does not help with the <script> case if you omit <body> anyway |
| 21:51 | <jgraham> | jwalden: Evil! I like it ;) |
| 21:51 | <jwalden> | :-) |
| 21:52 | <jwalden> | arguably it would have been better to have windows be entirely separate creatures, maybe with message passing as the only interface between them |
| 21:52 | <jwalden> | then instanceof wouldn't be half-broken for this case |
| 21:53 | <jwalden> | sixteen years too late |
| 21:53 | <Hixie> | jamesr: k cool |
| 21:54 | <jamesr> | Hixie: i'm pretty confident that the web perf wg will end up with something fairly dumb |
| 21:54 | <zcorpan> | jwalden: sounds like an acid test in itself |
| 21:55 | <jwalden> | zcorpan: dunno, I'm pretty sure all of those bits (except Object.getPrototypeOf, or a __proto__-based backwards-compatibility hackaround, so I guess the trick excludes <IEmumble) should be reliable |
| 21:56 | <Hixie> | jamesr: hopefully if it's dumb it won't be implemented |
| 21:56 | <jwalden> | "good will triumph because dumb is dumb" |
| 21:57 | <AryehGregor> | Hixie, that's only a possibility if the people coming up with it aren't implementers. Is that the case? |
| 21:57 | <AryehGregor> | Seems unlikely. |
| 21:58 | <jamesr> | well i can't tell what the IE implementors in the group think |
| 21:58 | <jamesr> | or how likely they are to implement dumb things |
| 21:58 | <AryehGregor> | IE team members are ever inscrutable. |
| 22:31 | <jamesr> | given w3 spec stored in hg and i have a link to the latest ED with 'tip' in the URL, how do i get a permalink to this draft? |
| 22:36 | <AryehGregor> | jamesr, use hgweb to find the current revision id and substitute that for "tip". |
| 22:36 | <AryehGregor> | jamesr, what's the specific example? |
| 22:37 | <jamesr> | http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PageVisibility/Overview.html |
| 22:38 | <jamesr> | mkay, it's http://dvcs.w3.org/hg/webperf/rev/62eb533e186b so i want http://dvcs.w3.org/hg/webperf/raw-file/62eb533e186b/specs/PageVisibility/Overview.html |
| 22:38 | <jamesr> | thanks! |
| 22:38 | <AryehGregor> | At http://dvcs.w3.org/hg/webperf/, if you click at the latest rev you get http://dvcs.w3.org/hg/webperf/rev/b51b296242fc. |
| 22:39 | <AryehGregor> | 62eb533e186b is old, but maybe it's the last commit that touched your file or something. |
| 22:39 | <AryehGregor> | Doesn't seem so. |
| 22:39 | <AryehGregor> | You probably want b51b296242fc. |
| 22:39 | <jamesr> | yeah later commits were to other files |
| 22:39 | <jamesr> | ah yeah |
| 22:40 | <jamesr> | actually c46bff617f9e |
| 22:40 | <AryehGregor> | (prefixes of revision id's work too, even as short as "b5" in this case, as long as they're unique) |
| 22:40 | <jamesr> | b51b was to a different spec |
| 22:40 | <AryehGregor> | Doesn't matter, it's the same repo, so it will still work. |
| 22:40 | <AryehGregor> | The latest in the repo is fine for your purposes. |
| 22:47 | <AryehGregor> | Stuff like Array.prototype.every.call(foo, ...) is a pain in the neck. Why can't array-like objects just inherit these methods somehow, the way you'd do it in standard OO? |
| 22:51 | <AryehGregor> | . . . have I mentioned before that IE9 has the best URL bar of any current browser? |
| 22:51 | <Lachy> | AryehGregor, what's so good about it? |
| 23:01 | <AryehGregor> | Lachy, it provides high-quality suggestions from your history, unlike Chrome; but seems to respond more quickly than Firefox's awesome bar; Shift-Enter lets you go to the first result, instead of Googling it; it has good UI for enabling search suggestions (clearly visible option on every search, one click to enable, but with a pretty clear indication of the privacy implications). |
| 23:01 | <jamesr> | what's best practice for the type attribute on script? |
| 23:01 | <jamesr> | are you supposed to set it? if so, to what? |
| 23:01 | <wilhelm_> | Hixie: Will the spec land on blacklists or whitelists for register*Handler()? (c: |
| 23:01 | <Hixie> | wilhelm_: dunno, haven't gotten to that thread yet |
| 23:02 | <AryehGregor> | jamesr, just omit it, assuming the script is JS. |
| 23:02 | <AryehGregor> | It's pointless. |
| 23:03 | <Hixie> | wilhelm_: for protocols it seems like a(n open-ended with a known ok prefix) whitelist is the obvious way to go |
| 23:03 | <jamesr> | also should example snippets in specs have a <!DOCTYPE html> declaration? |
| 23:03 | <AryehGregor> | Lachy, for instance, one of the most common pages I've been visiting in all four browsers I'm using is <http://aryeh.name/spec/editcommands/autoimplementation.html>;. When I type "auto" in the search bar, Chrome and Opera don't suggest it; Firefox 4.0 and IE9 do. |
| 23:03 | <Hixie> | wilhelm_: for content types, i have no idea what to do |
| 23:04 | <AryehGregor> | jamesr, if it's meant to be a complete document, yes, otherwise no. |
| 23:04 | <AryehGregor> | Lachy, Firefox is second-best IMO, but IE's is a bit more polished. |
| 23:04 | <Hixie> | chrome's guessing of urls seems poor to me too |
| 23:04 | <Hixie> | it takes forever for it to learn urls that i use a lot |
| 23:05 | <AryehGregor> | Chrome seems very biased toward showing search results, which are usually much less useful than history pages, and it only seems to look at small parts of history pages. |
| 23:05 | <AryehGregor> | Like the domain name. |
| 23:05 | <AryehGregor> | Firefox and IE seem to look at the title, at the least. |
| 23:05 | <wilhelm_> | Hixie: Alright. Then we'll do a whitelist for protocols without a yet to be defined prefix. (We're implementing this this week.) |
| 23:05 | <AryehGregor> | And possibly parts of the path. |
| 23:06 | <AryehGregor> | Oh, Chrome looks at parts of the path, at leas.t |
| 23:06 | <AryehGregor> | least. |
| 23:07 | <AryehGregor> | "editco" gets me the auto-running execCommand() page in Firefox and IE as the first result, nothing at all in Opera, and in Chrome it takes several seconds to display the editcommands/ pages and they're at the bottom, while useless Google searches are at the top. |
| 23:08 | <AryehGregor> | Maybe better to say IE's is about as good as Firefox's, but with slightly more polish. |
| 23:08 | <wilhelm_> | Hixie: For content types, our current implementation allows any MIME-type to be overriden except those the browser handles natively. Feeds are currently the only exception to this. |
| 23:08 | <wilhelm_> | It's not a definite list of content types – it's dynamically determined based on which content types the browser knows about. |
| 23:10 | <zcorpan> | what about types that plugins know about? |
| 23:11 | <wilhelm_> | That's the next thing we need to look at. I don't know. |c: |
| 23:11 | <Hixie> | wilhelm_: i think there was a prefix proposed at some point |
| 23:11 | <zcorpan> | knee-jerk reaction is to disallow them as well |
| 23:11 | <Hixie> | wilhelm_: web+ or something |
| 23:12 | <wilhelm_> | Hixie: Yes, you mentioned that in your email. web+ plus only alphanumeric characters is a lot less scary. (c: |
| 23:12 | <Hixie> | wilhelm_: yeah for content types i dunno what the right thing is but blacklisting most of the ua's known types, allowing only some like feeds and pdfs, seems reasonable |
| 23:12 | <zcorpan> | perhaps even block well-known plugin types even if the user doesn't have that plugin |
| 23:12 | <Hixie> | wilhelm_: seems good to me. if it's in the thread then that's what i'll probably do |
| 23:13 | <Hixie> | wilhelm_: if you come up with a good whitelist or blacklist for either of these let me know and i'll put it in the spec |
| 23:13 | <wilhelm_> | OK. Then our implementation will match that. |
| 23:13 | <wilhelm_> | Hixie: Sure. I have a list. Most of it has been mentioned publicly already. |
| 23:15 | <Hixie> | cool |
| 23:15 | <wilhelm_> | Writing a test suite for this sucks, though. Opera knows about different content types depending on its feature set. |c: |
| 23:15 | <zcorpan> | list the list on the list! |
| 23:15 | <wilhelm_> | Will do. (c: |
| 23:21 | <zcorpan> | nn |