| 00:01 | <sholmes> | is there any new spec on javascript being closer tied to css? |
| 00:01 | <AryehGregor> | What do you mean? |
| 00:01 | <TabAtkins> | You mean the CSSOM improvements? |
| 00:01 | <sholmes> | specs on javascript events for when a css property changes |
| 00:01 | <TabAtkins> | No. |
| 00:01 | <sholmes> | TabAtkins, I didn't know there was such a thing as CSSOM |
| 00:02 | <roc> | othermaciej: annevk suggested "From-Origin", which sounds a little better to me |
| 00:02 | <sholmes> | It would be cool to be able to bind events to custom css properties |
| 00:02 | <roc> | </bikeshed> |
| 00:02 | <TabAtkins> | sholmes: The CSSOM is the interface that you use when you do, say, elem.style.width="50px" |
| 00:02 | <othermaciej> | roc: that would sound a bit like it's a whitelist, not a blacklist |
| 00:03 | <roc> | it is a whitelist |
| 00:03 | <othermaciej> | Allow-Embedding-From-Origins: would sound like a whitelist, but might imply that in absence of the header default is none |
| 00:03 | <sholmes> | TabAtkins, I see. Those are only inline styles though. How do you access CSS styling information on an element? |
| 00:03 | <othermaciej> | er sorry, sounds like a blacklist |
| 00:03 | <sholmes> | How do you access psuedo element styles? |
| 00:03 | <roc> | Allow-Embedding-Origins? |
| 00:03 | <TabAtkins> | sholmes: getComputedStyle |
| 00:03 | <TabAtkins> | (Which is also part of the CSSOM.) |
| 00:03 | <roc> | or maybe just Allow-Embedding |
| 00:04 | <roc> | or Embedders |
| 00:04 | <sholmes> | TabAtkins, and what about the psuedo elements? |
| 00:05 | <AryehGregor> | Restrict-Embedding: |
| 00:05 | <AryehGregor> | Restrict-Embedding-To:, Restrict-Embedding-To-Origins: |
| 00:05 | <AryehGregor> | Take your pick. |
| 00:05 | <TabAtkins> | sholmes: That's part of the getComputedStyle function - you can specify that you want a pseudoelement off of the element instead. |
| 00:05 | <TabAtkins> | sholmes: https://developer.mozilla.org/en/DOM:window.getComputedStyle |
| 00:06 | <sholmes> | TabAtkins, this goes for psuedo classes too? |
| 00:06 | <TabAtkins> | pseudoclasses arent' things that can have properties. |
| 00:06 | <TabAtkins> | They're properties of elements. |
| 00:06 | <TabAtkins> | (Just like classes.) |
| 00:09 | <sholmes> | so you'd have to somehow get the element that has the psuedo class? |
| 00:09 | <TabAtkins> | sholmes: Yes? |
| 00:10 | <TabAtkins> | Look at the link I just provided. That explains how the function works. |
| 00:10 | <sholmes> | I did |
| 00:11 | <othermaciej> | AryehGregor: I like the brevity of Restrict-Embedding |
| 00:11 | <sholmes> | it says you can use a string to select a psuedo element |
| 00:11 | <AryehGregor> | Me too. |
| 00:11 | <TabAtkins> | I might like the brevity of Embedders even more. |
| 00:12 | <AryehGregor> | I don't. |
| 00:12 | <AryehGregor> | It's much less obvious what it means. |
| 00:12 | <AryehGregor> | It makes it sound like a list of things that do embed the file, not that can embed the file. |
| 00:13 | <sholmes> | I don't think IE < 9 supports getComputedStyles |
| 00:13 | <AryehGregor> | getComputedStyle, not getComputedStyles. |
| 00:13 | <AryehGregor> | Although probably it doesn't. |
| 00:13 | <TabAtkins> | They might support it on document.defaultView? |
| 00:14 | <sholmes> | AryehGregor, yeah it was a typo |
| 00:14 | <TabAtkins> | That's where it used to be defined, before everyone realized that was stupid and put it on window instead. |
| 00:14 | <AryehGregor> | Googling suggests IE has a currentStyle property. |
| 00:14 | <sholmes> | I think they use currentStyle |
| 00:14 | <sholmes> | but I don't know if that has a psuedo element argument |
| 00:15 | <AryehGregor> | Does IE < 9 support ::before or ::after anyway? |
| 00:15 | <TabAtkins> | Yes. |
| 00:15 | <Rik`> | AryehGregor: I think IE > 6 supports that |
| 00:15 | <TabAtkins> | Only the older single-colon version. |
| 00:15 | <AryehGregor> | I thought it didn't support generated content until very recently. |
| 00:15 | <TabAtkins> | Nope, it's done :before and :after for some time. |
| 00:15 | <gsnedders> | IE7 |
| 00:16 | <AryehGregor> | Oh. |
| 00:16 | <AryehGregor> | I'm getting mixed up with something else, then. |
| 00:16 | <Rik`> | hmm no, IE8 |
| 00:16 | <Rik`> | http://msdn.microsoft.com/en-us/library/cc351024%28v=vs.85%29.aspx |
| 00:17 | <Rik`> | http://msdn.microsoft.com/en-us/library/cc351024%28v=vs.85%29.aspx#pseudoelements |
| 00:17 | <sholmes> | :before and :after is what older versions support I think |
| 00:31 | <sholmes> | what's the standard on styling placeholders? |
| 00:35 | <AryehGregor> | There is none yet. |
| 00:38 | <sholmes> | AryehGregor, oh. Well I like ::placeholder |
| 00:39 | <boogyman> | sholmes: i'd equate it more similar to an attribute then a pseudo selector |
| 00:39 | <sholmes> | But attributes don't have elements. |
| 00:40 | <boogyman> | attributes have values |
| 00:40 | <sholmes> | I like the idea of having the implementation provide "hidden" psuedo elements which you can select. Then there's psuedo classes, which completely different. |
| 00:40 | <sholmes> | boogyman: values don't have styling |
| 00:40 | <sholmes> | only elements do, at least I argue. |
| 00:41 | <mattmay> | Anybody here want to answer a few intellectual property questions? |
| 00:43 | <boogyman> | mattmay: you might want to consult a lawyer, however, in absence of one, ask the question and i'm sure someone will provide his/her biased opinion |
| 00:43 | <mattmay> | Well, the ones I have should probably be answerable here. |
| 00:44 | <sholmes> | mattmay: does this have to do with pornography? |
| 00:44 | <mattmay> | From what I've been able to find, WHATWG has no patent policy. Is that still correct? |
| 00:44 | <mattmay> | sholmes: ha! no. |
| 00:45 | <gsnedders> | mattmay: That is correct. |
| 00:45 | <mattmay> | Is there any interest/effort in that ever changing? |
| 00:45 | <sholmes> | mattmay: are you sure? Because the wikipedia article uses the word pornagraphic more than once. |
| 00:47 | <AryehGregor> | I feel like I ask this question in some form like every three weeks, but: where's a database of web pages that I can search through to find things like innerText usage patterns? |
| 00:47 | <AryehGregor> | mattmay, the WHATWG does not formally exist. It has no members or anything. It's not obvious what form a patent policy would take. The W3C gets people to agree to its patent policy by having this whole system of membership and making it hard to contribute to its specs unless you join, but that's not how the WHATWG works. |
| 00:48 | <AryehGregor> | We'd have to not let people participate if their employer didn't agree to the patent policy or objectionable things like that. |
| 00:49 | <sholmes> | AryehGregor, you mean answer this question? |
| 00:49 | <AryehGregor> | For now, most of the WHATWG stuff is mirrored at the W3C and the rest will probably be mirrored there eventually, so we're not too bad on patents as it stands. |
| 00:49 | <Hixie> | AryehGregor: if you want i can do a search for you, if there's somethin specific you're looking for |
| 00:49 | <mattmay> | Yes, but you do have three browser engines and four companies participating. Is there even an agreement among them? |
| 00:49 | <Hixie> | companies don't participate in the whatwg, individuals do |
| 00:49 | <AryehGregor> | Hixie, I just want a large sample of pages that use it so I can see how people use it. Philip` has some database he uses for stuff like this. |
| 00:49 | <Hixie> | AryehGregor: not sure where Philip`'s is. If you just want me to search for pages with "innerText" in them I can do that. |
| 00:49 | <AryehGregor> | mattmay, the WHATWG is not a corporation or anything. It's hosted on Hixie's VPS and has no formal status at all. |
| 00:50 | <AryehGregor> | Hixie, that would be useful for now, thanks. |
| 00:50 | <mattmay> | Hixie: Yes, but don't many of those individuals have employment contracts with organizations that includes the assignment of IPR? |
| 00:52 | <Hixie> | you'd have to ask them |
| 00:52 | <Hixie> | AryehGregor: um. how many of these do you want? :-) |
| 00:53 | <TabAtkins> | A couple hundred thousand should work, I'd think. |
| 00:54 | <mattmay> | Hixie: Well, if they do (that is, if their contracts are anything like mine), doesn't that give you pause? Ostensibly, you're building something that somebody's employer could put a claim on later. |
| 00:55 | <Philip`> | AryehGregor: http://www.dotnetdotcom.org/ ? |
| 00:55 | <Hixie> | mattmay: the patent system in general gives me grave concerns |
| 00:56 | <mattmay> | Okay, so we do agree on something. :D |
| 00:56 | <Hixie> | is there an easy way on mac os to pipe the clipboard to a shell script? |
| 00:56 | <jamesr_> | man pbpaste |
| 00:57 | <Hixie> | sweet |
| 00:57 | <jamesr_> | pbpaste | say |
| 00:57 | <jamesr_> | always fun to run every now and then |
| 00:57 | <TabAtkins> | Heh. |
| 00:57 | <mattmay> | But being concerned is one thing. Actively protecting against bad things happening is another. |
| 01:01 | <Hixie> | AryehGregor: http://damowmow.com/temp/innerText.urls |
| 01:01 | <Hixie> | AryehGregor: i limited it to one url per hostname |
| 01:02 | <AryehGregor> | Great, thanks. |
| 01:02 | <Hixie> | AryehGregor: this is very much a biased sample, it's not a good random distribution or anything |
| 01:02 | <Hixie> | AryehGregor: but hopefully it's enough |
| 01:02 | <Hixie> | gotta go |
| 01:03 | <TabAtkins> | Heh, this is pretty cool: http://2011.beercamp.com/ (scroll it all the way to the end) |
| 01:04 | <jamesr_> | i wish the back button worked |
| 01:04 | <jamesr_> | pretty cute |
| 01:05 | <jamesr_> | i guess they're just eating onscroll? |
| 01:05 | <TabAtkins> | Just click on the top, no need for a back button. (And have speakers on.) |
| 01:05 | <TabAtkins> | Yeah, I assume, since it responds correctly to all forms of scrolling. |
| 01:05 | AryehGregor | used page down, and got confused |
| 01:06 | <TabAtkins> | But yeah, they should be watching the zoom level and altering the hash accordingly. |
| 01:06 | <TabAtkins> | They already watch so they can highlight the right entry in the floating menu. |
| 01:08 | <mattmay> | So, nothing? No plans to make sure WHATWG output is reasonably protected from patent nastiness? |
| 01:09 | <jamesr_> | mattmay: if you have a proposal submit it to the mailing list |
| 01:09 | <TabAtkins> | Hixie: Any particular reason you tried to redefine content:none to just make pseudos empty, rather than preventing them from being created? |
| 01:11 | <TabAtkins> | Hixie: For now I'm ignoring css3-content and just having ::marker compute to 'content:none' when appropriate. |
| 01:12 | <mattmay> | jamesr_: I had to see if the problem I saw actually existed, before proposing to fix it. Still not convinced people see a problem, though. |
| 01:12 | <jamesr_> | mattmay: well you aren't being terribly convincing here |
| 01:13 | <TabAtkins> | In the absence of anyone actually trying to patent-troll the WHATWG is its 6+ years of existence, it doesn't seem urgent to protect it against patent-trolling. |
| 01:13 | <mattmay> | jamesr_: I wouldn't know where to start. |
| 01:14 | <mattmay> | TabAtkins: That's like saying if your house isn't on fire, there's really no need to buy insurance. |
| 01:14 | <jamesr_> | mattmay: sounds like maybe you should figure out where to start before trying to present your case |
| 01:14 | <AryehGregor> | mattmay, all significant work at the WHATWG is eventually copied over to the W3C, which has a patent policy. What could the WHATWG do to improve the situation over that? |
| 01:15 | <mattmay> | Well, it's not going to be one line at a time. I think the first attempt is going to be tl;dr length, and we'l take it from there. |
| 01:15 | <AryehGregor> | (not that the W3C patent policy gives any protection from patent trolls or other non-members) |
| 01:15 | <jamesr_> | that's why i said email |
| 01:15 | <mattmay> | AryehGregor: Well, at least they have a process for rallying the members when patent trolls appear. |
| 01:16 | <jamesr_> | or maybe another channel so people can have useful discussions on this channel |
| 01:16 | <TabAtkins> | mattmay: Similar, sure. But patent trolls don't happen by accident. The WHATWG has been defining a major piece of internet technology for years now. |
| 01:16 | <AryehGregor> | I love web authors: s.setBaseAndExtent(e, 0, e, e.innerText.length - 1); |
| 01:16 | <AryehGregor> | jamesr_, since when does anyone have useful discussions on this channel? |
| 01:16 | <mattmay> | What I'm mostly concerned about is work that happens outside of W3C, which gets implemented by devs, and is unprotected until it gets rolled into a W3C draft. |
| 01:16 | <AryehGregor> | mattmay, what process do they have for rallying the members when patent trolls appear? |
| 01:16 | <jamesr_> | AryehGregor: touche |
| 01:17 | <mattmay> | Which is going to be a longer and longer period of exposure now that things aren't actively getting added to HTML5. |
| 01:17 | <AryehGregor> | mattmay, work is unprotected until it gets to a W3C Recommendation, if I remember correctly. So we're talking a lag of years here anyway. |
| 01:17 | <AryehGregor> | When HTML5 gets frozen, we can start working on HTML6 in parallel in the W3C. |
| 01:17 | <TabAtkins> | AryehGregor: That call won't do anything like what they intend, will it? |
| 01:17 | <AryehGregor> | CSS 2.1 has been frozen for years, but we're working on CSS 3 too. |
| 01:17 | <AryehGregor> | TabAtkins, nope. Not even close. |
| 01:17 | <mattmay> | AryehGregor: AFAIK, it's protected from FPWD status. |
| 01:18 | <mattmay> | As far as protection goes, they have the Patent Advisory Groups, which get formed to see if a claim is valid, see if it can be routed around, see who has prior art, etc. |
| 01:19 | <AryehGregor> | When it comes to post-facto stuff, the W3C can be used for that when it happens. |
| 01:19 | <mattmay> | Well, not if it's not in a W3C spec. |
| 01:20 | <AryehGregor> | It can be added to one quickly. :) |
| 01:20 | <AryehGregor> | It seems like there are licensing requirements for WDs, you're right. |
| 01:20 | <AryehGregor> | Not clear on exactly what they are. |
| 01:20 | <othermaciej> | FPWD doesn't actually give anyone a patent license |
| 01:21 | <AryehGregor> | I find the Patent Policy hard to read. |
| 01:21 | <othermaciej> | FPWD is just an exclusion opportunity |
| 01:21 | <othermaciej> | technically, licensing non-excluded patent claims is not required until REC |
| 01:21 | <othermaciej> | though FPWD (and later LC) at least gives you some notice |
| 01:21 | <mattmay> | It's an opportunity to ask the question before a bunch of implementers have to roll back running code. |
| 01:21 | <AryehGregor> | That's what I thought. |
| 01:21 | <AryehGregor> | Anyway, there's not much in the WHATWG that's not in the W3C. |
| 01:22 | <othermaciej> | anyhow, once HTML WG recharters, I expect our charter will include scope for HTML 5.1 / HTML6 / whatever |
| 01:22 | <mattmay> | Right, but like I said, there's going to be a backlog hanging out there. |
| 01:22 | <othermaciej> | in parallel with taking HTML5 the rest of the way to REC |
| 01:22 | <mattmay> | And it's going to be the stuff the cool kids are going to dig into. |
| 01:23 | <jamesr_> | what's the ETA for HTML5 to REC in w3c land? 2025ish? |
| 01:23 | <AryehGregor> | 2022 last I heard. |
| 01:25 | <AryehGregor> | The unescapeHTML function here is vaguely fascinating. I wonder what it's used for: http://api.opencast.naver.com/CS888/23 |
| 01:26 | <mattmay> | I'm skimming, but it looks like most of what W3C does is enforced within 60 days after LC. |
| 01:26 | <othermaciej> | depends on what you mean by "E" |
| 01:28 | <tw2113> | it's just a number |
| 01:29 | <jamesr_> | "E". it's just a number |
| 01:29 | <mattmay> | Well, thanks for the info, everybody. |
| 01:30 | <TabAtkins> | Ah, I love clear specs that answer my questions simply. |
| 01:30 | <TabAtkins> | (In this case, how to serialize the string ".". The answer, unsurprisingly, is ".") |
| 01:33 | <othermaciej> | the HTML WG charter estimates 2010 Q3 for REC |
| 01:33 | <othermaciej> | I don't think that was a very realistic estimate |
| 01:34 | <AryehGregor> | No, I have to grant it doesn't seem very realistic. |
| 01:34 | <AryehGregor> | Hixie estimated LC would be sometime in 2011, right? |
| 01:35 | <jamesr_> | according to the tech press we already have at least 2 implementations of HTML5 |
| 01:35 | <AryehGregor> | TabAtkins, what spec? |
| 01:35 | <TabAtkins> | AryehGregor: CSSOM |
| 01:35 | <AryehGregor> | Ah. |
| 01:36 | <AryehGregor> | The overwhelming majority of innerText uses could just be replaced by textContent. Either they're assignment only, or dealing with nodes that only have short text node children. |
| 01:36 | <TabAtkins> | I was fixing an example in Lists that was written by Hixie, where he'd given the computed value of something as containing "\002E". By current CSSOM, though, that's not the natural answer. |
| 01:39 | <AryehGregor> | I see multiple sites using createRange()+selectNodeContents()+toString() as an innerText replacement. I wonder why, since it's equivalent to textContent. Is textContent recent? |
| 01:39 | <AryehGregor> | Or is this just gratuitous cargo-culting? |
| 01:39 | <TabAtkins> | Sounds like cargo-culting. |
| 01:40 | <TabAtkins> | I just realized how odd of a word "unbeknownst" is. It confuses me just to type it, though I know instinctively how to spell it. |
| 01:40 | <TabAtkins> | Too much archaicness in it. |
| 01:41 | <AryehGregor> | Here's a case where someone's actually using the plaintextification properties of innerText, I think: view-source:http://albanolaziale.blogolandia.it/2008/06/13/la-scuola-di-pavona-campione-nazionale-di-teatro/ |
| 01:42 | <AryehGregor> | (that view-source: bit is pretty annoying, Chrome should drop that when you copy the URL IMO) |
| 01:42 | <jamesr_> | also kinda makes you sound like a ponce when you say it |
| 01:43 | <AryehGregor> | Possibly this one too: http://ask.chinese.cn/findAndReplyQuestionAction.action?problemId=377 |
| 01:44 | <AryehGregor> | But they don't seem to be relying on the details at all, they use textContent as a substitute. |
| 01:44 | <TabAtkins> | Agreed on the first. |
| 01:44 | <TabAtkins> | So what you're saying is, so far it looks like you can just spec it as "be like textContent" and you'd be okay? |
| 01:45 | <AryehGregor> | No, there are a couple of cases I've found where it looks like that would degrade website behavior. |
| 01:45 | <AryehGregor> | It would be mostly fine, yes. |
| 01:45 | <AryehGregor> | Opera more or less does that. |
| 01:46 | <AryehGregor> | But it wouldn't allow any way to get a plaintext representation of HTML except selecting it, which is kind of unreasonable. |
| 01:46 | <TabAtkins> | If the choice is "degrade a few websites" or "spec something complicated that no one wants to implement"... |
| 01:46 | <AryehGregor> | WebKit apparently doesn't want to make its innerText work like textContent. |
| 01:46 | <AryehGregor> | I'd be okay with that, reportedly so would Opera, and Mozilla certainly would. |
| 01:47 | <AryehGregor> | But anyway, you still have to spec Selection.toString(), which should be the same spec anyway. |
| 01:47 | <AryehGregor> | And largely the same implementation. |
| 01:56 | <TabAtkins> | Hrm. I wish I could go back in time and implement Positioned Layout before someone wrote list-style-position, as its values can be implemented in terms of that. Darn. |
| 01:56 | <TabAtkins> | Now I have to figure out how to talk about this in a way that will work correctly with ::marker being positionable. |
| 01:57 | <TabAtkins> | I think I can just punt by saying list-style-position only applies if the ::marker is an in-flow inline-level element. |
| 02:16 | <Philip`> | AryehGregor: It seems hard to judge the compatibility risk from the proportion of sites making more complex use of innerText, unfortunately |
| 02:17 | <Philip`> | since there might be 10% of all sites using it in trivial ways and 0.01% using it in complex ways |
| 02:17 | <Philip`> | so looking through a list of sites using innerText won't show the difficult ones |
| 02:17 | <Philip`> | which is a pain :-( |
| 02:18 | <Philip`> | (It's much easier with features that are used on 0.01% of sites and not used anywhere else, because then you don't have to try hard to filter out huge amounts of trivial junk) |
| 02:21 | <jamesr_> | are you auditing major libraries? |
| 02:43 | <wirepair> | does anyone implement the steps as outlined: http://dev.w3.org/html5/spec/Overview.html#autofocusing-a-form-control ? |
| 02:44 | <wirepair> | in particular ff 4.0b11 and chrome 8.0.552 seem to disregard step #3 |
| 02:44 | <wirepair> | er sorry step #5 |
| 05:04 | <Hixie> | hsivonen: do you recall why you wrote "the Document of the script element at the time the running a script |
| 05:04 | <Hixie> | algorithm started" |
| 05:04 | <Hixie> | rather than just the element's Document at the point in the running a script algorithm that the step is in? |
| 05:05 | <Hixie> | i don't see anything that could make it different |
| 05:06 | <Hixie> | hm i guess it's what the next step already says |
| 05:06 | <Hixie> | i wonder why i did it that way |
| 05:37 | <Hixie> | hey didn't we fix the spec to say that href="?from=1&to=2" was not an error? |
| 05:38 | <Hixie> | MikeSmith: do you know if the validator was updated with the latest char ref stuff? |
| 05:39 | Hixie | blogs for the first time in 10 months |
| 05:39 | <MikeSmith> | Hixie: how latest? |
| 05:39 | <Hixie> | the stuff that made &to= not be a bug |
| 05:40 | <MikeSmith> | you got a bug number? |
| 05:40 | <Hixie> | no |
| 05:40 | MikeSmith | looks through http://hg.mozilla.org/projects/htmlparser/ |
| 05:41 | <MikeSmith> | I have not ever touched that part of the parser code myself |
| 05:41 | <Hixie> | k |
| 05:41 | <Hixie> | looks like it hasn't |
| 05:41 | <MikeSmith> | and I don't remember Henri mentioning it |
| 05:41 | <Hixie> | it says my blog is invalid, but it looks like from the spec that I finally buckled under the pressure and made that not a bug |
| 05:41 | <Hixie> | not a conformance violation, i mean |
| 05:41 | <Hixie> | so i guess it's a validator bug now |
| 05:41 | <Hixie> | :-) |
| 05:42 | <Hixie> | anyway, gotta go. bbl. |
| 05:42 | <MikeSmith> | thanks! |
| 05:42 | <MikeSmith> | I'll raise a bug for it |
| 05:42 | <MikeSmith> | …and assign it to Henri |
| 05:42 | <Hixie> | hsivonen will hopefully be happy that i finally fixed one of his script things :-) |
| 05:42 | <MikeSmith> | hot potato |
| 05:42 | <Hixie> | hehe |
| 05:42 | <Hixie> | later |
| 05:50 | hsivonen | looks for spec changes |
| 05:50 | <hsivonen> | Hixie, MikeSmith: I thought I had fixed error reporting for ampersands in attribute values |
| 05:51 | MikeSmith | don't remember |
| 05:53 | <MikeSmith> | if so, I hope I didn't cause it to regress with any of my patches |
| 05:54 | <MikeSmith> | but I don't recall touching that |
| 05:57 | <hsivonen> | Hixie: thanks for fixing the async defaults to true bug! |
| 06:47 | <hsivonen> | wow. the IEblog WebM post sure has an astroturfy title |
| 08:08 | <othermaciej> | hsivonen: seems a little funny for them to call themselves "the community" but Dean has a good point about the standards status of WebM and Google's seeming disinterest in making it a real standard |
| 08:15 | <Hixie> | what is a "real" standard? |
| 08:16 | <othermaciej> | I guess that's hard to say |
| 08:16 | <othermaciej> | but I would say (a) controlled exclusively by a single corporation; and (b) defined in terms of a single specific implementation, bugs and all; are disqualifying conditions |
| 08:17 | <Hixie> | (b) seems resolved (http://tools.ietf.org/html/draft-bankoski-vp8-bitstream-00) |
| 08:17 | <Hixie> | dunno what the status on (a) is |
| 08:18 | <othermaciej> | "If there are any conflicts between this document and the reference source |
| 08:18 | <othermaciej> | code, the reference source code should be considered correct. The |
| 08:18 | <othermaciej> | bitstream is defined by the reference source code and not this |
| 08:18 | <othermaciej> | document." |
| 08:24 | <hsivonen> | othermaciej: yeah, it looks bad that WebM hasn't been blessed by something like ECMA. |
| 08:25 | <hsivonen> | personally, I think that at this point it would be bad to bikeshed the bitstream |
| 08:25 | hsivonen | would hate to see WebM have the fate of Web Socket |
| 08:25 | <othermaciej> | yeah, better not submit it to the IETF |
| 08:28 | <hsivonen> | has OpenType been blessed by ISO without bikeshedding? |
| 08:29 | <Hixie> | othermaciej: hm, yeah, that's sad. oh well. |
| 08:29 | <Hixie> | reference implementations are a terrible way to spec technology |
| 08:29 | <hsivonen> | that is, is OpenType basically an "open" spec where the participating communite was Microsoft and Adobe? |
| 08:29 | <hsivonen> | (at the time of speccing the details) |
| 08:29 | <hsivonen> | *community |
| 08:30 | <othermaciej> | I know nothing of the history |
| 08:30 | <othermaciej> | it is apparently an ISO standard now |
| 08:30 | <othermaciej> | (according to Wikipedia) |
| 08:31 | <hsivonen> | anyway, if stuff works and is RF, I don't think it's inherently bad that a format was set by one or a couple of players instead of a wide committee |
| 08:32 | <hsivonen> | PDF up to and including 1.4 works pretty well, though the spec was Adobe-controlled |
| 08:33 | <hsivonen> | from 1.5 onwards, I'm pretty happy that Apple de facto limited how crazy Adobe could make the format that can be deployed |
| 08:33 | <othermaciej> | Java being controlled by Sun is perhaps a more problematic example |
| 08:33 | <othermaciej> | notwithstanding claimed RF commitments |
| 08:34 | <othermaciej> | PDF in the wild is unfortunately still a bit too crazy |
| 08:34 | <hsivonen> | Java is not a file format, though |
| 08:34 | <hsivonen> | program execution environments are rather hard to make interoperate when they get as large and Java's default libs |
| 08:34 | <othermaciej> | there are sites that use PDF scripting solely to print things |
| 08:34 | <othermaciej> | by making self-printing PDFs that use JavaScript to do it, basically |
| 08:35 | <hsivonen> | I think JS in PDF is one of the part where Adobe went into the weeds |
| 08:35 | <hsivonen> | the Adobe Intelligent Document Platform in general is, IMO |
| 08:35 | <othermaciej> | I would agree that Java is not *just* a file format |
| 08:35 | <othermaciej> | but .class is sent over the wire just the same as .pdf or .html or .swf |
| 08:35 | <hsivonen> | othermaciej: well, sure, Java has a file format as a component, but it's not the interesting part |
| 08:36 | <hsivonen> | it's a necessary part, but not at all the hard part interop-wise |
| 08:36 | <hsivonen> | (well, depends on whether you count byte code verification as part of the format) |
| 08:38 | <othermaciej> | it kind of boggles the mind that HTML4 added a tag solely for embedding Java programs |
| 08:38 | <erlehmann> | hsivonen, watch the talk OMG WTF PDF from 27th chaos communication congress. you may be surprised. |
| 08:38 | <erlehmann> | PDF basically is a mess. |
| 08:38 | <erlehmann> | even without taking javascript into account |
| 08:39 | <othermaciej> | that reminds me that PDF and Java are also huge vectors for malware delivery via the browser |
| 08:39 | <erlehmann> | slides are here http://events.ccc.de/congress/2010/Fahrplan/events/4221.en.html |
| 08:41 | <othermaciej> | don't know if this relates to the de-facto mostly-single-implementation nature |
| 08:42 | <hsivonen> | erlehmann: I've read the entire PDF spec as it existed in 2002 (1.4 probably). I know it's an evolutionary mess, but it still works remarkably well for capturing resolution-independent final-form paginated graphics. |
| 08:42 | <hsivonen> | othermaciej: PDF or Adobe Reader? |
| 08:43 | <hsivonen> | othermaciej: is anyone delivering malware via Preview, Foxit or Evince? |
| 08:43 | <othermaciej> | hsivonen: I suspect you are a lot safer browsing PDFs on a Mac if you don't install Adobe Reader |
| 08:43 | hsivonen | doesn't count one of the iPhone jailbreaks as malware, because users wanted to have their phones jailbroken |
| 08:44 | <erlehmann> | hsivonen, mea culpa for underestimating your ability to withstand spec-induced pain. but you should still fast-forward through the talk, its funney :) |
| 08:44 | <hsivonen> | erlehmann: lol. the slides are in... PDF! |
| 08:45 | <hsivonen> | but 404 :-( |
| 08:45 | <erlehmann> | hsivonen, brace for impact |
| 08:45 | <erlehmann> | oops |
| 08:47 | <erlehmann> | hsivonen, http://blog.fireeye.com/files/27c3_julia_wolf_omg-wtf-pdf.pdf |
| 08:48 | <erlehmann> | possibly her best quote “It's called Adobe Acrobat because it'll bend over backwards!” |
| 08:49 | <erlehmann> | relevant blog post http://blog.fireeye.com/research/2011/02/omg-wtf-pdf-denouement.html |
| 08:49 | <hsivonen> | speaking of PDF, who wants to bet on http://www.w3.org/Bugs/Public/show_bug.cgi?id=11962 ending up FIXED? |
| 08:52 | <othermaciej> | maybe closed as WORKSFORME citing canvas... |
| 08:52 | <othermaciej> | (though of course, I don't think anyone implements that hypothetically possible feature) |
| 08:52 | <erlehmann> | hsivonen, when you read the PDF spec, was the launch action already available? did you get all “WTF were they thinking?” or was it just “this is wrong in a consistent and expected way”? |
| 08:53 | <hsivonen> | erlehmann: I don't recall, but by that time, they had already dabbled with video in PDF, which misses the core comptence of PDF spectacularly |
| 08:54 | <erlehmann> | othermaciej, i do not understand what problems baddi is having with printing to files. |
| 08:54 | <hsivonen> | erlehmann: that presentation seems to be a recount of all the crazy stuff that I'm happy that Apple doesn't support and, therefore, is confined to ill-fated intranets and Adobe Reader-based exploits |
| 08:54 | <erlehmann> | hsivonen, lets hope they converted the videos to CMYK, otherwise printers are not gonna print the- OH WAIT :D |
| 08:56 | <erlehmann> | does apple use libpoppler or something home-grown? |
| 08:56 | <hsivonen> | erlehmann: home-grown, I imagine |
| 08:56 | <hsivonen> | I haven't seen their source |
| 08:57 | <hsivonen> | but yeah, it's scary that people actually have Adobe Reader installed and use it given all those "features" |
| 09:00 | hsivonen | wonders what codebase Chrome's bundled PDF reader comes from |
| 09:00 | <erlehmann> | its funny what kind of computing environments i see in my peer groups. even the non-nerds mostly use linux or os x. |
| 09:01 | <erlehmann> | but when i visited an indie game jam recently, almost every single team developed for windows/xbox or flash. on windows. |
| 09:02 | <erlehmann> | those are the kinds of people affected by adobe reader exploits and i am happy i do not have to put up with that. |
| 09:02 | <erlehmann> | (some even got angry when i asked about their source repositories. so the culture shock goes both ways.) |
| 09:05 | <othermaciej> | I don't understand how anyone could possibly program without version control |
| 09:06 | <erlehmann> | ha! the two teams having version control used SVN! |
| 09:06 | <erlehmann> | (out of … 11?) |
| 09:08 | <erlehmann> | fun fact: several years ago, i saw the SVN repository of a student group having to do an assignment that included having to use version control to pass. |
| 09:08 | <erlehmann> | it included directories named 2006-11-01 and so on. |
| 09:08 | <erlehmann> | for every single day they had coded something. |
| 09:08 | <erlehmann> | my face was like ._. |
| 09:35 | <connrs> | [A |
| 09:51 | <webr3> | is CORS anywhere near going to LC? |
| 09:57 | <roc> | "PDF: a native code execution format pioneered by Adobe" (shaver quote) |
| 09:58 | <erlehmann> | roc, especially funny about the talk is julia wolfs idea in the beginning, that if the model was slightly different, adobe would have re-invented lisp. |
| 09:59 | <roc> | I think Google *wants* WebM to be a real standard, but is just failing to do anything useful about it |
| 10:00 | <roc> | I admit that it's hard to tell |
| 10:00 | <hsivonen> | erlehmann: AFAICT, except for the length versus sentinel stuff, I think most craziness wasn't fundamental to PDF's original design |
| 10:00 | <hsivonen> | erlehmann: rather, horrible, horrible later day misfeatures and Reader bugs |
| 10:01 | <hsivonen> | FWIW, I think it would be good for Firefox to have a built-in PDF reader that supports roughtly the Apple/Evince subset |
| 10:01 | <hsivonen> | *roughly |
| 10:02 | <roc> | we should write one in JS |
| 10:04 | <hsivonen> | roc: a PDF to SVG converter in JS would make sense if SVG had the ability to access fonts by glyph index instead of Unicode character |
| 10:04 | <roc> | we could add that |
| 10:05 | <hsivonen> | roc: so some stuff would need to be added, but yeah, I think writing one in JS (by converting to SVG) would make sense |
| 10:06 | <hsivonen> | though I wonder how that would perform compared to Evince or Preview |
| 10:06 | <roc> | you'd have to do some experiments to see if it can be competitively fast |
| 10:06 | <roc> | is PDF fully programmable like PS? |
| 10:07 | <hsivonen> | roc: if you count the misfeatures, it is! (with JavaScript) |
| 10:07 | <roc> | I mean the sane subset |
| 10:07 | <hsivonen> | roc: no |
| 10:07 | <jgraham> | I thought originally I was supposed to be less programmable |
| 10:07 | <jgraham> | Indeed, I thought that was the value proposition |
| 10:07 | <jgraham> | But I might be wrong |
| 10:07 | <erlehmann> | roc, multiple indepentent implementations, royalty-free patent licensing, IETF draft for vp8 bitstream … it is hard to tell what is missing. |
| 10:07 | <roc> | what maciej said, at least, part #2 |
| 10:08 | <hsivonen> | erlehmann: that the IETF drafts is on the "informational" track? |
| 10:08 | <erlehmann> | hsivonen, i see what you did there. |
| 10:09 | <hsivonen> | roc: oh, and I'm assuming the sane subset covers only outline fonts with TrueType or CFF outlines |
| 10:09 | <hsivonen> | roc: not Type 3 stuff and such |
| 10:10 | <hsivonen> | I'm not sure if Type 3 has crazy programmability. I suspect it does. |
| 10:10 | <erlehmann> | hsivonen, but it should serve to appease the „oh noes i have to read googles code to get anything done“ crowd |
| 10:10 | <roc> | we'd just repack embedded fonts into data: URLs |
| 10:10 | <erlehmann> | cue code examples excerpts from the draft. |
| 10:11 | <hsivonen> | roc: might be worth seeing how far Adobe Mars got |
| 10:11 | <hsivonen> | as I undestand it, they tried to support the PDF feature set with SVG syntax |
| 10:19 | <othermaciej> | erlehmann: the IETF draft explicitly says that the reference implementation is authoritative, and not the draft |
| 10:20 | <othermaciej> | erlehmann: as I said earlier: http://krijnhoetmer.nl/irc-logs/whatwg/20110203#l-546 |
| 10:20 | <jgraham> | hsivonen: Ignoring the fundamental design that you don't like, did you have some suggestion about the API for signalling to testharness.js "there are more results coming, please hold" |
| 10:20 | <jgraham> | I seem to recall that you did |
| 10:21 | jgraham | has a problem that he is not sure how to solve in the nicest way |
| 10:21 | <erlehmann> | othermaciej, oh. i guess that is the #whatwg version of slashdots RTFA, then. |
| 10:21 | <othermaciej> | so yeah, you do have to read and reverse-engineer Google's code if you want to independently reimplement it |
| 10:21 | <erlehmann> | othermaciej, thanks. |
| 10:22 | <othermaciej> | not only in theory, but apparently the people who wrote an independent decoder said had to consult the source too |
| 10:22 | <hsivonen> | jgraham: I think the default should be "there are more results coming, please hold" |
| 10:22 | <jgraham> | (I have a file with many tests. I would like each test to have a rather short timeout, and the overall file to have a rather long timeout. I would ideally like to declare all the tests upfront so that if the file times out it is obvious what went wrong rather than just getting fewer results than expected) |
| 10:22 | <hsivonen> | jgraham: and once there aren't more results coming, the test script should have to call finish(); |
| 10:22 | <othermaciej> | they claimed (I have no basis to verify) that the spec is extremely vague and flat contradicts what the code does in a number of places |
| 10:23 | <erlehmann> | othermaciej, so getting the bitstream fixed is not a priority for google? a truly sad thing :/ |
| 10:23 | <othermaciej> | by "fixed" do you mean "frozen" or "made correct"? |
| 10:23 | <jgraham> | hsivonen: Hmm, OK. |
| 10:23 | <jgraham> | Not really backwards compatible |
| 10:24 | <othermaciej> | because I believe it is already declared frozen, but based on the behavior of their implementation, not any spec |
| 10:24 | <jgraham> | But maybe enough to give me an idea |
| 10:25 | <erlehmann> | othermaciej, i meant frozen. but if they do not change their implementation, i guess thats as good as it can get. |
| 10:25 | <hsivonen> | jgraham: the alternative is doing what Mochitest does. |
| 10:25 | <hsivonen> | jgraham: where the test first calls waitForExplicitFinish() |
| 10:25 | <hsivonen> | jgraham: and then later finish(); |
| 10:26 | <hsivonen> | jgraham: but in my experience, it makes more sense to make waiting the default mode |
| 10:28 | <jgraham> | hsivonen: It seems people want a setup() function anyway that you can use to run code before any tests. I was thinking that being able to do setup({waitForExplicitFinish:true}) or similar might work |
| 10:28 | <jgraham> | and leave the option of flipping the default later |
| 10:29 | <hsivonen> | jgraham: I suggest using something less verbose than what Mochitest uses |
| 10:29 | <jgraham> | waitForExplicitFinish is very long for sure |
| 10:29 | <hsivonen> | jgraham: I have to copy and paste the mochitest stuff from a wiki every. single. time. |
| 10:29 | <hsivonen> | like namespace URLs |
| 10:29 | <othermaciej> | WebKit tests default is that the test is considered done after it finishes loading unless it earlier asks the harness to wait until it calls an explicit done method |
| 10:30 | <othermaciej> | (waitUntilDone() / notifyDone() are the calls) |
| 10:30 | <hsivonen> | othermaciej: that's the Mochitest model |
| 10:30 | <jgraham> | That sounds very like the model I am thinking of too :) |
| 10:30 | <hsivonen> | othermaciej: my observation is that almost always the explicit waiting mechanism is needed anyway |
| 10:30 | <othermaciej> | I think it is convenient for the significant subset of script tests that can be done fully syncrhonously or in onload |
| 10:30 | <hsivonen> | ok. |
| 10:31 | <roc> | It seems to me that I have to use SimpleTest.waitForFinish() and SimpleTest.finish() in every single test I write |
| 10:31 | <roc> | maybe it's just me |
| 10:32 | <jgraham> | Maybe Mochikit and the WebKit harness encourage different styles |
| 10:32 | <othermaciej> | a lot of the tests I have written have been for DOM APIs or pure JavaScript |
| 10:33 | <othermaciej> | so that may have an impact on my perception |
| 10:34 | <jgraham> | Yeah, testing pure javascript is rather easier than testing complex async APIs |
| 10:34 | <zcorpan> | the experience i have so far with testharness.js is that for future tests i write i'm only going to use async_test even if the test i write is sync in nature |
| 10:34 | <othermaciej> | editing tests are mostly not async either |
| 10:35 | <roc> | ok, rough numbers, 1590 out of 3131 mochitests use waitForExplicitFinish |
| 10:35 | <zcorpan> | because then i can copy/paste the same code for the next test regardless of whether i want it to be sync or async |
| 10:35 | <jgraham> | zcorpan: OOI why? Also, I didn't know you had used it :) |
| 10:35 | <jgraham> | Heh |
| 10:36 | <zcorpan> | jgraham: only a little |
| 10:36 | <zcorpan> | jgraham: also i would like step() to return a function :) |
| 10:36 | <jgraham> | zcorpan: Me too. |
| 10:37 | <jgraham> | zcorpan: I just don't fancy changing all the existing tests :( |
| 10:37 | <zcorpan> | i tested if using onevent = new t.step(function(){...}) would work but it seems it doesn't |
| 10:38 | jgraham | tries to remember how branching works in hg |
| 10:39 | <roc> | "hg update -r <changeset>", make some changes, "hg commit"? |
| 10:41 | <jgraham> | Well specifically named branched |
| 10:41 | <jgraham> | *branches |
| 10:41 | <jgraham> | What git would call branches |
| 11:23 | <hsivonen> | Hixie: I think conceptually, innerHTML, createContextualFragment and XSLTProcessor.transformToFragment are shortcuts for creating DOM subtrees in script |
| 11:24 | <hsivonen> | Hixie: since innerHTML-created scripts don't run anyway, it's safe to consider them as not parser-created |
| 11:24 | <hsivonen> | Hixie: so that the force-async stuff is observable in a way that's consistent for DOM subtrees created without such shortcuts |
| 11:25 | <hsivonen> | Hixie: it only matters if someone really wishes to read the .async property on innerHTML-created scripts |
| 11:25 | <hsivonen> | also, I wonder if mattmay has noticed what the IETF's patent policy is like |
| 11:26 | <hsivonen> | (not to suggest that IETF's makes the WHATWG's lack of policy better, but just to put things in perspective) |
| 11:48 | <jgraham> | Philip`: fwiw, it seems like PyPy has better than a factor of 2 wins for the benchmarks where you might expect it i.e. ones that sound like they are calculations in loops |
| 11:49 | <jgraham> | e.g. it is about 20x faster for "raytrace-simple" |
| 11:57 | <karlcow> | hsivonen: if you see errors into http://www.la-grange.net/2011/02/03/standard-organization |
| 11:57 | <hsivonen> | jgraham: why would PyPy have perf wins over anything? |
| 11:58 | <hsivonen> | isn't PyPy python implemented in python? |
| 11:58 | <jgraham> | hsivonen: Yes, but they also implemneted a JIT |
| 11:58 | <jgraham> | So it is faster than CPython for many cases |
| 11:58 | <hsivonen> | jgraham: what does in JIT to? |
| 11:59 | <hsivonen> | karlcow: I don't see errors, but I don't know OMG, OASIS or WAPF policies well enough to check correctness |
| 11:59 | <jgraham> | hsivonen: Machine code I assume |
| 11:59 | <hsivonen> | karlcow: oh, and I believe ISO WGs can decide to be RF if they want to |
| 11:59 | <hsivonen> | karlcow: don't take my word for that, though |
| 12:00 | <jgraham> | karlcow: I suppose it is obvious that you seem to be missing some people |
| 12:00 | <hsivonen> | karlcow: I believe the original JPEG Baseline wasn't RF by accident but the group deliberately wanted to have an RF Baseline profile |
| 12:00 | <hsivonen> | karlcow: so arithmetic coding wasn't put into Baseline |
| 12:00 | <hsivonen> | and of course, everyone implemented just the baseline |
| 12:01 | <hsivonen> | so the existence of non-Baseline is mainly an academic thing |
| 12:01 | <hsivonen> | blame IBM |
| 12:01 | <hsivonen> | for not making arithmetic coding RF back then |
| 12:02 | <hsivonen> | basically, we've been transmitting more bits than known to be necessary for the lifetime of the Web |
| 12:02 | <hsivonen> | so that IBM could make a buck |
| 12:03 | <hsivonen> | except no one wanted to take a license from them so everyone lost |
| 12:03 | <hsivonen> | IBM didn't get money and everyone else didn't get better compression |
| 12:03 | <hsivonen> | sadness |
| 12:08 | <karlcow> | it is a cut n paste of a table I made in 2002 |
| 12:12 | <hsivonen> | hmm. so it looks like there is an actual disposition of comments for ARIA that includes my comments |
| 12:12 | <hsivonen> | http://www.w3.org/WAI/PF/comments/issue_disposition_report?document_version_id=1 |
| 12:13 | <hsivonen> | but the latest version links to a different DoC that makes it look like those comments didn't exist |
| 12:14 | <hsivonen> | I find it interesting that the PF claims that some of the feedback items that I've raised have the disposition "Accepted proposal" when my Acknowledgement is "Do not accept" |
| 12:15 | <hsivonen> | I wonder if I should have made some of those Formal Objections |
| 12:17 | <hsivonen> | I wonder what the CR exit criteria for ARIA is... |
| 12:18 | <hsivonen> | if they are serious about CR exit criteria (like CSS is), some of my comments that they didn't address should block exit from CR |
| 12:18 | <hsivonen> | unless implementors do something silly |
| 12:19 | <zcorpan> | has ARIA fixed the <body>-or-<frameset>-is-the-root-element-in-HTML thing? |
| 12:19 | <hsivonen> | zcorpan: dunno |
| 12:19 | <hsivonen> | item 5 in ARIA CR exit criteria is "Verify interoperable results: Find at least two implementations of each normative requirement where the defined behavior for the respective accessibility API is observed. " |
| 12:20 | <hsivonen> | maybe I should check if e.g. the role=math stuff is formulated as a normative requirement |
| 12:20 | <hsivonen> | because it's easy to pull the XHTML2 WG trick of exiting CR by not having normative requirements |
| 12:23 | <zcorpan> | it seems the definition of "ARIA root" (or whatever it was called) is gone, but there's still "authors SHOULD set the role of application on the root node for content, such as the body element in HTML or svg element in SVG." |
| 12:23 | <hsivonen> | on a more positive note, role=math has gained examples: http://www.w3.org/TR/wai-aria/complete#math |
| 12:24 | <hsivonen> | the spec text itself doesn't make it at all clear what they meant |
| 12:24 | <hsivonen> | it's bad if one has to look at examples to decrypt the spec text |
| 12:25 | <hsivonen> | the sentence 'This role provides a hook whereby a plug-in mechanism can provide multi-modal access to compliant MathML, as well as enabling support for MathML in "mainstream" user agents.' is just weird |
| 12:25 | <zcorpan> | i think "math" should be axed, and argued my case when it was introduced but i didn't win |
| 12:26 | <zcorpan> | role=math for mathml makes no sense at all |
| 12:26 | <zcorpan> | role=math for LaTeX makes some sense, but it's not defined how it should work at all |
| 12:27 | <zcorpan> | seems better to focus on MathML |
| 12:28 | <hsivonen> | http://www.w3.org/WAI/PF/aria-implementation/#exclude_elements is truly bizarre as far as math goes |
| 12:29 | <jgraham> | zcorpan: LaTeX may have a better a11y story at present |
| 12:29 | <hsivonen> | is it now the WAI position that math accessibility won't be achieved by MathML getting spoken out but by authors providing textual representations of math as aria-label and the MathML stuff getting suppressed? |
| 12:30 | <jgraham> | At least there are > 0 screenreader implementation that understand LaTeX but I am not sure about MathML |
| 12:30 | <annevk> | hah, not even cold in Oslo |
| 12:30 | <hsivonen> | jgraham: Math Player does MathML to speech |
| 12:30 | <hsivonen> | jgraham: for LaTeX, do you mean AsTeR? |
| 12:30 | <jgraham> | hsivonen: Interesting. Know if it is any good? |
| 12:30 | <annevk> | webr3, if you're around now... |
| 12:30 | <hsivonen> | jgraham: I don't |
| 12:31 | <jgraham> | hsivonen: Possibly. I have heard they exist at least |
| 12:31 | <hsivonen> | jgraham: should be easy enough to try if you have a Windows VM around |
| 12:31 | <jgraham> | And it seems more generally useful since blind people publishing math content will probably have to use LaTeX anyway |
| 12:31 | <jgraham> | Or Microsoft word, I guess |
| 12:32 | <jgraham> | But LaTeX in maths/physical sciences |
| 12:33 | <hsivonen> | I guess I'll raise a CR comment about role=math |
| 12:33 | <hsivonen> | because the spec text sucks |
| 12:33 | <hsivonen> | even if one accepts the design that can be inferred from the Implementor's Guide and the examples taken together |
| 12:36 | annevk | should probably read the backlog |
| 12:37 | jgraham | wishes it were easy to pause a setTimeout |
| 12:38 | <jgraham> | Hmm, maybe I don't need it |
| 12:43 | webr3 | is around in about 2 minutes, need to grab a drink |
| 12:50 | <annevk> | webr3, having reread, what you think about namespaces is somewhat separate from thinking you can do things over |
| 12:50 | <annevk> | webr3, "XHTML 2.0" is sort of the canonical example of how reinventing a language and "improving" it slightly is not working in practice |
| 12:51 | <annevk> | webr3, with which I meant to say that reinventing the web security model is not going to work in practice |
| 12:51 | <annevk> | webr3, not until the web is replaced |
| 12:54 | <webr3> | annevk, on namespaces: did you see my comments on namespaces, rdfa and html to the tag before? http://lists.w3.org/Archives/Public/www-tag/2011Feb/0032.html |
| 12:56 | <webr3> | annevk, on web security I'm not saying CORS doesn't deal with the hear and now, it does - I'm saying that it doesn't cater for / help reverse the insecurities of the web in any way, there is something fundamentally flawed when you can do insecure stuff and be "logged in" by passing a string token in plain text (cookies) ... |
| 12:57 | <webr3> | and when you cannot read a comment in a script included remotely, but when you can execute a function from that script |
| 12:57 | <webr3> | and when most of the web APIs in the world use things like JSONP and not CORS, the former being a cross origin request that executes code from another library |
| 12:58 | <annevk> | well yes, you have said that before, and I believe I replied with that we hope that will change once CORS is more widely implemented |
| 13:00 | <webr3> | aside: obviously it's nothing personal in any way, and all a means to the same end, same side as it were, just want people to be secure/safe on line and have a good experience on line - it'd be good if both approaches could be combined (deal with the hear and now, move to a "securer" web from both a security and privacy standpoint, long term, and not /just/ for the browsers, but for everyone |
| 13:00 | <annevk> | the problem is unique to browsers though |
| 13:00 | <webr3> | I really don't have much else to say other than that, but do want to stress that I'm not just some random academic who uses decade old techs, rather a dev who wants to use the techs of the next decade |
| 13:01 | <webr3> | annevk, it's not - honestly |
| 13:01 | <annevk> | no need to say you're honest, you can give me an example |
| 13:02 | <annevk> | ;) |
| 13:03 | <webr3> | if an intranet is insecure because data can pass between the local net and internet, then it's insecure, and any program w/ tcp access is as vulnerable as the next - likewise if a website can be comprimised because a cookie can be sniffed and used to auth, then its comprimised for all clients, not just browsers (firesheep anybody?) |
| 13:05 | <webr3> | non of it can be addressed overnight - if intranets were secured properly, and XHR simply stripped all headers like cookie and the like (unsafe ones) then we'd all be in a better place |
| 13:05 | <hsivonen> | I sent yet another comment: http://lists.w3.org/Archives/Public/www-math/2011Feb/0001.html |
| 13:05 | <webr3> | disagree? |
| 13:06 | <hsivonen> | webr3: then you couldn't use XHR for services that need login, which would be bad, too |
| 13:06 | <hsivonen> | (or you'd need to implement XHR credentials explicitly in JS) |
| 13:07 | <webr3> | or use HTTP+TLS w/ client side certs or by havign an api and protocol which used TLS extensions to pass username and password like SRP |
| 13:08 | <webr3> | "login" shouldn't be happening though.. HTTP is stateless, TLS isn't, stateful auth at TLS session level = cool, stateful HTTP = not cool |
| 13:09 | <webr3> | we all know it's the source of almost every security vuln there is on the web and in the browsers |
| 13:09 | <webr3> | none of us can argue that |
| 13:10 | <hsivonen> | webr3: HTTP being stateless is fiction |
| 13:11 | <hsivonen> | webr3: how do things become better if ambient state moves to the TLS layer? |
| 13:11 | <hsivonen> | webr3: or would you make it non-ambient? |
| 13:11 | <hsivonen> | (how?) |
| 13:12 | <webr3> | well no, state should be maintained on the client side, in the application, not on the server at all, some resources need ACL protection and that's a different, non stateful matter, better handled with HTTP+TLS |
| 13:13 | <hsivonen> | webr3: cookie-based login maintains state on the client, no_ |
| 13:13 | <hsivonen> | ? |
| 13:13 | <annevk> | webr3, so yeah, if you have some kind of malware on your computer the intranet is "vulnerable" |
| 13:13 | <annevk> | webr3, if there is no such thing though, it is just the browser |
| 13:13 | <webr3> | hsivonnen, no - else there wouldn't be any need for a cookie.. |
| 13:14 | <hsivonen> | webr3: so a client-side cert is a glorified cookie |
| 13:14 | <webr3> | no.. |
| 13:15 | <hsivonen> | webr3: when the browser presents a client-side cert to the server, how does the server know the request wasn't triggered by something representing user intent instead of something scripted? |
| 13:15 | <hsivonen> | webr3: how is a client-side cert not a glorified cookie in the sense that it's an identifying token than the browser presents to the server |
| 13:15 | <hsivonen> | ? |
| 13:16 | <webr3> | lol, it's the browsers job to ensure the user knows they've just made a request whilst being identified.. |
| 13:16 | <webr3> | user agents job* |
| 13:16 | <hsivonen> | webr3: so how do client-side certs solve anything compared to a UX than confirms if you want to send this cookie to this server? |
| 13:17 | <hsivonen> | for this request |
| 13:17 | <hsivonen> | webr3: do you have plausible UI designs for letting the users review all the requests that the browser makes? |
| 13:18 | <webr3> | encryption over the wire, peer to peer, no requirement for server to maintain state over multiple requests, no way it to be hijacked by an intermediary or third party. |
| 13:18 | <hsivonen> | webr3: so do you expect the user to reauthorize the use of the cert for every request in order to avoid having client-side state? |
| 13:19 | <webr3> | hsivonen, not a UI guy, but there's another factor, scripts would need to be identified in such a way that users could allow X script and not Y - similar to the approach taken in widgets and warp |
| 13:19 | <webr3> | hsivonen, no i expect the user agent to manage which "scripts" are allowed to make what requests, and provide the user with a quick way of saying let script Y make requests to (everywhere, these palces, nowhere) |
| 13:20 | <hsivonen> | webr3: good luck with J. Random User identifying scripts |
| 13:20 | <hsivonen> | webr3: so how's that different from putting that UX on top of cookies? |
| 13:20 | <hsivonen> | how does SSL make the token and UI more magic? |
| 13:21 | <hsivonen> | it boils down to having a token and the user authorizing the presentation of the token to the server instead of all requests being ambiently authorized to present the token |
| 13:22 | <hsivonen> | or if you don't want the user to oversee this all, the tokens should be tied to the origins making the requests |
| 13:22 | <webr3> | no.. it boils down to whether users and websites are safe or not, sending a plain text cookie over insecured protocols to a stateful application is not safe for users or websites, hence the current mess |
| 13:22 | <hsivonen> | but that could be done with cookies tied to requesting origin |
| 13:23 | <webr3> | http+tls with the presentation of (some user identifier) protects users and websites |
| 13:23 | <webr3> | hsivonen, no it can't.. |
| 13:23 | <hsivonen> | webr3: why not? |
| 13:24 | <webr3> | sniff a cookie with firesheep, use curl to send it in a header with a spoofed origin, or no origin |
| 13:24 | <webr3> | that's hardly rocket science |
| 13:24 | <hsivonen> | currently if Origin A makes a request to Origin B and Origin B sets a cookie, Origin C making a request to Origin B sends back the cookie, because the cookie wasn't put into an Origin A-specific jar |
| 13:25 | <webr3> | in the web browsers /only/ - scope out a bit.. |
| 13:25 | <hsivonen> | webr3: I mean cookies over TLS as opposed to certs over TLS |
| 13:26 | <webr3> | okay that's an improvement and keeps people safer; sookie being much more vuln to dictionary brute force etc than public key encryption, but yet forcing TLS when identified is a HUGE step forward |
| 13:26 | <webr3> | I'd be happy to see that alone get adopted / pushed |
| 13:26 | <webr3> | tis half way there |
| 13:27 | <annevk> | anyone know status of IDN for email? and whether we should maybe ignore said status for type=email given that apparently it is seeing some usage already |
| 13:28 | <annevk> | we got a complaint that e.g. x@日.jp is not working currently |
| 13:31 | <webr3> | hsivonen, are we roughly agreed - or does that help explain my thoughts on the matter? |
| 13:32 | <webr3> | annevk, when you're done w/ the IDN stuff, see if the above convo w/ hsivonen makes sense and if you agree that'd be a good goal |
| 13:32 | <MikeSmith> | Hixie: nobody implemented @seamless yet? |
| 13:36 | <MikeSmith> | karlcow: you should add Khronos group to your standards-org table |
| 13:36 | <karlcow> | MikeSmith: ah thanks. will do. |
| 13:36 | <hsivonen> | webr3: well, I still don't see how client-side certs solve any cookie problems compared to cookies over TLS |
| 13:36 | <annevk> | webr3, STS is the always use TLS solution... or did you mean something else? |
| 13:37 | <hsivonen> | webr3: once the sniffing problem is solved with crypto, the rest is a question of when tokens are sent |
| 13:37 | <hsivonen> | not a matter of the tokens themselves being crypto thingies |
| 13:38 | <webr3> | hsivonen, roughly agree, other than crypto isn't user specific that way, it's just wire crypto, so then the strength of the token becomes a factor |
| 13:38 | <webr3> | I'mnot hooked on client side certs, just a TLS when identified as being a good thing, moving to HTTP (http://) being stateless, and anywhere near that would be a huge improvement |
| 13:39 | <webr3> | especially if intranet security could be addressed in some way over time too |
| 13:39 | <webr3> | just any step in those directions, and some agreement from you guys that that would be a good thing would be enough for me |
| 13:39 | <hsivonen> | the main reasons why people do login without crypto are 1) getting certs is trouble and 2) performing crypto burns cycles |
| 13:40 | <hsivonen> | of course, login without crypto is a terrible idea in a world with eavesdroppable channels |
| 13:40 | <webr3> | :) yes |
| 13:40 | <webr3> | to both |
| 13:40 | <webr3> | 1) is being worked on btw |
| 13:40 | <webr3> | making self signed certs easier that is |
| 13:42 | <hsivonen> | annevk: fwiw, I think the questions in the IEblog post are very reasonable. the main problems are not saying what risks are apply to H.264 as well and having "from community" in the title instead of "from Dean" |
| 13:42 | <hsivonen> | s/are apply/apply/ |
| 13:43 | webr3 | wonders if saying "yes lets try and do something, anything, about web security, even if it's just getting TLS as defacto when authed and discouraging cookie use" is a hard commitment to make and to facto in to the current model? |
| 13:45 | <annevk> | hsivonen, they are reasonable questions, but 2/3 apply to H.264 too |
| 13:46 | <annevk> | hsivonen, the problem is indeed the way it is presented |
| 14:14 | <loucapo> | greeting all, i am still trying to find some guidance on CORS to a pwd protected url. what i have doesnt seem to work |
| 14:19 | <annevk> | you might be running into browser bugs |
| 14:19 | <annevk> | if you set an Authorization header yourself and do an otherwise simple request, does the browser issue a preflight request? |
| 14:20 | <annevk> | or does it try to directly issue the request (if so, it's a browser bug) |
| 14:20 | <loucapo> | its does preflight but i do not see the header in the preflight |
| 14:23 | <annevk> | right, if the header is not in Access-Control-Request-Headers there's a bug too |
| 14:23 | <loucapo> | i see |
| 14:24 | <loucapo> | so i cannot really 100% support that as of now |
| 14:25 | <annevk> | you should file some bugs |
| 14:26 | <loucapo> | ok, i iwll test it with several browsers first |
| 14:26 | <webr3> | loucapo, you are sending the 'Access-Control-Allow-Credentials' header yes? |
| 14:26 | <webr3> | (from the server) |
| 14:26 | <loucapo> | let me dbl chk |
| 14:27 | <loucapo> | yup its true |
| 14:27 | <webr3> | how are you sending username and password? |
| 14:27 | <loucapo> | Access-Control-Allow-Head...X_REQUESTED_WITH, X-TxId, Content-Type, Cache-Control, AuthorizationAccess-Control-Allow-Meth...GET, POST, OPTIONSAccess-Control-Allow-Orig...http://localhostAccess-Control-Expose-Hea...Status, Content-LengthAccess-Control-Max-Age86400Content-Typetext/htmlAccess-Control-Allow-Cred...true |
| 14:28 | <loucapo> | oops that got jumbled |
| 14:28 | <webr3> | pastebin it |
| 14:29 | <loucapo> | http://pastebin.com/eZW2ZsHz |
| 14:31 | <loucapo> | i believe i need to base64 encode u & p |
| 14:34 | <webr3> | ahh I had loads of problems with Allow-Origin of localhost, swap that to * for a minute and see if it works |
| 14:34 | <annevk> | * + credentials does not work |
| 14:35 | <annevk> | besides, we already determined another problem |
| 17:33 | <zcorpan> | https://grepular.com/Abusing_HTTP_Status_Codes_to_Expose_Private_Information - should we always fire 'load' for cross-origin images and scripts etc? |
| 17:46 | <ap> | Hixie: hsivonen: it seems to be far from "post mortem" stage for script loading hacks required by LABjs, see <http://ln.hixie.ch/?start=1296711456&count=1>; |
| 17:47 | <ap> | which makes me unsure if we want to implement these latest spec changes in WebKit - what good are they if they don't even make LABjs work? |
| 17:48 | <ap> | <https://bugs.webkit.org/show_bug.cgi?id=30862>; has the discussion |
| 17:52 | <Hixie> | they don't make LABjs work? |
| 17:53 | <karlcow> | interesting http://www.guardian.co.uk/news/blog/2011/feb/03/egypt-protests-live-updates |
| 17:53 | <karlcow> | >5.52pm: The Guardian's Mona Mahmood has translated another summary into Arabic. We're working on how to format it correctly so that it aligns to the right, not the left. |
| 17:54 | <karlcow> | ***aligns to the right, not the left*** |
| 17:54 | <Hixie> | ap: that seems to be an unrelated caching issue |
| 17:54 | <karlcow> | I guess they didn't plan at the start to have multilingual pages. |
| 17:54 | <ap> | Hixie: it's definitely not technically related |
| 17:55 | <ap> | Hixie: it's related in that the technique LABjs wants seems to require both |
| 17:55 | <Hixie> | the bug above seems uncontroversial |
| 17:56 | <ap> | Hixie: all WebKit developers who cared to comment think it's WONTFIX - is that what you mean by uncontroversial? |
| 17:56 | <Hixie> | are we looking at the same bug? |
| 17:57 | <Hixie> | if you force-reload a page, the resources referenced by the parser are also force-reloaded, but those referenced by script later are not |
| 17:57 | <Hixie> | the comments from devs all seemed positive to me... |
| 17:57 | <Hixie> | but i did skim it |
| 17:58 | <ap> | Hixie: Kyle Simpson has hijacked the bug to talk about larger issues - he wants reload to set a permanent state on a page, so that all resources will be force-reloaded |
| 17:58 | <Hixie> | oh i just ignored his comments cos they were so long |
| 17:59 | <hsivonen> | ap: huh? how do you mean don't make LABjs work? |
| 17:59 | <hsivonen> | ap: it seemed to me WebKit devs were deferring to Hixie for decision |
| 17:59 | <Hixie> | hsivonen: different issue |
| 17:59 | <Hixie> | ap: seems reasonable to me to make force-refresh sticky until onload, i agree that beyond that it gets a bit weird |
| 18:00 | <hsivonen> | Hixie: oh, ok |
| 18:00 | <Hixie> | ap: this all seems to be a UI issue though, i don't see how LABjs could depend on it one way or the other |
| 18:01 | <ap> | Hixie: seems like they want to train users to hit shift-refresh (or ctrl+f5) when something doesn't work |
| 18:01 | <ap> | Hixie: and that will make dynamic script loading feasible |
| 18:02 | <Hixie> | one would hope that something not working would be rare enough that there would be no opportunity for user training on the matter |
| 18:02 | <Hixie> | especially since whether it works or not is entirely under the control of the author here |
| 18:02 | <Hixie> | if they want to force refresh, just have them change the url |
| 18:02 | <Hixie> | foo.js?r=2 |
| 18:02 | <Hixie> | foo.js?r=3 |
| 18:02 | <Hixie> | foo.js?r=4 |
| 18:02 | <Hixie> | etc |
| 18:04 | <hsivonen> | relying on user training when the author has too long an expiry but doesn't change the URL seems like FAIL to me |
| 18:05 | <hsivonen> | either the author should make expiry short or change the URL |
| 18:09 | <ap> | hsivonen: wholeheartedly agreed. Shift-reload is something we were extremely hesitant to even implement in Safari, and making it part of normal user experience is a bad idea |
| 18:12 | <othermaciej> | hsivonen, ap: maybe the shift-reload is only intended for use during development and testing? |
| 18:13 | <othermaciej> | (though really a staging server for testing should have very short expirations) |
| 18:13 | <ap> | othermaciej: today, its behavior only helps with buggy caching proxies - instead of revalidation, it forces end to end reload |
| 18:14 | <othermaciej> | ah |
| 18:16 | <hsivonen> | in any case, as long as window.location.reload() changes aren't being requestied, this seems like a thing that doesn't belong in a spec that's concerned with interop |
| 18:18 | <Hixie> | indeed |
| 18:18 | <Hixie> | ui issue |
| 18:24 | <AryehGregor> | Philip`, I was more trying to get a feel for how authors use the feature, not judge compat risk. |
| 18:25 | <AryehGregor> | E.g., ehsan asked what the use-cases were for innerText, and now I have a couple. |
| 18:25 | <AryehGregor> | Opera people have already said you can mostly get compat by making it work almost like textContent. |
| 19:20 | <jgraham> | FWIW Opera doesn't have a concept of force-reload exposed in the UI |
| 19:26 | <heycam> | annevk, a table i can't quite remember. what would it be a table of? |
| 19:32 | <jgraham> | heycam: If you are asking the question I think you are asking, DOM Method and behaviour with null |
| 19:34 | <heycam> | jgraham, ah |
| 19:34 | <heycam> | jgraham, yeah I did test a bunch of methods and put the results somewhere... |
| 19:38 | <heycam> | jgraham, annevk, i found this http://mcc.id.au/2007/05/binding-tests/index.html but i don't think that's what you're after. (there's one test in there for assigning null to some attributes but it looks like i don't have the results recorded.) |
| 19:40 | <heycam> | for DOMStrings and the specs, at least, there are these: http://dev.w3.org/2006/webapi/WebIDL/dom/ |
| 19:41 | <heycam> | s/the specs/the DOM specs/ |
| 20:03 | <AryehGregor> | Hixie, it's not at all clear to me whether any browsers are interested in an innerText or Selection.toString() spec. |
| 20:06 | <AryehGregor> | Maybe WebKit is, I've gotten no feedback from anyone there yet one way or another. |
| 20:06 | <AryehGregor> | Well, anyway, I'll keep discussing it, but I'll take a look at createContextualFragment() now. |
| 20:08 | <AryehGregor> | Is there something wrong with http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment ? |
| 20:08 | <othermaciej> | AryehGregor: we intend to keep those features and it would be nice to have a spec |
| 20:10 | <AryehGregor> | othermaciej, I'd appreciate feedback from WebKit people about whether they think the approach I'm using so far for the spec is correct. |
| 20:11 | <AryehGregor> | I suspect that it's very different from the way WebKit currently implements it, but I'm not sure. |
| 20:11 | <AryehGregor> | (more particularly, I want to know if WebKit would be willing to implement that approach, not just if they think it's correct) |
| 20:12 | <AryehGregor> | Does anyone know of cases where the exact implementation of these features actually affects interop? Opera seems to get by with innerText behaving mostly like textContent. |
| 20:13 | <AryehGregor> | I guess this depends on IE's implementation: view-source:http://beihai.gov.cn/5863/2010_4_28/5863_98289_1272423962000.html?open=1 |
| 20:13 | <AryehGregor> | Grr: http://beihai.gov.cn/5863/2010_4_28/5863_98289_1272423962000.html?open=1 |
| 20:14 | <AryehGregor> | It has extra whitespace in WebKit and Opera, because apparently (?) IE gets rid of nbsp's or something. |
| 20:14 | <AryehGregor> | Anyway, I'd prefer to have at least two browsers say they're interested in implementing a spec something along the lines of what I'm writing before I continue, because otherwise it seems somewhat pointless. |
| 20:17 | <AryehGregor> | Hixie, did you tell me to spec createContextualFragment() because you know that http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment is wrong or because you didn't know it exists? |
| 20:17 | <AryehGregor> | (I could still write tests, of course) |
| 20:19 | AryehGregor | starts reading up on execCommand() |
| 20:26 | <Hixie> | AryehGregor: wasn't aware it was complete |
| 20:26 | <AryehGregor> | I don't know, is it? |
| 20:26 | <Hixie> | AryehGregor: dunno. we still need tests either way, so i guess use the tests to find out :-) |
| 20:26 | <AryehGregor> | Okay. |
| 20:27 | <Hixie> | the algorithm definitely needs _some_ work, since "the context object's start's node" doesn't make any sense |
| 20:27 | <Hixie> | but it might just be editorial work |
| 20:27 | <AryehGregor> | Why doesn't that make any sense? |
| 20:27 | <AryehGregor> | Follow the links, it's pretty straightforward. |
| 20:28 | <Hixie> | "start" isn't a noun that applies to objects, for one, and "start" xrefs to nothing, for two |
| 20:28 | <AryehGregor> | It xrefs to http://html5.org/specs/dom-range.html#concept-range-start |
| 20:28 | <AryehGregor> | It's a noun that applies to Ranges. |
| 20:28 | <Hixie> | hm, i wonder why that didn't work before |
| 20:28 | <annevk> | heycam, I thought you once tried figuring out for which DOMString attributes null become "null" vs "" vs actually null mapped across various browsers |
| 20:28 | <AryehGregor> | It's an inter-spec xref. |
| 20:28 | <Hixie> | oh, it's a link to another document and the doc was still loading |
| 20:28 | <Hixie> | ok |
| 20:29 | <annevk> | xspec xref |
| 20:29 | <Hixie> | ok i guess it's fine, never mind me :-) |
| 20:30 | <annevk> | heycam, I think Gecko is pretty consistently doing null -> "" and undefined -> "undefined" |
| 20:30 | <heycam> | annevk, I likely did some testing like that, but I can't seem to find anything written down with results... |
| 20:30 | <annevk> | heycam, I'd like Opera to match, but I was wondering if there is some known exception list somewhere |
| 20:30 | <annevk> | hmm, I guess we'd have to do the research then |
| 20:30 | <heycam> | annevk, sorry about that |
| 20:31 | <annevk> | no worries, now I need not go looking for it :) |
| 20:57 | <karlcow> | http://www.fontspring.com/blog/the-new-bulletproof-font-face-syntax |
| 20:58 | <Dashiva> | Are we really still at the level where we use CSS parser hacks? |
| 21:03 | <zcorpan> | karlcow: heh, nice |
| 21:05 | zcorpan | has known about how ie parses url() but hasn't thought about using # |
| 21:08 | <karlcow> | Dashiva: years after years, hacks on top of hacks |
| 21:10 | zcorpan | implements the state of the art hack in html5-elements |
| 21:12 | <benschwarz> | zcorpan: best bug logger ever |
| 21:12 | <zcorpan> | heh |
| 21:13 | <benschwarz> | you're making work for me :) |
| 21:14 | <zcorpan> | sorry, i file bugs without thinking these days |
| 21:15 | <zcorpan> | could consider it a work injury for working with quality assurance |
| 21:15 | <zcorpan> | maybe i should have a vacation |
| 21:15 | <Hixie> | <script>{</script> doesn't seem to be a compile-time error in safari |
| 21:15 | <Hixie> | weird |
| 21:16 | <benschwarz> | zcorpan: the feed back is nice. its such a huge document. I discover new things every day still |
| 21:16 | <benschwarz> | right now, the one that has me upset is that mobile safari is consistently crashing on anything other than the index page |
| 21:16 | <jgraham> | AryehGregor: If we were ever to find (presumably webkit-only) content that we wanted to support that relied on fanct innerText, having a spec would be useful |
| 21:17 | <jgraham> | Until that day I don't think it will be a priority |
| 21:17 | <jgraham> | Especially since IE seems to be aligning more with Opera |
| 21:17 | <jgraham> | *fancy |
| 21:17 | <Hixie> | oh nm, i'm wrong |
| 21:17 | <benschwarz> | Hixie: seen the new "up next" page links? |
| 21:17 | <AryehGregor> | jgraham, that makes sense if WebKit actually implements the spec. :) |
| 21:17 | <Hixie> | benschwarz: not yet, will look after lunch |
| 21:18 | <AryehGregor> | Although even the behavior I've specced so far is way closer to WebKit than Opera now is. |
| 21:18 | <benschwarz> | Hixie: needs more styling... but the feature is in |
| 21:18 | <AryehGregor> | Although you're right that IE9 is a lot more textContent-like for some reason. |
| 21:18 | <jgraham> | AryehGregor: It makes sense if the spec is close enough to WebKit to be worth implementing as is compared to reverse engineering it ourselves |
| 21:18 | <jgraham> | I hope none of this happens though |
| 21:21 | <jgraham> | (really if the main webkit use case is "for our test framework" it would be nice if the name was prefixed and the public method name aligned with IE9) |
| 21:25 | <AryehGregor> | IE9's implementation isn't very useful. IE8's makes more sense. |
| 21:25 | <AryehGregor> | As does WebKit's. |
| 21:26 | <zcorpan> | Hixie: in http://html5.org/r/5819 you traded one typo for another |
| 21:26 | <Hixie> | d'oh |
| 21:26 | <Hixie> | i suck |
| 21:26 | <jamesr_> | in 2 months that typo will be on bing |
| 21:27 | <Hixie> | jgraham: getting 500s intermittently from pms today |
| 21:29 | <jgraham> | AryehGregor: I value simplicity more than usefulness |
| 21:29 | <AryehGregor> | Me too. |
| 21:29 | <AryehGregor> | But the algorithm I've specced seems pretty simple to me. |
| 21:29 | <jgraham> | Because a useful implementation would have all manner of tweakable parameters |
| 21:30 | <AryehGregor> | Not necessarily. |
| 21:31 | <jgraham> | AryehGregor: Well the current algorithm doesn't deal with alt text, right? So there's one failure already |
| 21:31 | <AryehGregor> | Yes, I know, there are various details to be added. |
| 21:32 | <jgraham> | And you have no choice about how paragraphs are spaced, or whether to show display:none content, or anything else |
| 21:32 | <AryehGregor> | Anyway, everyone seems to have more sophisticated algorithms for the sake of Selection.toString() anyway, so why not use them? |
| 21:32 | <jgraham> | AryehGregor: AFAIK WebKit / IE don't include alt text either |
| 21:33 | <jgraham> | (maybe they do if images are off?) |
| 21:33 | <AryehGregor> | Possibly not. |
| 21:33 | <jgraham> | If it depends on user prefs it seems even more complex |
| 21:33 | <jgraham> | Of, I assume it does for <noscript> too |
| 21:33 | <jgraham> | s/f/Oh/ |
| 21:34 | <david_carlisle> | hsivonen: If I make a singe file mathml spec in the format that used to be known as html5, is it anti-social to validate it with validator.nu, or should I try to build a local copy of the validator? (it's 2.4M, more or less) |
| 21:35 | <AryehGregor> | jgraham, what about Selection.toString()? |
| 21:35 | <jgraham> | AryehGregor: I have no opinion of that |
| 21:35 | <AryehGregor> | jgraham, if that's defined, why not reuse the same algorithm for innerText? It makes things simpler than if you define a different one. |
| 21:35 | <jgraham> | Hixie: I can't see anything obvious in the log |
| 21:35 | <AryehGregor> | Unless your innerText algorithm is the same as your textContent one. |
| 21:36 | <jgraham> | AryehGregor: I would propose using the textContent one |
| 21:36 | <AryehGregor> | For Selection.toString()? |
| 21:36 | <AryehGregor> | Or innerText? |
| 21:36 | <jgraham> | For innerText |
| 21:36 | <AryehGregor> | I'm not totally against it if everyone is willing to alias innerText to textContent. The use-cases are fairly marginal given the complexity. |
| 21:36 | <jgraham> | I don't know what the compat. constrains on Selection.toString are |
| 21:36 | <AryehGregor> | If you can convince WebKit to do that, please let me know. :) |
| 21:37 | <jgraham> | You'll probably see the flying pigs |
| 21:37 | zcorpan | meanwhile installs a font on his system with the name "☺" |
| 21:38 | <jgraham> | zcorpan: Just to be evil? |
| 21:38 | <zcorpan> | oh, apparently it wouldn't work on mac anyway |
| 21:50 | zcorpan | resists 386ing http://www.w3.org/Bugs/Public/show_bug.cgi?id=11973#c6 |
| 21:54 | <Dashiva> | I'm not familiar with 386 as a verb |
| 22:01 | <zcorpan> | http://xkcd.com/386/ |
| 22:01 | <TabAtkins_> | Dashiva: xkcd.com/366 |
| 22:01 | <Dashiva> | Oh, that 386 |
| 22:02 | <Dashiva> | I thought you meant the microprocessor |
| 22:10 | zcorpan | ponders about window.onerror and cross-origin <script src> |
| 22:13 | <zcorpan> | i guess window.onerror is another way to exploit https://grepular.com/Abusing_HTTP_Status_Codes_to_Expose_Private_Information |
| 22:14 | <Hixie> | jgraham: i'm guessing it's the w3c being slow again |
| 22:14 | <Hixie> | jgraham: did you ever look into what it would take to change the timeouts? |
| 22:15 | <Hixie> | abarth: for https://bugs.webkit.org/show_bug.cgi?id=47264#c13 we need some way to experiment before the spec is updated -- otherwise we can't get impl experience to update the spec |
| 22:16 | <abarth> | my understanding is that we weren't going to add any more self-closing tags to HTML |
| 22:17 | <abarth> | because they aren't parsed correctly by legacy browsers |
| 22:17 | <abarth> | which means they can't be used by authors' |
| 22:17 | <Hixie> | see http://www.w3.org/Bugs/Public/show_bug.cgi?id=11935#c4 |
| 22:17 | <Hixie> | i don't think that applies in this case |
| 22:17 | <Hixie> | and that's what we need to find out |
| 22:19 | <abarth> | really? |
| 22:19 | <abarth> | that doesn't seem like a good idea |
| 22:19 | <abarth> | HTML doesn't have a good extension model for self-closing elements |
| 22:19 | <abarth> | that just means folks need to include close tags |
| 22:19 | <abarth> | that seems better than having screwed up parsing in different implementations |
| 22:20 | <Hixie> | i think the issue is minimal in most cases, and nearly non-existent here |
| 22:20 | <Hixie> | i really don't buy into the "no new void elements" thing |
| 22:20 | <Hixie> | in this case you're (i think) never going to use <device> without feature-testing it first anyway |
| 22:20 | <abarth> | why not? |
| 22:20 | <abarth> | suppose 80% of the market supports <device> |
| 22:21 | <abarth> | are we going to have to feature-test it forever? |
| 22:21 | <abarth> | isn't it reasonable to put a SWF in the fallback content? |
| 22:21 | <Hixie> | let me rephrase |
| 22:21 | <Hixie> | for <device> i don't think you're going to use it without feature testing if you have a fallback solution. |
| 22:22 | <Hixie> | no, it doesn't make sense to have a SWF as fallback content, because the fallback would have to have an entirely different script too |
| 22:22 | <Hixie> | and likely different network protocol, etc |
| 22:22 | <abarth> | so in the case where you don't feature test, you want the parsing for the rest of the page to be goofed up? |
| 22:23 | <Hixie> | it doesn't goof up the rest of the page, that's wild over-exaggeration |
| 22:23 | <abarth> | because it will be closed automatically at some point? |
| 22:23 | <Hixie> | all it does in legacy UAs is insert a <span>-like element, which does nothing, in the parent element |
| 22:24 | <Hixie> | which closes at the end of the parent |
| 22:24 | <Hixie> | no harm is done |
| 22:24 | <Hixie> | user doesn't even notice |
| 22:24 | <Hixie> | the worst it could do is interfere with CSS, but the page author who cares about fallback would test that anyway. |
| 22:25 | <Hixie> | (and it's unlikely to do so unless your css uses child combinators, which isn't that common in the first place) |
| 22:25 | <abarth> | i guess this all seems like a lot of pain to go through to avoid having to type "</device>" |
| 22:25 | <Hixie> | what pain? |
| 22:25 | <Hixie> | my whole point is there's no pain |
| 22:26 | <Hixie> | but that's what testing it would discover |
| 22:26 | <abarth> | the pain is that your page will parse different in different browsers, so you'll need to test whether your CSS selectors will work properly under both parsings |
| 22:26 | <abarth> | etc |
| 22:26 | <abarth> | what if we do this 10 times? |
| 22:26 | <abarth> | now your testing matrix is large |
| 22:26 | <Hixie> | no it's not |
| 22:26 | <abarth> | you'll essentially need to test every browser |
| 22:26 | <Hixie> | you only need to test the browsers that exist |
| 22:26 | <Hixie> | you do anyway |
| 22:27 | <Hixie> | to make sure your fallback works |
| 22:27 | <abarth> | it seems like the opposite of interoperability |
| 22:27 | <Hixie> | it really isn't anywhere near as difficult a problem as you make out |
| 22:27 | <abarth> | should we make <canvas> self-closing? |
| 22:27 | <Hixie> | the parsing difference is minimal at worst |
| 22:27 | <Hixie> | <canvas> was self-closing |
| 22:28 | <abarth> | was, but not any more? |
| 22:28 | <Hixie> | we had to make it not self-close because of accessibility |
| 22:28 | <jamesr_> | <canvas> is supposed to contain AX 'fallback'-ish content |
| 22:29 | <Hixie> | every time we add a new feature, interoperability will briefly suffer |
| 22:29 | <Hixie> | that's what progress looks like |
| 22:29 | <Hixie> | the difference between having an unknown element in the DOM or not vs having access to the user's camera or not is vast. the latter is a real interop problem. the former is barely noticeable. |
| 22:30 | <Hixie> | and this is the kind of thing web devs excel at dealing with |
| 22:30 | <abarth> | ok. it would be nice to be able to distinguish between folks making random changes to the parser and changes that we think are worth experimenting with |
| 22:30 | <Hixie> | how? |
| 22:30 | <Hixie> | they should certainly be behind a flag or something, imho |
| 22:31 | <abarth> | for example, if the spec was color-coded |
| 22:31 | <abarth> | blue means "if you're experimenting with device, try this out" |
| 22:31 | <Hixie> | it is |
| 22:31 | <Hixie> | that's what the labels in the left margin are |
| 22:31 | <Hixie> | i can add something about device being void if you like |
| 22:32 | <abarth> | as someone reviewing that patch, i went and looked at that part of the spec and didn't see anything about device there |
| 22:32 | <Hixie> | yeah, it's not there |
| 22:32 | <abarth> | which makes it hard for me to know that you think this is a reasonable idea |
| 22:32 | <Hixie> | i didn't expect anyone to implement it yet |
| 22:32 | <Hixie> | you can ask me :-) |
| 22:32 | <abarth> | you really want me to ask you about every random change people want to make to the parser ? :) |
| 22:32 | <Hixie> | yes |
| 22:33 | <abarth> | ok |
| 22:33 | <Hixie> | (or rather, i'm happy to answer if you do. i'm not saying i want you to.) |
| 22:36 | <abarth> | do you think we should condition the parser change on whether <device> support is enabled? |
| 22:37 | <Hixie> | yeah |
| 22:37 | <Hixie> | makes the feature testing make more sense |
| 22:37 | <Hixie> | and emphasises that the patch is experimental |
| 22:37 | <jamesr_> | how do you feature test <device>? |
| 22:37 | <Hixie> | if (window.HTMLDeviceElement) {...} |
| 22:38 | <abarth> | Hixie: we had a similar discussion about how to handle the MathML parts of the parser when MathML support is disabled |
| 22:38 | <Hixie> | (i'm really surprised that people are already implementing this device stuff btw.) |
| 22:38 | <Hixie> | abarth: i'd leave it parsing with the mathml namespace, for mathml |
| 22:38 | <abarth> | that's what we ended up doing |
| 22:38 | <Hixie> | abarth: because it's specced and not experimental |
| 22:38 | <Hixie> | cool |
| 22:39 | <abarth> | there seems to be a lot of interest around the device element |
| 22:39 | <jamesr_> | the implementation of <device> seems really dodgy imo |
| 22:39 | <abarth> | webkit isn't very good about making decisions about when to implement features and when not to implement features |
| 22:39 | <othermaciej> | especially the latter |
| 22:39 | <abarth> | jamesr_: there's also another group of folks who apparently implemented <device> too, so we have two patches instead of zero |
| 22:39 | <othermaciej> | the concept of <device> is confusing to me |
| 22:40 | <othermaciej> | if it's just meant for A/V input, then it should be one or several more specific elememts |
| 22:40 | <abarth> | jamesr_: or at least that's what they've said on webkit-dev. i don't think they've produced their patch yet |
| 22:40 | <othermaciej> | if it's meant to connect to anything that could be called a "device", then that's nonsensically overbroad |
| 22:40 | <Hixie> | othermaciej: it's meant as a way to grant JS access to system devices, the way <input type=file> grants JS access to files |
| 22:41 | <othermaciej> | and a single API is sufficient for anything that could be termed a "system device"? |
| 22:42 | <Hixie> | each type of device we add support for gets its own API |
| 22:42 | <jamesr_> | what on earth is a "system device" anyway? |
| 22:42 | <Hixie> | peripheral, if you prefer the term |
| 22:43 | <othermaciej> | many peripherals have a dedicated API |
| 22:43 | <jamesr_> | like a mouse or a keyboard? |
| 22:43 | <othermaciej> | it's not clear to me why the camera and microphone should be lumped in with "other" and assumed to have the same API as them |
| 22:44 | <Hixie> | each type of device we add support for gets its own API |
| 22:44 | <jamesr_> | why do some peripherals have a dedicated set of APIs and some come in as "device"s? |
| 22:44 | <othermaciej> | mouse, keyboard, screen, disk, accelerometer, GPS, compass |
| 22:44 | <Hixie> | jamesr_: they all have dedicated APIs |
| 22:44 | <othermaciej> | none of those are on <device> |
| 22:45 | <jamesr_> | Hixie: ok, then why are some on <device> and some not? |
| 22:45 | <othermaciej> | I think <camera> and <microphone> elements would make more sense |
| 22:45 | <othermaciej> | or <videoinput> and <audioinput> if you prefer, or just <avinput> |
| 22:45 | <Hixie> | the distinction between <device> and other mechanisms is that other mechanisms don't need the user to grant permission to the page to get a handle to them, because they're not sensitive, or they have their own more sensible permissions system |
| 22:45 | <othermaciej> | there is no obvious common property that anything else has with these things |
| 22:46 | <Hixie> | the cammon property is that there isn't a necessarily just one of them, and we can't grant permission to them automatically |
| 22:46 | <othermaciej> | are there things besides the camera and the microphone that anyone wants to implement with the same permissions model as the camera and microphone? |
| 22:47 | <Hixie> | "wants to implement", no idea. "would make sense to implement", sure: RS232 devices, for instance. |
| 22:48 | <Hixie> | USB cash registers |
| 22:48 | <Hixie> | lots of stuff like that |
| 22:48 | <Hixie> | just mentioning <device> in the spec has gotten dozens of people to contact me directly or file bugs or mail the lists asking for their pet device to be supported. |
| 22:50 | <jamesr_> | it doesn't seem clear at all to me that <device> is a very good way to add support for such things |
| 22:52 | <Hixie> | why not? |
| 22:52 | <Hixie> | all you need is some sort of UI that lists the devices of the type the page wants, and then hands back an object implementing the relevant API |
| 22:53 | <Hixie> | it doesn't seem sane to have <usbcashregister>, <rs232>, <mic>, <camera>, <3dcamera>, <depthcamera>, etc |
| 22:53 | <Hixie> | just have <device> |
| 22:53 | <Hixie> | they're all gonna basically be the same anyway, except for what they vend |
| 22:54 | <othermaciej> | generic UI is almost always bad UI |
| 22:54 | <othermaciej> | generic API, it depends |
| 22:55 | <nimbupani> | MikeSmith: !!! |
| 22:55 | <MikeSmith> | allo |
| 22:55 | <othermaciej> | it's not clear to me that RS232 shares any properties with a camera or microphone from the user perspective |
| 22:56 | <othermaciej> | all the things you mention other than camera and microphone are at present highly specialized equipment that the majority of people don't have, and probably will not |
| 22:57 | <othermaciej> | it is also not clear that an in-page element is the best way to grant access to them |
| 22:57 | <othermaciej> | (I'm not even sure it's the best way to handle it for a camera or microphone) |
| 22:58 | <othermaciej> | anyway, this is tangential to the parsing issues |
| 22:58 | <othermaciej> | but it seems like a poorly designed feature to me |
| 23:11 | <Hixie> | othermaciej: there's no generic API here |
| 23:11 | <Hixie> | othermaciej: I don't see what would be different for picking a cash register vs picking a camera |
| 23:12 | <Hixie> | othermaciej: anyway, if it turns out we never use it for anything else, <device> is still fine for cameras and mics; whereas <camera> couldn't sanely be used for cash registers even if we find it would otherwise make sense |
| 23:12 | <Hixie> | so... |
| 23:20 | Philip` | wonders why not just use <object> for devices, since that already provides resource-specific APIs |
| 23:23 | <bga_> | ++ |
| 23:23 | <Hixie> | how would that work? |
| 23:23 | <Hixie> | (<object> has been overloaded to do so many different things that I'm reluctant to add anything else to it, frankly) |
| 23:23 | <Hixie> | (but i'm open to ideas if it makes sense) |
| 23:27 | <Philip`> | It sounded like the idea of <device> is to be a generic container that gets overloaded to do whatever arbitrary things people want, so it'll end up being another <object> with a different name |
| 23:28 | <AryehGregor> | Yeah, that thought just occurred to me too. |
| 23:45 | <Hixie> | Philip`: not at all, <device> just does one thing, vend APIs for devices |
| 23:48 | <zcorpan> | devices are many things |
| 23:55 | <Hixie> | zcorpan: that's like saying <input type=file> is overloaded because there are many files |
| 23:59 | <zcorpan> | it seems like we have a single API for all types of files, however i don't know if it makes sense to have a single API for types of devices |