| 00:15 | <jamesr> | Hixie: free fo rlunch? |
| 00:15 | <Hixie> | sure |
| 00:15 | <jamesr> | (i'm at a talk currently) |
| 00:19 | <zewt> | that sounded like "free for lunch? well I'm not" :P |
| 01:03 | <jamesr> | Hixie: so just to be clear, we are trying to support users or user-agents who support canvas 2d context, support javascript, but do not support CSS? |
| 01:03 | <Hixie> | you should be able to turn CSS off, or have a user style sheet, or have a custom UA-provided style sheet, and still use the Web, yes. |
| 01:03 | <Hixie> | that's part of the premise of CSS |
| 01:05 | <jamesr> | AX agents use a lot of cues from CSS |
| 01:06 | <Hixie> | legacy AX agents more or less uniformly suck. |
| 01:06 | <jamesr> | but i guess it is on authors to make it work |
| 01:06 | <jamesr> | none will, of course |
| 04:30 | <heycam> | if I want to treat some latin text as if it were some rtl language text (for layout), is putting "direction:rtl; unicode-bidi:bidi-override" on it the right thing to do? |
| 06:39 | <Akilo> | hi |
| 09:00 | <hsivonen> | I'm aware that html5.validator.nu is down. I'm working on getting it back. |
| 09:01 | jgraham | wonders if people have started worrying about text editors created using WebGL yet |
| 09:03 | <tw2113> | hadn't seen anyone mention it hsivonen |
| 09:03 | <tw2113> | but good to know |
| 09:04 | <zcorpan> | hsivonen: OMG! i need html5.validator.nu RIGHT NOW!!1 |
| 09:05 | <hsivonen> | zcorpan: thugbot is already worried |
| 09:07 | <MikeSmith> | hsivonen: my annoybot is going to report that every 10 minutes until it's back |
| 09:07 | <MikeSmith> | if it's too annoying, lemme know and I can turn it off |
| 09:07 | <hsivonen> | MikeSmith: not too annoying |
| 09:07 | <MikeSmith> | k |
| 09:08 | <hsivonen> | and it's back |
| 09:08 | <hsivonen> | with warnings for comments before doctype |
| 09:09 | <hsivonen> | also a bunch of stuff from MikeSmith and the stuff I did yesterday |
| 09:09 | <MikeSmith> | oh cool |
| 09:10 | <MikeSmith> | hsivonen: you redeployed validator.nu also? |
| 09:10 | <hsivonen> | MikeSmith: yes |
| 09:10 | <MikeSmith> | cool |
| 09:11 | <MikeSmith> | so I will redeploy the HTML5 backend on validator.w3.org as well |
| 09:15 | <MikeSmith> | hmm |
| 09:15 | <MikeSmith> | [[ |
| 09:15 | <MikeSmith> | File "build/build.py", line 648, in fetchUrlTo |
| 09:15 | <MikeSmith> | f = urllib2.urlopen(url, timeout=httpTimeoutSeconds) |
| 09:15 | <MikeSmith> | TypeError: urlopen() got an unexpected keyword argument 'timeout' |
| 09:15 | <MikeSmith> | ]] |
| 09:15 | <MikeSmith> | guess I need to update some urllib |
| 09:16 | <zcorpan> | Warning: Comments seen before doctype. Internet Explorer will go into the quirks mode. |
| 09:16 | <zcorpan> | From line 1, column 1; to line 1, column 21 |
| 09:16 | <zcorpan> | <?xml version="1.0"?><!DOCT |
| 09:16 | <zcorpan> | i guess that's ok; it's true for ie6 anyway |
| 09:18 | <hsivonen> | zcorpan: good point. The tree builder doesn't know that the comment was a particular kind of bogus comment |
| 09:18 | <hsivonen> | zcorpan: but yeah, true for IE6 |
| 09:20 | <MikeSmith> | "the timeout argument to urllib2.urlopen was introduced with Python 2.6" |
| 09:33 | <MikeSmith> | hsivonen: if you could please do a quick review |
| 09:33 | <MikeSmith> | build.py fix for the urllib timeout issue |
| 09:33 | <MikeSmith> | https://gist.github.com/976161 |
| 09:37 | <MikeSmith> | I should have tested dude's patch with older python |
| 09:37 | <MikeSmith> | I'm sure there are a lot of people still using python 2.5 |
| 09:37 | <MikeSmith> | I think Debian stable is still at python 2.5 |
| 09:37 | <MikeSmith> | for one thing |
| 10:07 | <hsivonen> | MikeSmith: did you start the rel implementation? |
| 10:07 | <hsivonen> | MikeSmith: my plan is to do it today with hard-coded lists that can be updated manually |
| 10:10 | <hsivonen> | hmm. the page on the microformats wiki doesn't have any extensions registered in a format that conforms to the registration requirements |
| 10:11 | <hsivonen> | I guess I'll have to implement things strictly in order to draw proper attention to this |
| 10:32 | <hsivonen> | "Except where otherwise specified, a keyword must not be specified more than once per rel attribute." |
| 10:33 | <hsivonen> | are there any keywords that are "otherwise specified" to be allowed to appear more than once per rel attribute? |
| 10:34 | <jgraham> | At one point there was the up up up stuff or something wasn't there? |
| 10:34 | <jgraham> | Did that die? |
| 10:35 | <MikeSmith> | hsivonen: I did not start on rel yet |
| 10:35 | <MikeSmith> | so please go ahead |
| 10:36 | <MikeSmith> | hsivonen: what registration requirements? |
| 10:36 | <bga_> | http://bellard.org/jslinux/ |
| 10:37 | <MikeSmith> | hsivonen: the microformats wiki itself has not registration requirements, as far as I can see |
| 10:37 | <MikeSmith> | if you mean the requirements in the spec, I already filed a spec bug about that |
| 10:37 | <MikeSmith> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=12613 |
| 10:38 | <MikeSmith> | "spec guidance on adding new link types to the microformats wiki page does not match the format of that wiki page" |
| 10:41 | <MikeSmith> | hsivonen: also please lemme know if it's OK with you if I commit https://gist.github.com/976161 |
| 10:42 | <MikeSmith> | I tested it in a python 2.5 environment and it seems to work as expected |
| 10:45 | <hsivonen> | MikeSmith: I mean the observation that you filed a bug about |
| 10:46 | <MikeSmith> | hsivonen: OK |
| 10:46 | <MikeSmith> | I think that language matched the format of the WHATWG wiki rel-extensions page |
| 10:47 | <MikeSmith> | but has not been changed yet to match the format of the microformats wiki |
| 10:48 | <MikeSmith> | oh |
| 10:48 | <MikeSmith> | I realize filed two bugs on this |
| 10:49 | <MikeSmith> | the one I meant was http://www.w3.org/Bugs/Public/show_bug.cgi?id=12612 |
| 10:49 | <MikeSmith> | anyway, as I mention in the bug description, I'd suggest not making the spec try to make the wiki closely but instead just have the spec say, "Any rel value listed on the |
| 10:49 | <MikeSmith> | Microformats wiki existing-rel-values page must be accepted unless that page explicitly states it must not be used." |
| 10:57 | <hsivonen> | MikeSmith: I'm not sure that's a good idea. The microformat wiki lists some stuff that appears to be brainstorming or repeating HTML4 instead of intending to be valid extensions |
| 10:59 | <MikeSmith> | yeah, they definitely need to do some work on that page to make more clear what is supposed to be considered "registered" and what's not |
| 11:00 | <hsivonen> | MikeSmith: I'd prefer everything that gets imported from microformats.org to be affirmatively marked by someone as "I intended this to be considered a valid extension for HTML5" |
| 11:00 | <hsivonen> | with an annotation that says if it is valid on <link> and/or <a>/<area> |
| 11:00 | <MikeSmith> | that would be nice, yeah |
| 11:01 | <hsivonen> | I think I'm not going to import anything from the wiki that doesn't have the <link> vs. <a>/<area> stuff in order |
| 11:01 | <MikeSmith> | sounds right to me |
| 11:01 | <MikeSmith> | maybe hober can help out with work on updates to that page |
| 11:05 | <hsivonen> | do I understand correctly that rel values with a colon in them have to be registered, too? |
| 11:05 | <hsivonen> | so a colon doesn't sprinkly magic "I'm distributed and don't need to register" pixie dust? |
| 11:05 | <hsivonen> | and just makes the comparison case-sensitive |
| 13:12 | <achshar> | why cant i play local audio files with audio tag? |
| 13:12 | <zcorpan> | which browser? |
| 13:12 | <achshar> | chrome |
| 13:12 | <achshar> | canary |
| 13:12 | <zcorpan> | same reason you can't do anythign else locally in chrome |
| 13:13 | <zcorpan> | i'd guess |
| 13:13 | <achshar> | hmm so its impossible? |
| 13:13 | <zcorpan> | although audio doesn't have same-origin restriction in general, so could be something else |
| 13:13 | <achshar> | :O |
| 13:13 | <achshar> | well never mind.. |
| 13:14 | <achshar> | thanks :) |
| 13:14 | <zcorpan> | try to lift the file: same-origin restriction with some command-line flag |
| 13:14 | <zcorpan> | see if that helps |
| 13:14 | <achshar> | hmm how can i do that? |
| 13:14 | <zcorpan> | don't remember, google for it |
| 13:14 | <achshar> | ohkzz |
| 13:16 | <achshar> | zcorpan: oh and also, is it possible to get a file's path when selected from input type file? |
| 13:16 | <zcorpan> | no |
| 13:17 | <achshar> | damn.. i guess that would be because of some security problem :( |
| 13:17 | <zcorpan> | privacy |
| 13:17 | <achshar> | hmm |
| 13:18 | <achshar> | well thanks alot :D |
| 13:18 | <zcorpan> | np |
| 13:19 | <achshar> | ok last tid bid.. am trying to play a local audio file through html5 audio tag.. user either drags the mp3 file or selects from input type file.. |
| 13:19 | <achshar> | can you give any idea as to how do i cange user's input to audio's source? |
| 13:20 | <zcorpan> | oh i thought you were doing <audio src="file:..."> |
| 13:21 | <achshar> | i was doing that only but it dosent work.. |
| 13:21 | <achshar> | it was a proof of concept |
| 13:21 | <zcorpan> | ok |
| 13:21 | <achshar> | that audio can play audio files but as it turns out chrome dosent |
| 13:22 | <achshar> | one way is to use dataurls but they become very very long and cannot be stored in websql :(((((( |
| 13:22 | <zcorpan> | input.onchange = function(e) { var file = input.files[0]; var url = URL.createObjectURL(file); audio.src = url } |
| 13:22 | <zcorpan> | or something like that |
| 13:23 | <achshar> | ohkeexxx let me check that out.. :D :D |
| 13:27 | <achshar> | what is 'URL.'? where does URL come from? |
| 13:28 | <zcorpan> | it's defined in abarth's url spec iirc |
| 13:29 | <achshar> | oh okieee |
| 13:32 | <achshar> | http://pastebin.com/L6wqXdMK |
| 13:32 | <achshar> | it gives URL undefined |
| 13:37 | <zcorpan> | seems like it's prefixed |
| 13:37 | <zcorpan> | webkitURL |
| 13:38 | <zcorpan> | use revokeObjectURL() when you don't need the url anymore |
| 13:39 | <achshar> | HOLLY COW IT WORKS! |
| 13:39 | <achshar> | thanks a ton |
| 13:39 | <achshar> | but can i store this url to websql for later use? |
| 13:39 | <achshar> | like after a browser restart? |
| 13:41 | <zcorpan> | dunno |
| 13:41 | <achshar> | actualy i wanted to make playlists |
| 13:41 | <achshar> | but hey this far is far enough.. this is awsone.. thanks alot for you help :D |
| 13:41 | <zcorpan> | welcome |
| 13:42 | <achshar> | cya |
| 14:20 | <achshar> | i have an arrayBuffer which contains a mp3 file.. how do i play it with audio tag? any ideas? |
| 14:21 | <hsivonen> | achshar: you can't. in a cross-browser way |
| 14:21 | <hsivonen> | achshar: in Firefox, you can supply your own MP3 decoder in JavaScript and send the decompressed audio to the Audio API |
| 14:22 | <hsivonen> | achshar: in Safari, you can encode the bytes into a data: URL and use that as the source of an <audio> element |
| 14:22 | <achshar> | oh.. i am mamking an app for chrome.. so it will always be open in chrome |
| 14:22 | <hsivonen> | making browser-specific apps instead of Web apps sucks, though |
| 14:23 | <achshar> | anything for chrome? i guess it will be same as safari.. right? |
| 14:23 | <achshar> | no its kind of a local app |
| 14:23 | <achshar> | for chrome OS |
| 14:23 | <hsivonen> | achshar: Chrome can play MP3 from a data: URL at least for the time being |
| 14:23 | <achshar> | yup it can |
| 14:23 | <hsivonen> | it's unclear if the announcement to drop H.264 has any effect on encumbered audio codecs |
| 14:24 | <achshar> | but i want to store thme in websql for later use |
| 14:24 | <hsivonen> | also, Chrome has had some activity around an audio API, but I don't know what the status is |
| 14:24 | <achshar> | like after a browser restart |
| 14:25 | <achshar> | hmm audio api is beta and user would have to go to about:flags to activate it |
| 14:25 | <achshar> | data: urls are quiet heavy and websql qont save them |
| 14:28 | <achshar> | any solution to have mp3s between page loads..? |
| 14:30 | <MikeSmith> | achshar: fwiw, there are at least a couple of JS libraries that abstract away the differences between the audio API implemented in Chrome and the audio API implemented in Firefox |
| 14:31 | <achshar> | hmm can any of those libraries save mp3s bteween page loads? |
| 14:31 | <MikeSmith> | achshar: dunno, sorry |
| 14:31 | <achshar> | hmm np.. :) |
| 14:32 | <achshar> | oh do you happen to know why websql wont save large data urls? |
| 14:32 | <MikeSmith> | asking on the public-audio mailing list might be a good way to find out |
| 14:32 | <MikeSmith> | http://lists.w3.org/Archives/Public/public-audio/ |
| 14:33 | <MikeSmith> | achshar, dunno about that either, but websql is also not a cross-browser technology |
| 14:33 | <MikeSmith> | it's not implemented in Firefox and never will be |
| 14:33 | <MikeSmith> | nor in IE |
| 14:33 | <achshar> | hmma as i said it only has to work in chrome :) |
| 14:33 | <achshar> | it is a packaged app |
| 14:35 | <MikeSmith> | achshar: then I guess you probably want to ask on a chrome-specific mailing list |
| 14:35 | <MikeSmith> | or some other chrome-specific forum |
| 14:35 | <MikeSmith> | maybe the #chromium-support channel |
| 14:36 | <achshar> | hmm they never reply |
| 14:36 | <achshar> | some ego problem with #chromium and #chromium-extension does nto have alot of memenrs |
| 14:36 | <MikeSmith> | ego problem? |
| 14:37 | <achshar> | yup.. #chromium's topic says 'this is *not* a support channel' so i guess they like to keep it for the devs only :( |
| 14:37 | <MikeSmith> | anyway, most often the reason you don't get an answer is that nobody on the channel actually knows the answer |
| 14:38 | <achshar> | :O |
| 14:38 | <achshar> | i doubt nobody of 100 ppl on chromium's channel wond know a chromium question :P |
| 14:39 | <achshar> | wel.. gtg.. cya and thanks again for your help :) |
| 14:40 | <erlehmann> | after just now reading a post on webGL and shaders, my layman's question … is webGL secure in any way? |
| 14:42 | <Philip`> | erlehmann: It's secure in lots of ways |
| 14:42 | <Philip`> | Probably the more important question is whether it's secure in every way |
| 14:44 | <erlehmann> | Philip`, http://translate.google.com/translate?hl=en&sl=de&tl=en&u=http%3A%2F%2Fblog.fefe.de%2F%3Fts%3Db32cb04e |
| 14:44 | <erlehmann> | this is the post i just read. |
| 14:44 | <erlehmann> | on one hand, felix von leitner apparently gets paid for security stuff™. OTOH, his web server cannot into range requests. |
| 14:45 | <erlehmann> | i don't remember enough from university courses to grok if his analysis is legit. |
| 14:48 | <Philip`> | Maybe I don't understand the poor translated text well enough, but it doesn't seem to make sense |
| 14:48 | <Philip`> | GPUs have access to lots of system resources, but so do CPUs, and you just have to avoid running arbitrary unrestricted code on them |
| 14:49 | <erlehmann> | Philip`, he says that GPU do not have MMU protection and reasons that therefore WebGL is dangerous. |
| 14:49 | <Philip`> | e.g. WebGL only allows you to write GLSL, which can't read system memory because the language has no functionality for that |
| 14:50 | <erlehmann> | and from a security standpoind, code without memory protection should be regarded as owning the system |
| 14:50 | <Philip`> | and implementations have shader validators to try to restrict you to a safe subset of GLSL |
| 14:50 | <Philip`> | to discourage infinite loops etc |
| 14:51 | <erlehmann> | i see a halting problem -_-* |
| 14:51 | <Philip`> | It's trivial to guarantee halting - just don't allow any loops except over finite constants |
| 14:53 | <erlehmann> | i am thinking maybe one should respond to von leitners post. he possibly the most-read tech blogger of germany, even without any CSS on his page. |
| 14:54 | <zcorpan> | foolip: how about always queueing events (at most one event per event type and element) until there's a listener registered? |
| 14:55 | <foolip> | zcorpan, what about scripts that try to do the right thing by looking at readyState/networkState and thus don't expect the event to be fired after attaching the event listener? |
| 14:56 | <erlehmann> | Philip`, are GLSL exploits feasible? i mean, if you can spray the heap in javascript … |
| 14:56 | <zcorpan> | foolip: good point |
| 14:56 | <MikeSmith> | hsivonen: sent you the build patch by e-mail for review |
| 14:57 | <zcorpan> | foolip: that's a conflicting requirement |
| 14:57 | <foolip> | zcorpan, I think it's going to be difficult to make it simultaneously work (and be sane) for those two cases, yes |
| 14:57 | <MikeSmith> | hsivonen: I'm going to go ahead and manually apply it now in the validator.w3.org backends |
| 14:58 | <foolip> | one could of course pile up more logic to avoid refiring events in certain cases, but it seems terribly messy |
| 14:58 | <MikeSmith> | hsivonen: and I can tweak it later if you see anything that seems to need changing |
| 14:58 | <zcorpan> | yeah, chances are that the api will be even worse if we try to be smart here |
| 14:58 | <foolip> | I think a solution that only fakes the state until the first time a script tries to look at it might work, but if native controls are implemented by scripts, then that's also messy |
| 14:59 | <Philip`> | erlehmann: GLSL has no memory allocation or pointers etc, so any exploits are more likely to be related to bugs in the browser's binding or in the graphics drivers |
| 14:59 | <foolip> | no brilliant ideas from me, yet |
| 14:59 | <erlehmann> | Philip`, oh. seems i have to look it up some time. |
| 15:02 | <hsivonen> | MikeSmith: rs=hsivonen on the patch |
| 15:02 | <MikeSmith> | sweet |
| 15:02 | <MikeSmith> | hsivonen: thanks |
| 15:03 | <Philip`> | erlehmann: http://mew.cx/glsl_quickref.pdf is most of the API exposed to GLSL programs |
| 15:08 | <erlehmann> | Philip`, thank you. last question: if a WebGL browser is exploited, is there any layer of security preventing upload of malicious shaders to the GPU? a shim or something? |
| 15:09 | <Philip`> | I have no idea what you mean |
| 15:13 | <erlehmann> | Philip`, My probably broken understanding is that any 3D program that can do arbitrary shaders can manipulate system memory, am I wrong? |
| 15:14 | <erlehmann> | And you told me that WebGL does not allow arbitrary shaders, which comforts me. |
| 15:14 | <erlehmann> | Oh wait. |
| 15:15 | <erlehmann> | Ignore what I just said. |
| 15:15 | <erlehmann> | I am asserting the opposite. :3 |
| 15:15 | <Philip`> | GLSL shaders can't manipulate system memory (though they can sometimes hang the system) |
| 15:15 | <Philip`> | (Stuff like CUDA/OpenCL might be able to - I don't really know anything about that) |
| 15:17 | <erlehmann> | Philip`, I was thinking of “arbitrary shaders” in terms of “writing shaders in assembly or stuff”. Then it hit me that you mentioned GLSL. |
| 15:17 | <Philip`> | As far as I'm aware (which isn't far), browsers add an extra layer (typically via ANGLE) to avoid some of those hangs, and also to validate shaders more strictly than drivers tend to |
| 15:18 | <Philip`> | There is a shader assembly language but that's even less powerful than GLSL :-) |
| 15:18 | <erlehmann> | The more you know! |
| 15:19 | <Philip`> | I expect the low-level machine code executed on GPUs changes far too often for any applications to rely on, so drivers only expose higher-level languages (GLSL, ARB assembly, CUDA, etc) |
| 15:19 | <erlehmann> | Well, it makes it cross-platform, too. |
| 15:23 | <Philip`> | Yeah, and every generation of hardware by a single vendor is effectively a separate platform |
| 15:24 | <Philip`> | They don't want applications tied so tightly to GeForce 9 that they can't sell people a GeForce 10 with a totally different internal architecture |
| 15:25 | <Philip`> | and it's just a fortunate coincidence that that led them to support high-level languages (GLSL etc) that can also provide adequate security properties when running untrusted code from the web |
| 15:26 | <Philip`> | (Consoles provide more low-level GPU access since they're a fixed platform and portability is irrelevant) |
| 15:40 | <sephr> | Hixie: under 7.5.1.3 Security and privacy, is this intended? |
| 15:40 | <sephr> | Leaking secure URLs. User agents should not send HTTPS URLs to third-party sites registered as content handlers, in the same way that user agents do not send Referer (sic) HTTP headers from secure sites to third-party sites. |
| 15:40 | <sephr> | because I think that's wrong |
| 15:40 | <sephr> | as long as the content handler also uses https it shouldn't matter |
| 15:41 | <sephr> | and afaik the Referer header *is* sent from https domain a->https domain b |
| 15:49 | <MikeSmith> | validator.w3.org HTML5 backends now synched up to latest validator.nu sources |
| 16:19 | <MikeSmith> | zcorpan: should we make you the default assignee for bugs against the diffs doc? |
| 16:19 | <MikeSmith> | in bugzilla, I mean |
| 16:22 | <zcorpan> | MikeSmith: if you like, wfm either way |
| 16:24 | <MikeSmith> | all right |
| 16:24 | <MikeSmith> | no turning back now |
| 16:25 | <MikeSmith> | you are now the default assignee |
| 16:25 | <MikeSmith> | at least until the triumphant return of Anne |
| 16:25 | <MikeSmith> | at which time, I recommend you two have a knife fight to decide who gets to be the default assignee |
| 16:28 | <zcorpan> | MikeSmith: should the component name change too? |
| 16:28 | <MikeSmith> | dunno |
| 16:29 | <MikeSmith> | what do? |
| 16:29 | <MikeSmith> | what to? |
| 16:29 | <zcorpan> | ... (editor: Simon Pieters) |
| 16:31 | <zcorpan> | (or list both, although i think anne might not be an active editor for it anymore) |
| 16:32 | <MikeSmith> | ah |
| 16:32 | <MikeSmith> | I think if I change that it'll break some stuff |
| 16:32 | <zcorpan> | ok |
| 16:32 | <zcorpan> | then leave it :) |
| 16:33 | <zcorpan> | come to think of it it'd at least break a link in the draft itself |
| 16:33 | <MikeSmith> | OK |
| 16:33 | <MikeSmith> | I can ask Hixie if it'll break his stuff |
| 18:54 | <TabAtkins> | The ease with which Google properties integrate translation is humbling. We are mere years from translation tech being ubiquitous, to the point where I could visit a foreign country and get along without any language knowledge. |
| 19:25 | <zewt> | well, maybe a European country; Asia, not so much ... |
| 19:26 | <zewt> | CJK machine translations are still borderline useless |
| 19:26 | <zewt> | well, I know C/J are, not sure about K |
| 19:27 | <TabAtkins> | I get at least *some* use out of machine translations of Japanese. |
| 19:27 | <TabAtkins> | It's pretty bad, but I can usually get the gist of it. |
| 19:28 | <TabAtkins> | (I was trying to follow a discussion a few weeks ago on a japanese mailing list, so I have recent experience.) |
| 19:29 | <hober> | speaking of which, see you in a couple of weeks :) |
| 19:29 | <wilhelm> | Yes, Norwegian → English machine translations make sort of sense. Japanese → English, not at all. |
| 19:32 | <zewt> | google translations for french are pretty nuts: http://translate.google.com/translate?js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&sl=auto&tl=en&u=http%3A%2F%2Fwww.lemonde.fr%2Finternational%2Farticle%2F2010%2F12%2F01%2Fwikileaks-poutine-raille-la-democratie-americaine_1447695_3210.html |
| 19:34 | <TabAtkins> | That's a pretty decent translation, zewt. |
| 19:36 | <jamesr_> | Hixie, lunch? |
| 19:38 | <jamesr_> | Hixie, going to bigtable |
| 19:39 | <erlehmann> | TabAtkins, I actually once helped an italian guy to order food only using my android phone. Was a pretty interesting experience. |
| 19:40 | <erlehmann> | Whatever made him come into a German fast food place without the slightest knowledge of German or English was beyond my comprehension. |
| 19:41 | <TabAtkins> | Haha |
| 19:41 | <TabAtkins> | I once did tech-support for a spanish-speaker using only google translate. |
| 19:41 | <erlehmann> | Even Turkish may have worked. This is Berlin, after all. |
| 19:41 | <TabAtkins> | And a decent ear for transcription (a couple of spanish classes helped there). |
| 19:42 | <AryehGregor> | That translation from French is actually excellent. It's completely intelligible. |
| 19:42 | <AryehGregor> | I think English-Spanish also works really well. |
| 19:43 | <AryehGregor> | Less major languages, not so much. |
| 19:43 | <AryehGregor> | Although most of them are still semi-usable. |
| 19:44 | <wilhelm> | I've tried using Google Translate in conversations. It kind of works if you type the equivalent of baby language into it, but I've mostly found I'm better off with a dictionary. |
| 19:44 | AryehGregor | tries Google Translate on haaretz.co.il |
| 19:45 | <AryehGregor> | It gets confused by proper nouns. Like it translates ברק as "lightning" instead of "Barak" in some places. |
| 19:45 | <wilhelm> | We're decades away from having proper machine translations. That said, Google probably has the best tools to get us there. |
| 19:45 | <AryehGregor> | So "(we need) to investigate Barak" becomes "To explore the lightning". |
| 19:46 | <TabAtkins> | Random interesting experience: On Sunday, I and my brother (who is a Hebrew translator) were in line to enter the SoaD concert. Directly behind us in line were two native Israelis who now lived in SF, and who were talking in Hebrew. |
| 19:47 | <TabAtkins> | I told my brother to start a conversation with them. The first question they asked was "Are you Jewish?" The second was "Are you a spy?". |
| 19:49 | <AryehGregor> | A Hebrew translator? What sort of things does he translate? |
| 19:49 | <AryehGregor> | (it's kind of weird for non-Jews outside Israel to know Hebrew, yeah) |
| 19:50 | <TabAtkins> | He's a Navy translator. |
| 19:50 | <TabAtkins> | And given that he's part of the Office of Information Dominance, he's not really allowed to tell us what he translates. ^_^ |
| 19:51 | <AryehGregor> | Ah, interesting. |
| 19:51 | <AryehGregor> | The military is one place where there's a lot of demand for people who are very fluent in languages, but aren't native speakers. |
| 19:51 | <gsnedders> | "Office of Information Dominance" — what a euphemism… |
| 19:51 | <AryehGregor> | Clearly most Jews would not be so trustworthy to translate some things from Hebrew. |
| 19:52 | <AryehGregor> | (similarly, and probably more important, Arabs and Arabic) |
| 19:52 | <Philip`> | Maybe it's next door to the Office of Missile Obliteration |
| 19:54 | <TabAtkins> | Another interesting observation: Ordinarily, if my brother were to hear someone on the street speaking Hebrew in the military town he's based in, he wouldn't be allowed to talk to them, and is required to report them as possible spies. |
| 19:55 | <gsnedders> | WTF? |
| 19:55 | <AryehGregor> | That's on the military base itself? |
| 19:55 | <TabAtkins> | The base, and the surrounding town. |
| 19:55 | <AryehGregor> | Interesting. |
| 19:55 | <TabAtkins> | Same for any of the languages they teach there. |
| 19:55 | <AryehGregor> | Militaries can be pretty serious about this stuff. |
| 19:56 | <TabAtkins> | Too much risk of seemingly innocent small-talk actually being info-probes. |
| 19:56 | <gsnedders> | But isn't English a risk too? |
| 19:56 | <AryehGregor> | When my sister was in the Israeli Air Force, she told my mother what bases she was on. One time my mother looked up the base and found that it was believed to be one of the places where the Israelis kept their nuclear missiles. |
| 19:56 | <TabAtkins> | Everyone speaks English. Hearing someone speak Farsi or Hebrew, though, is much rarer if they're not part of the military. |
| 19:57 | <AryehGregor> | So my mother was having a phone conversation with my father and sister, and my mother said something like "So, I read that the base you're on is one of the ones with the nuclear missiles!" |
| 19:57 | <AryehGregor> | There was a long silence, and my father said "She probably can't talk about that." So my mother changed the topic of conversation and my sister pretended she had never said anything. |
| 19:58 | <AryehGregor> | Fun places, militaries. |
| 19:58 | <TabAtkins> | Yup. Haven't run into much like that yet, but I expect it'll happen more often as my brother advances. |
| 19:58 | <TabAtkins> | My other brother, on the other hand, should be leaving the Marines this year and returning to civilian life, so yay! |
| 19:59 | <AryehGregor> | Also, my sister said all Israeli soldiers are under strict orders that if they leave the country, they have to leave their uniforms and military ID and everything behind, and aren't allowed to tell anyone that they're soldiers if asked. |
| 19:59 | <AryehGregor> | Although that's probably particular to Israel, for obvious reasons. |
| 19:59 | <AryehGregor> | My sister told lots of fun military stories. |
| 20:00 | <TabAtkins> | Yeah, my bros don't have any such requirement. |
| 20:00 | <AryehGregor> | Because an Israeli soldier traveling in Europe or someplace might theoretically get put on trial for war crimes or something. |
| 20:02 | <AryehGregor> | Whereas America has the Hague Invasion Act: http://en.wikipedia.org/wiki/Hague_Invasion_Act |
| 20:02 | <TabAtkins> | Heh, interesting. Never hard of that. |
| 20:02 | <TabAtkins> | s/hard/heard/ |
| 20:03 | <AryehGregor> | (spoiler: that's not its official name) |
| 21:30 | <zcorpan> | http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx - now we just need to figure out which behavior makes most sense and spec it |
| 21:31 | <AryehGregor> | I was gonna send an e-mail to whatwg about that, yeah. |
| 21:31 | <AryehGregor> | Also post a comment on the blog post asking him why he didn't file a bug. |
| 21:35 | <AryehGregor> | Last time I pointed him to something in the HTML5 spec, he seemed to take it well. |
| 21:37 | <zcorpan> | about http->https and cross-domain, are there security/privacy considerations with the fragment? |
| 21:37 | <zcorpan> | or https->http |
| 21:38 | <AryehGregor> | http->https should be fine, surely? |
| 21:38 | <zcorpan> | yeah |
| 21:39 | <zcorpan> | http://a/#foo -> https://a/ -> http://b/ |
| 22:16 | <Hixie> | hsivonen: i don't think rel= with a colon is magic in any way currently in the html spec |
| 22:16 | <Hixie> | sephr: send mail |
| 22:16 | <Hixie> | zcorpan: so long as it's not affecting a component with "Hixie" it it I don't think component name changes will affect me |
| 22:17 | <jgraham> | Puting editor names in component names seems bad for this reason |
| 22:18 | <zcorpan> | yeah |
| 22:18 | <zcorpan> | not that i actually care |
| 22:19 | <zcorpan> | anyway, bedtime |
| 22:54 | <Hixie> | sicking: what do you think of having an attribute that enbles CORS use and then also controls whether or not the credentials are sent? |
| 22:54 | <Hixie> | <img src="http://images.example.com/"; cross-origin="with-authentication" alt="..."> |
| 22:55 | <Hixie> | vs <img src="http://images.example.com/"; cross-origin="without-authentication" alt="..."> |
| 22:55 | <Hixie> | the latter would be the default, so you could do: |
| 22:55 | <Hixie> | <img src="http://images.example.com/"; cross-origin alt="..."> |
| 22:55 | <Hixie> | maybe "with-credentials" and "without-credentials" rather than "authentication" |
| 22:55 | <Hixie> | or "use-credentials" and "anonymous" |
| 23:01 | <AryehGregor> | Maybe this is old news, but: http://bellard.org/jslinux/ |
| 23:02 | <Dashiva> | Yeah, that's so a few hours ago :P |
| 23:02 | <Dashiva> | Worth repeating, though |
| 23:04 | <gsnedders> | AryehGregor: According to hsivonen, doesn't work if you have big endian typed arrays. |
| 23:04 | <gsnedders> | :( |
| 23:04 | <AryehGregor> | Unsurprising. |
| 23:04 | <AryehGregor> | Can we just define them to always be little-endian already? |
| 23:05 | <gsnedders> | I'd rather we defined it one way or the other. Defining it to be little-endian means it's mainly embedded devices that'll have the conversion cost, which is sub-optimal… |
| 23:07 | <AryehGregor> | Lots of embedded devices are little-endian too. |
| 23:07 | <AryehGregor> | ARM can go either way. |
| 23:07 | <gsnedders> | ARM is de-facto little-endian nowadays |
| 23:08 | <gsnedders> | MIPS is the only arch for which browsers really ship on in any quantity where they ship big-endian builds (MIPS is bi-endian too) |
| 23:08 | <zewt> | which will happen first: computers converge on a single set of endianness, word size and newlines; or the world converges on a single spoken language |
| 23:09 | <gsnedders> | zewt: Endianness and word-size may happen in the not unforseeable future, at least |
| 23:12 | <zewt> | maybe--still talking decades, though |
| 23:12 | <zewt> | unless 32-bit systems are shoved out earlier than natural by OS vendors, which could happen |
| 23:24 | <Philip`> | Is there any reason anyone would build a big-endian system nowadays, unless they really need compatibility with some particular old big-endian system? |