| 00:06 | <AryehGregor> | Argh, MikeSmith disappeared again. |
| 00:08 | <Hixie> | he's travelling |
| 00:20 | <annevk> | hmm, roc thinks he's even more right than before? |
| 00:20 | <annevk> | that does not bode well |
| 00:21 | <annevk> | oh well |
| 00:21 | <annevk> | months ago I already resigned myself to being right in hindsight |
| 00:21 | <Hixie> | between you, roc, and myself (in private e-mail just now), i can't imagine why people think we're arrogant. :-P |
| 00:23 | <erlehmann> | TabAtkins, biometrics is fundamentally flawed. but you should know that. |
| 00:23 | <annevk> | Hixie, :) |
| 00:23 | <erlehmann> | zcorpan, use a hand-held keyfob token for your hand-held touch device ;) |
| 00:23 | <annevk> | btw, "Two Steps From Hell" makes some epic music |
| 00:29 | <annevk> | http://googleblog.blogspot.com/2011/02/microsofts-bing-uses-google-search.html -- doesn't Bing have negligible market share? I wonder why they care... |
| 00:29 | <AryehGregor> | No, they have substantial market share, because they're the default search in IE. |
| 00:29 | <AryehGregor> | They have negligible market share among people who actually chose their search engine and are not Microsoft employees. |
| 00:30 | <annevk> | The other thing though, Microsoft seems to be using the power of crowd serving and "the cloud". Playing the Google game... |
| 00:32 | <Rik`> | Google has negligible market share but they are growing pretty fast |
| 00:32 | <AryehGregor> | "Let input and position be the same variables as those of the same name in the algorithm that invoked these steps." That's annoyingly brittle. |
| 00:33 | <annevk> | And by Google you mean Bing, Rik`? |
| 00:33 | <Rik`> | yeah, it's been a long day and I've been celebrating too much :) |
| 00:33 | <annevk> | Time to say Happy Birthday? |
| 00:35 | <Rik`> | nah, just received a permanent job offer at Mozilla |
| 00:35 | <AryehGregor> | Congrats! |
| 00:35 | <AryehGregor> | What will the job be, specs or programming or something else? |
| 00:35 | <annevk> | Rik`, "just"? Sounds somewhat better :) |
| 00:36 | <Rik`> | I've been contracting for 6 months or so. First evangelism and then web dev. And now it's web dev for real :) |
| 00:36 | <Hixie> | grats! |
| 00:36 | <AryehGregor> | Ah, cool. So maintaining some part of the Mozilla website, or what? |
| 00:36 | <Rik`> | thanks everyone |
| 00:36 | <Rik`> | AryehGregor: yep, mostly mozilla.com |
| 00:36 | <AryehGregor> | annevk, I interpreted "just" as "just now", not "only". |
| 00:48 | <_uf02> | any senior PHP developers interested in a project? will be paying, msg me... |
| 00:49 | <AryehGregor> | Try ##php. |
| 00:49 | <_uf02> | php are all anti php ironically |
| 00:49 | <_uf02> | they're all ruby or python |
| 00:50 | <AryehGregor> | So are we! |
| 00:51 | <_uf02> | anti-php? so what are you pro ruby or what? |
| 00:51 | <_uf02> | if all devs are anti-php why is it the most used or most supported? |
| 00:51 | <Hixie> | not used by devs, maybe? :-) |
| 00:52 | <_uf02> | most developed shall I say. |
| 00:52 | <_uf02> | so what's best in your opinion |
| 00:54 | <Hixie> | best for what? |
| 00:54 | <_uf02> | there are several back-end languages, PHP, Ruby, etc.. |
| 00:55 | <AryehGregor> | PHP is best for administrators of large shared hosts. |
| 00:55 | <_uf02> | which one do you recommend? if it isn't php |
| 00:55 | <AryehGregor> | So all the large shared hosts use it. |
| 00:55 | <AryehGregor> | So all the big web apps are written for it, and all the newbie web developers with cheap shared hosting use it. |
| 00:55 | <AryehGregor> | As an actual language, it's horrible. It wins by appealing to shared hosts, not developers. |
| 00:56 | <annevk> | PHP is great for quick hacks |
| 00:56 | <Hixie> | _uf02: which i recommend depends entirely on what you want to do with it |
| 00:56 | <AryehGregor> | That said, it's the most widely used language for web apps, so I'm not going to say you shouldn't use it. But I hate writing in it. |
| 00:56 | <Hixie> | _uf02: if you're looking for a language to configure Emacs, I'd recomment Lisp. If you're looking for a language to write an OS kernel, I'd recommend C. |
| 00:56 | <AryehGregor> | So I'm anti-PHP in that I think it's a horrible language and wish it would die, not that I don't recommend anyone use it. Often it makes sense (which is why it's so widely used). |
| 00:57 | <AryehGregor> | Personally, I like Python. |
| 00:57 | <Hixie> | _uf02: if you're looking for a language to write a quick hack that does intense string processing, I'd recommend Perl |
| 00:57 | <Hixie> | _uf02: if you're loking for a language to work with a large PHP codebase, I'd recommend PHP |
| 00:57 | <_uf02> | I see... |
| 00:57 | <Hixie> | etc |
| 00:57 | <_uf02> | hixie: I'll give an example of what I want to do, it's basically itunes but on the web |
| 00:58 | <_uf02> | that's the most simplest explanation without getting to detailed of what I want |
| 00:58 | <Hixie> | if you're looking to write a music player client for web browsers, i'd recommend javascript as the programming language. |
| 00:58 | <_uf02> | an organization of mp3s |
| 00:58 | <AryehGregor> | Did I mention this is not a good channel to ask? |
| 00:58 | <_uf02> | right for that, I'm using jquery obviously |
| 00:59 | <Hixie> | AryehGregor is right insofar as the answer you'll get from us is far more likely to be a smartass answer than a useful answer :-) |
| 00:59 | <Hixie> | but you're welcome to try your luck :-) |
| 00:59 | <AryehGregor> | The people who are answering are mostly trying to amuse themselves by making fun of you for annoying us with off-topic questions, not be helpful. |
| 01:00 | <_uf02> | well I still appreciate the input regardless |
| 01:00 | <Hixie> | well now, he's not off-topic |
| 01:00 | <Hixie> | we don't have a topic |
| 01:00 | <_uf02> | thanks guys |
| 01:08 | <AryehGregor> | There's no standard for how <br> is supposed to be implemented in terms of CSS, is there? |
| 01:08 | <AryehGregor> | If not, I'll have to special-case it for innerText, which is sad. |
| 01:09 | <Hixie> | br { content: '\A' } is the theory, iirc |
| 01:09 | <Hixie> | dunno how that works with respect to bidi |
| 01:10 | <Hixie> | check the html spec's rendering section |
| 01:10 | <Hixie> | it talks about <br> a bit |
| 01:11 | <AryehGregor> | I was looking there. |
| 01:12 | <AryehGregor> | So inline, but content: '\A'; white-space: pre;. That will work with how I've specced it, I think. |
| 01:12 | <AryehGregor> | Except no browser appears to do it that way. Oh well. |
| 02:12 | <Hixie> | AryehGregor: yeah, like i said, theory. :-( |
| 03:57 | <karlcow> | http://www.webglearth.org/ |
| 04:49 | <erlehmann> | chrome breaks on cross-origin on local files in subdirectories. firefox 3.6 does not. why? |
| 04:54 | <roc> | because origin checking on local files is not standardized AFAIK |
| 04:56 | <erlehmann> | I see. I prefer the same directory origin model Firefox uses, for obvious reasons (local testing without a web server). |
| 07:55 | <shichuan_> | gsnedders: may i ask a question about html5 outliner? |
| 09:53 | <annevk> | "Please let's make progress." I find that statement somewhat ironic... |
| 09:55 | <jgraham> | annevk: Where is that from? |
| 09:55 | jgraham | hopes the ISSUE to remove <progress> |
| 09:58 | jgraham | is disappointed |
| 10:03 | <annevk> | jgraham, if I'd known that I would not posted it ;) |
| 10:03 | <annevk> | have* |
| 10:10 | <annevk> | so should I now write "Introducing inconsistency in the web platform considered harmful"... |
| 10:10 | <annevk> | make that more inconsistency |
| 10:10 | <annevk> | otherwise it does not make sense |
| 10:10 | <jgraham> | example.com changed :( |
| 10:11 | <annevk> | managed by IANA, what did you expect? |
| 10:11 | Philip` | wonders how much traffic example.com gets |
| 10:11 | <jgraham> | It is pretty annoying that it doesn't just return a 200 and a static document, but does a redirect |
| 10:12 | <zcorpan> | woah |
| 10:12 | <jgraham> | annevk: re: inconsistency, see /topic |
| 10:13 | <zcorpan> | making it redirect makes it not-so-useful for use in examples |
| 10:13 | <annevk> | jgraham, the topic is about legacy, not about free-for-all with everything new |
| 10:14 | zcorpan | thought the topic was about leaving your sense of logic at the door |
| 10:14 | <annevk> | that is the topic :) |
| 10:14 | <jgraham> | annevk: Sure. But you can argue that in this case the legacy is inconsistent and therefore doesn't follow the consistent logic of enforcing the sop everywhere |
| 10:14 | <jgraham> | zcorpan: Indeed |
| 10:14 | <jgraham> | (about the redirect) |
| 10:15 | <annevk> | jgraham, it is actually quite consistent |
| 10:15 | <othermaciej> | annevk: did you see me and roc's discussion earlier? |
| 10:15 | <annevk> | othermaciej, I should probably reread the last bit |
| 10:16 | <othermaciej> | even though he was not persuaded, I think a generic anti-hotlinking header would be a much better approach than limiting font embedding to same-origin and then using CORS to break out |
| 10:16 | <jgraham> | annevk: How is it consistent? |
| 10:16 | <zcorpan> | othermaciej: i approve of generic anti-hotlinking header |
| 10:17 | <annevk> | othermaciej, yeah |
| 10:17 | <othermaciej> | jgraham: all existing resource embedding contexts or retrieval APIs in the Web platform follow the rule that cross-site linking is allowed, cross-site embedding is allowed, but cross-site reading is not allowed by default |
| 10:18 | <othermaciej> | that seems pretty consistent to me |
| 10:18 | <othermaciej> | roc's argument is that the distinction between embedding and reading is bad, therefore @font-face should be different from everything else |
| 10:20 | <jgraham> | othermaciej: Right, but his argument that reading->embedding is a continuum rather than a sharp divide seems strong to me |
| 10:20 | jgraham | doesn't particularly care about @font-face fwiw |
| 10:20 | <othermaciej> | you could also argue that embedding - > linking is a continuum |
| 10:20 | <othermaciej> | but so far we've managed to draw the lines |
| 10:21 | <Ms2ger> | Not "@font-face should be different from everything else", but "new features should be different from old junk" |
| 10:21 | <othermaciej> | and by "we" I mostly mean "browser hackers who accidentally stumbled into these rules before my time" |
| 10:21 | <jgraham> | I would be interested to see a detailed argument of embedding->linking |
| 10:21 | <zcorpan> | it'd be nice with a simple way to disable hotlinking for old junk too |
| 10:21 | <roc> | othermaciej: embedding -> linking is a continuum? |
| 10:22 | <jgraham> | Yes, the anti-hotlinking thing seems good in any case since there is a legacy |
| 10:22 | <roc> | what APIs can a document use to interact with a document it links to? |
| 10:22 | <othermaciej> | window.open |
| 10:22 | <roc> | mmmm OK |
| 10:22 | <roc> | but that's only one |
| 10:22 | <annevk> | the XLink people certainly considered it a continuum, but XLink is dead |
| 10:24 | <othermaciej> | the only differences between <iframe> and window.open are presentation and the possibility of clickjacking |
| 10:24 | <othermaciej> | (I hope we can find a decent way to fix the latter) |
| 10:24 | <roc> | I agree that the relationships between full-fledged HTML documents are complex |
| 10:25 | <roc> | I don't think we need to bring that complexity to other kinds of resources for the sake of consistency |
| 10:25 | <othermaciej> | that is a strawman argument |
| 10:27 | <roc> | so was "the distinction between embedding and reading is bad, therefore @font-face should be different from everything else" :-) |
| 10:27 | <othermaciej> | if you want to say "HTML documents, images, sounds, videos, stylesheets, scripts, other kinds of renderable XML documents, non-renderable XML documents, plaintext, possibly PDFS, and kinda plugin content" in place of "HTML documents" |
| 10:27 | <othermaciej> | I will accept your restatement of my position |
| 10:29 | <annevk> | making an exception just for fonts is very very weird |
| 10:29 | <othermaciej> | I'm willing to replace "@font should be different" with the complete list of new resource types for which the new behavior is proposed, in turn |
| 10:30 | <jgraham> | It's only "just for fonts" if we never have a new similar case |
| 10:30 | <roc> | not just for fonts, but for any new loading APIs where legacy constraints apply |
| 10:30 | <roc> | I can't predict what the next type is going to be |
| 10:30 | <roc> | sorry, where legacy constraints *do not* apply |
| 10:30 | <jgraham> | An interesting question might be why this didn't happen for <audio> and <video> |
| 10:30 | <jgraham> | Which similarly had no legacy |
| 10:30 | <roc> | we had legacy constraints for <video> |
| 10:31 | <annevk> | because sanity prevailed |
| 10:31 | <roc> | Apple had Quicktime videos they wanted to play with the <video> element |
| 10:31 | <roc> | and Quicktime already supported cross-origin by default |
| 10:31 | <othermaciej> | if you can't predict what the next type is going to be, how can you predict the best design for loading it? |
| 10:31 | <othermaciej> | I am skeptical of generalizing from a sample of 1 |
| 10:32 | <roc> | the argument in my blog is independent of fonts |
| 10:32 | <roc> | the same arguments apply to images, and CSS |
| 10:32 | <roc> | it's just too late to fix those |
| 10:32 | <othermaciej> | particularly since we we seem to be heading towards the long tail of generally useful resource types |
| 10:40 | <roc> | one thing is that it's actually not formats that matter here, but loading APIs |
| 10:41 | <annevk> | whoa, http://echo.opera.com/ is useful |
| 10:41 | <annevk> | and easy to remember as well |
| 10:42 | <othermaciej> | right |
| 10:43 | <roc> | for example, we could design a new image loading API that only loads same-origin, but has an API that returns everything you want to know |
| 10:43 | <othermaciej> | though, if you have a loading API designed to work at least in part with existing formats, that's not very helpful |
| 10:43 | <annevk> | roc, CORS is designed so that it can work with <img> as API |
| 10:43 | <othermaciej> | doesn't <canvas> achieve that in the form of an access API that uses already-loaded images? |
| 10:44 | <roc> | it does, but I believe the taint bit is nasty API |
| 10:44 | <annevk> | roc, <img> would just get an additional flag about the readability of the image, true for same origin and cross-origin with CORS |
| 10:44 | <annevk> | when true <canvas> would not be tainted |
| 10:44 | <othermaciej> | making a new <img> element that you had to use for painting into the canvas would have been worse |
| 10:45 | <roc> | right, because duplicate APIs suck too |
| 10:45 | <annevk> | yeah, if that is the idea we should revamp CORS |
| 10:45 | <annevk> | but I don't think it's a good idea |
| 10:46 | <roc> | this is probably all TBL's fault |
| 10:46 | <othermaciej> | not sure about that - I don't think there were any embedded resources at all in the original WWW |
| 10:47 | <othermaciej> | so I guess you have to blame Andreesen |
| 10:47 | <roc> | oh, <img> was introduced in Mosaic? |
| 10:47 | <othermaciej> | yep |
| 10:47 | <roc> | it's been a while |
| 10:47 | <othermaciej> | http://diveintomark.org/archives/2009/11/02/why-do-we-have-an-img-element |
| 10:48 | <othermaciej> | it is an amusing story |
| 10:48 | <othermaciej> | Tim's idea was <a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure </a> |
| 10:49 | <roc> | othermaciej: do you think when drawing a cross-origin font into a canvas, we should set the taint bit? |
| 10:50 | <othermaciej> | roc: consistency implies yes |
| 10:50 | <roc> | is Webkit going to? |
| 10:51 | <annevk> | it should only taint when CORS is not involved if we decide it should taint |
| 10:51 | <annevk> | because you could get the same data otherwise by loading it directly with XMLHttpRequest |
| 10:52 | <roc> | sure |
| 10:52 | <annevk> | I wonder though what kind of confidential information could be in a font file |
| 10:52 | <roc> | interesting. When we implement pointer-events:visiblePainted or similar for images, and presumably canvases, we'll need to treat tainted canvases as opaque. Or something like that. |
| 10:52 | <annevk> | maybe you would steal fonts from a competitor? |
| 10:52 | <roc> | no |
| 10:53 | <annevk> | why not? |
| 10:53 | <roc> | because in almost all cases you could just access the competitor's site directly, download the font, and proceed |
| 10:53 | <othermaciej> | Apple has proprietary fonts that exist on intranet servers |
| 10:53 | <zcorpan> | annevk: what kind of confiedential information could be in a css file? turned out to be a problem |
| 10:53 | <annevk> | roc, I mean like in development fonts |
| 10:53 | <roc> | zcorpan: that's exactly the reason I'm paranoid about such things |
| 10:54 | <roc> | annevk: I guess, if you can guess the URL |
| 10:54 | <annevk> | zcorpan, yeah, people would start using it for smuggling and then stuff would go wrong |
| 10:54 | <roc> | that's not really what I'm worried about though |
| 10:54 | <annevk> | so yeah, it should taint, just like images |
| 10:55 | zcorpan | files a spec bug |
| 10:55 | <roc> | but with the SOR, we don't need to taint. The author discovers the error when the font fails to draw, which is much nicer than later discovering that getImageData fails for unclear reasons |
| 10:56 | <roc> | or discovering that they can't click through their canvas even though they marked it pointer-events:visiblePainted |
| 10:57 | <Philip`> | annevk: On that echo page: <table mini:hint='folded;Headers' border=0 cellpadding=3 cellspacing=0> - eww, colons :-( |
| 10:57 | <zcorpan> | we could log in the error console when a canvas gets tainted |
| 10:57 | <annevk> | Philip`, interesting |
| 10:57 | <annevk> | roc, depends on whether or not you need getImageData |
| 10:58 | <annevk> | roc, and making that easily discoverable from debugging tools will likely be done |
| 10:58 | <annevk> | tainting was renamed to origin-clean btw |
| 10:58 | <annevk> | took me some time to find the section |
| 10:58 | <roc> | tainting is a more generally understood term |
| 11:00 | Philip` | wonders if the canvas should be tainted if you fill a shape with currentColor on a page that uses a CSS file from a different origin |
| 11:00 | <roc> | I don't know |
| 11:01 | <othermaciej> | I presume the color would already be accessible via getComputedStyle |
| 11:01 | <roc> | true |
| 11:01 | <Philip`> | Do browsers try to stop you detecting visited links via colours yet? |
| 11:01 | <roc> | yes |
| 11:01 | <roc> | we lie in getCcomputedStyle |
| 11:02 | <othermaciej> | Safari does, as of 5 |
| 11:02 | <othermaciej> | same design as what's in Firefox I think |
| 11:02 | <othermaciej> | (hyatt implemented dbaron's blog post, basically) |
| 11:02 | <roc> | there are still timing channel attacks for sniffing history though |
| 11:02 | <roc> | but don't tell anyone |
| 11:02 | <Philip`> | <style>a:visited{color:red}</style> <a href=...><canvas></canvas></a> ... ctx.fillStyle="currentColor"; // look for red when painting |
| 11:02 | <Philip`> | Might that work? |
| 11:03 | <othermaciej> | doubt it |
| 11:03 | <Philip`> | Okay, good :-) |
| 11:03 | <annevk> | seems the spec never used tainting |
| 11:03 | <othermaciej> | we always resolve the unvisited style (always both, I think) and pretend the style is the unvisited style for all purposes besides painting |
| 11:04 | <roc> | annevk: "tainting" is just the word people use for this kind of scheme |
| 11:04 | <roc> | there are programming languages where "high-security" variables can be marked tainted |
| 11:05 | <roc> | well, "a word" ... other terms are also used |
| 11:05 | <othermaciej> | tainting is sometimes used to refer to the opposite, where you "taint" untrusted data so that you can avoid accidentally using things computed from it without validation |
| 11:06 | <annevk> | oh, I got what tainting meant out of context, I just had a hard time finding the appropriate <canvas> section |
| 11:06 | <othermaciej> | that is what taintperl does, for example, was very popular in the late 90s |
| 11:06 | <othermaciej> | for writing your CGI scripts |
| 11:06 | <annevk> | but this additional info is cool :) |
| 11:07 | <Philip`> | Using taint mode in Perl still seems the recommended approach |
| 11:07 | <Philip`> | (via a command-line argument, not a separate executable) |
| 11:08 | <othermaciej> | that is one reason I find "tainting" to not be the best term for the canvas behavior, since it is sort of the opposite of perl |
| 11:11 | <roc> | "dynamic information flow analysis" sounds cooler anyway |
| 11:12 | <annevk> | what was it again? needs more cowbell? |
| 11:25 | <roc> | here's another information leak question, a non-hypothetical one. Is it OK for pointer-events:visiblePainted to let mouse events pass through the transparent pixels of cross-origin <img>s, given that with elementFromPoint() this leaks information about whether each pixel of the image is transparent? |
| 11:25 | <roc> | and should this depend on CORS? :-) |
| 11:31 | <roc> | maybe we should make <image> only load same-origin images, and give it all the APIs that don't want to worry about information leakage, and have pointer-events work on it |
| 11:33 | <annevk> | we cannot really change <img> at this point |
| 11:33 | <annevk> | or do you mean SVG <image>? |
| 11:33 | <othermaciej> | I think maybe roc means to change <image> to no longer map to the <img> element but rather act as a different same-origin-only element |
| 11:34 | <othermaciej> | not sure if it was a serious proposal |
| 11:34 | <roc> | I'm half joking |
| 11:34 | <annevk> | okay :) |
| 11:34 | <annevk> | can we not just add a flag to <img>? |
| 11:34 | <annevk> | for "safeness" |
| 11:35 | <othermaciej> | if pointer events work same-origin only, then it's not really helpful to authors to then also require embedding their images via <image> instead of <img> |
| 11:35 | <othermaciej> | the implementation part is easy in any case |
| 11:35 | <roc> | actually it is helpful |
| 11:35 | <roc> | because if you get into the habit of using <image> |
| 11:35 | <roc> | and you accidentally get a cross-origin image |
| 11:35 | <roc> | the error is easier to diagnose |
| 11:36 | <annevk> | we could just have an event or some such for that |
| 11:36 | <annevk> | or a property on <img> |
| 11:36 | <annevk> | <img>.readable |
| 11:36 | <othermaciej> | except that usually you are not using pointer-events, so your habit just makes more things fail |
| 11:36 | <othermaciej> | it's like sending XML to browsers to avoid the perils of "tag soup" |
| 11:37 | <roc> | now that's a low blow |
| 12:02 | <AryehGregor> | I don't think we're going to introduce enough new resource types that distinguishing between embedding and reading in new resource types would appreciably increase security. |
| 12:02 | <AryehGregor> | A general-purpose anti-hotlinking header sounds like a much better idea. |
| 12:03 | <AryehGregor> | Fonts might leak some information someday, but in how many cases are you really going to be able to get information from font embedding that you can't get from embedding imgs, iframes, etc.? |
| 12:03 | <AryehGregor> | Sites that need extra security (or want to save bandwidth) should be allowed to say that they don't want any of their resources used cross-origin. |
| 12:04 | <annevk> | Yeah, that is indeed the other point. We never drastically change design patterns because the unknown future will do things a certain way. |
| 12:04 | <Workshiva> | Would the header help much for bandwidth? I don't imagine browsers would like to HEAD every external resource |
| 12:04 | <AryehGregor> | Browsers should also probably apply such restrictions by default to non-intranet sites that try to load stuff from intranet sites. |
| 12:04 | <AryehGregor> | Workshiva, it will work for bandwidth because when all browsers implement this, people won't bother hotlinking from the site since the image will be broken. |
| 12:04 | <annevk> | Workshiva, loading happens incrementally, so you can close the connection once you see the header |
| 12:05 | <AryehGregor> | That too. |
| 12:05 | <Workshiva> | AryehGregor: I disagree with that |
| 12:05 | <AryehGregor> | Which part? |
| 12:05 | <Workshiva> | I did anti-hotlinking on my server for a long time by replacing the image with a fixed "Don't hotlink" |
| 12:05 | <annevk> | Workshiva, you get the same with CORS by the way |
| 12:05 | <Workshiva> | Yet people still hotlinked without worry, I guess because their own browser displayed the cached version of the image |
| 12:06 | <AryehGregor> | Which wouldn't happen here. |
| 12:06 | <annevk> | Indeed, the header would be part of the cache |
| 12:19 | <roc> | AryehGregor: I can't tell whether you want to distinguish embedding from reading in fonts or not |
| 12:21 | <AryehGregor> | roc, I agree with you that ideally we should have had the distinction from the start, but I don't think there's any mileage in trying to impose it now. Meaningfully addressing the problem will require some form of crackdown on all embedding. |
| 12:22 | <AryehGregor> | I don't think it's a big deal either way whether fonts can be embedded cross-origin. |
| 12:22 | <AryehGregor> | It's not a big security problem, but it's not a really big consistency problem either. |
| 12:22 | <AryehGregor> | If we have a decent general-purpose embedding solution, I'd think the security problem from cross-origin font embedding would be negligible, so may as well go for consistency. |
| 12:23 | <AryehGregor> | To start with, since so many of the scenarios under discussion revolve around public sites embedding stuff from intranets, could that just be banned by default, or would that be too big a compat risk? |
| 12:23 | <roc> | that didn't really answer the question |
| 12:23 | <AryehGregor> | Well, it did. I'm ambivalent. |
| 12:23 | <AryehGregor> | Leaning slightly toward no, don't bother distinguishing. |
| 12:24 | <roc> | do you think that drawing a cross-origin font to a canvas should clear the origin-clean flag, like cross-origin images do? |
| 12:24 | <AryehGregor> | That seems like it makes sense, I guess. I'm still ambivalent. :) |
| 12:25 | <roc> | maybe a better question is, do you think an API that lets script access the complete original font data from a cross-origin-loaded font would be OK? |
| 12:25 | <AryehGregor> | No, that sounds dangerous. |
| 12:25 | <roc> | Ok, so you do want a distinction between embedding and reading |
| 12:25 | <AryehGregor> | No, because I'd also be okay with banning cross-origin embedding as well. |
| 12:26 | <AryehGregor> | I just wish CORS were easier to use. |
| 12:26 | <AryehGregor> | HTTP headers stink. |
| 12:30 | <annevk> | CORS is not really designed for static files either |
| 12:31 | <annevk> | well, it was initially, but then all kinds of requirements made that a lot trickier |
| 12:37 | <annevk> | is RTW (Real-Time Web) going to be the next buzzword? |
| 12:38 | <zcorpan> | what would it mean? |
| 12:38 | <annevk> | DHTML -> XHTML/Semantics -> Ajax -> Web 2.0 -> HTML5 -> ... |
| 12:38 | <annevk> | zcorpan, instead of app-driven the web is driven by you and everyone, it's "live" |
| 12:38 | <jgraham> | RTW seems like a natural sucessor to Ajax |
| 12:39 | <jgraham> | But it's not very catchy |
| 12:39 | <jgraham> | Mind you neither is HTML5 |
| 12:40 | <zcorpan> | i dunno, the pattern so far has been something with "HTML" in it twice, then something without "HTML" in it twice, which suggests the next buzzword is something with "HTML" in it |
| 12:40 | <zcorpan> | maybe DHTML to close the circle? |
| 12:40 | <jgraham> | RTHTML5? |
| 12:40 | <annevk> | HTML Living Standard -> HTML Live |
| 12:40 | <zcorpan> | HTMLive |
| 12:41 | <annevk> | hahaha |
| 12:41 | <annevk> | that one is brilliant |
| 12:41 | <jgraham> | I can imagine LiveWeb or something catching on, except Microsoft polluted "live" |
| 12:42 | <jgraham> | (also, "Web" isn't great in a buzzword because it is the infrastructure rather than the technology that you are using that makes you better than everyone else) |
| 12:43 | <zcorpan> | yet Web 2.0 was a pretty successful buzzword |
| 12:48 | <jgraham> | Yeah, true |
| 12:57 | <beowulf> | HTML 2.0 |
| 12:57 | <beowulf> | no, wait... |
| 12:59 | <Ms2ger> | XHTML 2.0, if we're going to mix |
| 13:00 | jgraham | is rooting for RealHTML |
| 13:10 | <karlcow> | The evolution in HTML looks like the history of computing server side, client side, server side, client side, rinse and repeat. |
| 13:10 | <karlcow> | a bit like light. It is a wave! It is a particle! It is a wave! … etc. |
| 13:15 | <jgraham> | The difference being that the client/server thing is a simple symbiotic relationship whereas QED is deeply weird shit |
| 13:31 | <beowulf> | Continuity HTML is a joke no-one here is going to get |
| 13:34 | <Philip`> | Did Continuity HTML split out from Provisional HTML? |
| 13:35 | <beowulf> | Philip`: yes! but only after the Real HTML had already done so |
| 14:01 | <Savage^> | heya |
| 14:01 | <Philip`> | Hi |
| 14:02 | <Savage^> | is it true that the 0.90 download on http://code.google.com/p/html5lib/downloads/list is for Python 2.x? |
| 14:03 | <Savage^> | and where is the download for python 3.0 (the source is in the repo, so it should be somewhere, right?) |
| 14:04 | <gsnedders> | Savage^: yes, nowhere (and there's no guarantee it works, and it's certainly out of date) |
| 14:04 | <Savage^> | bottom line is I should just use python 2? |
| 14:05 | <annevk> | yes |
| 14:05 | <annevk> | is Python 3 gonna make it anyway? |
| 14:05 | <Savage^> | alright thanks for clearing that up |
| 14:05 | <Savage^> | I started learning python yesterday, so I thought I'd just use the latest python version. |
| 14:05 | <Savage^> | But things are not that simple on the internet.... |
| 14:06 | <annevk> | Python 3 was the great new thing, but now it seems like it failed like XHTML 2.0 |
| 14:06 | <Savage^> | Seems like a bad idea to make a non-backwards compatible version of your language in the first place. |
| 14:07 | <annevk> | compatibility wins and beauty dies; interwebs is a sad place |
| 14:07 | <gsnedders> | If Unladen-Swallow had got merged in, it might've had some advantage to convince people to move. |
| 14:07 | <annevk> | is the the JIT stuff? |
| 14:07 | <annevk> | they're making that work for 2.x too |
| 14:08 | <Savage^> | Well with software you just live with the mistakes from the past, right? |
| 14:08 | <Savage^> | No point in rewriting things every version... |
| 14:08 | <jcranmer> | non-backwards compatability can work if you're really willing to kill off the old stuff |
| 14:08 | <annevk> | Savage^, right |
| 14:08 | <Savage^> | Look at the windows PE (.exe) format |
| 14:09 | <gsnedders> | annevk: The original work was a CPython 2.x branch. Python 2.7 is the last non-bug-fix Python 2 release, and it missed the cut-off for that, so there's a Python 3 branch merging it in. |
| 14:09 | <Savage^> | Or x86, for that matter |
| 14:09 | <jcranmer> | but, seeing as how python is still working on the 2.x series, convincing people to move to 3.x is not going to work |
| 14:09 | Philip` | notes that Arch Linux makes "python" default to Python 3.x |
| 14:09 | <jcranmer> | Savage^: I don't think real 16-bit mode works in 64-bit chips anymore |
| 14:09 | <gsnedders> | jcranmer: The only work is bug fixes. |
| 14:10 | <jcranmer> | that's still work |
| 14:10 | <Philip`> | but rather than port stuff to work with Python 3, people seem to prefer just changing their build systems to run the python2 command instead |
| 14:11 | <Savage^> | jcranmer: yes but the whole instruction set is just ugly and ambiguous |
| 14:11 | jgraham | notes that US died because the memory usage was unacceptable and the perf. gains modest |
| 14:11 | <jgraham> | Also, Python 3 will be widley used eventually |
| 14:12 | <jgraham> | It's not really like XHTML2 at all |
| 14:12 | <jcranmer> | just like autoconf 2.61! |
| 14:12 | <gsnedders> | jgraham: The memory usage wasn't that bad |
| 14:12 | <jcranmer> | it's not like anyone uses autoconf 2.13, right? |
| 14:12 | <gsnedders> | PyPy is way quicker than US ever was, though |
| 14:12 | <jgraham> | jcranmer: I call bias since you work on Mozilla |
| 14:13 | <jgraham> | PyPy is more awesome than a bath full of balloons |
| 14:13 | <Savage^> | The people who lose in this are new developers... the first thing I faced was major problems over incompatibilities, not being sure if code snippets are python 2 or 3, etc. |
| 14:13 | <jgraham> | Savage^: Yes, it is a problem |
| 14:14 | <jgraham> | Anyway, for now use Python 2.x unless you are sure you want to use 3.x |
| 14:14 | <Philip`> | They should have made a clear distinction by e.g. changing all keywords in Python 3 to be uppercase |
| 14:14 | <jgraham> | Philip`: and renaming it COBOL? |
| 14:14 | <Savage^> | I was under the impression python was an easy language to make quick-n-dirty scripts |
| 14:14 | <Savage^> | And I'm sure python 2.x was ;) |
| 14:14 | <jgraham> | Savage^: And also for making sophisticated applications |
| 14:14 | <Savage^> | yes ofcourse |
| 14:15 | <Savage^> | Oh well, I installed python 2 now |
| 14:15 | <gsnedders> | We should benchmark html5lib with PyPY |
| 14:15 | <jgraham> | gsnedders: I assume it would still be rather slow |
| 14:17 | <gsnedders> | jgraham: http://speed.pypy.org/comparison/?exe=2%2B35%2C1%2BL&ben=6&env=1&hor=false&bas=none&chart=normal+bars |
| 14:17 | <Savage^> | And I am happy to inform you that I built and installed html5lib. Wow. :] |
| 14:17 | <karlcow> | annevk: if you tried 2to3, what where the results on html5lib? |
| 14:18 | <jgraham> | gsnedders: So about a 50% improvement |
| 14:18 | <jgraham> | Not bad |
| 14:18 | <jgraham> | karlcow: There is a bunch of stuff that has to be fixed up by hand |
| 14:18 | <karlcow> | yeah. I can imagine. Was it a lot? |
| 14:18 | <jgraham> | Also, the strings vs bytes stuff needs rather careful consideration so that the API makes sense |
| 14:19 | <Philip`> | 50% doesn't sound much, compared to Javascript engines that all double in speed every six months for the past several years |
| 14:19 | <Peter`> | Microsoft just released a plugin for Google Chrome which adds support for H.264 |
| 14:19 | <gsnedders> | jgraham: I wonder what difference it would make for PMS |
| 14:19 | <jgraham> | Not a huge amount. Someone could make a port in a weekend |
| 14:19 | <Peter`> | http://blogs.msdn.com/b/interoperability/archive/2011/02/01/greater-interoperability-for-windows-customers-with-html5-video.aspx |
| 14:19 | <Savage^> | By the way, do you guys do this stuff for a living, or do you just use mIRC from your day jobs? |
| 14:19 | <jgraham> | But the problem is how to maintain it |
| 14:19 | <Savage^> | Or maybe you're all extremely rich. |
| 14:19 | <jgraham> | Savage^: Most people here work for browser vendors |
| 14:20 | <jgraham> | So far this has not made me even moderatley rich |
| 14:20 | <karlcow> | haha |
| 14:20 | <jgraham> | gsnedders: I imagine the first effect it would have is that everything would break, unless lxml works with PyPy these days |
| 14:20 | <Savage^> | So do the IE developers get mocked in here? |
| 14:21 | <karlcow> | jgraham: it made your memory rich of endless discussions about the Web :p |
| 14:21 | <gsnedders> | jgraham: Ah, that's true. |
| 14:21 | <jgraham> | karlcow: Doesn't help pay the rent :p |
| 14:22 | hsivonen | wonders how the Chrome Frame folks feel about Microsoft injecting H.264 code into Chrome |
| 14:27 | <Philip`> | Firefox should ship a Free HTML5 Video Extension for Chrome which blocks Microsoft's extension |
| 14:28 | <Peter`> | :D |
| 14:29 | <Rik`> | if it's the same as the Firefox extension, it's not really support for H264 <video> |
| 14:29 | <Philip`> | Rather than browser wars where there's only one winner, we can end up with every user running a browser that's an amalgamation of every other browser |
| 14:29 | <AryehGregor> | Savage^, we were just commending the IE developers in here the other days for making IE9 such that it can actually run nontrivial JavaScript without browser-specific hacks! |
| 14:29 | <Philip`> | "This Extension is based on a Chrome Extension that parses HTML5 pages and replaces Video tags with a call to the Windows Media Player plug-in so that the content can be played in the browser." |
| 14:30 | <AryehGregor> | That sounds pretty awful. |
| 14:30 | <Philip`> | Rik`: Sounds like it's not really <video> support |
| 14:30 | <gavin> | isn't that what their firefox extension does too? |
| 14:30 | <jgraham> | I think so |
| 14:30 | <Rik`> | so kind of useless |
| 14:30 | <Rik`> | that will cause more random bugs reported to web developers |
| 14:31 | <jgraham> | Savage^: I think this is us mocking Microsoft developers :) |
| 14:31 | <AryehGregor> | At least they aren't auto-installing it yet, right? |
| 14:32 | <Savage^> | Haha I don't think they dare come in here, but the mocking is still fun :D |
| 14:32 | <AryehGregor> | Given that IE9 uses WebM support if installed, are Google and/or Mozilla planning to auto-install it when they're installed? |
| 14:32 | <AryehGregor> | Savage^, no member of the IE team has ever commented in any WHATWG venue, to my knowledge. |
| 14:33 | <AryehGregor> | I wouldn't be surprised if they had explicit instructions not to. |
| 14:33 | <AryehGregor> | Of course, they barely comment in the HTMLWG either, except for Paul in his role as co-chair. |
| 14:33 | <beowulf> | wasn't cwilso in here of a time? |
| 14:33 | <AryehGregor> | Not sure why. Sylvain Galineau is quite active in the CSSWG, for instance. |
| 14:33 | <AryehGregor> | Was he? I dunno. |
| 14:34 | <beowulf> | maybe it was the w3c room, my memory is bad |
| 14:34 | <AryehGregor> | Of course, now he works for Google, right? :) |
| 14:34 | <beowulf> | true :) |
| 14:34 | <gsnedders> | AryehGregor: How much HTML5 stuff are they actively implementing v. CSS stuff? |
| 14:35 | <gavin> | AryehGregor: does IE really support WebM (as opposed to vp8)? |
| 14:35 | <AryehGregor> | gsnedders, for IE9, probably not as much . . . media elements, canvas . . . |
| 14:35 | <AryehGregor> | gavin, I dunno. I hope so, otherwise it's fairly useless. |
| 14:35 | <AryehGregor> | Has anyone tried? |
| 14:35 | miketaylr | fires up windows |
| 14:36 | <gavin> | well it certainly doesn't work out of the box |
| 14:36 | <miketaylr> | right, have to have the codec there already |
| 14:36 | <gavin> | which codec? |
| 14:37 | <gavin> | codec is one thing, support for an entirely different container format is another... |
| 14:37 | <miketaylr> | oh, we're not talking about vp8, my bad |
| 14:39 | <Philip`> | The IE blog has linked to the #whatwg logs occasionally, so presumably they read this or are somehow made aware of its content |
| 14:40 | <beowulf> | really? IE people, can I have an IE sticker? |
| 14:40 | <Savage^> | hahaha |
| 14:41 | <Savage^> | I hear they use russian proxies from the IE headquarters to eavesdrop here... |
| 14:48 | <MikeSmith> | Rik`: congrats on moving to full employee, brotherman |
| 14:50 | <Rik`> | MikeSmith: hey thanks |
| 14:50 | <AryehGregor> | MikeSmith, does the fact that I'm working for Google part-time as an outside contractor/vendor/whatever affect my status as an Invited Expert in the HTMLWG? |
| 14:50 | <AryehGregor> | I'd assume that the W3C wouldn't care in any event, since Google already pays them $$$, but I just wanted to check. |
| 14:51 | <Ms2ger> | You promised to inform them, iirc |
| 14:51 | <MikeSmith> | yeah |
| 14:51 | <gsnedders> | AryehGregor: It could matter for patent policy reasons. |
| 14:51 | <MikeSmith> | it does matter |
| 14:51 | <miketaylr> | hmm no, i can't get webm to play on ie9 |
| 14:51 | <MikeSmith> | AryehGregor: you should let Raman know |
| 14:51 | <AryehGregor> | Even though I'm an outside contractor, not an actual employee? |
| 14:51 | <MikeSmith> | T.V. Raman |
| 14:51 | <loucapo> | hey all. posted a question on here yesterday but didnt get an answer |
| 14:51 | <MikeSmith> | AryehGregor: yes |
| 14:51 | <AryehGregor> | Okay. |
| 14:51 | <AryehGregor> | Will do. |
| 14:51 | <MikeSmith> | thanks |
| 14:52 | <AryehGregor> | Where should I contact him? |
| 14:52 | <AryehGregor> | Ms2ger, I don't remember what I promised them, it was lots of things. |
| 14:52 | <AryehGregor> | That's why I have people like MikeSmith, so that I don't have to remember stuff. |
| 14:52 | <MikeSmith> | heh |
| 14:52 | <Ms2ger> | I attempted to read through all the things they wanted me to agree to |
| 14:53 | <Ms2ger> | I might have missed some |
| 14:53 | <MikeSmith> | Raman public contact info is here: |
| 14:53 | <MikeSmith> | http://emacspeak.sourceforge.net/raman/ |
| 14:53 | <MikeSmith> | google address is raman⊙gc |
| 14:54 | <AryehGregor> | He's some W3C person who will tell me what paperwork to file or something? |
| 14:54 | <MikeSmith> | he's the W3C Advisory Committee rep from Google |
| 14:54 | <AryehGregor> | Ah, I see. |
| 14:55 | <MikeSmith> | so it is necessary for him to know of and approve any Google reps participating in W3C groups |
| 14:58 | <AryehGregor> | Okay, I've e-mailed him. |
| 14:58 | <AryehGregor> | What patent concerns are there? |
| 14:59 | <annevk> | posted my own Considered Harmful piece |
| 15:00 | <annevk> | first time since 2005 apparently |
| 15:00 | <Ms2ger> | You wouldn't necessarily have the rights to grant the patent rights to the W3C |
| 15:03 | <AryehGregor> | There are only two possible parties here that could possibly hold the patent rights: me and Google. Both of us have agreed to the W3C patent policy for the HTMLWG. So what difference does it make? |
| 15:04 | <AryehGregor> | I could understand if my employer wasn't a W3C member, or wasn't a member of the HTMLWG, but Google is both. |
| 15:04 | <Ms2ger> | Have they agreed to license *your* patent rights, though? |
| 15:05 | <AryehGregor> | The patent policy agreement that Google signed covers any patents they own that affect the HTMLWG's specifications (subject to various boring conditions). |
| 15:05 | <AryehGregor> | The patent policy agreement that I signed covers any patents I own that affect the HTMLWG's specifications (subject to various boring conditions). |
| 15:05 | <AryehGregor> | I don't see any place for the patent policy to not take effect. |
| 15:05 | <Ms2ger> | Meh, patents |
| 15:05 | <AryehGregor> | Plus, I never signed my patent rights away to Google, only copyrights. |
| 15:05 | <AryehGregor> | And I'm not even totally sure about those. |
| 15:07 | <gavin> | annevk: I think "(and presumably others at Mozilla)" may not be a fair presumption |
| 15:08 | <annevk> | it is what Gecko is shipping |
| 15:08 | <annevk> | if only Robert was behind it, I do not think that would be true |
| 15:09 | <gavin> | er, what? |
| 15:09 | <annevk> | Gecko has a cross-origin restriction on font loading |
| 15:10 | <annevk> | I will clarify the sentence to point that out when I come back |
| 15:10 | <annevk> | I really have to run now |
| 15:10 | <gavin> | oh, well that's going in the other direction |
| 15:11 | <gavin> | (restricting embedding vs. allowing reading) |
| 15:12 | <gavin> | which I guess may point out that I misunderstood the point of his post |
| 15:13 | <gavin> | I don't htnk the main argument for cross-origina restrictions on fonts was consistency, though |
| 15:13 | <annevk> | it's inconsistent, that's the whole problem |
| 15:13 | <gavin> | I mean consistency wrt reading vs. embedding |
| 15:14 | <gavin> | not consistency with the rest of the web platform |
| 15:14 | <MikeSmith> | AryehGregor: if Raman makes the determination that your particular situation doesn't require you to participate as a Google rep, then that's fine |
| 15:15 | karlcow | wonders why people from the IE Team do not come here. Maybe no rights from the management? |
| 15:15 | <MikeSmith> | but it's not my call |
| 15:16 | <gavin> | annevk: i.e. I think the main reason was "font foundries are going to freak out of XO embedding is allowed" was the real reason, not "we need to deny reading, so we should also deny embedding (as justified in roc's post)" |
| 15:17 | <gavin> | (I misread the last sentence in the second last paragraph of roc's post) |
| 16:19 | <TabAtkins> | gavin: I don't see why people continually insist on attributing different motivations to roc (and I, and other people) when we state our motivations pretty clearly. |
| 16:48 | <gavin> | TabAtkins: hmm? |
| 16:49 | <gavin> | I am not attributing motivations to roc... |
| 16:49 | <TabAtkins> | Your comment saying what the "real reason" was, about an hour and a half ago. |
| 16:50 | <gavin> | that was attributing motivations to Mozilla |
| 16:50 | <gavin> | and indeed my point was that roc's motivations and "mozilla's" (whatever that means) may have been different |
| 16:51 | <TabAtkins> | Mozilla's motivation is the motivation of its engineers. ^_^ |
| 16:51 | <gavin> | I am a Mozilla engineer :) |
| 16:51 | <TabAtkins> | And thus, Mozilla's motivations are inconsistent. ^_^ |
| 17:07 | <annevk> | http://blogs.msdn.com/b/ie/archive/2011/02/02/html5-and-web-video-questions-for-the-industry-from-the-community.aspx -- from the community? |
| 17:07 | <annevk> | classy, Microsoft |
| 17:08 | <annevk> | also fun how they only cite the articles that were against dropping H264 support |
| 17:09 | <annevk> | oh hello, we are Microsoft^H^H^H^H^H^H^H^H^Hthe community and have an interest in H264 |
| 17:09 | <bfrohs> | Well, doesn't surprise me after the incident between Google and Bing yesterday... well, it wouldn't surprise me anyway, being that it is Microsoft. |
| 17:10 | <annevk> | ieblog turned into a spinblog |
| 17:13 | <Rik`> | "we are so good, we give you plugin for other browsers. oh, btw, you won't be able to do anything other than playing the video" |
| 17:13 | <annevk> | I tweeted: "As long as you use Windows you can watch video on the web!" |
| 17:20 | <jgraham> | Microsoft's whole business model is based arounf "As long as you use Windows, you can do X" |
| 17:20 | <jgraham> | So it's really very unsurprising that they are extending it here |
| 17:20 | <jgraham> | +to |
| 17:30 | <Rik`> | annevk: the best part is how they claim not to do "uncertainty, fear, or doubt" |
| 17:39 | <ls_n> | I'd like to get some clarification on expected behavior of innerHTML assignment to option elements. |
| 17:41 | <ls_n> | Currently in FF4, Saf5, Chr8, and IE9, if I create an option element in js off DOM and assign innerHTML = '<img src="404.boom" onerror="alert(\'Oh Hai!\');">'; the onerror handler executes when I attach that option to the DOM. |
| 17:42 | <ls_n> | Even though the content model for option is text, and legally, they can't have child nodes (I am correct in this, right?) |
| 17:44 | <ls_n> | If Web Inspector is to be believed, Chrome (I didn't test others) does create the img as a child node of the option, and option.innerHTML reports out what was assigned. |
| 17:45 | <ls_n> | In fact, any arbitrarily complex markup string appears to be parsed and commuted to childNodes, barring tag soup clean up. |
| 17:46 | <ls_n> | But, first, if the content model for option is text, should child node creation be rejected? |
| 17:48 | <ls_n> | Related: select.innerHTML = '<option><img ... onerror=...></option>'; creates the option without the img node (pruned by tag soup process?) |
| 17:48 | <Philip`> | ls_n: The content model is only relevant for document conformance - it doesn't affect how browsers process the document at all |
| 17:49 | <Philip`> | When you assign innerHTML, it'll do http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#parsing-html-fragments |
| 17:50 | <Philip`> | and <option> isn't a special case there so it'll just parse the string like a normal HTML fragment and insert it into the option element, I think |
| 17:52 | <Philip`> | Oh, http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#reset-the-insertion-mode-appropriately is relevant too |
| 17:53 | <Philip`> | option isn't on that list either, so it'll parse like a normal HTML fragment |
| 17:53 | <Philip`> | whereas if you do select.innerHTML, then select is on that list so it'll be in "in select" mode |
| 17:53 | <Philip`> | which is http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inselect which ignores tags like <img> |
| 17:54 | <Philip`> | So it sounds like those browsers all match the spec |
| 17:56 | <ls_n> | Philip`: So the question then is: is the omission of option from the insertion mode list intentional? |
| 18:01 | <Philip`> | ls_n: If all browsers implement the same behaviour here, then it's likely intended that the spec should match that |
| 18:07 | <TabAtkins> | ls_n: We (Chrome) deal with restricted content models via shadow DOM. <option>s can have children, they just aren't displayed in any way. |
| 18:07 | <Philip`> | (Firefox 3.6 seems to skip the <img> in option.innerHTML, though, as does Opera 11) |
| 18:08 | <ls_n> | TabAtkins: it was unexpected that the js handler would execute from that context. |
| 18:08 | <Philip`> | (so this seems like partially new behaviour due to HTML5 parser implementation) |
| 18:08 | <TabAtkins> | ls_n: They're still ordinary children as far as we're concerned. We only ignore them for rendering purposes. |
| 18:09 | <ls_n> | I understand the technical reasons. My point is there doesn't seem to be a practical reason for the behavior. |
| 18:09 | <TabAtkins> | ls_n: Is there a practical reason for any other behavior? It's consistent with a model we like, which we're standardizing in our own code and are attempting to specify for other browsers. |
| 18:10 | <Philip`> | Why is shadow DOM stuff relevant here? |
| 18:10 | <TabAtkins> | (Others dont' necessarily have to use shadow DOM for existing elements, but it certainly makes our code easier.) |
| 18:10 | <Philip`> | It all just seems like a natural consequence of the parsing algorithm |
| 18:10 | <TabAtkins> | Philip`: <option> elements have an empty shadow tree. This suppresses the display of their light children. |
| 18:10 | <Philip`> | Why is display of children relevant here? |
| 18:10 | <TabAtkins> | The parsing algorithm happens to never generate children for them, but if you add children via DOM, they exist but aren't displayed. |
| 18:11 | <TabAtkins> | So events, such as <img onerror>, still fire. |
| 18:13 | <Philip`> | Display only seems relevant to the extent that the behaviour is due to display being irrelevant as far as image loading and script events are concerned |
| 18:13 | <TabAtkins> | Exactly. |
| 18:13 | <Philip`> | So it's mostly irrelevant ;-) |
| 18:13 | <TabAtkins> | Yes. But ls_n was thinking that it wasn't, and I was explaining our behavior to show why it was (irrelevant). |
| 18:14 | <Philip`> | Ah |
| 18:16 | <Philip`> | (Incidentally, Firefox 3.6 with option.innerHTML seems to strip <img> tags but keeps <option>s, so it'll generate nested option elements, which render a little bizarrely) |
| 18:16 | <ls_n> | Actually, if you add elements that contain text, the text is displayed, correct? |
| 18:18 | <TabAtkins> | Yeah. |
| 18:18 | <ls_n> | What seemed inconsistent to me, prior to seeing the insertion mode list, was that option.innerHTML = '<img onerror...>' fired the handler, option.innerHTML = '<div><p><span><img onerror></span></p></div>' fired the handler, but option.innerHTML = '<select><option><img onerror></option></select>' did not. |
| 18:19 | <ls_n> | But it is consistent with select.innerHTML = '<option><img onerror></option>' |
| 18:19 | <Philip`> | Yeah, option.innerHTML is pretty much like body.innerHTML |
| 18:20 | <Philip`> | seemingly for no good reason except that it's what naturally happens when the spec doesn't define special-case behaviour for it |
| 18:21 | Philip` | would hope this isn't something that'll cause compatibility issues with real pages |
| 18:22 | <ls_n> | so IMO, it is odd that the assigning select.innerHTML will prune img, but option.innerHTML won't. Exactly to your point, Philip` |
| 18:22 | <TabAtkins> | ls_n: That's because innerHTML invokes the parsing algorithm to create the fragment, and <img> can't be a child of <option>. ^_^ |
| 18:23 | <Philip`> | This is far from the most odd aspect of HTML parsing :-) |
| 18:23 | <ls_n> | Yeah, I get it. It doesn't give me that gratifying DWIW feeling, though :) |
| 18:24 | <ls_n> | not that I want anyone assigning subtrees to innerHTML of options... |
| 18:24 | <Philip`> | Just don't assign anything than text to option.innerHTML and you won't have to worry :-) |
| 18:24 | <Philip`> | *other than |
| 18:24 | <Philip`> | (The spec would have to add a whole new parser insertion mode to handle this 'correctly', I think) |
| 18:25 | <Philip`> | (since it doesn't currently have an "in option" mode) |
| 18:25 | <ls_n> | Just that it seemed reasonable in this case not to execute js. But yeah, exceptional case. |
| 18:27 | <ls_n> | Soooo maybe then I need to understand better the justification for "in select" |
| 18:27 | <TabAtkins> | The justification is "the internet is crazy". |
| 18:27 | <ls_n> | hehe. See exhibit A: "the internet is crazy" |
| 18:28 | <Ms2ger> | Exhibit B: Julian |
| 18:28 | <AryehGregor> | MikeSmith, he asked me for "the URL to nominate you -- it's on the html wg page". I don't see it. |
| 18:28 | <MikeSmith> | hang on |
| 18:28 | <AryehGregor> | Julian isn't crazy, he just has interests that we don't care about. Like theoretical purity. |
| 18:28 | <ls_n> | if option can have children that just have different display behavior, why not the same for select? |
| 18:29 | <AryehGregor> | ls_n, this stuff is mostly dictated by legacy requirements. |
| 18:29 | <AryehGregor> | I.e., pages out there expect particular behavior because that's how old browsers behaved. |
| 18:29 | <MikeSmith> | AryehGregor: http://www.w3.org/2004/01/pp-impl/40318/change |
| 18:29 | <MikeSmith> | I believe |
| 18:30 | <MikeSmith> | but I think before he can do that, I may need to have the W3C systems team change your affliliation |
| 18:30 | <MikeSmith> | should I go ahead and do that? |
| 18:30 | <AryehGregor> | I have no idea what you're asking me, so I find it hard to pick an answer. |
| 18:30 | <MikeSmith> | that is, is Raman agreed that you'll be representing Google |
| 18:31 | <AryehGregor> | I dunno, he didn't say. |
| 18:31 | <AryehGregor> | What are the ramifications? |
| 18:31 | <ls_n> | AryehGregor: Sure. Don't break the web. But the treatment of select content and option content seems and odd thing to be considered sacrosanct. |
| 18:31 | <Philip`> | ls_n: The whole web is sacrosanct as far as breakage is concerned, and select/option are a part of that |
| 18:32 | <MikeSmith> | AryehGregor: ramification is just that as far a W3C's concerned you will be a Google participant instead of being an individual participant |
| 18:32 | <AryehGregor> | Does that actually have any practical implications one way or another? |
| 18:32 | <AryehGregor> | Particularly given that my contract only goes till the end of August? |
| 18:34 | <ls_n> | Philip`: that seems a speewing generalization and, in fact, not true. But I realize at this point that I'm soapboxing. Closed: invalid (by design). |
| 18:34 | <ls_n> | hehe, s/speewing/sweeping/ -- stupid fingers |
| 18:35 | <TabAtkins> | Seems correct anyway. |
| 18:35 | <TabAtkins> | I thought it was intentional, just misspelled. |
| 18:35 | <MikeSmith> | AryehGregor: no particular implications in practice in this case other than the patent-policy thing discussed earlier; and after August we can just change you back to being an individual |
| 18:35 | <MikeSmith> | AryehGregor: do you have a Google e-mail address? |
| 18:36 | <TabAtkins> | I highly recommend *not* using a google email address, even if you have one. |
| 18:36 | <AryehGregor> | MikeSmith, no, I'm totally outside Google. |
| 18:36 | <AryehGregor> | The only relationship we have is I do some stuff and they give me money. |
| 18:36 | <MikeSmith> | ok |
| 18:36 | <Philip`> | AryehGregor: Are you allowed to do evil? |
| 18:36 | <AryehGregor> | TabAtkins, why? |
| 18:36 | TabAtkins | is still sad that he's signed up for the FontsWG with his @google.com address. |
| 18:36 | <AryehGregor> | Philip`, they didn't say, so I assume so. But I'm not sure if I can bill for it. |
| 18:36 | <AryehGregor> | TabAtkins, why? |
| 18:36 | <Ms2ger> | Because then all your emails are sent to spam in gmail? |
| 18:36 | <TabAtkins> | AryehGregor: It's inconvenient, especially if you'll be losing control of it later. |
| 18:37 | <Hixie> | eah that's why all my public work happens with my hixie.ch address |
| 18:37 | <Hixie> | +y |
| 18:37 | <TabAtkins> | Ms2ger: Haha. Not a problem, since I'm *also* subscribed with my personal one. |
| 18:37 | <AryehGregor> | Ms2ger, in my experience that doesn't happen when forwarding between Gmail accounts, so I figure it wouldn't happen with google.com either. |
| 18:37 | <AryehGregor> | But yeah, corporate e-mail addresses get revoked when you no longer work there, that's true. |
| 18:37 | <TabAtkins> | AryehGregor: It does. I had to add a manual filter keeping @google.com addresses out of spam. |
| 18:37 | <AryehGregor> | For some reason, academic addresses seem to stick around forever. |
| 18:38 | <AryehGregor> | TabAtkins, might that be because of a bad SPF record? |
| 18:38 | <AryehGregor> | google.com. 3600 IN TXT "v=spf1 include:_netblocks.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all" |
| 18:38 | <TabAtkins> | Hmm... I need to check next time a tobacco promo or british lottery spam gets into my inbox, to see if that's why. |
| 18:38 | <AryehGregor> | It's softfail, so theoretically shouldn't break stuff, but it might factor into a heuristic of some kind. |
| 18:38 | <Philip`> | List mail from @google.com almost always gets marked as fraudulent in my Gmail |
| 18:38 | <TabAtkins> | I get one or two a day in that vein, which constantly surprises me. |
| 18:38 | <AryehGregor> | Yeah, because it gets sent by the list instead of google.com servers. |
| 18:38 | <AryehGregor> | That's why SPF is of limited use. |
| 18:39 | <AryehGregor> | DKIM is better that way, but also doesn't work with lists, which tend to append stuff to the mail. |
| 18:40 | <AryehGregor> | MikeSmith, okay, I gave him the URL you gave me. If it doesn't work, I guess he'll tell me. |
| 18:40 | <AryehGregor> | On a different note: the latest IEBlog post, about video, makes some fairly good points. |
| 18:41 | <AryehGregor> | It certainly fits with my theory that Microsoft is being basically honest about their motives to oppose WebM. |
| 18:41 | <MikeSmith> | AryehGregor: k |
| 18:41 | <AryehGregor> | (or not oppose it, but not support it fully either) |
| 18:42 | <TabAtkins> | Which points do you like about it? I thought it was really dishonest. |
| 18:42 | <AryehGregor> | 1) If there's really no patent risk, Google should indemnify everyone. Microsoft indemnifies customers against patent issues with Windows. |
| 18:43 | <AryehGregor> | 2) It should be an actual open standard, not just source code with non-normative documentation. |
| 18:43 | <AryehGregor> | 3) Embedded devices are still a problem. |
| 18:43 | <TabAtkins> | Of the three areas, (1) is ridiculous FUD because h.264 doesn't indemnify anyone either. (2) is reasonable, but there's no good reason to assume that we *won't* do so. (3) is stupid, because the plan is obviously *get everyone to support WebM*. |
| 18:44 | <AryehGregor> | H.264 has been around for a lot longer, and the patent pool draws patent trolls out of the woodwork -- they can join and get royalties instead of suing. Microsoft said they'd be okay with an MPEG-LA-style patent pool too, so it's not a double standard. |
| 18:44 | <TabAtkins> | And for 3, we have hardware partners releasing WebM decoders *right now*. |
| 18:45 | <Hixie> | wow, faulkner really doesn't understand how ATs work |
| 18:46 | <AryehGregor> | I'm hoping Google will eventually indemnify people for WebM. That would pretty much solve things, unless someone starts suing. |
| 18:46 | <AryehGregor> | Maybe they're only waiting a while to see if there are any lawsuits before they offer indemnification. I can hope. |
| 18:46 | <TabAtkins> | Hixie: Which failure are you talking about? |
| 18:47 | <Hixie> | the hgroup thing |
| 18:47 | <Hixie> | he seems to think that anything ARIA doesn't convey can't be conveyed by an AT |
| 18:47 | <TabAtkins> | Ah. I skimmed his emails there. |
| 18:47 | <TabAtkins> | That's... completely wrong. |
| 18:47 | <Hixie> | yeah |
| 18:47 | <Hixie> | oh well |
| 18:48 | <TabAtkins> | AryehGregor: I don't think it's SOP to indemnify these sorts of things, is it? |
| 18:50 | <AryehGregor> | TabAtkins, it's SOP to indemnify customers, at least. |
| 18:50 | <AryehGregor> | Unpaid users, maybe not, but since when is Google standard? |
| 18:53 | <TabAtkins> | Granted, but still, just because we're extraordinary in general doesn't mean we're extraordinary in every specific circumstance. |
| 18:53 | <TabAtkins> | (Though I would hope that we're not worse than ordinary anywhere, at least.) |
| 18:54 | <AryehGregor> | You don't have to be defensive. |
| 18:54 | <AryehGregor> | I'm just saying it's perfectly reasonable for Microsoft to not be willing to support WebM without some form of patent protection. |
| 18:54 | <TabAtkins> | Not trying to be. If we were face-to-face, you'd have noted me saying that with an amused tone. |
| 18:55 | <AryehGregor> | And that it's reasonable for it to object to being labeled by Google as anti-open web just because it supports H.264 and not WebM. |
| 18:55 | <AryehGregor> | (although it's anti-open web in various other ways, of course) |
| 18:55 | <TabAtkins> | Actually, I think that that latter point is still reasonable. Royalty-encumbered technologies are harmful to the open web. |
| 18:57 | <AryehGregor> | If they're not willing to use WebM or Theora because of patent fears, they have no choice. |
| 18:57 | <TabAtkins> | That doesn't reduce the badness of the decision. |
| 18:58 | <TabAtkins> | Something can be objectively bad even if it's personally the best you can do. |
| 18:59 | <AryehGregor> | You can't call it a bad decision, or fault them for it, if there are no other options. You only have a right to complain about the circumstances in that case, not the actor. |
| 18:59 | <AryehGregor> | E.g., it's not reasonable to fault Mozilla for supporting Flash. |
| 19:00 | <TabAtkins> | Eh, I disagree. I can still fault Mozilla while recognizing that they have no choice. |
| 19:00 | <TabAtkins> | As well, I can distinguish between the relative badness of different options. Flash is less bad than h.264 due to royalties. |
| 19:02 | <Ms2ger> | We have no choice partially because your employer's sites still use flash, TabAtkins ;) |
| 19:03 | <TabAtkins> | Ms2ger: I don't disagree! |
| 19:03 | <TabAtkins> | ^_^ |
| 19:07 | <TabAtkins> | Argh, list-style-* is badly designed. list-style-type should have just taken a <url> from the beginning, so we wouldn't need list-style-image. |
| 19:13 | <jgraham> | AryehGregor: academic email addresses generally die, in my experience |
| 19:13 | <AryehGregor> | After how long? |
| 19:14 | <AryehGregor> | And this is the US you're talking about? |
| 19:14 | <jgraham> | AryehGregor: Not the US and as soon as you leave |
| 19:14 | Ms2ger | has his for life |
| 19:14 | <jgraham> | I kept 1/2, my g/f 0/2 |
| 19:15 | <jgraham> | And I'm not sure that the 1 I kept doesn't violate some university policy |
| 19:15 | <AryehGregor> | I've kept both of mine so far even though I left. |
| 19:15 | <AryehGregor> | This is the US, though. |
| 19:15 | <jgraham> | Won't they run out of good names rather fast? |
| 19:15 | <TabAtkins> | I think mine still exists, but I set up an auto-forward to my personal while I was at college, so I'd have to actually go check. |
| 19:15 | <Ms2ger> | Yes |
| 19:16 | <jgraham> | (although we didn't have that problem due to systematic use of bad names for everyone) |
| 19:16 | <AryehGregor> | They number them. |
| 19:16 | <AryehGregor> | I'm agregor02 at CCNY and ag2837 at NYU. |
| 19:17 | <AryehGregor> | I'm gregor at Courant, but Courant probably only gives addresses to staff and grad students, so not such pressure. |
| 19:17 | <jgraham> | Ah, the NYU one has the same naming scheme as cam.ac.uk |
| 19:17 | <AryehGregor> | Although I get e-mail from Microsoft intended for Karen Gregor or something. |
| 19:17 | <AryehGregor> | I keep telling them to not send it to me, but the last time I did that, they told me it was hard to change their system and so I should just ignore it. |
| 19:17 | <AryehGregor> | I guess I'll flag it as spam from now on. |
| 19:18 | <AryehGregor> | Go Microsoft. |
| 19:18 | <AryehGregor> | (this is Microsoft Research) |
| 19:18 | <miketaylr> | i still get emails from NYU telling me that it's not a snow day |
| 19:18 | jgraham | would occasionally get email for the other James Graham in Astrophysics who is a rather well-known professor and got invited to give keynotes and things |
| 19:19 | <TabAtkins> | jgraham: Accept! |
| 19:19 | <AryehGregor> | miketaylr, me too! |
| 19:19 | <miketaylr> | :) |
| 19:20 | <AryehGregor> | Okay, so no browser reflects generated content in plaintext conversion (innerText or Selection.toString()). |
| 19:20 | <AryehGregor> | This seems like a bad thing to me. |
| 19:20 | <AryehGregor> | Opinions? |
| 19:21 | <jgraham> | innerText should die |
| 19:21 | <jgraham> | Was theat the opinion you were looking for? |
| 19:21 | <jgraham> | *that |
| 19:21 | <AryehGregor> | Then answer for Selection.toString(). |
| 19:22 | <jgraham> | Hmm. What do non-WebKit browsers do with Selection.toString()? |
| 19:22 | <Ms2ger> | That should die |
| 19:22 | <AryehGregor> | Really? Why? |
| 19:22 | <bfrohs> | From an end-user/author standpoint, I believe generated content should be included. |
| 19:22 | <AryehGregor> | bfrohs, me too. |
| 19:22 | <AryehGregor> | jgraham, I'm testing both innerText and toString together. http://aryeh.name/spec/innertext/test/innerText.html |
| 19:22 | <AryehGregor> | Maybe you can tell me why the latter doesn't work in Opera. |
| 19:24 | <jgraham> | AryehGregor: Since I was previously unaware it was supposed to work, maybe it is just unimplemented |
| 19:24 | <jgraham> | Does it work in IE? |
| 19:24 | <AryehGregor> | Yes. |
| 19:24 | <AryehGregor> | It's documented in DOM Range, although there's no actual spec for it. |
| 19:25 | <AryehGregor> | Or rather there was, but it was defined in terms of Range stringification, where a) that's wrong and b) Range stringification wasn't itself defined. |
| 19:25 | <AryehGregor> | Now I've defined Range stringification, so it's well-defined but wrong. :) |
| 19:25 | <AryehGregor> | (which I've noted in the spec) |
| 19:25 | <jgraham> | Yay DOM specs |
| 19:25 | <jgraham> | Do we have any evidence of people using this? |
| 19:27 | <AryehGregor> | Yes, e.g.: http://www.mediawiki.org/wiki/User:Catrope/W3C_Range_feature_requests#Newline_handling_in_stringification_of_getSelection.28.29 |
| 19:27 | <AryehGregor> | That implies it's probably used on Wikipedia, at least. |
| 19:27 | <gsnedders> | jgraham: Doesn't work in what way? |
| 19:27 | <gsnedders> | AryehGregor, even |
| 19:28 | gsnedders | is too tired |
| 19:28 | <AryehGregor> | gsnedders, "Actual Selection stringification" is always the empty string for me. |
| 19:28 | <AryehGregor> | That part works in all the other browsers I tried it in (obviously other than IE8). |
| 19:28 | <AryehGregor> | How do you get a dev console in Opera? |
| 19:29 | <AryehGregor> | Ah, found it. |
| 19:29 | <AryehGregor> | No errors there that I see, though. |
| 19:29 | <gsnedders> | AryehGregor: selection.toString() seems to work here |
| 19:30 | <AryehGregor> | gsnedders, what's wrong here? http://aryeh.name/spec/innertext/test/innerText.html |
| 19:30 | <gsnedders> | jgraham: ebay apparently uses it |
| 19:30 | <AryehGregor> | Maybe what I'm doing is somehow ending up being an empty selection in Opera. |
| 19:31 | <gsnedders> | Probably something with ranges |
| 19:37 | <AryehGregor> | Well, if anyone can pinpoint the problem, I'll be able to compare to Opera's toString() behavior. |
| 19:37 | <AryehGregor> | Otherwise I won't bother, which is okay, because Opera's behavior is probably the least compatible. |
| 19:37 | <AryehGregor> | (except maybe for IE9) |
| 19:41 | <AryehGregor> | If s is a string, what does s[0] = "x"; do? It seems to do nothing. |
| 19:41 | <annevk> | webr3, you cannot just say "why not start over?" |
| 19:42 | <AryehGregor> | I'd expect it to change the first character of the string. |
| 19:42 | <AryehGregor> | Or at least throw an error. |
| 19:42 | <annevk> | webr3, if you cannot see how unrealistic that is, you have not learned much on that front yet |
| 19:43 | <jgraham> | Javascript strings are immutable |
| 19:43 | <annevk> | webr3, maybe the former XHTML2 WG members can shed some light on that -- that was a rather small-scale attempt at starting over one part of the platform |
| 19:43 | <jgraham> | and it generally doesn't throw errors |
| 19:43 | <AryehGregor> | So that statement actually silently does nothing? |
| 19:43 | <jgraham> | So it's not very surprising behaviour |
| 19:43 | <AryehGregor> | <3 JS |
| 19:45 | <AryehGregor> | Okay, so I'm going to go ahead and require that browsers include generated content in plaintext conversion, even though no one does it. |
| 19:47 | <AryehGregor> | Is there a dev version of generated content? |
| 19:47 | <AryehGregor> | I'm only seeing a WD from 2003, edited by Hixie. |
| 19:47 | <annevk> | generated content as part of copy & paste? |
| 19:48 | <annevk> | hmm |
| 19:48 | <AryehGregor> | Yes. It makes the most sense from a user perspective. |
| 19:48 | <annevk> | are you copying all other style information too? |
| 19:48 | <AryehGregor> | Also, it means I don't have to special-case <br>, which is nice because so far I haven't had to special-case any HTML element or attribute. |
| 19:48 | <AryehGregor> | What does that mean? This is conversion to plaintext. |
| 19:48 | <AryehGregor> | So most style info will be lost. |
| 19:48 | <AryehGregor> | But the output depends on CSS in a whole bunch of ways. |
| 19:48 | <annevk> | oh wait |
| 19:49 | <annevk> | I doubt you can do that for innerText |
| 19:49 | <AryehGregor> | Why? |
| 19:49 | <annevk> | compat of course |
| 19:49 | <AryehGregor> | Really? |
| 19:49 | <annevk> | generally also, copying generated content is somewhat controversial |
| 19:49 | <annevk> | at least it used to be |
| 19:49 | <AryehGregor> | How many authors use generated content, and how can they depend on its behavior when it's so inconsistent and doesn't even exist in Firefox? |
| 19:50 | <AryehGregor> | I guess I won't add it to the spec yet. |
| 19:50 | <AryehGregor> | I'll leave an XXX. |
| 19:50 | <annevk> | AryehGregor, yeah, e.g. with list items you would get the bullet and such suddenly |
| 19:50 | <TabAtkins> | What do you mean? Generated content exists in firefox, though only in list items and ::before and ::after. |
| 19:50 | <annevk> | because list items will eventually be done using some kind of generated content |
| 19:50 | <annevk> | through ::marker or some such |
| 19:50 | <TabAtkins> | annevk: I'm speccing it right now! |
| 19:50 | <annevk> | if that gets copied, fail |
| 19:50 | <annevk> | at least for innerText it's fail |
| 19:50 | <annevk> | TabAtkins, :) |
| 19:51 | <AryehGregor> | All right, I'll leave it alone for now. |
| 19:52 | <annevk> | AryehGregor, I don't really want you to stop from exploring it, it might be interesting, definitely for copy & paste, but it's hairy :) |
| 19:53 | <AryehGregor> | I'll consider later. |
| 19:53 | <AryehGregor> | Since no one does it, I'll have to ask some implementers what they think before I add it. |
| 19:53 | <AryehGregor> | They might object. |
| 20:00 | <TabAtkins> | Hm, I wonder if current browsers render the 'square' list style with different characters... |
| 20:20 | <webr3> | annevk, ack I can see how it'd take an incredibly long time and much effort to reverse / address even partially, but it'd be worth it :) as for XHTML 2.0 you're not confusing me (a web developer who just wants to make some client side apps runnign over a web of data in html+js) with an academic who's in namespace and xml land are ya? |
| 20:20 | <webr3> | probably worth noting that I /don't/ think namespaces are a good thing, and would like to see them transitioned away from quite swiftly (I'd just pull them now if i could) |
| 20:55 | <AryehGregor> | If a function returns a list with a fixed number of elements, is there a convenient way to unpack it, like "a, b = f()" in Python or "list($a, $b) = f();" in PHP? |
| 20:55 | <AryehGregor> | Or do I just have to use a temporary? |
| 20:56 | <Ms2ger> | [a,b] = f() |
| 20:56 | <Ms2ger> | Might be Mozilla-only |
| 20:57 | <roc> | only Spidermonkey implements that right now |
| 20:57 | <Ms2ger> | Also, function f({foo: bar, baz: quux}) { w(bar); w(quux) } |
| 21:05 | <TabAtkins> | AryehGregor: It's a harmony feature, which Moz does now, and v8 will be doing in the near future. |
| 21:06 | <AryehGregor> | Yay. |
| 21:07 | <TabAtkins> | You can unpack to a list, or an object, and when doing lists you can get rest parameters. |
| 21:07 | <TabAtkins> | [a,...b] = foo(); |
| 21:08 | <TabAtkins> | If foo() returns [1,2,3], a=1, b=[2,3] |
| 21:10 | <TabAtkins> | Hrm. Anyone know how to get the permalink to a tweet in NewTwitter? |
| 21:14 | <bfrohs> | TabAtkins: Click the date (or # hours ago) |
| 21:15 | <bfrohs> | TabAtkins: ...and then take out #!/ if you want it to be accessible. |
| 21:15 | <TabAtkins> | bfrohs: Thanks! It wasn't obvious that was a link. |
| 21:15 | <TabAtkins> | Yeah. |
| 21:16 | <AryehGregor> | othermaciej, roc (or other WebKit/Gecko people): who would be good people to talk to about the convert-to-plaintext algorithms (innerText/Selection.toString()) in WebKit/Gecko? |
| 21:16 | <AryehGregor> | In terms of how they work and reviewing my spec so far. |
| 21:17 | <AryehGregor> | And discussing possible changes like handling of generated content. |
| 21:17 | <roc> | jonas maybe? |
| 21:18 | <roc> | maybe ehsan |
| 21:30 | <AryehGregor> | I'll just post it to whatwg. |
| 21:31 | <othermaciej> | AryehGregor: enrica probably knows a lot about it but I'm not sure she has time to explain in much detail |
| 21:31 | <AryehGregor> | Anyone who you'd suggest I CC on my whatwg post? |
| 21:31 | <othermaciej> | AryehGregor: generated content + editing (including basic things like selection and copying) is a world of hurt |
| 21:32 | <AryehGregor> | Well, that's what I've been assigned to spec. :) |
| 21:32 | <AryehGregor> | In fact, the last specific thing I'm supposed to do is spec execCommand(). |
| 21:32 | <AryehGregor> | Should be fun. |
| 21:32 | <othermaciej> | in most browsers I think even selection behavior for generated content is not sane |
| 21:34 | <jamesr___> | it's definitely not in WebKit |
| 22:18 | <TabAtkins> | Oh, wow. Very clever, Hixie, in your CSS usage in the Hebrew example in the lists module. |
| 22:19 | <TabAtkins> | (Setting tbody { display:table; float:left; } to get a multicolumn table. |
| 22:21 | <Hixie> | TabAtkins: heh |
| 22:26 | <TabAtkins> | Only problem is that it breaks the display of thead, at least in Chrome. Hm. |
| 22:26 | <TabAtkins> | Oh, because you display:none'd it. Never mind. |
| 22:26 | <Hixie> | i do that quite often |
| 22:26 | <Hixie> | i display:noned the thead in the atob table recently too |
| 22:27 | <Hixie> | but for that one i used the multicol module to get columns |
| 22:27 | <Hixie> | not the tbody trick |
| 22:27 | <Hixie> | and for some reason it's not rendering right |
| 22:27 | <Hixie> | dunno what's up with that |
| 22:28 | <TabAtkins> | Not surprised that multicol and tables work oddly together. |
| 22:29 | <Hixie> | yeah there's all kinds of bugs with it |
| 22:29 | <Hixie> | multicol+abspos+table+:hover breaks in the named char ref table too |
| 22:29 | <TabAtkins> | It's pretty undefined, I think, what multicol is supposed to do with other layout modes inside of it. |
| 22:29 | <TabAtkins> | There's nothing sensible about a multicol containing a flexbox, frex. |
| 22:30 | <TabAtkins> | I think it needs to work with the same mechanism as multipage (which is also undefined ;_;). |
| 22:33 | <Hixie> | is kyle simpson here by any chance? |
| 23:05 | <TabAtkins> | Hixie: The intent of accept=image/*, etc is that browsers can let the user record an image with their webcam, right? |
| 23:06 | <TabAtkins> | If so, could you add a note to that effect? It's not at all obvious that this is intended to be a hint to offer protected hardware access. |
| 23:06 | <TabAtkins> | I can send an email if necessary. |
| 23:07 | <Hixie> | e-mail would be good, i'm deep in script land |
| 23:07 | <TabAtkins> | kk |
| 23:08 | <Hixie> | trying to translate hsivonen's suggestion into something that's readable in the spec |
| 23:08 | <Hixie> | which is proving harder than i'd hoped, partly because the simplest way to avoid triple-negatives is to reverse the meaning of his flag |
| 23:08 | <Hixie> | from force-async to honour-async |
| 23:08 | <Hixie> | and revert all the logic accordingly |
| 23:08 | <TabAtkins> | You can't use a single negative? |
| 23:09 | <Hixie> | they're not actually negatives |
| 23:09 | <Hixie> | they're exceptions and stuff |
| 23:10 | <Hixie> | either i have to have the flag be set to false then set to true in a whole bunch of complicated cases, or i can have the opposite flag default to false and have it set to true in a single case |
| 23:11 | <TabAtkins> | Oh, if it's just a flag then reverse away. |
| 23:11 | <Hixie> | hsivonen doesn't like it when i make editorial changes to his proposals |
| 23:11 | <TabAtkins> | Too bad! |
| 23:11 | <Hixie> | hrm, hsivonen's proposal makes document.write() work different than innerHTML |
| 23:12 | <Hixie> | i wonder why he did that |
| 23:13 | <Hixie> | hm, in fact his proposal states something that's false (that innerHTML doesn't set parser-inserted). odd. |
| 23:14 | <Hixie> | man, i really don't like this script.async crap |
| 23:15 | <Hixie> | i hope the people who think the spec matches exactly what i want are watching |
| 23:17 | <Dashiva> | Hixie: In the interest of stating the obvious, even if they did they wouldn't admit it :P |
| 23:17 | <Hixie> | yeah, i know |
| 23:19 | <Hixie> | i guess it's kinda funny that nobody wants the spec to look like it is, but some people feel they somehow deserve to have the spec say what they want, and they therefore accuse me of having the spec say what I want |
| 23:20 | <Hixie> | it's like they assume that because they don't have what they want, and because I'm the one denying them what they want, I must be getting what _I_ want. |
| 23:21 | <MikeSmith> | http://en.wikipedia.org/wiki/Psychological_projection |
| 23:22 | <MikeSmith> | esp. http://en.wikipedia.org/wiki/Psychological_projection#Counter-projection |
| 23:22 | <MikeSmith> | "an obsession to continue and remain in a recurring trauma-causing situation and the compulsive obsession with the perceived perpetrator of the trauma or its projection" |
| 23:30 | <AryehGregor> | Yay: https://grepular.com/Abusing_HTTP_Status_Codes_to_Expose_Private_Information |
| 23:30 | <AryehGregor> | Is that known? |
| 23:32 | <Hixie> | abarth: thanks (re mail) |
| 23:32 | <abarth> | np |
| 23:34 | <TabAtkins> | AryehGregor: It's known in that I knew about it on the 21st. |
| 23:34 | <Hixie> | AryehGregor: interesting. Seems like an easier-to-fix problem than the cache attack |
| 23:34 | <Hixie> | where you time how long it takes to download an image from a particular site |
| 23:34 | <Hixie> | and if that time is low, you assume the user went there |
| 23:34 | <karlcow> | AryehGregor: yeah I posted it a few days ago |
| 23:35 | <Hixie> | i guess if we want to fix this we just make onerror/onload for images only fire same-origin |
| 23:39 | <AryehGregor> | I wonder how many sites that will break. |
| 23:40 | <TabAtkins> | Hixie: Just make images only load same-origin. |
| 23:41 | <roc> | hahaha |
| 23:42 | <roc> | making onerror/onload only fire for same-origin images won't help here |
| 23:42 | <roc> | at least not for the GMail case |
| 23:42 | <roc> | you can inspect the size of the image to find out of it loaded or not |
| 23:43 | <AryehGregor> | This is why we need a "no hotlinking" header. |
| 23:43 | <AryehGregor> | What's the story on that? Anyone working on it? |
| 23:43 | <AryehGregor> | I guess you could ask why not use Referer/Origin sniffing. |
| 23:44 | <gsnedders> | AryehGregor: could you not do something with CORS, and make it possible to have a default * mode? |
| 23:44 | <Hixie> | roc: true |
| 23:44 | <roc> | did you read the conversation about this yesterday? :-) |
| 23:44 | <AryehGregor> | Didn't I participate? |
| 23:44 | <AryehGregor> | (toward the end) |
| 23:44 | <roc> | AryehGregor: not without annevk getting on your case :-) |
| 23:44 | Hixie | did not |
| 23:44 | <roc> | er, that was for gsnedders |
| 23:44 | <AryehGregor> | In the end, is anyone working on either specs or implementations for such a feature, and if not, why not? |
| 23:44 | <gsnedders> | roc: No :) |
| 23:44 | <AryehGregor> | It sounds really simple. |
| 23:45 | <MikeSmith> | gsnedders, jgraham, whoever else might be interested - http://www.wirfs-brock.com/allen/things/es5-technial-notes-and-resources |
| 23:47 | <roc> | AryehGregor: Referer/Origin sniffing has two problems: a) it's harder to deploy (you need to read and process headers instead of just sending a static header), and b) making the decision in the browser means it works even if someone strips Origin headers in the network (which they might do for reasonable privacy reasons) |
| 23:47 | <AryehGregor> | Right. |
| 23:47 | <AryehGregor> | I'm all for a new header. |
| 23:47 | <AryehGregor> | So is there some reason no one's working on it? |
| 23:48 | <roc> | yes |
| 23:48 | <roc> | we're all very very busy |
| 23:48 | <gsnedders> | Busy? I missed a CSS WG telecon today because I was drinking. |
| 23:48 | <roc> | ok, except for those Opera guys |
| 23:48 | <AryehGregor> | Does anything important happen in CSS WG telecons, or are they like HTML WG telecons? |
| 23:49 | <TabAtkins> | gsnedders: It wasn't useful today. |
| 23:49 | <gsnedders> | AryehGregor: A fair number of decisions are made on them, so yes |
| 23:49 | <TabAtkins> | AryehGregor: They're usually at least moderately useful. The past few months have been almost entirely about CSS2.1 testsuite issues, though. |
| 23:49 | <gsnedders> | roc: Hey, I am a student 100% of the time, so I'm meant to behave like that. :P |
| 23:50 | <TabAtkins> | Today was about a few 2.1 things, then we spent the rest of the time talking about Speech because the editor doesn't realize he can make decisions now and let people object later. |
| 23:51 | <othermaciej> | AryehGregor: I might work on proposal for and/or WebKit implementation of an anti-hotlinking header |
| 23:51 | <AryehGregor> | Yay. |
| 23:52 | <othermaciej> | I only thought of it a few days ago, so haven't actually done anything on it yet |
| 23:52 | <TabAtkins> | I still think an anti-hotlinking header is putting the complexity on the wrong case, but I'm okay with it because it's so simple and it can be used on general resources. |
| 23:53 | <AryehGregor> | What's your preferred alternative? |
| 23:53 | <othermaciej> | well, for defense against image hotlinking, it seems like the only plausible solution |
| 23:53 | <TabAtkins> | @font-face always using SOP, then relaxing that with CORS. |
| 23:53 | <AryehGregor> | It makes more sense to be same-origin by default, but that ship sailed about 18 years ago. |
| 23:53 | <othermaciej> | and image hotlinking is the main in-the-wild case of bandwidth abuse |
| 23:53 | <TabAtkins> | But that's not generalizable, shrug. |
| 23:53 | <AryehGregor> | @font-face is likely to never be a major source of information leaks or bandwidth leeching compared to <img>. |
| 23:54 | <TabAtkins> | Dude, fonts are huge. |
| 23:54 | <AryehGregor> | They're unlikely to be hotlinked as much as images. |
| 23:55 | <othermaciej> | Limit-Embedding-To-Origins could also serve as a clickjacking mitigation |
| 23:55 | <AryehGregor> | Image: want amusing cat picture for forum post -> Google Image Search -> copy URL from navigation bar. |
| 23:55 | <TabAtkins> | othermaciej: By preventing an <iframe>? |
| 23:55 | <othermaciej> | yeah |
| 23:56 | <Philip`> | If an anti-hotlinking header just blocks the image loading, it wouldn't satisfy the use case of sending disturbing images to hotlinkers |
| 23:56 | <Philip`> | Maybe the header should give a URL of an alternative image to load |
| 23:56 | <TabAtkins> | True, but that doable with roughly the same difficulty. |
| 23:57 | <othermaciej> | but more flexibly than x-frame-options |
| 23:57 | <TabAtkins> | It's just an easy redirect line in your .htaccess. |