| 01:40 | <AryehGregor> | http://lists.wikimedia.org/pipermail/wikitech-l/2010-April/047617.html |
| 01:40 | AryehGregor | waits for someone here to inform him of the various factual errors he made about XML in that post |
| 03:32 | <annevk> | everyone else was on a weekend break too? |
| 03:32 | <annevk> | no fun logs to read :/ |
| 03:33 | <nessy> | hehe! we have a long w/e here! |
| 03:33 | <othermaciej> | annevk: you could make your own fun logs! |
| 03:33 | <othermaciej> | just pick someone to flame |
| 03:33 | <doublec> | nessy: really? You have an extra day for anzac day? |
| 03:34 | <roc> | they do |
| 03:34 | <doublec> | nice, the kiwi's get ripped off in that regard |
| 03:34 | <roc> | actually, NZ does too, I just lied to get you guys into the office |
| 03:35 | <doublec> | haha |
| 03:35 | <nessy> | doublec: yes, anzac day holiday! means I get to catch up on work! :) |
| 03:36 | <doublec> | nessy: in NZ we don't get an extra day if anzac day falls on a weekend |
| 03:36 | <nessy> | so, no difference to you either |
| 03:36 | <nessy> | it's a nice feature of Australian holidays |
| 03:36 | <nessy> | if they fall on weekends you get them back during the next week |
| 03:36 | <nessy> | unknown in Germany, too |
| 03:36 | <roc> | it's true for the Christmas holidays here |
| 03:37 | <roc> | I don't know why Anzac Day is different |
| 03:38 | <doublec> | apparently they don't 'mondayize' holidays that have actual national historical significance |
| 03:38 | <doublec> | so waitangi day is also left out |
| 03:42 | <nessy> | that's inconsistent |
| 03:43 | <nessy> | I have a question about Firefox and video - does Firefox store the byte ranges in an actual file on disk, so when all byte ranges have been downloaded the full original files is available? or do you just keep the byte ranges in memory and throw them out? |
| 03:44 | <doublec> | we keep the ranges on disk in a 'media cache' but throw them out when you leave the page |
| 03:45 | <doublec> | we also cache the video in the standard browser cache if it meets caching requirements - but due to the nature of video (seeking, large files, etc) it often doesn't meet those requirements |
| 03:46 | <doublec> | the media cache is shared across all videos being played too - and defaults to 50MB iirc. As more video gets played old entries in the cache get evicted |
| 03:47 | <nessy> | so in the 'media cache' you won't typically end up with the full original file |
| 03:47 | <nessy> | just its byte ranges as temp storage? |
| 03:47 | <doublec> | nessy: http://weblogs.mozillazine.org/roc/archives/2009/04/media_cache.html |
| 03:47 | <doublec> | nessy: correct |
| 03:47 | <nessy> | I'm asking, since it's then not strictly progressive download as described here http://weblogs.mozillazine.org/roc/archives/2009/04/media_cache.html |
| 03:48 | <roc> | why does it matter? |
| 03:48 | <nessy> | it's more like actual streaming and more secure - except for the "Download src" right context menu functionality :) |
| 03:49 | <nessy> | thanks for the link! |
| 03:49 | <nessy> | ppl are concerned about the possibility to "steal" the original file in a simple way |
| 03:49 | <doublec> | that's pretty easy with html 5 video... |
| 03:50 | <nessy> | I have a potential customer who wants to use rtp/rtsp instead of http server for html5 video because it's less prone to stealing |
| 03:50 | <doublec> | in the same was as 'stealing' an image is |
| 03:50 | <nessy> | yes, exactly |
| 03:50 | <doublec> | I'm pretty sure rtp/rtsp will only work in one browser |
| 03:50 | <doublec> | if at all |
| 03:50 | <doublec> | (I'm thinking Safari) |
| 03:50 | <nessy> | yes, I think so too |
| 03:50 | <nessy> | are you planning to support it? |
| 03:51 | <doublec> | There's a bug for it. No known plans to do anything in the immediate future. |
| 03:51 | <nessy> | fair enough |
| 03:52 | <nessy> | I don't think Opera or Chrome support it either or plan to |
| 03:52 | <doublec> | https://bugzilla.mozilla.org/show_bug.cgi?id=506834 |
| 03:52 | <nessy> | and I'm not sure Safari supports it properly other than their HTTP adaptive streaming |
| 03:54 | <annevk> | I wish these DRM-requesting types would realize they're wrong :/ |
| 03:54 | <nessy> | https://bugs.webkit.org/show_bug.cgi?id=26416 |
| 03:55 | <nessy> | annevk: this guy is offering paid content and ppl go steal his stuff and resell it - I don't think there is anything wrong with wanting some control over this situation |
| 03:56 | <doublec> | the people who want to steal it and resell it have the resources to rip it using any tool they want |
| 03:56 | <doublec> | no matter what you do |
| 03:57 | <doublec> | it's hard to the people offering the content of that though |
| 03:57 | <doublec> | there's a 'convince' in between 'to' and 'the' there :) |
| 03:58 | <nessy> | he said he cut the problems by 85% when moving from http to rtsp |
| 03:58 | <nessy> | that's substantial when you're running a biz |
| 04:00 | <roc> | that sounds odd |
| 04:00 | <doublec> | how did he measure that? |
| 04:00 | <roc> | perhaps there's no off-the-shelf RTSP ripper yet and all his enemies are too stupid to write one |
| 04:00 | <nessy> | it's safety by more obscurity, is all I think |
| 04:00 | <doublec> | there's a few RTSP rippers around for Windows at least. And gstreamer, etc can be used on Linux. |
| 04:01 | <doublec> | what % of viewers did he lose going to rtsp? |
| 04:01 | <nessy> | he frequently trolls all the public video sites for his content, cause that's where it turns up, too |
| 04:01 | <roc> | doing a ton of work and integrating heaps more code into the browser just to raise the obscurity bar a minute amount doesn't sound like a win to me |
| 04:01 | <nessy> | non cause he did it all in Flash |
| 04:01 | <nessy> | might have been Flash steaming rather than rtsp, actually |
| 04:02 | <doublec> | interesting |
| 04:02 | <doublec> | when poker training sites first started out they all used rtsp or flash streaming solutions with DRM for training videos |
| 04:03 | <doublec> | the newer sites however moved to DRM free |
| 04:03 | <roc> | 05e790926d9ee13e08916f878432adbb |
| 04:03 | <doublec> | and got more customers as a result |
| 04:03 | <doublec> | because people could play them anywhere |
| 04:03 | <doublec> | and the videos weren't pirated any more than the DRM video sites videos |
| 04:04 | doublec | starts a cracking roc's hash |
| 04:04 | <nessy> | yeah - I am not convinced either |
| 04:04 | <nessy> | I didn't want to encourage rtsp implementation - was just curious about status |
| 04:05 | <nessy> | he wants to move away from flash and to html5 video cause he hates all the flash stuff - so we'll have to wait and see if that will create pirating again |
| 04:06 | <nessy> | I just needed to know more details :) |
| 04:06 | <nessy> | thanks! |
| 04:49 | <annevk> | roc, again? :) |
| 04:49 | <annevk> | I believe at least one is still without public answer, right? |
| 04:54 | <roc> | they all are |
| 05:28 | <jlebar> | roc, how long are the messages, on average? |
| 05:28 | <roc> | it varies :-) |
| 05:28 | <roc> | this one was just a one-liner |
| 05:33 | <jlebar> | Sounds like it may need some salt. :) |
| 05:33 | <jlebar> | (Interesting idea for a cryptographic protocol: You give me a hash, and at the same time, proof that the message is a meaningful English sentence, without revealing the sentence.) |
| 05:33 | <slango> | am I crazy, or is this page poison to Firefox: http://www.whatwg.org/specs/web-apps/current-work/? |
| 05:34 | <jlebar> | slango, It's better in trunk. |
| 05:45 | <slango> | thanks |
| 06:12 | <magcius> | Is this a bug? The scrollbar appears in http://magcius.mecheye.net/canvasbug.html |
| 06:13 | <magcius> | I looked into it, and a linebreak textnode is somehow being added. |
| 06:13 | <magcius> | Causing the html tag's scrollHeight to be 4px larger. |
| 06:13 | <magcius> | It happens in all major browsers |
| 07:55 | annevk | wonders if he should write a reply to http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Apr/0037.html |
| 07:55 | <annevk> | it seems sort of set in stone already that CORS will be abused for fonts |
| 07:55 | <annevk> | I guess I'll write my thoughts anyway, so they can at least be considered |
| 07:56 | <roc> | I'd like to read that |
| 08:10 | <annevk> | hmm, I hope my email gets through |
| 08:39 | <annevk> | worked out: http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Apr/0040.html |
| 08:53 | <hsivonen> | hmm. what do I need to do to make <svg> not clip its contents to the box established by <svg>? |
| 08:53 | <othermaciej> | mess with the viewbox attributes |
| 08:54 | <othermaciej> | (I think) |
| 08:54 | <hsivonen> | no, viewBox sets up the coordinate space |
| 08:54 | <zcorpan> | possibly preserveAspectRatio can change it, but i think at least in opera it'll always be clipped |
| 08:54 | <hsivonen> | but how do I make shapes outside the viewBox box get painted outside the box |
| 08:55 | <hsivonen> | zcorpan: oh so the IE9 demo that gets clipped in "other browsers" isn't about "defaults" but about other browsers always clipping? |
| 08:56 | <zcorpan> | dunno |
| 08:56 | <othermaciej> | I don't know what the IE9 demo is specifically |
| 08:56 | <othermaciej> | SVG in theory requires (effectively) that SVG root elements have overflow: hidden !important in the UA stylesheet |
| 08:57 | <othermaciej> | I think at least some browsers let you override that to overflow: scroll |
| 08:57 | <hsivonen> | http://ie.microsoft.com/testdrive/Graphics/21FallingBalls/Default.xhtml |
| 08:57 | <othermaciej> | on the theory that the SVG spec didn't know what it was talking about |
| 08:57 | <othermaciej> | hsivonen: something different happens in IE? |
| 08:57 | <hsivonen> | othermaciej: that's sad. overflow: hidden !important sabotages one of the coolest things one could do with inline SVG |
| 08:58 | <othermaciej> | hsivonen: we have that in our UA stylesheet but I am tempted to get rid of it |
| 08:58 | <hsivonen> | othermaciej: in IE9, the balls that fall out of the box don't get clipped out |
| 08:58 | <zcorpan> | image-fit:cover (or content-fit or what it's called now) should be able to make svg paint outside its box |
| 08:59 | <othermaciej> | oh I guess we don't have that any more |
| 08:59 | <othermaciej> | just overflow: hidden |
| 08:59 | <othermaciej> | the demo could choose to set overflow: visible on the <svg> |
| 08:59 | <hsivonen> | is !important supposed to work in the style attribute? |
| 08:59 | <hsivonen> | overflow: visible !important; doesn't work for me in <svg style= |
| 08:59 | <hsivonen> | in Gecko |
| 09:00 | <zcorpan> | hsivonen: !important is supposed to work in style="" but it would only affect later declarations in the same style="" |
| 09:00 | <othermaciej> | we don't actually have a !important rule in WebKit trunk |
| 09:00 | <hsivonen> | looks like I won't be making the demo I wanted to make |
| 09:01 | <zcorpan> | hsivonen: since style="" is author level and highest specificity, it will override anything that doesn't have !important anyway, and if something earlier has !important then nothing will override it |
| 09:01 | <hsivonen> | zcorpan: is image-fit implemented in any browser? |
| 09:01 | <zcorpan> | hsivonen: it's implemented in opera but not shipped yet |
| 09:01 | <othermaciej> | see the comment here for a long-winded explanation of the clipping issue: http://trac.webkit.org/browser/trunk/WebCore/css/svg.css |
| 09:01 | <hsivonen> | plain overflow: visible; doesn't work in Gecko, either. |
| 09:02 | <zcorpan> | hsivonen: i hope gecko and webkit will implement it as well since it's really cool |
| 09:03 | <othermaciej> | WebKit still clips if I force overflow: visible |
| 09:03 | <othermaciej> | not sure why |
| 09:03 | <hsivonen> | when I moved from Mac to Linux, I lost the assistive tech for writing namespace URIs :-( |
| 09:04 | <hsivonen> | and now I need to write those in order to test SVG in WebKit :-( |
| 09:04 | <zcorpan> | hsivonen: just memorize them |
| 09:05 | <othermaciej> | svg root element seems to clip to its bounds regardless |
| 09:05 | <othermaciej> | I could probably figure out why with some code study but I don't have time at the moment |
| 09:06 | <zcorpan> | it's really easy, the leading part is invariant, the year is 1999 for xhtml and xlink, 2000 for svg, and the trailing part is xhtml, svg or xlink (no trailing slash for any of them) |
| 09:06 | <zcorpan> | the mathml and xml namespaces are harder |
| 09:06 | <othermaciej> | I think our rule in svg.css is probably based on an incorrect interpretation of "outermost" |
| 09:07 | <othermaciej> | it should really be a rule for svg svg rather than for svg:not(:root) I think |
| 09:07 | <othermaciej> | not that this would fix the IE demo but it would make the stylesheet match the comment |
| 09:08 | <othermaciej> | hsivonen: what was it that assisted you with the namespace URI before? |
| 09:08 | <hsivonen> | othermaciej: Typinator |
| 09:10 | <othermaciej> | that seems like just the sort of product I would expect to exist in some form on Linux |
| 09:10 | <othermaciej> | though perhaps in a form with thousands of configuration options, most completely useless |
| 09:33 | <hsivonen> | reading the SVG 1.1 spec for the <animate> element is rather annoying |
| 09:38 | <hsivonen> | I need to find a way to demo MathML that is cool but not verbose as source |
| 09:39 | <annevk> | guess you can't use e=mc^2 as you don't need MathML for that? |
| 09:42 | <webben> | how about the uncertainty principle: http://en.wikipedia.org/wiki/Uncertainty_principle |
| 09:42 | <hsivonen> | annevk: right. I want something with at least an integral, fraction or a big square root in it |
| 09:42 | <hsivonen> | preferrably something that people recognize |
| 09:43 | <hsivonen> | maybe the solution for the 2nd degree equation |
| 09:43 | <jgraham> | I was going to suggest that |
| 09:44 | <jgraham> | Not many integral equations that are well known among the general population |
| 09:44 | <hsivonen> | I wanted to use Gaussian blur and put also SVG Gaussian blur in the demo, but Gaussian blur as MathML is awfully verbose |
| 09:45 | <jgraham> | Everything is awfully verbose as MathML |
| 09:47 | <roc> | the fact that overflow:visible doesn't work on inline <svg> is just our bug |
| 09:47 | <zcorpan> | hsivonen: http://www.gstatic.com/knol/static/images/cartoons/42111-29252.jpg |
| 09:52 | <hsivonen> | roc: OK. |
| 09:52 | <Dashiva> | Good one, zcorpan |
| 09:53 | <roc> | annevk: so if we were to create a new feature to give authors control over who can load their (font) resources, how would it be different from CORS in practice? |
| 09:54 | <othermaciej> | roc: apparently a popular bug |
| 10:10 | gsnedders | wonders if it's at all disturbing taht the first diary entry that Hixie appears in in my diary in years is written while he was intoxinated |
| 10:10 | <gsnedders> | (I'm sorry, but any Avenue Q reference makes me think of Hixie now…) |
| 10:11 | <Dashiva> | Who replies four times to the same tweet... |
| 10:13 | <othermaciej> | why does Avenue Q make you think of Hixie? |
| 10:13 | <hsivonen> | Dashiva: someone with more than 140 characters to say? |
| 10:13 | <asmodai> | hsivonen: https://bugzilla.mozilla.org/show_bug.cgi?id=561714 |
| 10:13 | <asmodai> | hsivonen: created the bug report for that leak |
| 10:13 | <annevk> | roc, it would work for <img>, <video>, etc. too |
| 10:14 | <annevk> | roc, instead of a font-specific hack of CORS |
| 10:14 | <asmodai> | Heh, Avenue Q, now I have to think of the Internet is for pr0n. |
| 10:14 | <annevk> | roc, which imo is silly |
| 10:14 | <hsivonen> | asmodai: thanks |
| 10:14 | <asmodai> | hsivonen: ideas for tracking it down more than welcome :) |
| 10:15 | <jgraham> | othermaciej: You have met Hixie, right? |
| 10:15 | <othermaciej> | jgraham: yes...? |
| 10:15 | <gsnedders> | othermaciej: Because he never shuts up about it? |
| 10:15 | <othermaciej> | I have also seen Avenue Q |
| 10:15 | <othermaciej> | he has never mentioned it to me |
| 10:16 | <gsnedders> | Are you not in #webapps |
| 10:16 | <jgraham> | This othermaciej is clearly an imposter |
| 10:16 | <gsnedders> | *? |
| 10:16 | <othermaciej> | apparently not |
| 10:16 | <othermaciej> | this server or w3c? |
| 10:16 | <gsnedders> | w3c |
| 10:16 | <jgraham> | We need to find the realothermaciej |
| 10:16 | <gsnedders> | That's where he makes the majority of references I've seen online |
| 10:16 | <othermaciej> | haven't been, just added to my autojoin |
| 10:17 | <othermaciej> | I can't recall him mentioning it on this channel or any time I have met him IRL |
| 10:17 | <gsnedders> | I've certainly seen it on this channel, on #webapps, and IRL |
| 10:19 | <jgraham> | and on his blog |
| 10:21 | <annevk> | http://www.google.com/search?q=avenue+q+site:krijnhoetmer.nl |
| 10:21 | <annevk> | proof |
| 10:21 | <gsnedders> | But yes, that's what Hixie gets for people singing The Internet is for Porn while I'm just-about-managing to go home |
| 10:22 | <hsivonen> | annevk: looks like there are more instances of gsnedders mentioning Avenue Q than Hixie mentioning it |
| 10:23 | <gsnedders> | fail. |
| 10:23 | <jgraham> | OTOH Hixie has seen Avenue Q >= 3 times whereas gsnedders has seen it once |
| 10:23 | <annevk> | therefore Hixie ranks higher than gsnedders |
| 10:30 | <zcorpan> | if Hixie and gsnedders were in the same Document, we could run the outline algorithm on them |
| 10:32 | <roc> | annevk: my point of view is that CORS lifts same-origin restrictions. I don't see how when those restrictions are imposed "for privacy" CORS is suitable but when those restrictions are imposed for other reasons, lifting them with CORS is an abuse of CORS |
| 10:32 | <annevk> | because CORS cannot be used in a generic way for those other purposes |
| 10:33 | <othermaciej> | why can't it? |
| 10:33 | <annevk> | and CORS is intended to be a protocol that works q |
| 10:33 | <annevk> | equally for all resources |
| 10:33 | <annevk> | othermaciej, because most scenarios already allow cross-origin loads |
| 10:33 | <roc> | that's because we currently have no way to impose same-origin restrictions for <img> loads etc |
| 10:33 | <othermaciej> | couldn't CORS be used in principle to allow cross-origin images or videos to draw into a canvas without tainting? |
| 10:34 | <othermaciej> | annevk: yeah, but CORS isn't what allows you to do the load, it's what allows you to read the data |
| 10:34 | <roc> | if we did have a way to impose such restrictions, we could use CORS to lift it |
| 10:34 | <annevk> | othermaciej, that's not another purpose, that's CORS' purpose |
| 10:34 | <annevk> | othermaciej, preventing bandwidth theft through CORS just for fonts is what is being proposed here |
| 10:34 | <othermaciej> | I don't say it was another purpose |
| 10:34 | <roc> | the problem <img> is that no restrictions exist for CORS to apply to |
| 10:34 | <annevk> | othermaciej, but that cannot be used for <video> or <img> in that way |
| 10:35 | <annevk> | othermaciej, so it is completely tied to font loading |
| 10:35 | <annevk> | and just makes CORS some kind of weird case there |
| 10:35 | <annevk> | which imo is wrong |
| 10:35 | <roc> | it's not a weird case |
| 10:35 | <roc> | CORS can be used to lift same-origin restrictions where they exist |
| 10:35 | <othermaciej> | if you wanted to limit <video> or <img> to same-origin-only for bandwidth protection purposes, you'd have to check Origin or Referer on the server side |
| 10:35 | <roc> | they just happen to not exist at all for <video> and <img> |
| 10:35 | <othermaciej> | I don't think the intent of applying same-origin policy to fonts is for bandwidth limits |
| 10:35 | <hsivonen> | annevk: is this about a matter of principle, a technical problem or fear of a lawyer thinking that CORS is Effective? |
| 10:35 | <othermaciej> | I think the intent is for half-assed pseudo-DRM |
| 10:36 | <othermaciej> | at least I imagine that is why the font vendors want it |
| 10:36 | <annevk> | hsivonen, technical consistency? |
| 10:36 | <annevk> | hsivonen, haven't really tried to think about lawyers and DRM that much |
| 10:36 | <othermaciej> | if font had a same-origin restriction then it would be reasonable for CORS to lift it |
| 10:37 | <hsivonen> | annevk: seems technically consistent to use CORS to lift the Same Origin restriction whenever it is lifted for any reason |
| 10:37 | <othermaciej> | I think the controversial part is whether fonts should have a same-origin restriction by default |
| 10:37 | <annevk> | othermaciej, there's no reason for fonts to have same-origin restrictions |
| 10:37 | <othermaciej> | I don't think anyone in WebKit-land has any interest in adding that restriction |
| 10:37 | <roc> | right, that is the issue |
| 10:38 | <roc> | CORS is a red herring |
| 10:38 | <othermaciej> | but if the Trident and Gecko developers want to add such a restriction, then it seems reasonable to use CORS to selectively lift that restriction |
| 10:38 | <roc> | thank you! |
| 10:38 | <annevk> | hsivonen, we shouldn't have same-origin restrictions however for whatever reason |
| 10:39 | <annevk> | hsivonen, if the problem is bandwidth theft then that problem also exists for <video> |
| 10:39 | <annevk> | hsivonen, so the solution cannot be CORS imo |
| 10:39 | <othermaciej> | I would be unhappy if whatever spec people are talking about required same-origin restrictions by default for fonts though |
| 10:39 | <roc> | CORS is not the solution to bandwidth theft |
| 10:39 | <annevk> | indeed it's not |
| 10:39 | <roc> | the solution for bandwidth theft and certain other problems is a same-origin restriction |
| 10:40 | <othermaciej> | WebKit-based browsers would probably never be conforming if that was the case |
| 10:40 | <roc> | CORS lets authors opt out of that |
| 10:40 | <annevk> | roc, that solution fails for a lot of scenarios so it's not a good solution |
| 10:41 | <roc> | we can argue about that, but the fact remains that if we're going to have a same-origin restriction, it seems reasonable to use CORS to lift that restriction |
| 10:41 | <jgraham> | Why isn't video same-origin only? |
| 10:42 | <roc> | there was a big discussion about that |
| 10:42 | <annevk> | because it doesn't make sense |
| 10:42 | <othermaciej> | it would suck to not be able to embed video cross-site |
| 10:42 | <roc> | that |
| 10:42 | <annevk> | at least not with how <script>, <img>, etc. work |
| 10:42 | <jgraham> | Yeah I remember a discussion |
| 10:42 | <roc> | plus legacy reasons |
| 10:42 | <othermaciej> | given that a key feature of the most popular video sites is embedding cross-site |
| 10:42 | <othermaciej> | also, plugins can do it and <video> shouldn't be less capable than plugins |
| 10:42 | <annevk> | anyway i need to get some food/sleep and make some more slides |
| 10:42 | <othermaciej> | (e.g. QuickTime) |
| 10:42 | <jgraham> | Yes, but if CORS is a solution for fonts it is a solution for video |
| 10:43 | <jgraham> | but moreso given the realtive bandwidth requirments |
| 10:43 | <jgraham> | *relative |
| 10:43 | <othermaciej> | the proposed solution for fonts isn't so much CORS as it is imposing a same-origin restriction by default |
| 10:43 | <othermaciej> | CORS just mitigates some of the downsides of that basic decision |
| 10:43 | <roc> | right |
| 10:44 | <othermaciej> | imposing a same-origin restriction by default wasn't really a viable option for video |
| 10:44 | <othermaciej> | it seems less obviously broken for fonts, though I am not super enthusiastic about it myself |
| 10:45 | <jgraham> | So the argument goes that fonts are fundamentally different from video because video is often cross origin whereas fonts are typically same origin? |
| 10:45 | <roc> | I think it's reasonable to provide a convenient mechanism allowing authors to control who accesses their resources |
| 10:45 | <othermaciej> | I think it's reasonable too |
| 10:46 | <othermaciej> | the questions are: (a) should the default be no cross-origin access instead of full access as for most other resource types? |
| 10:46 | <annevk> | they can just check the Origin header |
| 10:46 | <othermaciej> | and: (b) should this mechanism be enforced client-side instead of server-side? |
| 10:46 | <annevk> | or we could have a header that enforces same-origin loads |
| 10:46 | <roc> | checking the Origin header is not convenient |
| 10:46 | <othermaciej> | if you answer "no" to both, then nothing in particular needs to be added |
| 10:46 | <annevk> | that would also work for all other types of resources |
| 10:47 | <jgraham> | Would people have argued differently for video if CORS was already widely deployed? |
| 10:47 | <roc> | checking on the client has better privacy properties |
| 10:47 | <othermaciej> | using CORS to undo the restriction is about as convenient/inconvenient as checking Origin to add a restriction |
| 10:47 | <roc> | jgraham: it would have helped a bit, but probably we'd have the same outcome |
| 10:47 | <roc> | othermaciej: most authors don't need to undo the restriction |
| 10:48 | <othermaciej> | which goes back to question (a) |
| 10:48 | <annevk> | we could just have a header that enforces same origin loads |
| 10:48 | <jgraham> | roc: In that case the argument for fonts seems very weak |
| 10:48 | <annevk> | that could even be part of the CSRF work from Mozilla |
| 10:48 | <annevk> | a header which people likely need to use anyway |
| 10:48 | <jgraham> | s/fonts/making fonts same-origin by default/ |
| 10:49 | <roc> | annevk: a header on the document referencing the font? |
| 10:49 | <annevk> | no on the font of course |
| 10:49 | <roc> | ok |
| 10:49 | <roc> | that's a question of what the default should be |
| 10:49 | <annevk> | it's also a question of whether we want to solve the bandwidth problem two times or just once... |
| 10:49 | <roc> | based on what the font vendors say, it sounds like they're going to require authors to control access |
| 10:50 | <annevk> | and whether a different request policy for fonts really makes sense -- i think it doesn't |
| 10:50 | <roc> | most of them |
| 10:50 | <roc> | so authors will frequently want to same-origin restriction |
| 10:50 | <annevk> | i personally think this whole WOFF thing is somewhat of a mistake |
| 10:51 | <annevk> | before it's done Ubuntu and other systems will support it natively, I'm sure |
| 10:51 | <annevk> | or simple web-based tools will be available |
| 10:51 | <roc> | sure |
| 10:51 | <roc> | that's all fine |
| 10:51 | <othermaciej> | I think the vendor's legal requirement for a same-origin restriction should be handled between the vendor and their customer |
| 10:51 | <roc> | othermaciej: it is |
| 10:51 | <othermaciej> | no need to bring the browser into it |
| 10:51 | <annevk> | anyway, gotta go, will read the logs later |
| 10:52 | <roc> | the question is how easy is it going to be for the customer to follow their side of the license? |
| 10:52 | <roc> | we can give them tools to make it super easy |
| 10:53 | <othermaciej> | or we can create a business opportunity for Adobe Straming Font Server :-) |
| 10:53 | <roc> | or we can force them to do server-side checking, with a number of downsides for convenience, privacy and robustness (firewalls stripping headers) |
| 10:54 | <zcorpan> | so should we add a header Restrict-Load-To: http://example.org |
| 10:54 | <zcorpan> | which would work for everything (fonts, images, videos, html) |
| 10:54 | <othermaciej> | server-side checking would be better if the motive was actually preventing bandwidth waste |
| 10:55 | <jgraham> | Embedding laws and licensing agreements in code is a bit scary. Apart from anything else laws and licenses change but required behaviour on the web tends to live on |
| 10:55 | <othermaciej> | since by the time the client checks, your bandwidth has already been wasted |
| 10:55 | <roc> | "embedding laws and licensing agreements in code" is totally not happening here ... that's the DRM bogeyman |
| 10:56 | <roc> | othermaciej: the point is that site authors aren't going to link to a font cross-site if that load isn't actually going to work |
| 10:56 | <roc> | unless they just want to maliciously eat your bandwidth to no useful purpose |
| 10:56 | <othermaciej> | roc: really, authors aren't going to do strange things with no visible effect and then leave that in their production site? |
| 10:56 | <jgraham> | Well you are justifying inconsistencies in the platform because they help people to conform to licensing agreements circa 2010 |
| 10:56 | <jgraham> | +typical |
| 10:57 | <othermaciej> | that would make my job a lot easier if it was true! |
| 10:58 | <roc> | othermaciej: ok, there'll be a little of that |
| 10:58 | <othermaciej> | you are correct that it would reduce the motive for bandwidth waste somewhat, though not the opportunity |
| 10:58 | <roc> | jgraham: we have same-origin restrictions for XHRs. I don't see having them for fonts as a wild innovation |
| 10:59 | <jgraham> | roc: For XHR is is needed for security |
| 10:59 | <roc> | sure, so? |
| 10:59 | <jgraham> | So that is a clear reason for the difference |
| 10:59 | <roc> | it's still true that we have different classes of loads |
| 11:00 | <jgraham> | The font thing seems to be predicated on the idea that fonts are somehow fundamentally different from an IP point of view compared to images or video |
| 11:00 | <jgraham> | or text |
| 11:00 | <roc> | there are a different set of tradeoffs |
| 11:00 | <hsivonen> | Restrict-Load-To would have bad effects if Opera supported it before IE |
| 11:00 | <roc> | images are totally constrained by legacy issues |
| 11:01 | <roc> | video is constrained by legacy issues and the "viral video" feature |
| 11:01 | <jgraham> | Right, if we were designing the platform from scratch we would do it differently |
| 11:02 | <hsivonen> | but server refusing to serve if the request didn't have the right Origin header would have better game theoretica characteristics to motivate UA implementation |
| 11:02 | <roc> | if those issues didn't exist, would it be a good idea to have a default-same origin restriction for images and video? I think so, although that world's so counter-factual I'd have to think harder than I have |
| 11:02 | <othermaciej> | it does seem to me like many font deployments won't really want to share cross-origin, on the other hand, I could imagine big sites wanting to serve their fonts off of Akamai |
| 11:03 | <othermaciej> | or I could imagine the existence of central type hosting sites like TypeKit |
| 11:03 | <othermaciej> | or of sites that have a separate domain for large static resources in general, or which have multiple subdomains |
| 11:03 | <roc> | I can tell you that in practice when we raised the idea of same-origin restrictions for <video> there were howls of protest from authors and, well, just about everyone |
| 11:03 | <hsivonen> | typekit's core feature is addressing complications |
| 11:03 | <roc> | whereas for fonts, we have had no protest whatsoever |
| 11:04 | <jgraham> | roc: Because people aren't expecting Youtube for fonts |
| 11:04 | <hsivonen> | the more complications there are, the more attractive typekit is |
| 11:04 | <roc> | jgraham: well, there you go |
| 11:04 | <othermaciej> | those are the things that would get harder in exchange for making other things easier |
| 11:04 | <jgraham> | roc: It doesn't mean it won't happen |
| 11:05 | <roc> | well, we're waiting |
| 11:05 | <jgraham> | It's just that people's frame of reference is different |
| 11:05 | <othermaciej> | making a decent-quality font is hard |
| 11:05 | <roc> | it's been a couple of years now |
| 11:05 | <Philip`> | jgraham: About the IP point of view, lots of commercially-produced video makes use of secure Flash streaming etc to prevent it being used in unauthorised ways, but there's also a lot of free/amateur video like most stuff on YouTube where people are happy to use <video>, so there's still a substantial use case for the latter |
| 11:05 | <othermaciej> | there are lots of freely redistributable fonts out there, mostly they are crappy |
| 11:05 | <othermaciej> | as with video, the most popular way to distribute fonts currently is via Flash |
| 11:05 | <Philip`> | jgraham: and there's lots of commercially-produced fonts which want similar protection, but very few decent free/amateur fonts, so the focus is much more heavily on the former |
| 11:06 | <Philip`> | jgraham: so in both cases there's two categories of difference importances and different technological solutions for each |
| 11:06 | <gsnedders> | zcorpan: We'd also have to both be header elements |
| 11:06 | <roc> | one of the nice things about making same-origin restriction the default is that cross-origin links tend to have many sites linking to a few repositories instead of a few sites linking to many repositories |
| 11:07 | <zcorpan> | gsnedders: yes. aren't you? |
| 11:07 | <gsnedders> | zcorpan: I feel more like generic flow content. |
| 11:08 | <roc> | so a default same-origin restriction means you need to add Access-Control-Allow-Origin:* to a few repositories rather than add some other header to a lot of sites |
| 11:08 | <zcorpan> | gsnedders: any specific element you feel identifies you? |
| 11:09 | <gsnedders> | zcorpan: the div element. |
| 11:09 | <gsnedders> | I feel divisive, like that. |
| 11:09 | <zcorpan> | wow that's like the most boring element |
| 11:09 | <othermaciej> | wait, when did this become a game of "who is which element"? |
| 11:10 | <gsnedders> | othermaciej: When we got bored of writting assembly to generate C++ :) |
| 11:10 | <gsnedders> | *writing |
| 11:10 | <othermaciej> | how could you ever get bored of that? |
| 11:10 | <gsnedders> | I dunno. I think Ollie gets bored enough of doing it the sane way round. |
| 11:10 | <zcorpan> | it's like that if you're a div element |
| 11:11 | <Philip`> | gsnedders: I suggest writing assembly code that generates C++ code that (when compiled and executed) generates the original assembly code |
| 11:11 | <jgraham> | "This is not a game of who the fuck are you" |
| 11:12 | <zcorpan> | "knock knock" "who's there?" "fuck you" |
| 11:12 | <gsnedders> | jgraham's bullying me into saying things on IRC. |
| 11:13 | <gsnedders> | I am not going to give into bullying again, after having multiple people force-feed me drink on Saturday |
| 11:15 | <jgraham> | At least one of them was force feeding you water |
| 11:16 | jgraham | feels he should give the impression that not everyone gsnedders knows is entirely irresponsible |
| 11:16 | <jgraham> | (because that would reflect badly on gsnedders' ability to chose friends) |
| 11:17 | <gsnedders> | jgraham: Actually, I was asking him to get me more water, multiple times |
| 11:17 | <gsnedders> | jgraham: He was just kind enough to give me it and not give me vodka instead. |
| 11:19 | <gsnedders> | jgraham: Still, I'll refrain from mentioning for your sake your girlfriend dragging me off to dance with her with both of us only just standing up |
| 11:19 | <gsnedders> | Oh, sorry. |
| 11:19 | jgraham | refrains from mentioning that that's not really true |
| 11:20 | <gsnedders> | Oh, it is… |
| 11:21 | <jgraham> | No really you were both standing up very well. Her slightly moreso |
| 11:21 | <gsnedders> | Yes, her moreso, certainly. |
| 11:21 | <gsnedders> | But the last time I didn't dance long, as moving was challenging. |
| 11:21 | <gsnedders> | Standing still I could manage. |
| 11:22 | <jgraham> | Actually you were making more of a fuss about standing still. Whenever you actually walked anywhere you were quite fine |
| 11:23 | <gsnedders> | I almost fell over several times walking home |
| 11:24 | <jgraham> | Yeah but I do that when I'm sober |
| 11:24 | <gsnedders> | Or maybe you're just permanently stoned from all the medication you're on. |
| 11:24 | <jgraham> | No |
| 11:25 | <gsnedders> | I guess I had enough beer to fulfill annevk's request that I should have some beer for him. |
| 11:49 | <gsnedders> | http://www.wolframalpha.com/input/?i=%280.5%2Ax%5E2%2By%5E2-1%29%5E3-x%5E2%2Ay%5E3%3D0 |
| 12:55 | annevk | wonders why people are still using slideshare.net |
| 12:56 | <annevk> | surely there's a better way to show a few images |
| 12:56 | <annevk> | i.e. one that doesn't require me to install Flash |
| 12:56 | <annevk> | (which I won't) |
| 13:05 | <Philip`> | annevk: The better way to show slides is PDF |
| 13:06 | Philip` | generally dislikes HTML slides because the layout never looks quite right and they always have weird navigation controls |
| 13:07 | <webben> | I like using Slidy personally. |
| 13:07 | <webben> | I tried using Keynote and found it unusable. |
| 13:08 | <webben> | (trying to format code examples - especially horrible) |
| 15:11 | <remysharp> | Q: is there any time that the Web Messaging API would use postMessage without it going via an iframe? |
| 15:13 | <gsnedders> | remysharp: A window opened through window.open, maybe? |
| 15:13 | <remysharp> | gsnedders: cheers - that's what I was after. |
| 16:19 | <annevk> | remysharp-away, also Web Workers |
| 17:24 | <magcius> | Is this a bug? The scrollbar appears in http://magcius.mecheye.net/canvasbug.html I looked into it, and a linebreak textnode is somehow being added, causing the html tag's scrollHeight to be 4px larger. It happens in all major browsers, so that's why I'm asking here. |
| 17:42 | <divya> | magcius: use display:block on canvas in your css. |
| 17:42 | <magcius> | divya: it's not display: block; already? |
| 17:42 | <divya> | magcius: Don't think it is so by default. |
| 17:43 | <Philip`> | magcius: Use html{line-height:0} |
| 17:44 | <magcius> | Philip`: ah. I used html {margin-bottom: -1em;} |
| 17:45 | <remysharp> | Q: Web Workers - the spec suggests that a worker has access to Web SQL databases |
| 17:45 | <remysharp> | but none of the browsers that have workers and databases seemed to have implemented this |
| 17:45 | <remysharp> | is this something that /should/ be in a worker, or am I missing something? |
| 17:46 | <ap> | remysharp: this is being actively worked on for WebKit |
| 17:46 | <remysharp> | ap: cheers, so it's just something that's pending implementation |
| 17:47 | <Philip`> | magcius: Looks like either canvas{display:block} or html{line-height:0} are the right solutions, since <canvas> is normally display:inline the same as <img> and so it has the layout of a line of text |
| 17:47 | <magcius> | Philip`: alright |
| 19:12 | <Dashiva> | Surely whether you're writing a polyglot document or not should be handled by editor configuration |
| 19:25 | <Matjas_> | Which ARIA roles should be used when faking a HTML5 <details> element? |
| 19:35 | <webben> | Matjas_: Hmm. Does it require ARIA? |
| 19:36 | <Matjas_> | webben: Once <details> is natively supported, I don't think so, but for now (while we're still stuck using fallbacks) I'd say some ARIA wouldn't hurt |
| 19:37 | <webben> | Matjas_: When you say faking it - do you mean using the HTML5 markup and adding behavior with JS? |
| 19:37 | <Matjas_> | webben: Yes. Like this: http://mathiasbynens.be/notes/html5-details-jquery (also see Shelley Powers’s comment, suggesting to add ARIA: http://mathiasbynens.be/notes/html5-details-jquery#comment-6) |
| 19:38 | <divya> | Matjas_: Slide 65 on this: http://www.slideshare.net/AaronGustafson/why-aria-devchatt-2010 seems to discuss ARIA for tabbed interfaces, I am guessing you could investigate some of the roles covered there. |
| 19:39 | <Matjas_> | divya: Thanks! |
| 19:39 | <webben> | But it's not tabbed? |
| 19:39 | <webben> | Matjas_: Or is it tabbed? |
| 19:40 | <Matjas_> | webben: Depends what you mean by ‘tabbed’ |
| 19:40 | <Matjas_> | webben: There’s a demo here: http://mathiasbynens.be/demo/html5-details-jquery What do you think? |
| 19:40 | <webben> | Matjas_: Mmm I wouldn't really say that's a list of tabs. |
| 19:41 | <webben> | I don't think there are ARIA roles that map perfectly onto details and summary. |
| 19:41 | <Matjas_> | Agreed |
| 19:41 | <Matjas_> | Perhaps aria-hidden="false" could be used |
| 19:41 | <Matjas_> | Question mark? |
| 19:42 | <webben> | Matjas_: In your JS implementation, should you not move focus to the start of the content when you open the details? |
| 19:42 | <webben> | Matjas_: I agree aria-hidden="true" should be applied to the contents in the closed state. |
| 19:42 | <divya> | Matjas_: http://www.w3.org/TR/2009/WD-wai-aria-implementation-20091215/#mapping_role see the table for the huge list of roles you can choose from :/ |
| 19:43 | <Matjas_> | webben: Why? I’m focusing the <summary> element so that when tab is pressed, it jumps to the next 'tabbable' element |
| 19:43 | <webben> | slightly newer at http://www.w3.org/TR/wai-aria/roles#role_definitions |
| 19:43 | <webben> | Matjas_: Let's say I'm using a screen reader. I activate the summary element ... somehow (we can come back to that), how do I know what's changed? |
| 19:44 | <Matjas_> | webben: Hmm, I see your point |
| 19:44 | <Matjas_> | divya: Thanks again! |
| 19:46 | <webben> | Matjas_: With regards to activation, I guess give the summary element a role of "button" and a property of "aria-pressed". |
| 19:46 | <webben> | Matjas_: Though given you're faking the lot with JS, you could just as well insert an actual button element. |
| 19:46 | <webben> | and it will work with more UAs |
| 19:47 | <webben> | Matjas_: you could use aria-owns/aria-controls to indicate the relationship between the button and the content. |
| 19:48 | <Matjas_> | webben: I'm trying to keep DOM manipulations to a minimum. JS makes the summary element clickable, regardless of wether the browser understands it correctly. Would it really be beneficial to replace it with an actual button? |
| 19:48 | <divya> | webben: Would the role of "note" be not sorta similar to what <details> semantically stands for? http://www.w3.org/TR/wai-aria/roles#note |
| 19:49 | <webben> | divya: Not necessarily. |
| 19:49 | <webben> | I think that's a bit closer to <aside> really. |
| 19:49 | <AryehGregor> | Well, what are the default ARIA semantics of <details> in HTML5? |
| 19:49 | <webben> | Matjas_: It would be beneficial in the sense that there's plenty of deployed software which can't make head or tail of ARIA or HTML5. |
| 19:50 | <divya> | "The details element represents a disclosure widget from which the user can obtain additional information or controls." says http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-details-element |
| 19:51 | <Matjas_> | webben: Yeah, but that's what my JS is for. Or are you talking about the case where JS is not available? |
| 19:51 | <webben> | Matjas_: Let's say I focus the summary in a pre-ARIA UA+screenreader. Adding role=button won't make my screenreader read it as a button. |
| 19:52 | <Matjas_> | webben: I see |
| 19:52 | <webben> | Matjas_: Thinking about your actual example, I wonder if it's best represented as some sort of ARIA tree - that doesn't apply to all instances of details though. |
| 19:53 | <webben> | Matjas_: In fact, I'm pretty sure your particular example is precisely a tree |
| 19:53 | <webben> | http://www.w3.org/WAI/PF/aria/roles#tree |
| 19:53 | <webben> | "A type of list that may contain sub-level nested groups that can be collapsed and expanded." |
| 19:53 | <webben> | Matjas_: http://www.w3.org/WAI/PF/aria/states_and_properties#aria-expanded might be generalizable for use outside of trees too. |
| 19:54 | <webben> | hmm section supports aria-expanded for example: http://www.w3.org/WAI/PF/aria/roles#section |
| 19:55 | <webben> | AryehGregor: Can't see any at http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#annotations-for-assistive-technology-products-(aria) |
| 19:55 | <webben> | (assuming that's the place to look) |
| 19:56 | <AryehGregor> | Then my guess is ARIA doesn't have anything with equivalent semantics. |
| 19:56 | <Matjas_> | Should aria-expanded be used as an attribute to the details element, or to the summary element? |
| 19:56 | <AryehGregor> | If it does, then the spec is buggy, I assume. |
| 19:57 | <webben> | Matjas_: That's not clear to me from http://www.w3.org/WAI/PF/aria/states_and_properties#aria-expanded . |
| 19:57 | <Matjas_> | webben: Yeah, me neither :p |
| 19:57 | <webben> | Matjas_: http://www.w3.org/WAI/PF/aria-primer/#exampletree should be helpful. |
| 19:58 | <webben> | ah that answers the question in fact |
| 19:58 | <webben> | <li role="treeitem" aria-expanded="false">Cats |
| 19:58 | <webben> | Matjas_: should be details that has aria-expanded |
| 19:58 | <Matjas_> | webben: Thanks |
| 20:02 | <webben> | Matjas_: http://pastie.org/936045 ... maybe |
| 20:02 | <webben> | Matjas_: What worries me about that is I don't see anything to make it clear that pressing the button will expand the section. |
| 20:08 | <webben> | Matjas_: Another approach might be to look at native desktop UI implementations of details-like widgets and see what accessibility roles and properties they use, then map those back to aria. |
| 20:12 | webben | can't find an example on OS X. |
| 20:18 | <webben> | ah ... Details disclosure in Password prompt is an example. |
| 20:19 | <webben> | It's interesting - the actual control in that case is the disclosure triangle - which is either collapsed or expanded. |
| 20:21 | <Matjas_> | webben: Isn’t http://img.riddle.pl/_disclosure-osx-20100425-212835.png a good example of details-like usage as well? |
| 20:24 | <webben> | Matjas_: I think that's a tree example. |
| 20:24 | <webben> | Matjas_: (In classic HTML5 that would have been a datagrid I think) |
| 20:25 | <webben> | Matjas_: But could be implemented as a list of details elements I guess, then annotated as an ARIA tree. |
| 20:25 | <webben> | Matjas_: http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGControls/XHIGControls.html "Disclosure Triangles" |
| 20:25 | <webben> | is the control I'm thinking of |
| 20:26 | <webben> | Looks like OS X has a distinct Accessibility Role for the little triangle AXDisclosureTriangle. |
| 20:26 | <webben> | Possibly "Disclosure Buttons" is also details-like |
| 20:27 | <webben> | fwiw based on the human guidelines, AXDisclosureTriangles are used in trees ("hierarchical list[s]") |
| 20:29 | <webben> | http://tinyurl.com/3yyl5gh : spec for AXDisclosureTriangle |
| 20:33 | <webben> | Matjas_: Inspecting the Finder with the Accessibility Inspector, those arrows are also Disclosure Triangles exposing AXDisclosureTriangle. |
| 20:34 | <Matjas_> | webben: Wow, you should really reply to riddle’s comment: http://mathiasbynens.be/notes/html5-details-jquery#comment-1 |
| 20:35 | <webben> | Similar HIG from MS: http://msdn.microsoft.com/en-us/library/aa511487.aspx |
| 20:37 | <zcorpan> | TabAtkins: yo. had you heard anything from ms on their <video> fallback behavior? |
| 20:39 | <webben> | http://msdn.microsoft.com/en-us/library/ee671276(v=VS.85).aspx ExpandCollapse pattern - I guess that's the UI Automation equivalent |
