| 00:01 | <matjas> | TabAtkins: I can imagine it being a pain to get those URLs in there |
| 00:01 | <TabAtkins> | I dunno if it is or not. If the url is carried in the email somehow, I can do it. |
| 00:01 | <matjas> | TabAtkins: I don’t think it is |
| 00:02 | <matjas> | TabAtkins: In that case, you could host the diffs yourself |
| 00:02 | <TabAtkins> | I'm confused. What is missing about the diffs? They're right there in the feed. |
| 00:02 | <matjas> | TabAtkins: Yeah, but there’s no way to link to them individually (from the feed) |
| 00:03 | <TabAtkins> | Oh, to link to individual commits? |
| 00:03 | <matjas> | Yeah |
| 00:03 | <matjas> | Like your full feed, only limited to one commit |
| 00:04 | <TabAtkins> | I can rig that up. I'll see if I can do that later today. |
| 00:04 | <matjas> | It would allow us to turn http://twitter.com/csscommits into something that looks more like http://twitter.com/whatwg |
| 00:05 | <TabAtkins> | In fact, just gimme a few minutes to talk to my dentist, and I'll get on it. |
| 00:05 | <matjas> | Yay! |
| 00:08 | <TabAtkins> | Argh, where is MikeSmith when you need him? WAKE UP, JAPAN. |
| 00:09 | <bga_> | omg http://code.google.com/p/es-operating-system/ |
| 00:12 | <TabAtkins> | paul_irish: Contacted the LearnBoost dude and let him know that my slidedeck is out-of-date, and he shouldn't rely on *any* syntax until he sees something ship. |
| 00:16 | <wilhelm> | bga_: OK, that is fascinating. Most of the UI on the Wii web browser is HTML, CSS and JS - but that's taking it a bit further. (c: |
| 00:26 | <bga_> | btw wilhelm while we invent tabs/lists/trees/... each time because whatwg does not want standardize xul/other full ui markup - its bad |
| 00:30 | <wilhelm> | That's a difficult problem to solve. |
| 00:31 | <bga_> | choose most popular open version http://en.wikipedia.org/wiki/User_interface_markup_language :) |
| 00:32 | <AryehGregor> | abarth, where's the CSP use-cases pages you started that Lucas mentioned? |
| 00:36 | <wilhelm> | bga_: Just within Opera, there are at least three different UI toolkits in use, in part due to platform constraints and in part due to a decade of legacy code. As I said, this is a difficult problem to solve. (c: |
| 00:37 | <Hixie> | man i hate iana's mime type registry |
| 00:37 | <Hixie> | it is so completely useless |
| 00:39 | <bga_> | wilhelm cross platform toolkits: wxwidget qt gtk ... :) |
| 00:40 | <bga_> | gtk is very lightweight |
| 00:42 | <wilhelm> | Neither of those are sufficiently cross-platform. And no, gtk isn't lightweight enough for all use cases. Neither is qt - which we removed from our GNU/Linux browser because it was too slow. |
| 00:50 | <TabAtkins> | matjas: Is this sufficient? http://www.xanthir.com/feed/public-css-commits/?t=2011-01-31T21:57:35+00:00 |
| 00:50 | <TabAtkins> | The feed now lists each entries' permalink as a rel=alternate. |
| 00:50 | <matjas> | definitely! |
| 00:51 | <matjas> | TabAtkins: +2 internets to you |
| 00:51 | <TabAtkins> | Excellent. Soon I will have *all* the internets. |
| 00:52 | <TabAtkins> | I really need to cache this stuff, so I'm not constantly hitting up GMail for the data. |
| 00:52 | <TabAtkins> | But to do that, I need to write my file-based persistence layer, which I'll be using all over my site so I can turn off my db and save myself 2c per day! |
| 00:53 | <AryehGregor> | Am I misunderstanding HTTP auth here, or is this guy clueless? http://www.w3.org/Bugs/Public/show_bug.cgi?id=11912 |
| 00:54 | <Hixie> | aaah, wall of text |
| 00:54 | Hixie | hides |
| 00:54 | <TabAtkins> | skip his wall of text, read Aryeh's comments. |
| 00:54 | <Hixie> | cunning plan |
| 00:55 | <Hixie> | oh he's just asking for s/cookies/auth/? |
| 00:55 | <Hixie> | good luck with that |
| 00:55 | <TabAtkins> | Looks like it, yeah. |
| 00:55 | <AryehGregor> | I'm trying to figure out if the benefits he claims for HTTP auth even theoretically make sense. |
| 00:55 | <AryehGregor> | Leaving aside whether it's practically useful. |
| 00:55 | <AryehGregor> | I can't see how they do. |
| 00:56 | <AryehGregor> | But I have no idea how HTTP auth actually works. |
| 00:56 | <matjas> | TabAtkins: could you remove the leading whitespace in your feed? |
| 00:56 | <matjas> | TabAtkins: before the XML prolog |
| 00:57 | <matjas> | http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.xanthir.com%2Ffeed%2Fpublic-css-commits%2F |
| 00:57 | <matjas> | (and while you're at it, why not just remove the XML prolog altogether?) |
| 00:57 | <TabAtkins> | Can I? |
| 00:57 | TabAtkins | has no idea. |
| 00:57 | TabAtkins | is confused and enraged by XML. |
| 00:57 | <Hixie> | AryehGregor: http auth works different ways depending on the auth type |
| 00:58 | <Hixie> | AryehGregor: for basic, you send the username and password with each request. |
| 00:58 | <Hixie> | in plain text |
| 00:58 | <matjas> | TabAtkins: Sure you can. http://mathiasbynens.be/notes.atom validates just fine |
| 00:58 | <TabAtkins> | matjas: Just removed the entity. Validates now. |
| 00:59 | <AryehGregor> | Yeah, I can't see how that has any advantages whatsoever except convenience. |
| 00:59 | <TabAtkins> | I'm gonna go remove it from my blog feed too, then. I hate the contortions you have to go through to output an XML prolog in PHP. |
| 01:00 | <AryehGregor> | What contortions? |
| 01:01 | <TabAtkins> | You can't just output it literally, because it looks like a PHP shorttag. |
| 01:02 | <TabAtkins> | Which I use, because I love <?= ?> |
| 01:02 | <Hixie> | AryehGregor: it's theoretically better, but was poorly deployed and is now practically irrelevant |
| 01:02 | <AryehGregor> | What's theoretically better about it? |
| 01:02 | <AryehGregor> | TabAtkins, oh, shorttags, blech. |
| 01:02 | <TabAtkins> | <?php echo 'foo' ?>, blech. |
| 01:03 | <TabAtkins> | <?= 'foo' ?>, yay! |
| 01:03 | <Hixie> | ok <div id="div>p+p:first-child"></div> is pretty funny (from http://www.456bereastreet.com/archive/201011/html5_allows_almost_any_value_for_the_id_attribute_use_wisely/) |
| 01:03 | <abarth> | AryehGregor: http://www.w3.org/Security/wiki/Use_Cases_for_Content_Security_Policies |
| 01:03 | <abarth> | got to run |
| 01:03 | <TabAtkins> | Hixie: Hehe. |
| 01:04 | <Hixie> | AryehGregor: it's theoretically better because the browser is in charge of login/logout, rather than the page |
| 01:04 | <TabAtkins> | ...wait. That selector selects nothing, by definition. |
| 01:04 | <Hixie> | TabAtkins: it's not a selector, so that's unimportant :-P |
| 01:04 | <Hixie> | AryehGregor: so you can do clever things like have many different sessions, or whatnot |
| 01:04 | <TabAtkins> | Hixie: But it's clearly supposed to be used as one. |
| 01:04 | <Hixie> | TabAtkins: sure |
| 01:06 | <TabAtkins> | Anyway, sent him a correction. |
| 01:09 | <matjas> | TabAtkins: FYI, updated the proxy feed that posts to http://twitter.com/csscommits |
| 01:09 | <TabAtkins> | kk |
| 01:09 | <matjas> | i.e. http://mathiasbynens.be/demo/css-commits |
| 01:10 | <matjas> | slooooow since it pings your feed, which in turns connects to gmail |
| 01:10 | <matjas> | but it should only get 1 hit every 30 mins anyway |
| 01:10 | <matjas> | yay first tweet https://twitter.com/csscommits/status/32245165687046145 |
| 01:13 | <TabAtkins> | yay! |
| 01:13 | <TabAtkins> | It makes me happy to add two more links in the ridiculous chain of interconnected data here. |
| 01:14 | <TabAtkins> | CVS commits -> mailing list -> gmail inbox -> atom feed -> twitterbot -> html page |
| 01:14 | <TabAtkins> | +1 for the web |
| 01:15 | <matjas> | TabAtkins: you forgot about my intermediary Atom feed |
| 01:15 | <TabAtkins> | Oh jeez. What does your intermediary do? |
| 01:16 | <matjas> | TabAtkins: clears out some whitespace and weird semicolons so it looks nice in a tweet |
| 01:16 | <TabAtkins> | Those semicolons are misplaced. I didn't initially realize that I was keeping the \n at the end of each log line. |
| 01:16 | <TabAtkins> | I need to fix that. |
| 01:17 | <matjas> | CVS commits → mailing list → Gmail inbox → Atom feed → proxy Atom feed → Twitterbot → Twitter → link to detailed log |
| 01:17 | <matjas> | Eff yeah. |
| 01:18 | <matjas> | TabAtkins: I’m off for tonight, but please do keep me posted :) |
| 01:18 | <TabAtkins> | kk |
| 01:29 | <AryehGregor> | It's amazing how much cleaner this makes your code: function $(sel) { return document.querySelector(sel); } |
| 01:31 | <TabAtkins> | I know! |
| 01:31 | <TabAtkins> | Though, I use query() and queryOne(). Same deal. |
| 01:33 | karlcow | is discovering http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingWIthAPS/CommunicatingWIthAPS.html |
| 01:35 | <karlcow> | through http://blog.mfabrik.com/2011/01/29/apple-push-notifications-apn-with-python/ |
| 01:44 | <AryehGregor> | Fun, JS diffs: http://aryeh.name/spec/innertext/test/innerText.html |
| 01:57 | <paul_irish> | AryehGregor: what is the difference, in practice, between innerText and textContent ? |
| 01:57 | <AryehGregor> | paul_irish, innerText is way more complicated, and much better matches what you actual see. |
| 01:57 | <AryehGregor> | It's basically a plaintext version of the HTML. |
| 01:58 | <AryehGregor> | So it will hide things that are display: none, add newlines when you have display: block, normalize runs of whitespace to a single space, etc. |
| 01:58 | <AryehGregor> | Add tabs for tables. |
| 01:58 | <AryehGregor> | Lots of other stuff. |
| 01:59 | <Hixie> | AryehGregor: i'm about to integrate window.atob! :-) |
| 01:59 | <AryehGregor> | :)! |
| 01:59 | <Hixie> | AryehGregor: is http://aryeh.name/spec/base64.html still the most up to date copy? |
| 01:59 | <AryehGregor> | Hixie, yes. |
| 01:59 | <Hixie> | awesome |
| 01:59 | <AryehGregor> | paul_irish, my spec for innerText so far is here: http://aryeh.name/spec/innertext/innertext.html It's still missing lots of details and testing, but you get the idea. |
| 02:00 | <jamesr__> | AryehGregor: do you think if you spec it fully that ffx will implement it? |
| 02:00 | <paul_irish> | I ask because we're looking to modify what .text() does in jQuery and i'd love to do elem.textContent || elem.innerText .. we might still do it but document the visibility cases |
| 02:00 | <paul_irish> | AryehGregor: great. thank you |
| 02:00 | <AryehGregor> | Well, for setting they should behave the same, or roughly so. |
| 02:00 | jamesr__ | wouldn't implement innerText if he was a firefox dev and could get away with it. it sucks |
| 02:01 | <AryehGregor> | For getting they're totally different -- in particular, the whitespace they return will be extremely different in most real-world cases. |
| 02:01 | <AryehGregor> | jamesr__, even if it's to a spec? |
| 02:01 | <jamesr__> | AryehGregor: well depends on the spec, but the webkit implementation is horrifying |
| 02:01 | <AryehGregor> | How much of the horrifyingness is required for web compat? |
| 02:01 | <jamesr__> | no clue :) |
| 02:02 | <jamesr__> | maybe going from code -> reverse engineering -> spec -> code will clean it up |
| 02:02 | <AryehGregor> | I'll aim for something not too horrifying and we'll see if it works. |
| 02:02 | <jamesr__> | that sort of worked for the parser |
| 02:02 | <AryehGregor> | The parser spec is pretty horrifying . . . |
| 02:02 | <jamesr__> | imo it's a lot better than the code we had before |
| 02:02 | <gsnedders> | Opera's impl is incredibly simple, it ignores almost all the complexity and isn't that different to textContent. |
| 02:02 | <AryehGregor> | Well, you'd know better than me. |
| 02:02 | <AryehGregor> | gsnedders, yes, which makes it basically useless. May as well use textContent instead. |
| 02:02 | <jamesr__> | just from an implementation point of view |
| 02:03 | <gsnedders> | That hasn't caused too much site compat issues :P |
| 02:03 | <jamesr__> | most of that is (hopefully) hidden safely away from authors |
| 02:03 | <gsnedders> | AryehGregor: If you're looking for simplicity… :P |
| 02:04 | <Hixie> | if we can drop any of this stuff altogether, i'd be even happier, but my (and thus AryehGregor's) goal is to at least have a spec so that we can have that discussion well-informed |
| 02:04 | <Hixie> | my suspicion, though, is that given that ffx is the only one to not do it at all (right?) we are probably stuck with it |
| 02:04 | <Hixie> | wow, http://aryeh.name/spec/innertext/innertext.html is the closest anyone has come to convincing me to change the small-caps style on the h1 :-) |
| 02:05 | <TabAtkins> | Hehe |
| 02:05 | <AryehGregor> | Glad to be of service. |
| 02:05 | <Hixie> | AryehGregor: btw the wording here may be of use http://www.whatwg.org/specs/web-apps/current-work/complete/#being-rendered |
| 02:06 | <TabAtkins> | We need font-variant:small-caps-unless-ugly |
| 02:07 | <Hixie> | hah |
| 02:07 | <AryehGregor> | Hixie, that doesn't seem to match my needs, at a glance. For instance, innerText works on elements that aren't part of a Document. |
| 02:07 | <AryehGregor> | You didn't expect we could actually reuse definitions on the web platform, did you? |
| 02:07 | <AryehGregor> | Silly Hixie. |
| 02:07 | <Hixie> | yeah i didn't mean you could reuse the definition |
| 02:08 | <Hixie> | just that the phrasing may be of interest |
| 02:08 | <Hixie> | what should i call th esection in which i define atob and btoa |
| 02:09 | <TabAtkins> | The "discard last 4 and interpret as an 8-bit number" bit is crazy. |
| 02:09 | <othermaciej> | innerText does something different when used on unrendered content IIRC |
| 02:12 | <AryehGregor> | It seems to do something completely insane in WebKit when used on display: none content. |
| 02:12 | <AryehGregor> | Maybe that's why. |
| 02:12 | <AryehGregor> | It seems to behave a lot more like textContent in that case. |
| 02:12 | <AryehGregor> | TabAtkins, how so? |
| 02:14 | <othermaciej> | I think it might behave exactly like textContent in that case |
| 02:14 | <AryehGregor> | That would be easy to spec, if it's actually desirable. Is it? It doesn't make any sense to me. |
| 02:21 | <Hixie> | hsivonen: we discussed what happens when you document.write() a string with broken surrogates at some point... i'm going to promote the use of webidl's "convert to unicode" thing from AryehGregor's atob() spec to apply to every method with a DOMString argument, so document.write() will be adding U+FFFDs to the input stream for that case. |
| 02:22 | <AryehGregor> | Maybe that change should just be made in WebIDL? |
| 02:22 | <Hixie> | yeah maybe |
| 02:22 | <gsnedders> | Yeah, that'd make sense to have in the ES binding |
| 02:23 | <Hixie> | i don't understand what the "a" in "atob" is supposed to stand for. |
| 02:23 | <Hixie> | oh wait. |
| 02:23 | <Hixie> | i have them backwards. |
| 02:23 | <Hixie> | so "b" is binary and "a" is ascii. |
| 02:23 | <Hixie> | ok. |
| 02:24 | <Hixie> | which should i put first, base64-to-"binary", or "binary"-to-base64? |
| 02:24 | <Hixie> | i guess the latter |
| 02:31 | <Hixie> | AryehGregor: what errors aren't caught by the algorithm? |
| 02:31 | <Hixie> | in atob() |
| 02:34 | <Hixie> | also, why "strictly greater" rather than "greater"? |
| 05:41 | <Hixie> | jgraham: i'm getting an error from pms that i've never had before |
| 05:41 | <Hixie> | "TypeError: expected string or buffer" deep inside build/bdist.linux-i686/egg/html5lib/treewalkers/lxmletree.py, according to the traceback i get |
| 06:34 | <Hixie> | jgraham: may have been because of a <?p> typo |
| 06:58 | <hsivonen> | Hixie: I strongly disagree with making document.write FFFD out unpaired surrogates. What problem is being solved? |
| 07:25 | <Hixie> | hsivonen: the problem of having unpaired surrogates in what is supposedly a Unicode-clean environment |
| 07:25 | <Hixie> | why would we ever want to allow surrogates -- paired on unpaired -- in? |
| 07:54 | <Hixie> | hahaha http://ishtml5readyyet.com/ has been updated to use new HTML elements |
| 07:54 | <Hixie> | and has a very pretty countdown clock |
| 08:03 | <benschwarz> | Hixie: I have another change request :) |
| 08:05 | <Hixie> | benschwarz: shoot |
| 08:05 | <benschwarz> | Hixie: can we rename the "web developer edition" text to read "A technical specification for web developers" |
| 08:06 | <Hixie> | you betcha |
| 08:06 | <Hixie> | lowercase "w" in "web"? |
| 08:06 | <Hixie> | not "Web"? |
| 08:06 | <Hixie> | I always think of Web as the proper noun name for the Web |
| 08:06 | <Hixie> | like the Internet as opposed to one of the many possible internets |
| 08:07 | <benschwarz> | Hixie: we can do upper case :) |
| 08:08 | <Hixie> | regenning |
| 08:08 | <benschwarz> | Hixie: <3's floating towards you |
| 08:09 | <Hixie> | it's up |
| 08:09 | <benschwarz> | legend |
| 08:09 | <benschwarz> | did you make the chrome frame change? |
| 08:12 | <Hixie> | benschwarz: not yet, will do that momentarily |
| 08:13 | <Hixie> | holy cow, someone actually used <canvas> to do a fractal. with web workers in the background for the calculation! http://juliamap.googlelabs.com/#ll=29.152261,-81.051636&z=10&p=ffffff,ffffff,ffffff,ffffff,ff0000,ffff00,ffff00,ff00,ff&f=mandelbrot |
| 08:13 | <Hixie> | sweet |
| 08:14 | <benschwarz> | Hixie: see your secret messages? |
| 08:21 | <Hixie> | can someone explain to me why the rows on http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#base64-table are not lined up? |
| 08:22 | <Hixie> | chrome |
| 08:22 | <Hixie> | using -webkit-column-stuff |
| 08:30 | <Hixie> | AryehGregor: atob is in |
| 08:31 | <Hixie> | AryehGregor: i made a number of minor editorial changes to your text to make it fit the spec's style, you may be interested in comparing the two for your edification :-) |
| 08:54 | <annevk> | ISSUE-151 o_O |
| 08:54 | <annevk> | Maybe we should recharter too to cut all cooperation |
| 08:56 | <Dashiva> | So issues are still being created without any kind of filtering? |
| 08:56 | <annevk> | Anything goes it seems |
| 08:56 | <benschwarz> | Hixie: what do you think about a applicationCache.canceUpdate() method? |
| 09:00 | <hsivonen> | Hixie: the DOM isn't a Unicode-clean environment |
| 09:17 | <jgraham> | hsivonen: What do you think about innerHTML? I presume you think the same? |
| 09:17 | <hsivonen> | jgraham: yes |
| 09:17 | <jgraham> | Conceptually I don't think the innerHTML case is so cleancut |
| 09:18 | <jgraham> | I mean, document.write just adds bytes to the input stream, so it isn't surprising if you get the bytes out that you put in |
| 09:18 | <hsivonen> | conceptually, I think the DOM and JavaScript form a system of UTF-16 code units and layout has to deal with unpaired surrogates |
| 09:19 | <jgraham> | But conceptually innerHTML runs the HTML parser on the input and if you want to reuse the full parser pipeline you naturally get the unpaired surrogate handling |
| 09:19 | <hsivonen> | jgraham: existing browsers don't seem to use the full pipeline |
| 09:21 | <jgraham> | That might be a winning argument. Nevertheless it is unclear to me that the behaviour makes sense |
| 09:21 | hsivonen | points to topic |
| 09:21 | <jgraham> | Well yes |
| 09:22 | <jgraham> | It is less stupiod than, say, innerText, I will give you that |
| 09:22 | <annevk> | topic really is a good one :) |
| 09:22 | <hsivonen> | I don't look forward to explaining to smaug and others who've spent time optimizing innerHTML that I landed something that makes it slower so that we can be theoretically cleaner in the Unicode sense |
| 09:22 | <hsivonen> | especially when we can't make JS strings enforce UTF-16 well-formedness, because people use JS strings for binary data |
| 09:23 | <jgraham> | Right, I agree that the Unicode-hygiene argument doesn't make any sense given that you can already add unpaired surrogates via DOM |
| 09:23 | <MikeSmith> | virtuelv: why's maxf giving you congrats? |
| 09:23 | <jgraham> | (I assume?) |
| 09:23 | <hsivonen> | (well, actually, they don't tend to use the code points that are surrogates for binary data) |
| 09:23 | <hsivonen> | jgraham: right |
| 09:25 | jgraham | wonders what SteveF would expect an implemenation of <hgroup> to look like |
| 09:25 | <hsivonen> | jgraham: I believe the parts of the pipeline I used for Firefox 4 innerHTML and document.write are exactly the right ones considering compat |
| 09:25 | <hsivonen> | and perf |
| 09:27 | <jgraham> | hsivonen: I don't really disagree. I just want to be sure that we have covered all the cases |
| 09:38 | <annevk> | oh, 151 is a Last Call issue... |
| 09:40 | <zcorpan> | Hixie: could you run the fixBrokenLink() script earlier than onload to speed up loading? |
| 09:44 | <zcorpan> | benschwarz: same with you ^ :) |
| 09:45 | <benschwarz> | zcorpan: other than the obvious factor of it "fixing the links" |
| 09:45 | <benschwarz> | what does it actually do? |
| 09:46 | <annevk> | https://lists.webkit.org/pipermail/webkit-dev/2011-January/015797.html yay Maciej |
| 09:47 | <virtuelv> | MikeSmith: it was meant for @opvard who's been with Opera for ten years this year |
| 09:47 | <zcorpan> | benschwarz: it redirects to the right page if the fragment is not found on the current page |
| 09:48 | <benschwarz> | zcorpan: so its important for the pages that are split? |
| 09:48 | <benschwarz> | (multipage specs)? |
| 09:48 | <zcorpan> | yeah |
| 09:49 | <zcorpan> | but hmm, i guess it needs to be run after the content has been loaded after all |
| 09:49 | <zcorpan> | so ignore me |
| 09:49 | <benschwarz> | zcorpan: perhaps I could re-write it in ruby postprocessors |
| 09:49 | <benschwarz> | and remove the script altogether |
| 09:51 | <zcorpan> | benschwarz: that wouldn't work, it needs to be in javascript |
| 09:53 | <zcorpan> | but link-fixup.js logic could be put in fragment-links.js and instead of checking getElementById() just check if the current fragment is in the table and if so, if the current page matches what the table says it should be |
| 09:54 | <zcorpan> | then you could run it ASAP and get faster redirects |
| 09:54 | <benschwarz> | zcorpan: I'll look into it |
| 09:54 | <benschwarz> | can you add an issue for me to track? |
| 09:54 | <zcorpan> | sure |
| 09:55 | <benschwarz> | thanks ;) |
| 10:02 | <Philip`> | zcorpan: I split link-fixup.js from fragment-links.js because I didn't really want it loading a quarter of a megabyte of scripts every time you visit a page |
| 10:03 | <Philip`> | since that doesn't seem good for bandwidth or performance in the common case where you're not visiting an obsolete fragment address |
| 10:21 | <zcorpan> | Philip`: is it a quarter of a megabyte gzipped? |
| 10:24 | <Philip`> | zcorpan: More like 50KB to download |
| 10:25 | Philip` | wonder how long parsing takes |
| 10:25 | <zcorpan> | 50KB doesn't sound so bad to waste in normal cases to speed up shortlink fixups |
| 10:26 | <zcorpan> | developers.whatwg.org already does that anyway |
| 11:11 | <hsivonen> | cool. brucel has started posting HTML5 videos on his blog instead of Flash-trapped videos |
| 11:12 | <hsivonen> | the medium is the message |
| 11:15 | <jgraham> | http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/ |
| 11:30 | hsivonen | wonders what the business model for Opera Widgets Runtime for Android is |
| 11:30 | <hsivonen> | will handset makers or operators pay to bundle it? |
| 12:00 | <annevk> | volkmar, for your <progress> bugs, did you check what existing impls do? |
| 12:08 | <zcorpan> | the vid.ly player doesn't seem particularly keyboard accessible |
| 12:09 | <zcorpan> | and the flash fallback doesn't seem to work for me in ie |
| 12:15 | <benschwarz> | Philip`: ping |
| 12:15 | <annevk> | http://www.gapminder.org/ is quite cool |
| 12:15 | <annevk> | I wish it did not use Flash |
| 12:16 | <espadrine> | annevk: did you see the ted talks? |
| 12:16 | <annevk> | yup |
| 12:16 | <espadrine> | The speaker ends up with a sword down his throat... |
| 12:16 | <espadrine> | Pretty odd. |
| 12:17 | <annevk> | I did not see that one... |
| 12:18 | <hsivonen> | smaug____: did you see the unpaired surrogate discussion earlier on this channel today? |
| 12:18 | <smaug____> | hsivonen: no |
| 12:19 | <hsivonen> | smaug____: "surrogate" is the string to look for in the logs. |
| 12:19 | <jgraham> | annevk: I am wary of a site with a title like that |
| 12:19 | <jgraham> | Although the graphs are pretty, the brief commentary seems to be bogus |
| 12:20 | <hsivonen> | smaug____: AFAICT, it's a case of theoretical purity vs. innerHTML perf |
| 12:20 | <hsivonen> | smaug____: I thought you might care since you've worked on innerHTML perf |
| 12:20 | <annevk> | jgraham, see e.g. http://www.youtube.com/watch?v=jbkSRLYSojo |
| 12:21 | <hsivonen> | jgraham: I think the main think to be wary of is the Flash use. The substance is good. |
| 12:21 | jgraham | has only looked at a couple of graphs |
| 12:22 | <hsivonen> | in this case, the software is quite old, so it's understandable it wasn't written in JS+HTML+SVG |
| 12:29 | <annevk> | zcorpan, oh, did <device> change? |
| 12:30 | <smaug____> | hsivonen: so every method taking a DOMString should check the input and possibly modify it? |
| 12:31 | <jgraham> | I think we would not be happy with that in general |
| 12:32 | <smaug____> | hsivonen: that would certainly cause some performance regressions, and for things like Gecko's xhr.sendAsBinary it just doesn't make sense |
| 12:33 | <jgraham> | At least I imagine that the conversation would go "the spec says that we have to check for unpaired surrogates in all DOM APIs" "the spec is stupid. That will just cause performance issues for no appreciable gain" |
| 12:33 | <jgraham> | But I am only guessing |
| 12:35 | <zcorpan> | annevk: dunno |
| 12:37 | <annevk> | smaug____, the spec allows for exceptions though I hope sendAsBinary goes away... |
| 12:37 | <hsivonen> | smaug____: right. so since browsers don't historically do it, I think we should just say "no" |
| 12:37 | <smaug____> | sendAsBinary was just an example, and yeah, I hope it will go away |
| 12:37 | <annevk> | (Though I'm not really convinced this make sense either. Unpaired surrogates can still get through.) |
| 12:42 | <jgraham> | Right. I don't understand why we hate unpaired surrogates so much. They don't seem to be causing any harm at present, but trying to guard against them everywhere would case harm |
| 12:43 | <hsivonen> | Hixie: see above. Please don't make the spec check for unpaired surrogates in innerHTML or document.write |
| 12:44 | <annevk> | There is a few places where you need that algorithm by the way. But only when you want to serialize to e.g. UTF-8 or some such. |
| 12:45 | <annevk> | XMLHttpRequest uses it for that reason. |
| 13:05 | <hsivonen> | aaargh. yay for XML. so createContextualFragment requires to propagate XML well-formedness errors as exceptions to the caller. How sad. |
| 13:07 | <Ms2ger> | I followed innerHTML, but we don't do that either |
| 13:10 | <zcorpan> | in http://canvex.lazyilluminati.com/misc/dom-viewer/x.html?%3C!DOCTYPE%20html%3E%0A%3Cscript%20xmlns%3D%27http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml%27%3Etry{d%3Ddocument.createElement%28%27div%27%29%3Bd.innerHTML%3D%27%26lt%3Bfoo%3E%27%3B}catch%28e%29{alert%28e%29}%3C%2Fscript%3E i get two alerts at the same time in firefox |
| 13:11 | <zcorpan> | shouldn't alerts wait for the current alert to be dismissed? |
| 13:12 | hsivonen | has no idea how the new alerts in Firefox work |
| 13:12 | hsivonen | is generally unhappy about propagating nsresult |
| 13:14 | Ms2ger | is generally unhappy about not propagating nsresult |
| 13:14 | <Ms2ger> | "Mediocrity: It's quicker, and by the time anybody notices, it's too late." |
| 13:16 | <hsivonen> | Ms2ger: well, now that we have the infallible malloc, the vast majority of nsresult propagation is useless |
| 13:35 | <volkmar> | annevk: that's what Webkit does, I don't think anyone implement progress element |
| 13:36 | <annevk> | both Opera and Chrome have an implementation |
| 13:37 | <volkmar> | annevk: i should check Opera then |
| 13:39 | <hsivonen> | annevk: looks like in Opera it doesn't use the theme from Gtk |
| 13:40 | <hsivonen> | oven uglier in Chrome |
| 13:40 | <hsivonen> | :-( |
| 13:40 | <hsivonen> | I don't expect Web authors to use this any time soon if it looks like this in Chrome |
| 13:40 | <volkmar> | hsivonen: Opera and Chrome don't really care about system theme for what i've seen (at least for GTK) |
| 13:40 | <volkmar> | annevk: Opera is following the specs word by word |
| 13:41 | <hsivonen> | I guess the Chrome impl. still scores some points on html5test.com or something :-( |
| 13:41 | <volkmar> | hsivonen: it looks great on MacOS though |
| 13:42 | <volkmar> | so i would probably bet on web authors using it with no care for the GNU/Linux users |
| 13:43 | <hsivonen> | maybe |
| 13:44 | <hsivonen> | maybe Linux users welcome their new unthemed Chromium overlords, because it's "so fast" :-( |
| 13:45 | <annevk> | I suspect for Linux they mostly care about Chromium OS |
| 13:50 | jgraham | wonders if Chrome would seem faster if I used it more |
| 13:51 | <jgraham> | As it is, the processes tend to get swapped out and there is a noticable responsiveness issue when the UI is swapped in but not the content |
| 13:53 | <hsivonen> | Also, while Firefox and Opera seem to map well known font names to Ubuntu-bundled lookalikes properly, Chromium doesn't. |
| 13:54 | <hsivonen> | correction: It seems that Opera has failures in that department, too |
| 13:55 | <Ms2ger> | Why do you make me look at XMLSerializer :( |
| 13:56 | <hsivonen> | Ms2ger: I thought you had volunteered. :-) |
| 13:57 | <hsivonen> | Ms2ger: anyway, I think we should make XMLSerializer escape stuff that would otherwise be normalized away when round-tripping |
| 13:57 | <hsivonen> | Ms2ger: perhaps the right place to spec it is in HTML5 |
| 13:58 | <hsivonen> | since XMLSerializer already refers to it |
| 13:58 | <Ms2ger> | We need an algorithm for XML serializing in any case |
| 14:18 | <annevk> | indeed we do |
| 14:18 | <annevk> | part of DOM Parsing and Serializing no? |
| 14:19 | <Ms2ger> | Sure |
| 14:19 | <Ms2ger> | Patches welcome ;) |
| 14:24 | hsivonen | wonders what the point of using kSpace instead of ' ' is |
| 14:25 | <hsivonen> | it's not like the code point will get reassigned every couple of years warranting a layer of abstraction |
| 14:31 | <loucapo> | hi again everyone! |
| 14:41 | <erlehmann> | the video element in chrome is ugly. :( |
| 14:46 | <Philip`> | hsivonen: Maybe a general policy that inline constants are bad? |
| 14:47 | <hsivonen> | Philip`: what's bad about inline constants for ASCII characters? |
| 14:49 | <Philip`> | Probably nothing, but some other cases of magic constants are bad, and complex policies with exceptions depending on the types of constants are bad, so it's easier just to forbid them entirely if you don't trust your programmers to be sensible, I guess |
| 14:51 | <hsivonen> | Philip`: well, it leads to issues like having to push .h files around because different people defined kSpace in different places than must never see each other |
| 14:51 | <hsivonen> | s/than/that/ |
| 15:02 | <hsivonen> | annevk: are you gonna call into the HTML-XML TF? |
| 15:02 | <annevk> | thanks |
| 15:05 | <AryehGregor> | Hixie, atob() as I specced it ignores trailing bits that aren't zero, as noted in the second-to-last step, even though those can't be output by btoa(). It also doesn't require the trailing equals signs, although if they're present they must be the exact right number. As I note in HTML comments, WebKit is laxer, but I followed Gecko. |
| 15:06 | <AryehGregor> | Hixie, I say "strictly greater" out of mathematician's habit, I guess. To mathematicians, "greater" is ambiguous, it's often used to mean "greater than or equal to". Probably for a spec, the "strictly" is unnecessary. |
| 15:08 | <Ms2ger> | Greater than is >, always |
| 15:08 | <AryehGregor> | To programmers, yeah. |
| 15:08 | <Ms2ger> | Just like 0 is never positive |
| 15:08 | <AryehGregor> | Mathematicians also are sometimes sloppy about the difference between "positive" and "nonnegative". The thing is, when you're dealing with continuous quantities, the difference is usually irrelevant. |
| 15:09 | <AryehGregor> | Because it's a difference of one point in a continuum, which doesn't matter. |
| 15:09 | <AryehGregor> | Programmers deal with discrete quantities, so it makes a difference. |
| 15:09 | <AryehGregor> | (sometimes it makes a difference in math too, but then mathematicians will often say "strictly" if they mean strictly, to clarify) |
| 15:09 | <AryehGregor> | But it's unnecessary in a computing spec, I agree. |
| 15:16 | <AryehGregor> | Hixie, I filed three bugs about editorial issues in the base64 stuff. |
| 17:00 | zcorpan | points out that hgroup has at least parser impl in at least gecko and webkit |
| 17:02 | <zcorpan> | also, http://software.hixie.ch/utilities/js/live-dom-viewer/saved/818 styling is still suboptimal with the :any(section, ...) ... h1 styling |
| 17:18 | <karlcow> | hmm |
| 17:18 | <karlcow> | "MIME-Handling: Sniffing Opt-Out |
| 17:19 | <karlcow> | http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-v-comprehensive-protection.aspx |
| 17:19 | <karlcow> | I wonder how it will be more effective. As soon it is built into a library that people use inadequatly |
| 17:32 | <annevk> | tech support from ISP at my mom's house does not do Ubuntu |
| 17:32 | <annevk> | apparently it was too hard to click on the connection thingie at the top and select the wired connection option |
| 17:32 | <annevk> | (she previously had a wireless connection) |
| 17:33 | <annevk> | unfortunately the competing ISPs are even worse |
| 17:35 | <annevk> | othermaciej++ |
| 17:35 | <annevk> | using CORS for fonts is protocol abuse |
| 17:36 | <othermaciej> | annevk: sadly, TabAtkins is being kind of pushy about it |
| 17:36 | <othermaciej> | annevk: fortunately, I think my C++-fu is better than his... |
| 17:37 | jgraham | wonders in what strange universe a debate about the merits of CORS for font DRM comes down to C++-fu |
| 17:37 | <othermaciej> | annevk: incidentally, if we backed down and decided to use SOP+CORS for WOFF, is there any way we could still allow free cross-site linking of other font formats (TrueType, OpenType, SVG) |
| 17:38 | <karlcow> | webkit? |
| 17:38 | <othermaciej> | jgraham: I doubt he's able to code a patch to implement his suggestion |
| 17:38 | <annevk> | othermaciej, the way CORS works in theory is that the requester sets the policy |
| 17:38 | <annevk> | so this would in theory need to be defined by @font-face |
| 17:38 | <jgraham> | Hmm, I guess this is the logical conclusion of "those who implement win" |
| 17:39 | <annevk> | and you could of course do the request, and if it is WOFF (after sniffing) also check the relevant CORS stuff and otherwise ignore them |
| 17:39 | <annevk> | however, that is very much like checing "usage rights" rather than "read rights" (what CORS is designed for) |
| 17:39 | <othermaciej> | annevk: so the problem with this is either you make a CORS simple request for cross-site access for TT/OT/SVG fonts (which means no cookies etc are sent) or you make a preflight request for all font requests |
| 17:40 | <othermaciej> | annevk: or you violate CORS by sending a request with credentials and no preflight |
| 17:40 | <annevk> | i.e. CORS is not designed to prevent cross-origin image usage, it is designed to allow cross-origin images to be read by e.g. <canvas> |
| 17:40 | <othermaciej> | IE and FF get around this by applying a same-origin limitation to all font formats |
| 17:40 | <annevk> | othermaciej, actually, for GET requests there is no preflight needed |
| 17:40 | <annevk> | othermaciej, you got that wrong in your message |
| 17:41 | <othermaciej> | is it ok to send credentials with a GET with no preflight? |
| 17:41 | <karlcow> | http://sebleedelisle.com/2011/02/html5-canvas-sprite-optimisation/ |
| 17:41 | othermaciej | has trouble remembering this stuff |
| 17:41 | <annevk> | othermaciej, yes, otherwise we could never make <img> work with CORS |
| 17:41 | <othermaciej> | ok |
| 17:41 | <annevk> | othermaciej, and I wanted <img> to be able to work with CORS |
| 17:41 | <othermaciej> | so since none of the headers would be provided by the embedder, you could just send a normal request and read CORS headers in the response depending on Content-Type |
| 17:41 | <othermaciej> | in principle |
| 17:41 | <othermaciej> | though it would still (IMO) be bad design |
| 17:42 | <annevk> | yeah, where the Content-Type is derived from sniffing |
| 17:42 | <zcorpan> | killing WOFF was my knee-jerk reaction when IE came out and supported OTF |
| 17:42 | <annevk> | it's protocol abuse for sure |
| 17:42 | <othermaciej> | zcorpan: yeah, I have no idea what the point of WOFF is now |
| 17:42 | <othermaciej> | I thought the whole purpose was to have a single font format, when IE refused to implement OTF and others refused to implement EOT |
| 17:42 | <annevk> | I have stated several times that using CORS for this is the wrong solution |
| 17:45 | <othermaciej> | I also wonder why deciding not to support part of a spec is suddenly a huge deal |
| 17:45 | <othermaciej> | no one is up in arms because Mozilla refuses to support SVG fonts |
| 17:46 | <annevk> | or Web SQL DB *cough* *cough* |
| 17:47 | <annevk> | the foundries and e.g. Sylvain from Microsoft seem to be making it a big deal |
| 17:48 | <annevk> | and the rest of the WG sort of gets dragged into it |
| 17:48 | <annevk> | but I am not really interested in participating there, I was not welcome, so I posted something on my blog somewhere in April last year |
| 17:50 | <zcorpan> | not implementing part of a spec *can* be pretty bad. but i think not implementing SOR for fonts isn't bad |
| 17:52 | <zcorpan> | e.g. implementing WF2 API but not UI is pretty bad |
| 17:52 | <Ms2ger> | What about implementing ugly UI? ;) |
| 17:53 | <zcorpan> | that's also pretty bad |
| 17:54 | <annevk> | subjective! :p |
| 18:00 | <zcorpan> | why does http://dev.w3.org/2006/webapi/FileAPI/#abort fire both 'error' and 'abort'? |
| 18:00 | <annevk> | looks like a bug |
| 18:23 | <loucapo> | hey everyone, is this a good place to post a code question or is there a better group? |
| 18:35 | <jgraham> | For today's episode of "an ignorance shared is an ignorance harshly mocked on the internet" I have a question straight out of CS 101 |
| 18:36 | <jgraham> | Say I am trying to construct a representation of tests, in code. The obvious thing to do would be to have a Test base class and derive specific types of tests from that base class |
| 18:37 | <jgraham> | (these are web browser Tests fwiw) |
| 18:38 | <jgraham> | However it seems this will violate the Liskov Substitution Principle |
| 18:39 | <jgraham> | For example a Javascript test will have a single URL |
| 18:39 | <jgraham> | But a RefTest will have two urls and a type |
| 18:39 | <jgraham> | So, given that almost all the methods will be the same for all the types, what is one supposed to do? |
| 18:41 | Philip` | doesn't really understand what Substitution is occurring in this case |
| 18:42 | <Philip`> | Are you having a JavascriptTest and RefTest both derived from Test? |
| 18:42 | <TabAtkins> | othermaciej: I'm being "pushy" because SOR on @font-face is the right choice, and Moz and IE have both gone with it already. I'd like any new embedded media to have SOR. |
| 18:42 | <othermaciej> | the latter is definitely not going to happen |
| 18:42 | <jgraham> | Philip`: Well that was the hypothesis |
| 18:43 | <othermaciej> | video and audio don't have SOR (despite Mozilla's attempt to enforce it at some point) |
| 18:43 | <TabAtkins> | Right, we've very likely already lost our chance with those two. |
| 18:43 | <Philip`> | Are you having any methods on Test that won't behave equivalent for objects of either subclass? |
| 18:43 | <othermaciej> | SOR for non-WOFF fonts is something I'd definitely consider an unacceptable change, there isn't even a spec argument for it |
| 18:43 | <loucapo> | i was on here last week asking about xmlhttp level 2 posting to a pwd protected url |
| 18:43 | <TabAtkins> | Sure there is. @font-face suggests applying SOR (though doesn't require it). |
| 18:43 | <Philip`> | s/equivalent/equivalently/ |
| 18:43 | <jgraham> | Philip`: Not that I know of. But does the constructor count? |
| 18:44 | <annevk> | TabAtkins, that's not a good argument |
| 18:44 | <jgraham> | I mean the constructor necessarily has a different signature |
| 18:44 | <loucapo> | annevk suggested that if u set the Authoization header via JS it should be ok |
| 18:44 | <loucapo> | assuming the server accepts that header |
| 18:44 | <TabAtkins> | annevk: That was just challenging the statement that "there isn't even a spec argument for it". |
| 18:44 | <loucapo> | i allowed it on the server |
| 18:45 | <othermaciej> | TabAtkins: I can't find the word "origin" in http://www.w3.org/TR/css3-fonts/ |
| 18:45 | <loucapo> | but i dont see the header showing in my request's options call |
| 18:45 | <annevk> | TabAtkins, also, "suggestions" suggests it's a pretty bad spec |
| 18:45 | <annevk> | TabAtkins, and what I've seen in WOFF about CORS is crap too |
| 18:45 | <annevk> | TabAtkins, does not follow CORS at all |
| 18:46 | <othermaciej> | TabAtkins: nor in the editor's draft |
| 18:46 | <othermaciej> | wait, I guess it is in the ED |
| 18:46 | <TabAtkins> | annevk: What do you mean? |
| 18:46 | <Philip`> | jgraham: I believe constructors are irrelevant to the LSP, because the LSP is about using an object of a type that's a subclass of T as if it were an object of type T, so it's only applicable after you've already constructed the object |
| 18:47 | <jgraham> | Philip`: Interesting |
| 18:47 | <jgraham> | I hadn't considered that |
| 18:47 | <TabAtkins> | annevk: The language used is identical to that used in CSS3 Fonts. |
| 18:47 | <othermaciej> | TabAtkins: CSS3 fonts doesn't "suggest" it afaict |
| 18:47 | <annevk> | TabAtkins, I mean a) "suggests applying SOR" makes no sense, it should either require it or not and b) WOFF does not properly use CORS as specified by the CORS specification |
| 18:47 | <TabAtkins> | othermaciej: You're right. It simply defines what it means to apply SOR to @font-face resources. |
| 18:47 | <AryehGregor> | jgraham, why do the URLs or type have to be part of the base class? Why not make them members of the derived classes? |
| 18:48 | <othermaciej> | btw, who decided to replace the perfectly good term "same-origin policy" with "same-origin restriction"? |
| 18:48 | <AryehGregor> | If you have lots of types of single-URL tests, make a SingleUrlTest class that they derive from. |
| 18:48 | <annevk> | yeah, "SOR" makes no sense either |
| 18:48 | <AryehGregor> | If you want to get all obsessive about OO. |
| 18:48 | <jgraham> | AryehGregor: I don't want to get all obsessive |
| 18:48 | <TabAtkins> | annevk: I don't immediately see what's wrong with WOFF's use of CORS. Could you be more explicit? |
| 18:48 | <Philip`> | It's not like JS really does OO anyway |
| 18:48 | <jgraham> | Having a huge multi-level class heirachy is overkill |
| 18:48 | <othermaciej> | TabAtkins: in fact, it doesn't even clearly say UAs MAY apply a same-origin limitation |
| 18:48 | <TabAtkins> | othermaciej: I don't see the distinction. |
| 18:49 | <jgraham> | But having one level of inheritance seems sensible |
| 18:49 | <TabAtkins> | Sorry, that was to SOP vs SOR. |
| 18:49 | <othermaciej> | TabAtkins: I don't either, but using a different term sounds like it is drawing a distinction from the traditional terminology |
| 18:49 | <annevk> | TabAtkins, to use CORS you need to define that the UA need to do a cross-origin request and set various parameters |
| 18:49 | <annevk> | TabAtkins, then you need to deal with the potential return flags of that algorithm |
| 18:49 | <annevk> | TabAtkins, as e.g. XMLHttpRequest does |
| 18:49 | <annevk> | TabAtkins, @font-face nor WOFF does any of that and are therefore not really using CORS |
| 18:49 | <TabAtkins> | annevk: Is it simply defined somewhere in CORS what specs need to say to make it work? |
| 18:50 | <annevk> | TabAtkins, yes |
| 18:50 | <annevk> | but it is pretty clear nobody has actually read or understood the purpose of CORS |
| 18:50 | <othermaciej> | TabAtkins: anyway - the ED (which it's not clear the CSS WG will even agree on) says if you limit fonts to same-origin, you MUST allow relaxation of that limit via CORS |
| 18:50 | <TabAtkins> | annevk: As far as I can tell, you've objected to every use of CORS outside of specs that you directly maintain. |
| 18:51 | <TabAtkins> | othermaciej: Yes. |
| 18:51 | <jgraham> | Philip`, AryehGregor: Thanks |
| 18:51 | <annevk> | TabAtkins, no |
| 18:51 | <annevk> | TabAtkins, what the fuck is that about? |
| 18:51 | <TabAtkins> | annevk: Not meant to be offensive. It's just that the only time I hear you talk about CORS, it's that some spec is using it wrong. |
| 18:51 | <Philip`> | jgraham: All that really matters is whether you can write code that takes an object which you know acts like a Test, without caring which type it really is - inheritance is useful as a way to encode "acts like a Test" in statically typed languages, but that doesn't work in JS, so JS prototype inheritance is just useful as a code-sharing mechanism |
| 18:51 | <TabAtkins> | Or that people don't understand it. |
| 18:52 | <othermaciej> | it doesn't even say you MAY have a restriction (though presumably that is intended) |
| 18:52 | <othermaciej> | TabAtkins: maybe there's nothing to say when people use it right? |
| 18:52 | <Ms2ger> | Well, otherwise it wouldn't have to be mentioned, no? ;) |
| 18:52 | <annevk> | TabAtkins, oh? |
| 18:52 | <Philip`> | jgraham: so it seems fine to not worry much about inheritance hierarchy design |
| 18:52 | <annevk> | TabAtkins, other than fonts I'm not aware of anyone trying to use it |
| 18:52 | <jgraham> | Philip`: This is actually Python |
| 18:53 | <othermaciej> | WebSockets sort of does something similar, but it's not really CORS |
| 18:53 | <annevk> | TabAtkins, and CORS isn't easy or anything |
| 18:53 | <annevk> | it's really quite complicated |
| 18:53 | <loucapo> | not that anyone is available to listen but the only headers on the response i see are: |
| 18:53 | <TabAtkins> | annevk: I just skimmed through CORS again, and I can't find anywhere that defines in some simple way what a spec using CORS is supposed to provide. |
| 18:54 | <loucapo> | DateTue, 01 Feb 2011 18:53:00 GMTWWW-AuthenticateBasic realm="People Rails RC Environment"Content-Length401ConnectioncloseContent-Typetext/html; charset=iso-8859-1 |
| 18:54 | <annevk> | which is why it upsets me WOFF is using it without the WG actually understanding what they are doing |
| 18:54 | <TabAtkins> | annevk: What chapter are the requirements in? |
| 18:54 | <annevk> | TabAtkins, "CORS API Specification Advice" |
| 18:55 | <TabAtkins> | annevk: Oh, a "CORS API" is something another spec defines. |
| 18:55 | <annevk> | of course |
| 18:55 | <annevk> | CORS is a protocol |
| 18:55 | <TabAtkins> | In a spec called "CORS", it's not clear to me that "CORS API" is something outside of the spec. ^_^ |
| 18:55 | <Philip`> | jgraham: Oh, okay - I suppose that's a bit more OOey, but still not at all strictly |
| 18:56 | <TabAtkins> | Not sure what name would be better, though. |
| 18:56 | <Philip`> | (hence duck typing) |
| 18:56 | <annevk> | I suppose I could rename it to "Advice for specifications using CORS" |
| 18:57 | <TabAtkins> | Ah, yeah, that would at least draw the eye better. |
| 19:05 | <jgraham> | http://www.googleartproject.com/ is awesome |
| 19:05 | <jgraham> | Wonder what we have to do so it can ditch flash for the image viewing |
| 19:06 | <TabAtkins> | Most likely, add DRM. |
| 19:07 | <jgraham> | That could be the problem I guess |
| 19:07 | <jgraham> | Although one would have thought that the paintings were out of copyright (I know the digital reproductions may not be) |
| 19:08 | <AryehGregor> | jgraham, the digital reproductions are out of copyright too, at least in the US, but you're not going to get museums' cooperation if you point that out. |
| 19:08 | <AryehGregor> | Since they get a lot of revenue from licensing copyrights they don't own. |
| 19:10 | <jgraham> | AryehGregor: Right, but not everywhere has the same law as the US there |
| 19:10 | <jgraham> | e.g. I think the UK is different |
| 19:10 | <AryehGregor> | The UK is unclear, AFAIK. |
| 19:11 | <jgraham> | Unclear to me at least :) |
| 19:11 | <jgraham> | (but that is diffrent from the US where it is fairly clear) |
| 19:12 | <AryehGregor> | I have to say, JS code I write for Chrome basically works fine in IE9. |
| 19:13 | <AryehGregor> | As opposed to IE8, where it dies horribly very early on. |
| 19:13 | <AryehGregor> | Kudos to the IE team. |
| 19:14 | <zcorpan> | is the opposite true? JS code written for IE works in Chrome? |
| 19:15 | <Ms2ger> | document.all('x') |
| 19:15 | <Ms2ger> | Looks like a yes |
| 19:16 | jgraham | totally has to visit MoMA |
| 19:16 | <annevk> | it's quite nice |
| 19:17 | <AryehGregor> | How do I feature-test the IE8 JS engine? I'm actually testing in IE9 in IE8 document mode, so I'm getting confused. |
| 19:17 | <othermaciej> | I think IE9's JS engine is more conforming to ES5 than Chrome's |
| 19:17 | <AryehGregor> | In IE8 document mode, it fails with "'Node' is undefined", but trying to do something like if (Node === undefined) or if (typeof(Node) == "undefined") gives the same error. |
| 19:17 | <jgraham> | Yeah, the IE9 js engine should be very conforming |
| 19:17 | <AryehGregor> | Is there some way to say "if 'Node' is a variable name" that works in IE8? |
| 19:18 | <AryehGregor> | Maybe TabAtkins would know, he actually writes real web pages sometimes. |
| 19:18 | <Philip`> | if (window.Node) ? |
| 19:18 | <TabAtkins> | What's up? |
| 19:19 | <TabAtkins> | If foo is undefined, (foo === undefined) shouldn't be throwing an error. |
| 19:19 | <AryehGregor> | Nice, thanks. |
| 19:19 | <AryehGregor> | TabAtkins, this is IE8. |
| 19:20 | <TabAtkins> | I haven't cared about browser craziness in some time, sorry. Last cross-browser dev I did leaned heavily on jQuery. |
| 19:20 | <TabAtkins> | Nowadays I just code to Chrome and assume it'll work everywhere, which is usually true. |
| 19:20 | <TabAtkins> | (For some definition of "everywhere".) |
| 19:21 | <miketaylr> | jgraham: come to NYC to see MoMA and you can work out of Opera Brooklyn (my tiny 2 person office) |
| 19:23 | <jgraham> | miketaylr: Sounds awesome, but I'm not sure how well "see MoMA" would go down under "purpose of trip" |
| 19:23 | <miketaylr> | heh |
| 19:24 | <TabAtkins> | "network with other Opera employees" |
| 19:24 | jgraham | was somewhat considering visiting the US in the summer anyway |
| 20:10 | <AryehGregor> | Can anyone tell me why the Selection stringification is empty here for Opera? http://aryeh.name/spec/innertext/test/innerText.html |
| 20:11 | <Workshiva> | "typeof identitifer" shouldn't be throwing reference errors... |
| 20:11 | <AryehGregor> | Even in IE8? |
| 20:12 | <Workshiva> | Yeah |
| 20:12 | <Workshiva> | If the identifier isn't previously declared it should just return undefined |
| 20:12 | <AryehGregor> | Oh well. |
| 20:13 | <AryehGregor> | Testing window.Node works, anyway. |
| 20:14 | <Workshiva> | Yeah, that's the usual approach. I never liked typeof :) |
| 20:15 | <Workshiva> | (Side note, Node == undefined is allowed to throw, and typeof is not a function so you don't need to do typeof(x)) |
| 20:19 | <AryehGregor> | I originally did "typeof x", but tried "typeof(x)" in case it would work. |
| 20:19 | <AryehGregor> | Which it didn't. |
| 20:19 | <AryehGregor> | Why is Node === undefined allowed to throw? That's silly. |
| 20:19 | <Workshiva> | Because you're referencing an undeclared identifier |
| 20:19 | <AryehGregor> | That's either a reason to throw or not to throw, not to allow throwing. |
| 20:20 | <Workshiva> | Well, allow as in "throw if there is a reason to throw" |
| 20:20 | <Workshiva> | It's not optional |
| 20:20 | <AryehGregor> | What's "a reason to throw"? |
| 20:20 | <Workshiva> | unresolvable reference |
| 20:21 | <AryehGregor> | Also, can anyone help me figure out where the plainText function called here is defined? I've been looking, but I can't find it. I want to compare my super-simple innerText to WebKit's real-world implementation: http://www.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/third_party/WebKit/WebCore/dom/Element.cpp&exact_package=chromium&l=1507 |
| 20:21 | <AryehGregor> | othermaciej, could you point me to WebKit's plainText implementation, or whatever does the bulk of the work of innerText? |
| 20:24 | <AryehGregor> | (I'm beginning to suspect that it uses some kind of internal rendering data structure, not the DOM at all . . .) |
| 20:25 | <AryehGregor> | (Which would be hopeless to spec.) |
| 20:25 | <TabAtkins> | It might rely on the Render Tree, which is a close analogue to CSS's box tree. |
| 20:27 | <Workshiva> | This one maybe? http://www.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/third_party/WebKit/WebCore/editing/TextIterator.h&q=\bplainText\%28%20lang:cpp&exact_package=chromium&sa=N&cd=3&ct=rc |
| 20:28 | <AryehGregor> | It does scary things like respecting text-transform. |
| 20:28 | <Workshiva> | (Well, the matching .cpp file anyway) |
| 20:30 | <Ms2ger> | Looks like it |
| 20:31 | <Workshiva> | Searched for plainText taking a Range as parameter and that was the only one I could see |
| 20:32 | <AryehGregor> | I don't get that code at all, but I feel like the code that does the actual work must be someplace else. |
| 20:32 | <othermaciej> | AryehGregor: I can look for you after I grab lunch |
| 20:32 | <AryehGregor> | Obviously I should just ask in #webkit. |
| 20:35 | <AryehGregor> | Ah, I think I see it now. |
| 20:35 | <AryehGregor> | handleTextNode() et al. |
| 20:37 | <AryehGregor> | Hmm, doesn't seem easy enough to understand to be useful. |
| 20:38 | <othermaciej> | yes, you'll need someone to explain what it is doing |
| 20:38 | Ms2ger | hears othermaciej volunteer |
| 20:39 | AryehGregor | asks in #webkit |
| 20:40 | <MikeSmith> | we need code-analysis heuristics that magically read source code files and tell us what they do |
| 20:40 | AryehGregor | finds http://www.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/third_party/WebKit/LayoutTests/fast/dom/inner-text-001.html&exact_package=chromium&d=6 |
| 20:41 | <Ms2ger> | MikeSmith, why do you want us all unemployed? |
| 20:42 | <MikeSmith> | yeah |
| 20:42 | <MikeSmith> | then we can all be gentleman and ladies of leisure |
| 20:42 | <MikeSmith> | can retire with our riches to a bucolic life in the countryside |
| 20:43 | <nimbupani> | hahahaha |
| 20:43 | <TabAtkins> | MikeSmith: Yo, question about boilerplate on the specs. |
| 20:44 | <TabAtkins> | Art sent me the message that you said to use the HTML5 WD boilerplate for the SotD. Should I just take the whole thing, replacing spec names when appropriate? |
| 20:44 | <roc> | othermaciej, annevk: are you opposed to having *any* standard mechanism which allows authors to control who can deep-link resources on their servers? (I mean subresource loads like IMG, font-face and video, not <a href>) |
| 20:45 | <MikeSmith> | TabAtkins: yeah, please |
| 20:45 | <othermaciej> | roc: there already is one, isn't there? |
| 20:45 | <TabAtkins> | MikeSmith: Okay, just making sure. |
| 20:45 | <MikeSmith> | k |
| 20:45 | <roc> | othermaciej: which is? |
| 20:45 | <othermaciej> | (server-side check of Referer, or Origin in browsers that have it) |
| 20:45 | <othermaciej> | sites do take measures to prevent image hotlinking |
| 20:46 | <othermaciej> | I'm not sure adding a client-side way to do it for img would be worthwhile |
| 20:46 | <roc> | that requires an information leak from to the server and is unreliable due to firewall stripping |
| 20:47 | <othermaciej> | I don't think any firewalls strip Origin, though it's true not all browsers send it for subresource loads (yet) |
| 20:47 | <roc> | a solution where the browser decide wouldn't have those problems, and could be easier for authors to deploy too |
| 20:47 | <othermaciej> | firewall stripping is estimated to affect <5% of users and so would not materially affect the effectiveness of hotlinking prevention |
| 20:49 | <erlehmann> | why should a firewall strip headers? |
| 20:49 | <othermaciej> | some firewalls strip Refer for privacy purposes |
| 20:49 | <TabAtkins> | 'cause firewalls are crazy. |
| 20:50 | <othermaciej> | or to avoid disclosing URLs on intranet servers that link to external sites |
| 20:50 | <roc> | because intranet administrators are concerned about people clicking on a link from worlddomination.google.com to evil.com |
| 20:50 | <othermaciej> | Origin should be less of an issue, since it doesn't disclose the full linking URL |
| 20:50 | <othermaciej> | though it's true that the hostname itself could leak info |
| 20:50 | <othermaciej> | anyway |
| 20:51 | <othermaciej> | if there's some general mechanism that can reasonably be applied to IMG, whether client-side or not, I would not be averse to also applying it to @font-face |
| 20:51 | <roc> | is Webkit going to start sending Origin for all subresource loads? |
| 20:51 | <othermaciej> | I believe we already do |
| 20:53 | <roc> | good |
| 20:53 | <othermaciej> | trying to figure out how to construct the tcpdump command to verify |
| 20:54 | <roc> | I think deploying Origin checking is likely to be very hard for most Web authors though |
| 20:56 | <roc> | and "default allow" just seems wrong :-( |
| 20:56 | <othermaciej> | well, according to tcpdump I'm wrong (about sending Origin), but I'm not sure why |
| 20:57 | <erlehmann> | othermaciej, just use wireshark :) |
| 20:58 | <othermaciej> | roc: if we were redesigning the Web from scratch, it might make sense to default to denying cross-origin resource loads, but it seems unhelpfully inconsistent to do it only for some resource types, and reversing the default on IMG or SCRIPT at this point is likely impossible |
| 20:58 | <roc> | I agree that's impossible |
| 20:59 | <roc> | I don't buy the consistency argument since we DO default-deny cross-origin for XHR |
| 20:59 | <othermaciej> | that said, I'd be fine with an across-the-board hotlinking prevention mechanism that servers can opt into |
| 20:59 | <roc> | OK |
| 20:59 | <othermaciej> | if it was materially easier than checking headers |
| 20:59 | <roc> | I ask mainly because I've heard some people claim that any such mechanism is "against the spirit of the Web" or something like that |
| 21:00 | <othermaciej> | well, servers can do it already |
| 21:00 | <othermaciej> | if we had a header that a server could send to ask the browser to limit embedding, that doesn't seem hugely different |
| 21:00 | <roc> | people do all kinds of things that are against the spirit of the Web :-) |
| 21:00 | <othermaciej> | since adding a static header to a resource might be easier than checking a request header |
| 21:01 | <othermaciej> | XHR is different because it lets you read the response |
| 21:01 | <othermaciej> | not just embed it in an opaque way |
| 21:01 | <othermaciej> | same-origin policy is traditionally about preventing actual access to data from another site, not preventing embedding |
| 21:02 | <othermaciej> | (XHR has the added wrinkle that it can make requests that could be dangerously side-effecting which are otherwise impossible to produce from a WEb page) |
| 21:02 | <othermaciej> | I would also want to get rid of cross-origin non-GET form submission if that was possible |
| 21:02 | <roc> | I understand why it's different, but it's still not consistent |
| 21:02 | <othermaciej> | sadly, probably not |
| 21:03 | <roc> | and denying cross-origin loads is still not a new concept on the Web |
| 21:03 | <othermaciej> | fonts are like images or video in that respect, not like XHR |
| 21:03 | <roc> | the distinction between "reading" and "embedding" makes sense but I don't know if authors appreciate it ... and in practice, the distinction is not so clear, witness all the information leak issues we've had with cross-origin CSS loads etc |
| 21:03 | <othermaciej> | neither of the reasons that XHR is different apply (reading result, sending dangerous requests) |
| 21:04 | <othermaciej> | agree; if starting from scratch, it might make sense to reverse the polarity |
| 21:05 | <othermaciej> | I think adding an Allow-Embedding-From-Origins: header that works across the board would be reasonable and possibly helpful to authors |
| 21:05 | <Dashiva> | Alex Russel believes that doing perfect browser detection is so simple he leaves it as an exercise for the reader, no need to actually demonstrate how |
| 21:06 | <Ms2ger> | All you need is indexOf("Netscape") |
| 21:07 | <annevk> | roc, I think we need a generic blocking mechanism that can be used for fonts/images/scripts/framed resources/etc. |
| 21:08 | <annevk> | roc, using CORS for fonts and something else for all the other stuff is somewhat insane |
| 21:08 | <annevk> | plus, CORS is not meant for blocking |
| 21:09 | <roc> | that is why we want a default-same-origin policy for fonts |
| 21:09 | <roc> | well, one of the reasons |
| 21:09 | <annevk> | but our platform is such that such resources work cross-origin by default |
| 21:09 | <annevk> | singling out fonts is silly |
| 21:09 | <roc> | no it's not, see above |
| 21:09 | <annevk> | XHR is reading data |
| 21:09 | <annevk> | fonts is like images |
| 21:09 | <annevk> | and scripts |
| 21:10 | <annevk> | you cannot read the data, just use it |
| 21:10 | <roc> | it's "cross origin by default" when you "embed" a resource instead of "reading" it, which it turns out is a rather slippery distinction in the presence of cssText etc |
| 21:10 | <jcranmer> | you might be able to pixel-hunt images |
| 21:10 | <annevk> | and we're gonna have CORS for images, to enable not getting <canvas> tainted |
| 21:10 | <annevk> | same would apply with fonts |
| 21:10 | <Ms2ger> | AryehGregor, gave you access to the data repo too, I forgot earlier |
| 21:12 | <annevk> | i gotta go |
| 21:12 | <annevk> | maybe later tonight |
| 21:12 | <AryehGregor> | Ms2ger, oh, okay, thanks. |
| 21:13 | <AryehGregor> | I'll update that at some point, then. |
| 21:13 | <Ms2ger> | Would be nice ;) |
| 21:14 | <roc> | this "embedding" vs "reading" distinction actually constrains our API design, because we have to make sure that we minimize data leakage from resources that are only "embeddable", not "readable" |
| 21:14 | <roc> | are there any genuine use-cases for resources being "embeddable but not readable", other than legacy content? |
| 21:14 | <annevk> | yes, all our APIs do that |
| 21:15 | <othermaciej> | roc: thinking about it more, it seems like a possibly useful state to be able to allow cross-site embedding, but not cross-site reading |
| 21:15 | <roc> | othermaciej: maybe; what are the use-cases? |
| 21:15 | <othermaciej> | I'm not sure that's necessarily true for fonts, but it seems clearly true for non-font resources |
| 21:15 | <roc> | how about images? |
| 21:16 | <roc> | scripts? css? (note that CSS isn't really supported, because cssText exists --- do authors resent that?) |
| 21:16 | <TabAtkins> | I don't really see any author caring about the distinction between their resources being downloaded for an embed vs for a read. |
| 21:17 | <othermaciej> | we allow image embedding but not image reading by default |
| 21:17 | <roc> | for legacy reasons |
| 21:17 | <othermaciej> | and I think most would agree we can't change either of those defaults |
| 21:17 | <TabAtkins> | roc: imxp, no one cares about cssText allowing reading of CSS. |
| 21:17 | <roc> | othermaciej: I agree, of course |
| 21:18 | <othermaciej> | so it seems that a priori it must be a useful state |
| 21:18 | <roc> | othermaciej: the point is, are we carrying this "embedding vs reading" distinction forward into new resource types just for the sake of consistency with legacy stuff? Or are there genuine use-cases for it? |
| 21:18 | <erlehmann> | roc, what is your problem with canvas tainting? do you see dom tainting coming? ;) |
| 21:18 | <roc> | it's complexity |
| 21:18 | <roc> | it surprises authors |
| 21:18 | <TabAtkins> | erlehmann: canvas tainting is similar to xorigin iframes being limited. |
| 21:19 | <roc> | as far as I know, it has not real purpose other than working around a mistake in the design of the Web |
| 21:19 | <erlehmann> | for me, as an author, it took some time to figure out to do embedding <video> correctly. also, i had to lecture people on it. |
| 21:19 | <roc> | othermaciej: I don't think distinguishing "embedding" from "reading" for images was a conscious design decision |
| 21:19 | <erlehmann> | even people who had worked with XHR before. |
| 21:20 | <othermaciej> | my tentative position is that if we can't eliminate the distinction, it's better to be consistent about it |
| 21:20 | <roc> | originally, there was only embedding, and cross-origin loads were allowed because, hey why not? The problems we were going to have were not understood at the time |
| 21:21 | <roc> | later we wanted to add the ability to read, and then we realized that cross-origin reading is bad, so we had to create a distinction |
| 21:21 | <othermaciej> | besides embedding and reading, there is also linking |
| 21:21 | <othermaciej> | I'm guessing we don't want to give an easy client-side way to prevent cross-origin linking, though servers can make a vague semi-effective attempt at it server-side |
| 21:21 | <TabAtkins> | I believe free xorigin linking is a Good Thing, at least. |
| 21:22 | <othermaciej> | embedding seems to be intermediate between reading and linking, to me |
| 21:22 | <roc> | so do I |
| 21:22 | <erlehmann> | preventing cross-origin linking, haha. that would lead to even more fuckuppery. |
| 21:23 | <Hixie> | AryehGregor: thanks |
| 21:23 | <erlehmann> | othermaciej, funny enough, at least the german justice system distinguishes between embedding or linking to resources (IANAL) |
| 21:24 | <roc> | if we don't have actual use-cases for distinguishing embedding vs reading, I think propagating it forward into new resource types for the sake of consistency is a mistake |
| 21:24 | <erlehmann> | roc, embedding is different because usually it does not leak information. amirite? |
| 21:24 | <othermaciej> | well, it applies to most existing resource types, which are also by far the most common resource types |
| 21:24 | <erlehmann> | or rather, it should not. |
| 21:24 | <roc> | I mean, should we taint the canvas when we draw glyphs from a cross-origin font? |
| 21:25 | <othermaciej> | I don't think it reduces cognitive load to make it different for new resource types |
| 21:25 | <roc> | if we add the ability to extract path data from a font, should that be conditional on the origin? |
| 21:25 | <roc> | or do we have to decide right now that no-one will ever have sensitive data in a font? |
| 21:25 | <erlehmann> | roc, why not? it prevents data-spills. |
| 21:26 | <roc> | if we do make it conditional, I'm very confident that authors will trip over it and be surprised |
| 21:27 | <erlehmann> | roc, authors are surprised already with tainted canvases. |
| 21:27 | <roc> | exactly |
| 21:27 | <erlehmann> | so better keep that consistent. |
| 21:27 | <roc> | no! :-) |
| 21:27 | <erlehmann> | the second time something cross-origin paints on the canvas, no one will be surprised. |
| 21:28 | <roc> | You also have to decide where to draw the line |
| 21:28 | <erlehmann> | but if you make it into a lookup table what can be done and what cannot, it *will* surprise people. |
| 21:28 | <erlehmann> | you are mixing unexpected behaviour with not-so-easy-to-work-with behaviour? |
| 21:28 | <roc> | do you expose font tables? |
| 21:28 | <roc> | glyph metrics? |
| 21:29 | <roc> | this is because the distinction between "embedding" and "reading" is artificial as noted above |
| 21:29 | <erlehmann> | roc, why can't the line for cross-origin be “default deny” |
| 21:29 | <erlehmann> | roc, embedding should not leak data. reading should. |
| 21:29 | <roc> | everything leaks data |
| 21:29 | <roc> | <img> leaks the image size |
| 21:29 | <roc> | canvas.measureText leaks font data |
| 21:31 | <erlehmann> | so embedding should leak the least amount of data. reading should leak the maximum amount. |
| 21:31 | <erlehmann> | “some X are Y, so every X should be Y” is not really an argument. |
| 21:31 | <roc> | trying to preserve an embedding vs reading distinction forces us to decide early, for all time, exactly where we want to draw that artificial line, and creates crazy security requirements for Web authors like "don't correlate sensitive information with the size of an image on your intranet" |
| 21:31 | <erlehmann> | neither is “all X are to some extent Y, so all X should be Y to full extent” |
| 21:34 | <roc> | I'm not saying a line can't be drawn. It can, we do for images. The problem is that it's arbitrary, it creates strange requirements, authors won't understand it, and worst of all there are not real use-cases , it's just for legacy content |
| 21:36 | <othermaciej> | if we think fonts can't contain sensitive information, we could just say that when you're allowed to embed, you're allowed to read, and then we only need to solve the "prevent embedding" problem, ideally in a way that is consistent with other resource types, which also seem to need this feature |
| 21:36 | <roc> | right |
| 21:36 | AryehGregor | has suddenly realized that his approach to speccing this doesn't work at all for whitespace trimming . . . hmm, will need to rethink |
| 21:36 | <roc> | but if we say there's no distinction between embedding and reading, *and* font loads are cross-origin by default, then we're effectively deciding right now that fonts will never contain sensitive information |
| 21:37 | <roc> | that feels like a very big call to me |
| 21:37 | <othermaciej> | it seems to me a Limit-Embedding-To-Origins: header (or whatever) could solve the problem in a consistent way for everything |
| 21:38 | <roc> | it would help, but it doesn't solve the problems I've just been talking about |
| 21:39 | <othermaciej> | well, it would help with the problem of hotlinking of legacy resource types |
| 21:39 | <othermaciej> | then the question would be, should fonts adopt a different model instead? |
| 21:39 | <roc> | an hour ago I would have said "I don't know", but now I'm thinking "yes" |
| 21:46 | <erlehmann> | hhnnnnng. just saying. |
| 21:46 | <TabAtkins> | othermaciej: By "different model", do you mean SOR+CORS, or the LETO you strawmanned, or what? |
| 21:47 | <othermaciej> | TabAtkins: I don't know what LETO is |
| 21:47 | <TabAtkins> | Limit-Embedding-To-Origins |
| 21:47 | <othermaciej> | my strawman proposal is to apply that to all resource types, and not make fonts different |
| 21:48 | <TabAtkins> | Okay, that's what I was trying to determine. I couldnt' quite tell what you were trying to say |
| 21:48 | <othermaciej> | roc would probably say even if we have that for all other resource types, fonts should be different |
| 21:48 | <roc> | well, new resources in general |
| 21:48 | <othermaciej> | (presumably still restricted to same-origin embedding by default, with CORS to opt out, so you can enable cross-site embedding by also enabling cross-site reading) |
| 21:49 | <roc> | yes |
| 21:49 | <othermaciej> | I am thinking it would probably have to be new embedding contexts as opposed to resource types |
| 21:49 | <roc> | unless we come up with use-cases for a distinction between reading and embedding, of course |
| 21:49 | <roc> | and a good way to define them! |
| 21:49 | <othermaciej> | since for instance PDF in an <iframe> should follow same rules as HTML in an iframe |
| 21:49 | <roc> | yes, I meant new categories |
| 21:50 | <othermaciej> | I think new resource types with a new embedding context come along rarely |
| 21:50 | <othermaciej> | one problem with the WOFF requirement is that it's tied to the format, not the embedding context |
| 21:52 | <roc> | hard to predict |
| 21:55 | <TabAtkins> | Right, that's probably an architectural mistake. |
| 21:58 | <roc> | this has been a stimulating discussion, thanks othermaciej |
| 21:59 | <othermaciej> | roc: thanks to you too |
| 21:59 | <othermaciej> | best discussion I've had on this topic so far |
| 22:00 | zcorpan | hasn't been following |
| 22:00 | <zcorpan> | what's the conclusion? |
| 22:01 | <roc> | I concluded that I was more right than I thought |
| 22:01 | <roc> | hey, it was an Internet discussion, what did you expect? |
| 22:02 | <roc> | alright, gotta catch a bus |
| 22:02 | <zcorpan> | "arguing on the internet..."? |
| 22:05 | zcorpan | realizes that a graphical password on a touch device is pretty useless unless you clean the screen every time |
| 22:06 | <zcorpan> | finger print to unlock would be better |
| 22:09 | <TabAtkins> | finger print works pretty good imxp. My wife's computer has that for the windows unlock, and it reliably reads my fingers (and doesn't read the fingers I don't have stored) |
| 22:10 | <zcorpan> | i guess there are no smartphones with finger print support yet |
| 22:11 | <TabAtkins> | Even better is a thermal camera that can read faceprints. My university was working on that. |
| 22:11 | <zcorpan> | can't that be fooled by holding up a picture in front of the phone? |
| 22:11 | <TabAtkins> | No, it uses thermal to read your face capillaries. |
| 22:12 | <TabAtkins> | Apparently they are highly uniquifying, and easy to read. |
| 22:12 | <zcorpan> | interesting |
| 22:12 | <Philip`> | Doesn't sound like it'll work well for zombies |
| 22:13 | <TabAtkins> | I consider discrimination against zombies justified. |
| 23:23 | <AryehGregor> | lol, so Bing copies Google search results. |