| 00:07 | <sebmarkbage> | Anything needing to embed image or video. I should be able to use them in img, video, css or canvas. I like the URI approach since it's ubiquitous. |
| 00:31 | <Hixie> | good lord |
| 00:31 | <Hixie> | what a lot of new feedback |
| 00:35 | <hober> | yeah, that teal line has been trending upward for quite a bit there |
| 00:39 | <sebmarkbage> | Hixie: Where is the most appropriate place to leave new feedback? Forums? Mailing list? |
| 00:43 | <Hixie> | mailing list is most ideal |
| 00:43 | <Hixie> | see the top of the spec for details |
| 01:15 | <sebmarkbage> | Has there been any talk about explicitly specifying various mouse gestures? Like iPhone pinch could trigger onzoomin/onzoomout. I also think it'd be good to have something like draggable="gesture" that'd only trigger events on the source node. |
| 01:38 | <Hixie> | sebmarkbage: that's more of a suggestion for the events work -- www-dom⊙wo |
| 01:40 | <heycam> | sebmarkbage, and i think olli pettay sent a mail to public-webapps or www-dom recently asking if there was any interest in speccing gesture/touch events |
| 01:42 | <sebmarkbage> | thx. I will look through the archives. |
| 07:20 | <MikeSmith> | hsivonen: I'm getting build errors after syncing up to latest v.nu sources |
| 07:20 | <MikeSmith> | ./syntax/relaxng/datatype/java/src/org/whattf/datatype/MicrodataIdentifier.java:32: package com.sun.org.apache.xerces.internal.dom3.as does not exist |
| 07:21 | <hsivonen> | MikeSmith: sorry. Eclipse has beeing doing random autocomplete again |
| 07:21 | <hsivonen> | MikeSmith: fixing |
| 07:22 | <MikeSmith> | thanks |
| 07:22 | <MikeSmith> | dispense with the IDE, man. that's stuff for sissies :) |
| 07:23 | <hsivonen> | MikeSmith: does it work now? |
| 07:24 | <hsivonen> | I read comments on Zeldman's blog and now I'm having a "someone's wrong on the Internet" moment again |
| 07:25 | <hsivonen> | appeals to the TAG even: http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-44699 |
| 07:30 | <MikeSmith> | hsivonen: works now -- thanks |
| 07:35 | <MikeSmith> | hsivonen: which part of the v.nu is emitting the new warnings? |
| 07:35 | <MikeSmith> | nm |
| 07:35 | MikeSmith | finds syntax/non-schema/java/src/org/whattf/checker/ConformingButObsoleteWarner.java |
| 09:15 | nessy | giggles at the whattf directory :) |
| 09:17 | <takkaria> | the zeldman comments are pretty amazing |
| 09:18 | <MikeSmith> | takkaria: in what way? |
| 09:18 | <takkaria> | there's somsone there claiming they're going to have to relearn most of the stuff they know to the code a website with the advent of HTML5 |
| 09:19 | <MikeSmith> | ah |
| 09:19 | <hsivonen> | I guess my comment is still in a moderation queue. |
| 09:20 | hsivonen | wishes blog comment systems said "Your comment is awaiting moderation" when it is |
| 09:20 | <hsivonen> | the commenter using the handle "Luke" is onto something |
| 09:21 | <hsivonen> | too bad (s)he feels the need to post anonymously |
| 09:22 | <hsivonen> | http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-44679 |
| 09:23 | <Hixie> | who used the "it will help screen readers" line? |
| 09:24 | <Hixie> | of the new sectioning elements, only <nav> has been put forward as being able to help screen reader users, as far as i'm aware |
| 09:25 | <hsivonen> | Hixie: hasn't footer been, too? and every one of them by the logic that if ARIA landmarks help, the HTML5 structural elements should, too |
| 09:25 | <takkaria> | apparently adding role="" is a much more incremental step than <header>/<nav>/ et all |
| 09:25 | <Philip`> | People have talked about using the sectioning elements to do an automatic "skip to content", which mainly helps screen reader users |
| 09:26 | <jgraham> | Better outlining seems like it wwould help screenreader users, as does "skip to next article" even without good use of headings |
| 09:26 | <hsivonen> | Philip`: Opera Mobile has a heuristic "skip to content" feature |
| 09:26 | <Philip`> | hsivonen: Does it work better than e.g. Opera's "next page" heuristic? |
| 09:26 | <hsivonen> | Philip`: presumably this stuff could tie into that feature, too |
| 09:27 | <hsivonen> | Philip`: it works amazingly well. I wish Mini had it, too. |
| 09:28 | <Hixie> | man i can't wait til blogs are all federated across wave |
| 09:28 | <Hixie> | it would make tracking these comments and responding properly so much easier |
| 09:28 | <hsivonen> | maybe that happens when all Java jar dependencies are federated over Maven |
| 09:29 | jgraham | onders if wave uses the term "federated" because it sounds vaugely like something from Star Trek so subconciously suggesting 23rd Century technology |
| 09:29 | <Philip`> | Hixie: Can't you just follow the RSS comment feeds? |
| 09:29 | <Hixie> | i can't respond to RSS comment feeds and have them appear in the other person's RSS feed |
| 09:30 | <hober> | jgraham: we just need a wave app on our communicators, err, iphones. |
| 09:30 | <Hixie> | jgraham: it uses it because that's what jabber uses, iirc |
| 09:30 | <jgraham> | OK, well s/wave/jabber/ in the above then :) |
| 09:30 | <Hixie> | no idea |
| 09:31 | <hsivonen> | I tend to get an enterprisey vibe from "federated" |
| 09:31 | <hsivonen> | probably from associations with WS-* stuff |
| 09:32 | <hsivonen> | I do think that federated SSO, chat, etc. are good |
| 09:32 | <Hixie> | "enterprise" also has the startrek feel :-P |
| 09:32 | <hsivonen> | heh |
| 09:32 | <hsivonen> | WS-* has a StarWars feel, though :-) |
| 09:33 | <jgraham> | Yeah. Talking about things being "federated to your enterprise" seems like a winning strategy because it allows CEOs to like out their Picard fantasy |
| 09:33 | <jgraham> | s/like/live/ |
| 09:39 | hsivonen | gestures angrily in the general direction of whoever invented the syntactic sugar for declaring multiple variables in one declarator |
| 10:05 | <zcorpan> | Hixie: Scripts that modify the page as it is being parsed - is not error handling |
| 10:05 | <Hixie> | yeah but there's no doctype! |
| 10:06 | <zcorpan> | the section doesn't discuss the doctype :) |
| 10:10 | <Lachy> | Hixie, John Allsop may have a valid point about the <footer> content model that he mentioned here http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-44699 - Sites like YouTube and Flickr group the links in their footers by category. Although they currently use table layouts to achieve it, it seems reasonable to do that with sections |
| 10:10 | <Hixie> | zcorpan: details! :-P |
| 10:10 | <Hixie> | zcorpan: (i'm happy to change that section title if you can find a better one -- drop me a mail) |
| 10:11 | <Hixie> | Lachy: those are <section>s. They're at best paragraphs. |
| 10:11 | <Hixie> | maybe <dl>s |
| 10:11 | <Lachy> | ok |
| 10:12 | <Lachy> | well, I'm not sure if they're the type of sites he's referring to though. That's just the closest I could find that matches his description |
| 10:12 | <Hixie> | well when he sends his feedback like he told me he would we'll see :-) |
| 10:16 | <zcorpan> | Hixie: i think it is now undefined what document.bgcolor does when document.body *is* a frameset |
| 10:16 | <Hixie> | zcorpan: send mail, i'm in the middle of a massive edit |
| 11:12 | <gsnedders> | Hixie: http://www.whatwg.org/specs/web-apps/current-work/ is missing header-whatwg |
| 11:13 | <Hixie> | yeah |
| 11:13 | <Hixie> | i'm rewriting the script |
| 11:13 | <Hixie> | it still has bugs |
| 11:15 | gsnedders | looks at the W3C version instead |
| 11:16 | <MikeSmith> | Hixie: btw, I plan to write a cron job that will generate a multipage version of the W3C copy |
| 11:16 | <MikeSmith> | I meant to do it today, but didn't |
| 11:17 | <MikeSmith> | today being, it's 19:20 here and I need to get some food and alcohol of some form |
| 11:18 | <MikeSmith> | but to give a heads-up, I would like to also set up a .htaccess file so that the index file for the multipage version becomes the default |
| 11:18 | <MikeSmith> | with a link to the single-page one |
| 11:19 | <Hixie> | k |
| 11:19 | <MikeSmith> | which I realize might break some people's bookmarks and such |
| 11:20 | <MikeSmith> | I'm mentioning because when I do get it set up, I would need for you to add the link on the single-page version |
| 11:20 | <MikeSmith> | your source, I mean |
| 11:20 | gsnedders | also set up http://gsnedders.html5.org/html5.txt semi-jokingly |
| 11:21 | <MikeSmith> | gsnedders: there's at least one SDO I know of for which that format looks optimized |
| 11:21 | <MikeSmith> | good job |
| 11:22 | <hsivonen> | gsnedders: how are you generating it? Lynx? |
| 11:22 | <gsnedders> | MikeSmith: But we don't have all the proper form feed characters and such like in the right place |
| 11:22 | <gsnedders> | hsivonen: yeah |
| 11:22 | <hsivonen> | gsnedders: it has a very IETF-like flavor |
| 11:24 | <MikeSmith> | gsnedders: I think I like link #19944 best |
| 11:24 | <gsnedders> | MikeSmith: I quite like #772 |
| 11:25 | <MikeSmith> | ah yes, good old #772 |
| 11:25 | <MikeSmith> | solid gold |
| 11:26 | <MikeSmith> | zen-like |
| 11:28 | <MikeSmith> | but outside of that instance, the combination of plain text with ridiculously long fragment IDs has its own kind of aesthetic quality |
| 11:28 | <Philip`> | MikeSmith: The WHATWG multipage one has a script that ensure bookmarks to /#foo will get redirected to /bar.html#foo etc |
| 11:28 | <MikeSmith> | (scare quotes implied in my statement above) |
| 11:28 | <MikeSmith> | Philip`: OK, maybe I can make use of that |
| 11:28 | <MikeSmith> | after I actually get around to doing it |
| 11:29 | <MikeSmith> | instead of just talking about, repeatedly |
| 11:29 | <Philip`> | If you talk about doing the work enough times, someone else will do the work to shut you up |
| 11:30 | <MikeSmith> | great strategy |
| 11:30 | <MikeSmith> | I will try that |
| 11:30 | <MikeSmith> | will try it later |
| 11:30 | <MikeSmith> | in the mean time, I noticed that the beer clock rang 90 minutes ago |
| 11:31 | <MikeSmith> | so I must depart |
| 11:31 | <gsnedders> | MikeSmith: Good bye, fair well, and best wishes for your future life! |
| 11:32 | MikeSmith | fires up his chopper and heads to the rock shop |
| 11:36 | <Hixie> | gsnedders: ok, it should be ok again |
| 11:49 | <gsnedders> | getComputedStyle returns interesting values for iframes |
| 11:50 | <Hixie> | self.numberOfSpecs += 1 |
| 11:53 | <hsivonen> | http://www.w3.org/mid/A7420EAA6B164D40A3D94E082C4D2773@JukanPC |
| 11:53 | <hsivonen> | last paragraph |
| 11:54 | <Hixie> | o_O |
| 11:54 | <hsivonen> | I could well imagine Jukka blasting us for making it valid had we done that |
| 11:54 | <Hixie> | he wants the character references that refer to numbers that aren't the specified numbers to be conforming? |
| 11:55 | <Hixie> | i don't understand that e-mail |
| 11:55 | <Hixie> | he says it's undefined but it should be allowed? |
| 11:55 | <Hixie> | how does that even make sense |
| 11:56 | <hsivonen> | Hixie: maybe you could ask him what he wants |
| 11:56 | <Hixie> | since he thinks html5 is pointless, i don't see much point asking him |
| 11:57 | <hsivonen> | fair enough |
| 11:57 | <hsivonen> | when did Jukka flip the bozo bit on us? |
| 11:59 | <hsivonen> | I need some kind of Mail.app trick for dealing with duplicate email on 3 mailing lists plus self |
| 12:00 | <Hixie> | route your mail through gmail |
| 12:00 | <Hixie> | it filters dupes |
| 12:01 | <Hixie> | dunno when jukka flipped the bit, but it was a while back |
| 12:01 | <Hixie> | ok i now have less e-mail on the pile than this morning. Only by 3 e-mails, but still. |
| 12:01 | <Hixie> | bed time |
| 12:01 | <Hixie> | nn |
| 12:45 | <takkaria> | hm, I just discvered the CSS property table-layout |
| 12:46 | <takkaria> | I wonder how I've gone so long without knowing it exists |
| 12:47 | <takkaria> | I think I'd actually have preferred not to know about it... |
| 12:47 | <RyanRoberts> | FF2 supports it so probably a while ;) |
| 12:49 | <jgraham> | hmm I'm not sure I remember that one either |
| 12:49 | <jgraham> | Well I have a vauge memory of having encountered it before |
| 12:50 | <RyanRoberts> | actually I maybe mistaken |
| 12:51 | <takkaria> | table-layout: fixed is an abomination, it lets you tell tables to not pay attention to the size of the content of its cells when calculating layout |
| 12:52 | <RyanRoberts> | it's CSS2 isn't it? I rarely use tables so not used it often but I'm sure I've come across it. |
| 12:52 | <takkaria> | yeah, css2 |
| 12:55 | <jgraham> | I guess someone decided that the default algorithm was slow/complex/hard to specify and thought "I know why don't we add an option" |
| 12:55 | <jgraham> | But the mailing list archives don't turn anything up |
| 13:02 | <Lachy> | takkaria, table-layout: fixed; actually has some benefits. You just have to be careful about how you use it. |
| 13:02 | hsivonen | wonders if Google has criteria for phasing out support for old browser versions |
| 13:03 | <Philip`> | Revenue from ads for old browsers users < cost of supporting old browser versions, perhaps |
| 13:04 | <Lachy> | takkaria, one benefit is that it makes table columns equal width by default, which is otherwise difficult to achieve when the number of columns can vary but you always want the table to be a set width regardless |
| 13:05 | <Philip`> | http://philip.html5.org/tests/canvas/suite/tests/results.html uses table-layout:fixed |
| 13:06 | <hsivonen> | I wonder how much RAM I'd need not to beach ball all the time |
| 13:07 | <Lachy> | hsivonen, how much RAM do you have? |
| 13:08 | <hsivonen> | 4 GB |
| 13:08 | <Lachy> | which apps are causing the beach ball so frequently? |
| 13:09 | <hsivonen> | I guess the combination of multiple browsers, IDEs and operating systems |
| 13:09 | <jgraham> | virtual machines that reserve large chunks of RAM are a killer |
| 13:09 | <Lachy> | oh. yeah, if you keep multiple OSs running in VMs all the time, there's not much you can do about it |
| 13:09 | <Philip`> | You could get faster swap space |
| 13:10 | <Lachy> | although, it wouldn't hurt upgrading to a new machine with 8GB or RAM |
| 13:10 | <jgraham> | Can you use SSDs as swap yet? and does that work well? |
| 13:10 | <Philip`> | jgraham: Why would you have ever been unable to? |
| 13:10 | <hsivonen> | Lachy: Macs that can host more than 4 GB of RAM are expensive and large |
| 13:11 | <jgraham> | Philip`: Because they didn't exist. ALso because they had very poor rewrite characteristics |
| 13:11 | <Lachy> | hsivonen, the new MacBook Pro's support 8GB. Just buy your RAM from a 3rd party supplier, instead of through Apple |
| 13:11 | <jgraham> | (like they would die after an alarmingly small number of rewrites) |
| 13:11 | <hsivonen> | oh. I was unaware of MacBook Pro accepting 8 GB |
| 13:12 | <hsivonen> | perhaps I should pay up and get one of those |
| 13:12 | <Lachy> | yeah, as of the most recent update, they do |
| 13:12 | <jgraham> | hsivonen: Would it actually be a blocker for you to use a Mac Pro as your main development machine and just use a laprop when travelling? |
| 13:12 | <jgraham> | THat seems like a more sensible solution |
| 13:13 | <hsivonen> | jgraham: Mac Pro seems like an overkill in every dimension except RAM |
| 13:14 | <jgraham> | hsivonen: Hmm. It just seems worryingly shortsighted to upgrade to a machine in order to use its maximum amount of RAM |
| 13:15 | <jgraham> | Since probably in 1 year you will want more again |
| 13:15 | <Lachy> | hsivonen, a dual Quad Core Mac Pro with 32 GB of RAM would be awesome! |
| 13:17 | <hsivonen> | I could also try running a manual garbage collection of my Firefox tabs once in a while |
| 13:17 | <hsivonen> | the annoying part is that closing multiple tabs beach-balls Firefox |
| 13:22 | <gsnedders> | What's the W3C IRC server? |
| 13:22 | <hsivonen> | irc.w3.org with weird port |
| 13:22 | <hsivonen> | 6667 or 6665 but not the one that's normal |
| 13:23 | <Lachy> | either port 6665 or port 80 works |
| 13:23 | <hsivonen> | I wonder if port 80 complies with Architecture. |
| 13:24 | <Lachy> | I don't think they care too much if it does. They just need it to bypass overzealous port blocking |
| 14:28 | <zcorpan> | Hixie: + attribute unsigned <span title="dom-img-vspace">vspace</span>; |
| 14:28 | <zcorpan> | Hixie: should say unsigned long |
| 15:28 | <mookid> | hello collection of hated people |
| 15:28 | <mookid> | how's it hanging? |
| 15:30 | <takkaria> | I'm feeling pretty hated today |
| 15:31 | <mookid> | and all you had to do was make the internet better |
| 15:31 | <mookid> | pfff |
| 15:33 | <krijnh> | Am I hated as well? |
| 15:33 | <krijnh> | For doing what, nothing? |
| 15:33 | <Lachy> | mookid, there are some people in here who aren't hated by anyone |
| 15:33 | <krijnh> | Pick me, pick me |
| 15:34 | <mookid> | well you're associated |
| 15:34 | <Lachy> | mookid, do you dislike such people enough to not feel like saying hi to them as well? |
| 15:34 | <mookid> | that's bad enough |
| 15:34 | <mookid> | I didn't say I hated you |
| 15:34 | <mookid> | I think you're hillarious |
| 15:34 | <mookid> | personally |
| 17:10 | <ezyang> | So, if something is ignored but "not conforming", does that result in a parse error? |
| 17:10 | <ezyang> | A "non-conforming error"? |
| 17:14 | <Philip`> | ezyang: If something is not said to be a parse error, then I would expect that it's not a parse error |
| 17:14 | <Philip`> | (though it could still be a conformance failure) |
| 17:14 | <ezyang> | Sure. |
| 17:15 | <Philip`> | So I'm not sure what your query is :-) |
| 17:15 | <ezyang> | The html5lib spec doesn't give me a lot to work on in terms of algorithms that convert nonconforming HTML to conforming HTML |
| 17:15 | <ezyang> | erm, s/html5lib/HTML 5/ |
| 17:15 | <Philip`> | In general that's impossible |
| 17:15 | <Philip`> | since it's not even possible for a machine to determine whether a document is conforming or not |
| 17:16 | <Philip`> | so I suppose you'll have to choose what set of errors you want to restrict yourself to fixing |
| 17:17 | <ezyang> | Oh yeah, of course. The goal is "anything that is machine detectable" |
| 17:19 | <jgraham> | ezyang: Still not possible (at least in some sensible way) e.g. if alt were mandatory there would be no way to take an image with no alt value (machine detectable) and insert the correct alt value |
| 17:20 | <jgraham> | Even in more simple cases my feeling is that "you don't want to do that" even though clearly some people do want to do that |
| 17:20 | <ezyang> | haha. My algorithm there is to insert the filename, or some configurable value. |
| 17:21 | <jgraham> | ezyang: Fail |
| 17:21 | <Philip`> | Will you handle stuff like <table><tr><td><td rowspan=2><tr><td colspan=2></table> too? :-) |
| 17:21 | <ezyang> | Philip`: I don't handle that yet, but it's presumably an algorithm I could write. |
| 17:21 | <jgraham> | ezyang: Seriously there is nothing good about inserting the filename automatically and a bunch of bad things. Please don't do it |
| 17:22 | <ezyang> | Can I... insert a Zen koan? |
| 17:22 | <Philip`> | jgraham: The good thing is that the validator will give you a tick, and that's what really matters |
| 17:23 | <jgraham> | Philip`: :( |
| 17:24 | <ezyang> | Unfortunately, that's the most user visible, and I have a commitment to not break that. |
| 17:24 | <gsnedders> | ezyang: From an a11y POV, you don't want to add an alt attribute to some useless value. |
| 17:25 | <Philip`> | (I presume the main point of a non-conforming-to-conforming converter is to let you get ticks, because in terms of e.g. preserving the author's intent it's going to be worse than HTML5's processing requirements for non-conforming content) |
| 17:25 | <ezyang> | I mean, ideally the form processor would be smart enough to recognize these unresolvable cases and ask the user what they actually meant. |
| 17:26 | <ezyang> | Philip`: The other point of nonconforming to conforming is because it means we can unambiguously determine intent. |
| 17:26 | <jgraham> | ?!? |
| 17:26 | <ezyang> | The space of conforming HTML is much smaller than nonconforming HTML, and browser behavior much better studied. |
| 17:26 | <ezyang> | sorry, bad word choice |
| 17:26 | <ezyang> | When I say intent, I mean, the way browsers will deal with it. |
| 17:27 | <ezyang> | i.e. it gives desirable security properties. |
| 17:27 | <gsnedders> | Once all browsers use HTML 5 parsers, that's no longer the case. |
| 17:27 | jgraham | doesn't understand how original code -> magic black box -> conforming code really helps |
| 17:27 | <jgraham> | I certianly don't see how it is a security issue |
| 17:27 | <gsnedders> | jgraham: XSS |
| 17:27 | <Philip`> | ezyang: If the goal is to fix markup that will have browser behaviour differences, then that seems very different to translating all non-conforming markup |
| 17:28 | <jgraham> | gsnedders: Conforming code can have XSS holes |
| 17:28 | <Philip`> | e.g. you wouldn't have to worry about img with no alt even if it was non-conforming |
| 17:28 | <gsnedders> | jgraham: <a href=`javascript:alert("so sue me")`>asd</a> will run the JS in IE but is non-conforming |
| 17:28 | <ezyang> | Right, so there are multiple issues here. |
| 17:28 | <gsnedders> | Actually, I don't think that is non-conforming. |
| 17:28 | <jgraham> | gsnedders: Right so you should strip that in a sanitizer, conforming or not |
| 17:29 | <Philip`> | and you would have to worry about conforming code like <!--[if IE 6]><script>alert("oh no")</script><![endif]--> |
| 17:29 | <ezyang> | From the XSS standpoint, syntactic conformance is a huge plus. Not as much for tags, although by whitelisting to conformant tags and then further removing problem tags, you further restrict things. |
| 17:29 | <gsnedders> | It probably should be non-conforming, though, for the very reason that IE will execute that |
| 17:29 | <ezyang> | Philip`: I explicitly disallow comments because of the fact that they commonly carry out of band information that is exploitable |
| 17:30 | <Philip`> | ezyang: So you're making a sanitiser, rather than a tool to convert non-conforming markup to conforming markup? |
| 17:30 | <jgraham> | For XSS I would have thought that applying sanitization based on the HTML5 algorithm is enough. Whether the result is conforming or not is irrelevant |
| 17:30 | <ezyang> | But not just that |
| 17:30 | <gsnedders> | Philip`: It's both |
| 17:30 | <Philip`> | That sounds needlessly complex :-) |
| 17:30 | <jgraham> | Certianly whether it has alt attributes is irrelevant |
| 17:30 | <gsnedders> | http://htmlpurifier.org/demo.php |
| 17:31 | <ezyang> | From a marketing standpoint, it also makes sense to fix any conformance errors so that users can have the nice fuzzy feeling of a Green validator check. |
| 17:31 | <ezyang> | It is then that alt attributes are relevant. |
| 17:31 | <gsnedders> | ezyang: Even if that actually makes them less accessible? |
| 17:31 | <jgraham> | ezyang: It feels like we have got to the real reason for wanting conforming output |
| 17:31 | <gsnedders> | ezyang: And quite possibly makes them non-conforming in another way? |
| 17:32 | <jgraham> | or rahter "valid" |
| 17:32 | <jgraham> | *rather |
| 17:32 | <gsnedders> | (As I'd hope giving useless @alt would be non-conforming, as I hope it requires an alternative to the image) |
| 17:32 | <Philip`> | We could add a <pretendthisisconforming> element to HTML5 so people can get validator ticks without having to make their code worse |
| 17:33 | <gsnedders> | ezyang: The problem with trying to make code valid is you can quite easily make it a lot worse from a conformance and accessibility point of view |
| 17:33 | <ezyang> | I think alt is the big offender. |
| 17:36 | <ezyang> | So, to reiterate, conformance has various benefits: 1. you get validator ticks, 2. syntactic conformance makes XSS harder, 3. conforming HTML has more regular browser interpretation, letting us canonicalize the interpretation |
| 17:36 | <ezyang> | You roll over accessibility in the img alt case, but this can be fixed by smarter form processing, and is fairly isolated. |
| 17:39 | <gsnedders> | ezyang: 1 is not a benefit. |
| 17:39 | <jgraham> | 1 is not a benefit on its own. 2 seems extremely dubious to me. 3 is probably true but since you are basically just putting things through a magic black box you still won't get the results you expect in many cases |
| 17:39 | <gsnedders> | ezyang: 2 doesn't need validity |
| 17:40 | <gsnedders> | ezyang: 3 can't really be done programmatically. |
| 17:40 | <gsnedders> | (I say 2 doesn't need validity as it can be done just by doing stuff token-by-token) |
| 17:40 | <gsnedders> | (You can get a lot of the benefits of 2 just by parsing then serializing, and doing nothing more) |
| 17:41 | <Philip`> | http://htmlpurifier.org/demo.php?filter%5BAutoFormat.PurifierLinkify.DocURL%5D=%ef%bf%bf |
| 17:42 | <jgraham> | Actually if you have any attacks that htmlpurifier prevents but the html5lib sanitizer does not you should really file a bug on us |
| 17:42 | gsnedders | notes that that was reported before and fixed, so is a regression |
| 17:42 | <gsnedders> | jgraham: We won't stop <script>alert("foo")</script> though |
| 17:43 | <Philip`> | gsnedders: No attacker would think we're stupid enough to try just writing a script tag, so they'll never know |
| 17:43 | <gsnedders> | Oh, wait, duh |
| 17:43 | <jgraham> | gsnedders: THe sanitizer will strip that |
| 17:43 | <gsnedders> | sanitizer, not serializer |
| 17:46 | <ezyang> | Philip`: That... should have been fixed. |
| 17:46 | <ezyang> | Oh, that's a bug in the form code, not in the purifier |
| 17:47 | <Philip`> | (There's http://htmlpurifier.org/demo.php?filter%5BAutoFormat.AutoParagraph%5D=cheese too) |
| 17:48 | <Philip`> | I like how Sourceforge has adopted a colour scheme in which its forum messages are thin light grey text on a light blue background, and if I look at my laptop screen from an angle greater than twenty degrees then the text entirely disappears |
| 17:49 | <ezyang> | gsnedders: There is one main point that requires some sort of tree building algorithm, which is preventing user HTML elements from leaking to the parent tree. |
| 17:50 | <gsnedders> | ezyang: Sure, just parse and serialize to get there. |
| 17:50 | <gsnedders> | ezyang: Nothing more than that is needed for that, |
| 17:50 | <gsnedders> | ezyang: Also, both myself and jgraham have doubts over two, as most of the issues will be fixed by parsing and serializing the tree, provided you quote attribute values and special case one or two things like < in tag name |
| 17:50 | <ezyang> | Whitelist philosophy means that I should very thoroughly inspect attributes and recursively parse data formats (i.e. CSS to URI) |
| 17:51 | <gsnedders> | ezyang: Sure, but that doesn't have anything to do with building a balanced tree |
| 17:51 | <ezyang> | It also means that I should know exactly what tags that I'm going to allow. |
| 17:51 | <jgraham> | Parsing CSS is a good idea. I would like to add that to html5lib |
| 17:51 | <ezyang> | Ok, so the core issues |
| 17:52 | <ezyang> | building a conforming tree, and generating required attributes |
| 17:52 | <ezyang> | Which y'all would like to convince me to not do. |
| 17:53 | <ezyang> | Everything else that HTML Purifier is useful, no? |
| 17:53 | <ezyang> | *is doing |
| 17:53 | <gsnedders> | ezyang: You cannot create a conforming tree programmatically. You can, however, produce a valid tree. |
| 17:54 | <ezyang> | oh yes, that's what I meant |
| 17:54 | <jgraham> | ezyang: I expect so althogh I don't know what all the other things it is doing are |
| 17:54 | <gsnedders> | ezyang: Everything else meaning what? |
| 17:54 | <ezyang> | With regards to fulfilling HTML 5 conformance requirements |
| 17:55 | <ezyang> | We want to fulfill syntactic conformance, which you get from tokenizing the stream |
| 17:55 | <ezyang> | We want to build a tree, which has its own conformance things associated with it (i.e. <b><i>f</b></i>), which you get from tree-building |
| 17:55 | <jgraham> | The point about trying to create valid markup is that the main benefit seems to be a happy feeling conformance tick but there are substantial costs in terms of complexity, possibilites of harming end users, possibility of automagically misinterpreting the markup |
| 17:56 | <ezyang> | We want to recursively validate attributes, which increases conformance |
| 17:56 | <gsnedders> | What does HTML Purifier aim to do? Does it aim to produce secure markup, does it aim to produce valid markup? |
| 17:56 | <ezyang> | It aims to do both. |
| 17:56 | <ezyang> | You could remove maybe 15% if you got rid of the valid markup requirement, specifically valid trees and attribute generation. |
| 17:57 | <gsnedders> | Fundamentally the latter is not a useful goal. |
| 17:57 | <ezyang> | The primary complexity comes from whitelisting and attribute validation |
| 17:57 | <ezyang> | Possibly. |
| 17:57 | <gsnedders> | You will get a lot of it from just parsing and serializing the tree, certainly |
| 17:57 | <gsnedders> | But that is a side-effect, more than anything else. |
| 17:57 | <ezyang> | Which is why I'm planning on swapping out most of my code for html5lib when the PHP impl gets stable enough |
| 17:59 | <gsnedders> | Basically, I think what you need to do is parsing the input stream, remove elements/attributes on whitelist, remove some more attributes based upon their value, then serialize, quoting attribute values. |
| 17:59 | <gsnedders> | I think that should get you security. |
| 18:00 | <Philip`> | (and remove comments) |
| 18:01 | <ezyang> | gsnedders: I argue that removing attributes based on value is the wrong paradigm (it should be machine-semantic deconstruction of each attribute), but yes, essentially. |
| 18:01 | <ezyang> | And remove comments, yep. |
| 18:01 | <gsnedders> | ezyang: What's the difference? |
| 18:01 | <gsnedders> | ezyang: That is, ultimately, just inspecting the value. No? |
| 18:02 | <ezyang> | Semantic deconstruction means that attribute values might change. |
| 18:02 | <Philip`> | The html5lib sanitiser has e.g. a regexp for detecting 'safe' style attribute values, and throws out any attribute that doesn't match, I think |
| 18:02 | <ezyang> | Canonicalization of a URL or CSS string is more important |
| 18:02 | <gsnedders> | Ah, OK |
| 18:02 | <gsnedders> | Yeah, right. |
| 18:02 | <ezyang> | Right. That kind of regex doesn't make me feel safe |
| 18:02 | <Philip`> | Me neither |
| 18:02 | <ezyang> | Although theoretically it might be secure. |
| 18:03 | <gsnedders> | For most attributes though, it is just looking at the value and nothing more |
| 18:03 | <gsnedders> | And I'm throwing together stuff from the top of my head :) |
| 18:03 | <Philip`> | The person who discovered the regexp takes exponential time on certain inputs probably wasn't too happy |
| 18:03 | gsnedders | was just discussing that with jgraham |
| 18:03 | <Philip`> | gsnedders: Your hair? |
| 18:04 | <gsnedders> | (the use of the regex that is) |
| 18:04 | <gsnedders> | (Both of us think having a proper CSS parser would be better) |
| 18:04 | <Philip`> | (The stuff from the top of your head, that is) |
| 18:04 | <ezyang> | There is one more thing that HTML Purifier does, and that's enhance HTML. |
| 18:04 | <gsnedders> | Philip`: No, my hair doesn't include interesting information. |
| 18:04 | <gsnedders> | ezyang: "enhance"? |
| 18:04 | <ezyang> | Take something that normally didn't have meaning and transform it accordingly |
| 18:04 | <ezyang> | For example, turning plaintext URLs into links |
| 18:04 | <jgraham> | ? |
| 18:04 | <jgraham> | Oh |
| 18:05 | <jgraham> | Well that sounds like an OK function is your users want it |
| 18:05 | <ezyang> | Or adding paragraphing |
| 18:05 | <gsnedders> | ezyang: Can you just stick with purifying? :P |
| 18:05 | <ezyang> | I mean, you kind of /need/ these features if you're going to be writing HTML raw. |
| 18:05 | <ezyang> | Anyway, performing this transforms when you have a tree is much better. |
| 18:06 | <ezyang> | *these |
| 18:06 | <gsnedders> | I'd rather have a tool that just made sure HTML was secure. |
| 18:06 | <gsnedders> | s/tool/library/ |
| 18:06 | <ezyang> | So you want decoupling. Well, you easily turn it off :-P |
| 18:07 | <jgraham> | Philip`: Any idea how hard it is to write a CSS parser? |
| 18:07 | gsnedders | thinks the issue of what HTML Purifier should do is simpler if we take one thing it aims to do at a time |
| 18:07 | <takkaria> | jgraham: talk to jmb, he's just written one... |
| 18:08 | <ezyang> | It's a lot of drudge work. |
| 18:08 | <jmb> | takkaria: heh |
| 18:08 | <gsnedders> | ezyang: how do you parse it/ |
| 18:08 | <gsnedders> | *? |
| 18:08 | <Philip`> | jgraham: I haven't got a clue |
| 18:08 | <gsnedders> | Philip`: Get a clue. |
| 18:08 | <ezyang> | Oh, that's easy: I just split on semicolons :-P |
| 18:08 | <ezyang> | Which is wrong, and also needs to be fixed. |
| 18:09 | <gsnedders> | ezyang: I expect doing any nice parser will be rather horrible in PHP |
| 18:09 | <ezyang> | CSS Tidy does it. |
| 18:09 | <gsnedders> | Mainly because there is no nice lexer to just easily use :P |
| 18:09 | <ezyang> | I just need to subsume it into HTML Purifier. |
| 18:09 | <jgraham> | jmb: Any idea how hard it is to write a CSS parser? |
| 18:10 | <ezyang> | You can cut some corners, since style="" is much simpler than <style></style> |
| 18:10 | <Philip`> | I tried using a Python CSS parser once, but it seemed to have something like quadratic time complexity and so it was unusable for typical large inputs |
| 18:10 | <jmb> | jgraham: if one existed in a useful form before I wrote mine, I wouldn't have bothered |
| 18:10 | <jmb> | jgraham: this one's taken me about a year of spare time fwiw |
| 18:11 | <jgraham> | :( |
| 18:11 | <ezyang> | I would also argue that you need to whitelist the values of CSS properties, since you don't want to enumerate against browser proprietary extensions |
| 18:11 | <jmb> | you may have more spare time than me, though :) |
| 18:12 | gsnedders | wonders how there manages to be no decent parsing libraries for PHP |
| 18:12 | <jgraham> | jmb: Wouldn't count on it |
| 18:12 | <jmb> | jgraham: http://www.netsurf-browser.org/projects/libcss/ |
| 18:12 | <jmb> | fwiw |
| 18:16 | <ezyang> | I still wonder if, one day, a browser will add support for a specific combination of tags that results in JavaScript being executed. |
| 18:16 | <ezyang> | and in separate contexts it's ok. |
| 18:19 | <ezyang> | Seems very unlikely. |
| 18:20 | <ezyang> | Ok, so here's what's going to happen. HTML Purifier 5.0 will be able to operate as "make it valid omgwtf" and "make it secure" |
| 18:21 | <ezyang> | For interest of backwards compatibility, "make it valid omgwtf" will be the default. Conscientous developers who don't care about validity can turn that off. |
| 18:21 | <gsnedders> | And then have the fun of evangelism to dissuade people from using the former. |
| 18:21 | <ezyang> | I mean, validators really did a lot of harm to conformance. |
| 18:21 | <gsnedders> | ezyang: In the longer term <iframe sandbox seamless> should work |
| 18:22 | <ezyang> | So long as there are legacy browsers, that will not be sufficient. |
| 18:22 | ezyang | afk for lunch |
| 18:22 | <ezyang> | This was a good discussion, and definitely changed my mind about where HTML Purifier 5.0 is going. |
| 18:31 | <gsnedders> | ezyang: I'll probably send an email later |
| 18:31 | <gsnedders> | (Like, when I get home from work) |
| 18:41 | <ezyang> | Email? |
| 19:17 | <JoePeck> | Hello. Is there any way to access the current page's response headers via Javascript, like you can access an AJAX Requests response headers (with xhr.getAllResponseHeaders etc). And if not, why not or was it just not thought of? |
| 19:19 | <JoePeck> | Since you can just spawn an AJAX request for the current page, and get the headers that way, I think it should be allowable for Javascript to have access to the response headers of the current page. At least I can't think of a realistic security concern. |
| 19:35 | <sebmarkbage> | JoePeck: As far as I know you can't and I agree. It is an oversight. |
| 19:36 | <JoePeck> | Hmm, should I make a formal email to the mailing list? |
| 19:39 | <mookid> | no |
| 19:39 | <mookid> | the response is the response |
| 19:40 | <sebmarkbage> | Scripts should be able to resolve things such as relative URIs if the HTTP header "Content-Base" is used. We shouldn't have to use meta or base tags for that. |
| 19:40 | <JoePeck> | mookid: but the headers aren't available to Javascript? |
| 19:40 | <mookid> | the client side doesn't, and shouldn't, be able to modify the response - it just is what it is |
| 19:40 | <gsnedders_> | ezyang: Yes, email. You know these things? |
| 19:40 | <JoePeck> | mookid: not modify, access. What about custom headers? |
| 19:41 | <JoePeck> | not that it would make any sense to modify the response headers... they are the response headers =) |
| 19:43 | <sebmarkbage> | Out of curiousity, what headers would you like to access? Custom only? |
| 19:44 | <JoePeck> | sebmarkbage: actually, someone in ##javascript wanted to access the "Date" header sent from his server |
| 19:44 | <JoePeck> | but I could think of accessing the Content-Type and custom headers |
| 19:44 | <JoePeck> | as possible use cases |
| 19:44 | <mookid> | wait - what |
| 19:45 | <JoePeck> | mookid: it seems I have a difficult time explaining this because everyone seems to respond with a "what?" =( |
| 19:45 | <mookid> | you can't read response headers? |
| 19:45 | <JoePeck> | Here was my example page: http://bogojoker.com/x/xhr/headers.html |
| 19:46 | <JoePeck> | you can read the response headers, but only for an AJAX Request |
| 19:46 | <sebmarkbage> | You can read response headers off of XHR but not for the current document. |
| 19:46 | <JoePeck> | exactly |
| 19:46 | <sebmarkbage> | I.e. you'd have to make another request to find that out. |
| 19:46 | <JoePeck> | sebmarkbage++ thanks =) |
| 19:47 | <mookid> | yeah well that's a good example of what a ridiculously poor HTTP client most browsers are |
| 19:47 | <mookid> | you'll get the "we need a use case" nonsense |
| 19:48 | <takkaria> | ... |
| 19:48 | <mookid> | the reality is that they didn't read the RFC properly |
| 19:48 | <JoePeck> | well, why get the response headers from an ajax request? If there was a use case for that then they all apply for this case as well |
| 19:48 | <takkaria> | you can be a perfectly good HTTP client without exposing request headers to JavaScript |
| 19:49 | <mookid> | browsers are crap HTTP clients |
| 19:49 | <JoePeck> | I agree with takkaria on that |
| 19:49 | <JoePeck> | mookid: and what would you suggest as a good HTTP client? |
| 19:49 | <takkaria> | that may or may not be true, but it's irrevelant to exposing things to JS |
| 19:49 | <mookid> | one that behaves as though the developers read the HTTP RFC |
| 19:50 | <JoePeck> | hmm the "and" makes that statement sound stuck up, I don't mean that, I'm just curious |
| 19:50 | <mookid> | take a look at the Accept header for most browsers |
| 19:50 | <mookid> | go read the RFC |
| 19:50 | <mookid> | and try and work out what these people were thinking |
| 19:50 | <mookid> | if anything at all |
| 19:50 | <mookid> | probably too busy doing crack and beating their wives |
| 19:51 | <JoePeck> | oookay |
| 19:51 | <mookid> | but hey |
| 19:51 | <mookid> | there's no use case for appropriate Accept headers |
| 19:52 | <mookid> | what about HTML5 providing a mechanism for protocol level content negotiation? |
| 19:52 | <mookid> | nope - no use case |
| 19:52 | <mookid> | we've got URIs! |
| 19:52 | <mookid> | idiotic. |
| 19:52 | <mookid> | completely and utterly idiotic. |
| 19:52 | <mookid> | # |
| 19:53 | <mookid> | it's a wonder why anyone actually bothers writing RFCs |
| 19:53 | <takkaria> | mookid: watch out, you'll start to rail against the evils of the capitalist press next |
| 19:53 | <mookid> | yeah be as aloof as you want |
| 19:54 | <mookid> | your technology is a joke. |
| 19:55 | <mookid> | but hey - at least we've got snazzy videos moving around the page that rotate and shit! |
| 19:55 | <mookid> | awwwwweeesssommmme |
| 19:55 | <takkaria> | my technology? I'm not sure I've produced any technology I could lay claim to. :) |
| 19:55 | <sebmarkbage> | I'm sorry, you lost me at crack. The use case of being able to read headers is that it allows for a cleaner model as opposed to for example meta tags. Meta data that belongs in HTTP could then stay there. |
| 19:56 | <mookid> | I'm all for self descriptive messages |
| 19:56 | <mookid> | that's probably why you lost me |
| 19:57 | <mookid> | I'm in favour of keeping that stuff in the message headers |
| 19:57 | <mookid> | good luck convincing these guys that HTTP is relevant to their 'ground breaking' work |
| 19:57 | <mookid> | unless there's a use case for it |
| 19:59 | <mookid> | a use case for them to listen to you i mean |
| 20:00 | <gsnedders_> | mookid: What's inappropriate about the Accept headers browsers send? (And I'm totally serious about asking that, I know what the spec says, and it seems perfectly sane to me.) |
| 20:01 | <mookid> | well |
| 20:01 | <mookid> | someone wrote a post about this recently |
| 20:01 | <mookid> | http://newmediacampaigns.com/page/browser-rest-http-accept-headers |
| 20:02 | <mookid> | what is so hard about changing it to Accept: text/html,*/*;q=0.9 |
| 20:02 | <mookid> | oh wait sorry I forgot |
| 20:02 | <mookid> | there's no use case |
| 20:03 | <gsnedders_> | mookid: Because then people will complain that they don't claim to support application/xhtml+xml just as well as it does text/html |
| 20:04 | <mookid> | why don't you read that post |
| 20:04 | <gsnedders_> | I am reading it. |
| 20:06 | <gsnedders_> | IE's seems sane insofar as it lists what it supports, but all equally, which is a bit odd. I would expect it to prefer text/html. WebKit's is odd seeming that image/png is there (I do also wonder why application/xml is equal to application/xhtml+xml and above text/html, but providing a generic XML MIME type along side application/xhtml+xml doesn't seem entirely crazy). Firefox seems the sanest, though. |
| 20:06 | gsnedders_ | wonders what we send |
| 20:06 | <mookid> | we = firefox? |
| 20:06 | <gsnedders_> | we = Opera |
| 20:06 | <mookid> | oh right |
| 20:06 | <mookid> | oh you're probably sane =) |
| 20:06 | <gsnedders_> | (As we are only mentioned in passing as being sane) |
| 20:06 | <gsnedders_> | text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 |
| 20:07 | <mookid> | eww |
| 20:07 | <gsnedders_> | That doens't seem quite so sane. |
| 20:07 | <gsnedders_> | *doesn't |
| 20:07 | <gsnedders_> | If anything, that's the least sane. |
| 20:07 | <mookid> | well this is academic anyway since there's no need for HTTP content negotiation because "you can put it in the URI" |
| 20:07 | <mookid> | apparently. |
| 20:07 | <mookid> | =/ |
| 20:08 | <ezyang> | I think Accept headers make most sense for embedded resources |
| 20:09 | <mookid> | well they make no sense in practical web app terms |
| 20:09 | <mookid> | because you can't specify them in context to a browser in HTML |
| 20:09 | <ezyang> | Yes you can. <img /> |
| 20:09 | <JoePeck> | mookid: so if a person asks for blah.html and their Accept header states they would want xml over html you should respect the Accept header and give them xml? |
| 20:09 | <mookid> | ok ok |
| 20:09 | <mookid> | let me just say something |
| 20:09 | <Philip`> | Ooh, this discussion again |
| 20:09 | <ezyang> | JoePeck: No, since you explicitly specified what content type you want with .html |
| 20:10 | <krijnh> | Is it known that IE throws almost the entire DOM inside the head in this case: http://krijnhoetmer.nl/zooi/html5/gone-in-ie.html ? |
| 20:10 | <gsnedders_> | ezyang: File names are meaningless. |
| 20:10 | <mookid> | say I have something called /resource - and I have 2 representations of that resource in json and xml; but they are the SAME resource |
| 20:10 | <JoePeck> | ezyang: thats what I thought, so most of this doesn't seem crazy to me. =) |
| 20:10 | <gsnedders_> | ezyang: If you have both representations of the resource, you should give them XML. |
| 20:10 | <mookid> | I don't want /resource.xml and /resource.json because those URIs are 2 separate resources |
| 20:10 | <ezyang> | gsnedders_: How so? If you want to turn on Multiviews, you better damn well be serving files w/o extensions |
| 20:10 | <mookid> | URIs are *opaque* |
| 20:10 | <mookid> | which is extremely important |
| 20:11 | <gsnedders_> | ezyang: Well, I mean extensions are. |
| 20:11 | <JoePeck> | "those URIs are 2 separate resources" those 2 URIs don't need to exist, they just need to be parsed. |
| 20:11 | <mookid> | the fact that we've been forced into using the URI for this is irrelevant it's bad practice if the two document types are representations of the same resource |
| 20:11 | <gsnedders_> | mookid: When does it become important, though? |
| 20:11 | <mookid> | good god. |
| 20:11 | <ezyang> | mookid: I agree. But there still needs to be a mechanism for explicitly specifying the desired content type |
| 20:11 | <mookid> | caching./ |
| 20:12 | <mookid> | caching caching caching |
| 20:12 | <JoePeck> | mookid: its much easier to work with something you can modify easily, like the URI, then the header which goes along |
| 20:12 | <mookid> | JoePeck: no it's not |
| 20:12 | <gsnedders_> | mookid: But you need to vary caching based upon the Accept header then, which means you gain nothing by having the same URI for both. |
| 20:12 | <JoePeck> | would you suggest changing browsers to have 2 textfields, one for the URI and one for the preferred accepted mimetype? |
| 20:12 | <mookid> | ezyang: the best way to do that is an accept attribute in hypermedia tags |
| 20:13 | inimino | makes popcorn |
| 20:13 | <JoePeck> | lol =) |
| 20:13 | <mookid> | so <a accept="application/json" href="/resource"> |
| 20:13 | <gsnedders_> | mookid: But why do you want to override the browser default? |
| 20:13 | <ezyang> | ==gsnedders_ |
| 20:13 | <mookid> | because it depends on the context |
| 20:13 | <ezyang> | Then the resources are not identical. |
| 20:13 | <gsnedders_> | ezyang: That doesn't follow. |
| 20:13 | <JoePeck> | I like mookid's accept attribute |
| 20:13 | <mookid> | WHATWG don't |
| 20:14 | <JoePeck> | but still |
| 20:14 | <mookid> | there's not a good enough use case |
| 20:14 | <JoePeck> | if you want to get something by typing a URI into your big honking location bar |
| 20:14 | <JoePeck> | what would you suggest then? |
| 20:14 | <gsnedders_> | mookid: You need a more specific use case. |
| 20:14 | <mookid> | I'd suggest if you're putting a URI into a browser you want HTML |
| 20:14 | <mookid> | :) |
| 20:14 | <JoePeck> | if not embedding the mime type into the URI (like .xml or .json) you're going to need 2 peices |
| 20:14 | <mookid> | but say.. |
| 20:14 | <mookid> | I fancy pdf |
| 20:15 | <gsnedders_> | mookid: Just, "it depends on context" isn't very specific. |
| 20:15 | <JoePeck> | ahh, I don't like that =( |
| 20:15 | <mookid> | you don't like that if the resources are differnet |
| 20:15 | <mookid> | if the resources are different they need different URIs |
| 20:15 | <mookid> | if they are the same they need the same URI |
| 20:15 | <JoePeck> | gsnedders_: seems decent enough. If your application wants to to force the browser to interpret things in a certain way then you should be allowed to? |
| 20:15 | <gsnedders_> | mookid: Something like, "I want to make available a PDF representation of the document", is a lot more precise |
| 20:16 | <mookid> | gsnedders_: I gave you an example |
| 20:16 | <gsnedders_> | mookid: Where? |
| 20:16 | <mookid> | I have an application that has /resource I want to link to |
| 20:16 | <gsnedders_> | mookid: But why do you want to override the Accept header? |
| 20:16 | <mookid> | and on another HTML5 page I want to link to both the json and xml |
| 20:16 | <mookid> | I CANT DO THAT |
| 20:16 | <mookid> | WITHOUT AN ACCEPT ATTRIBUTE |
| 20:16 | <JoePeck> | whoa. calm down |
| 20:16 | <gsnedders_> | Why do you want to link to both? |
| 20:16 | <inimino> | mookid: then you have two resources, get over it |
| 20:17 | <gsnedders_> | To give a use-case, you need to answer that. |
| 20:17 | <mookid> | because I want to give my clients a hyperlink to both states |
| 20:17 | <gsnedders_> | Why? |
| 20:17 | <ezyang> | This is what I was trying to say previously. |
| 20:17 | <mookid> | why? because I do |
| 20:17 | <mookid> | that's irrelevant |
| 20:17 | <gsnedders_> | That's not a reason. |
| 20:17 | <gsnedders_> | Yes it is. |
| 20:17 | <mookid> | oh for fucks sake |
| 20:17 | <JoePeck> | I actually think it is a good reason =/ |
| 20:17 | <gsnedders_> | Should we add everything that anyone asks for, "because they do"? |
| 20:17 | <JoePeck> | I just can't come up with a good example of using it |
| 20:18 | <jgraham> | This discussion was quite boring the first time you know |
| 20:18 | <mookid> | yeah |
| 20:18 | <ezyang> | So, let's suppose the HTML and PDF example |
| 20:18 | <mookid> | ^ |
| 20:18 | <jgraham> | This is like the lame sequel |
| 20:18 | <JoePeck> | hahaha |
| 20:18 | <ezyang> | I publish an HTML document with the intent of this being shown to people who are just browsing on the web. |
| 20:18 | <takkaria> | ah, I thought it might go this way |
| 20:18 | <mookid> | yeah well there's a good reason for that |
| 20:18 | <takkaria> | I was hoping that mookid would just have continued spewing vitriol for a while |
| 20:18 | <mookid> | it's important |
| 20:18 | <ezyang> | And then the PDF document because it has better typogrpahy or can be sent to people or something |
| 20:19 | <gsnedders_> | ezyang: Why not just use link@rel=alternate that works in existing, already deployed, UAs? |
| 20:19 | <JoePeck> | ezyang: that sounded good to me |
| 20:19 | <ezyang> | That's one solution. |
| 20:19 | <mookid> | did you just suggest putting it in the URI? |
| 20:19 | <ezyang> | gsnedders_ did not suggest puttin git in the URI |
| 20:20 | <JoePeck> | he suggested changing the element alltogether? instead of <a> use <link> ? |
| 20:20 | <takkaria> | let me suggest it |
| 20:20 | <jgraham> | In practice the one-uri-maps-to-many-representions thing doesn't match how people think about this stuff |
| 20:20 | <JoePeck> | isn't that semantically unacceptable (pardon the pun)? |
| 20:20 | <gsnedders_> | ezyang: It does have that implication, actually |
| 20:20 | <takkaria> | you should just call it document.html and document.pdf |
| 20:20 | <mookid> | takkaria: then you don't understand the HTTP or URI spec and don't belong in this discussion |
| 20:20 | <JoePeck> | takkaria: "could" not should |
| 20:20 | <jgraham> | No one tries opening a URI that works in their web browser in their PDF viewer and expects to get a PDF back |
| 20:20 | <takkaria> | mostly because it just works, and in this world-wide web of indifference, something that just works is pretty good |
| 20:21 | <ezyang> | Now, my interpretation of the matter is that PDF has a distinct identity from the HTML document. |
| 20:21 | <JoePeck> | mookid: I don't understand the harshness... |
| 20:21 | <mookid> | because of the shit I went through last time |
| 20:21 | <mookid> | and blatant ignorance |
| 20:21 | <ezyang> | So, a more appropriate URI for it would be foo?publishable |
| 20:21 | <ezyang> | To carry the semantic meaning of this other resource. |
| 20:22 | <ezyang> | And like it or not, "pdf" very concisely expresses the semantics you expect. |
| 20:22 | <jgraham> | JoePeck: mookid is somewhat bitter because he spent something like two days ranting about this before and people refused to accept that they were ignorant heathens |
| 20:22 | <JoePeck> | lol, okay thanks for the context |
| 20:22 | <JoePeck> | I see what he wants |
| 20:22 | <ezyang> | A more reasonable use-case for negotiation is .jpg and .png, where joe user sees no difference between them. |
| 20:22 | <jgraham> | and he was the only one who understood the web architecture |
| 20:22 | <JoePeck> | but ultimately, I just see putting it the URI as much easier |
| 20:22 | <mookid> | the main gain for sticking to single URIs for multiple representations of the same resource is the cache invalidation you get across all representations of a resource when you modify the resource |
| 20:22 | <Dashiva> | Who started the time machine in here? |
| 20:23 | <mookid> | I'm not the only one |
| 20:23 | <mookid> | Philip` got it |
| 20:23 | <JoePeck> | mookid: is there no way in HTTP |
| 20:23 | <mookid> | it's pointless anyway there's HTTP functionality you are denying developpers on the basis that "you don't think it's really necessary" |
| 20:23 | <JoePeck> | to make two URIs equivalent? |
| 20:24 | <mookid> | no |
| 20:24 | JoePeck | puts up shield |
| 20:24 | <mookid> | URIs are opaque |
| 20:24 | <mookid> | good question :) |
| 20:24 | <jgraham> | mookid: I get the idea. I get the fact that some people think it would be nice if things worked that way. I think it is impractical in reality |
| 20:24 | <mookid> | what?! |
| 20:24 | <gsnedders_> | mookid: Should we allow every single HTTP header to be set by the page? |
| 20:24 | <mookid> | actually I dont think that's a bad idea |
| 20:24 | <Philip`> | I don't entirely remember whether I got it |
| 20:24 | <Philip`> | or what it even was |
| 20:24 | <JoePeck> | so this could be solved in HTTP by making two URIs have an equivalent HTTP cache uri? |
| 20:24 | <Philip`> | and whatever it was, I guess I didn't keep it |
| 20:25 | <mookid> | JoePeck: that means you have to couple your caching mechanisms to your application |
| 20:25 | <mookid> | it's inefficient and brittle |
| 20:25 | <JoePeck> | no the HTTP client |
| 20:25 | <mookid> | yeah again |
| 20:25 | <Dashiva> | Philip`: Did you get it now, or the last time mookid was here? |
| 20:25 | <mookid> | you can do that but it's coupling to your application |
| 20:26 | gsnedders_ | gets the idea, gets why people want multiple representations of a single URI, but thinks some things (like changing content-type) are impractical in the real world |
| 20:26 | <mookid> | that's not your choice. |
| 20:26 | <mookid> | just support the protocol |
| 20:26 | <JoePeck> | mookid: is it? if you have /resource.html and /resource.pdf can you return and say these are both "/resource" and thus invalidate the cache when one changes |
| 20:26 | <Philip`> | Dashiva: The last time |
| 20:26 | <gsnedders_> | mookid: What should @accept do on protocols apart from HTTP? |
| 20:26 | <Philip`> | Dashiva: I haven't bothered reading the conversation this time, since it seems exactly the same as before |
| 20:28 | <mookid> | erm |
| 20:28 | <gsnedders_> | mookid: Also, what else in HTML is specific to HTTP? |
| 20:28 | <mookid> | what? |
| 20:28 | <mookid> | POST? |
| 20:28 | jgraham | has no idea where the http protocol mandates that HTML pages should be able to change the browser headers via the DOM |
| 20:28 | <gsnedders_> | mookid: HTML isn't tied to HTTP, by and large. form@method I guess is, but otherwise not |
| 20:28 | <mookid> | jgraham: yeah bad luck it's not spelled out for you |
| 20:28 | <mookid> | probably a bit much. |
| 20:28 | <mookid> | wouldn't worry about it too much |
| 20:28 | <Philip`> | Dashiva: Also I'm distracted by watching pretty graphs and hoping Slashdot doesn't hurt my server |
| 20:28 | takkaria | puts up a Don't Feed The Troll sign (scare quotes implied) and goes to make risotto |
| 20:28 | <JoePeck> | mookid: what about what I said before |
| 20:28 | gsnedders_ | goes to get washing |
| 20:28 | <jgraham> | takkaria: What type of risotto? |
| 20:28 | <takkaria> | jgraham: just a mushroom and pepper one, nothing fancy |
| 20:28 | <mookid> | JoePeck: there's nothing stopping you introducing that kind of logic into your client or caches |
| 20:28 | <JoePeck> | as it exists right now is that possible? Or does that mean the browser can only cache 1 representation of /resource at a time? |
| 20:28 | <mookid> | but that's the opposite philosophy underlying HTTP |
| 20:28 | jgraham | is just enjoying a break from packing |
| 20:29 | <mookid> | URIs are meant to be *opaque* which means that if they aren't the same - they aren't the same |
| 20:29 | <Dashiva> | Have you covered the "multiple representations of the same URL confuses users" angle yet? |
| 20:29 | <mookid> | nothing more complicated |
| 20:29 | <JoePeck> | mookid: okay, I don't see what you mean this time. I've gotten all the REST (hahaha, my puns...) |
| 20:29 | <mookid> | Dashiva: that is utterly irrelevant but thanks a bunch |
| 20:29 | <jgraham> | Dashiva: Did that one |
| 20:29 | <JoePeck> | hmm okay |
| 20:29 | <Dashiva> | jgraham: Was it dismissed out of hand like last time? |
| 20:29 | <mookid> | it's irrelevant |
| 20:30 | <mookid> | it's not your descision |
| 20:30 | <JoePeck> | I would say developers are not users =) |
| 20:30 | <JoePeck> | we have to deal with this crap because we made it that way =) |
| 20:30 | <JoePeck> | if we can't make it usable to our users it was our own fault |
| 20:30 | <jgraham> | Philip`: You are on slashdot? |
| 20:31 | <Dashiva> | JoePeck: Regular users deal with URLs, though. They should be able to do so without having to learn about http black magic |
| 20:31 | <mookid> | Dashiva: you don't know what you're tlaking about and even if you did it's not your place to decide for the world how that's dgoing to work |
| 20:31 | <JoePeck> | well, lets say you put a URL into your browsers address bar |
| 20:31 | <JoePeck> | and get back a popup saying |
| 20:31 | <Philip`> | jgraham: Yes |
| 20:31 | <JoePeck> | "Would you like this in HTML, PDF, or XML" |
| 20:31 | <mookid> | haha |
| 20:31 | <jgraham> | Philip`: Where? |
| 20:32 | <Philip`> | jgraham: hence the worrying about it |
| 20:32 | <Philip`> | jgraham: http://slashdot.org/ |
| 20:32 | <jgraham> | Philip`: I was hoping for something more specific |
| 20:32 | <Philip`> | jgraham: http://games.slashdot.org/article.pl?sid=09/07/15/170217 |
| 20:33 | <mookid> | JoePeck: so yep there you go - we don't need an accept attribute because we can "just put it in the URI" |
| 20:33 | <JoePeck> | mookid: well, I understand what you're going for. And actually I do agree with you. But I think too few people care about getting it right when you can just take the easy way out |
| 20:33 | <mookid> | yup pretty much it |
| 20:33 | <mookid> | just ignorance basically |
| 20:33 | <JoePeck> | who cares if your cache has a .html and .pdf representation out of date |
| 20:33 | <JoePeck> | is what it boils down to, for me |
| 20:34 | <JoePeck> | mookid: cheers on sticking up for yourself though =) |
| 20:34 | <jgraham> | Philip`: The game looks nice |
| 20:34 | <Dashiva> | Between a few developers and all the users, the users get priority. That's just how it is. |
| 20:35 | <mookid> | it's got nothing to do with that |
| 20:35 | <mookid> | you're not a fucking gatekeeper |
| 20:36 | <mookid> | excuse my language |
| 20:36 | <mookid> | but that is the *most* pathetic response |
| 20:36 | <mookid> | out of the lot |
| 20:36 | <JoePeck> | Dashiva: how many users use FTP even though they don't know how its done under the hood. How many people know DNS is complicated yet it just works. Speaking of "it just works" Apple does magic with DNS to get Bonjour working and the User never knows. I think usability always has a solution (my 2¢) |
| 20:36 | <Dashiva> | JoePeck: Usability is why we use URLs instead of contenet negotiation |
| 20:36 | <mookid> | jesus |
| 20:36 | <Philip`> | jgraham: It's quite a long way from being a decently playable game, though :-( |
| 20:37 | <JoePeck> | Well, I'm going to stop here |
| 20:37 | <mookid> | :) |
| 20:37 | <JoePeck> | I could argue though =) |
| 20:37 | <mookid> | now you might understand why I approach it the way I do |
| 20:37 | <Dashiva> | Yeah, trolling always works. Keep it up. |
| 20:37 | <JoePeck> | well, sorry, but I don't think yelling would ever open up someone elses mind like this debate would |
| 20:38 | <mookid> | Dashiva: you're form of trolling is far more irritating |
| 20:38 | <JoePeck> | need to have happen in order for the other side to get the "aha" moment |
| 20:38 | <Dashiva> | mookid: Maybe one day you will sit down and consider the possibility that you might just be wrong. Just maybe. |
| 20:38 | <mookid> | well I'm not |
| 20:39 | <JoePeck> | ultimately I think you're right. They haven't given you a good reason that you aren't (cause you aren't) |
| 20:39 | <mookid> | and I'm betting I've given this more though than you. |
| 20:39 | <mookid> | since it's my proposal and everything |
| 20:39 | <mookid> | + you're primary reason for resistance (i.e. protecting *your* poor users) is pretty silly |
| 20:40 | <mookid> | the crazy thing about this is that it doesnt stop you carrying on using the URI |
| 20:40 | <JoePeck> | I said I was going to stop, and I will now =) |
| 20:40 | <JoePeck> | cheers |
| 20:40 | <mookid> | cheers Joe |
| 20:40 | <mookid> | :) |
| 20:41 | <mookid> | only case I can see you getting pissy about is page refresh |
| 20:42 | <mookid> | but if each page request is a state |
| 20:42 | <mookid> | that includes all the headers |
| 20:42 | <mookid> | then refresh should work fine |
| 20:44 | <mookid> | but that is really my own problem - if you don't like it and want to use browser defaults and URI conneg then you can continue to and ignore the accept attribute all together |
| 20:44 | <mookid> | there's no reason we can't do both together |
| 20:50 | <jgraham> | mookid: As a piece of general advice, if you want to convince people of something, particularly something that they are sceptical of, being pissy doesn't help. |
| 20:51 | <jgraham> | In fact quite the opposite |
| 20:51 | <mookid> | yeah need a ciggy :) |
| 20:51 | jgraham | is aware he isn't saintly |
| 20:52 | <mookid> | well sorry for being a nob head |
| 20:52 | <mookid> | force of habit |
| 20:53 | <jgraham> | Philip`: You may want to updat your bio |
| 20:54 | <mookid> | the popular HTTP-centric API for java called JAX-RS only supports HTTP conneg |
| 20:54 | <mookid> | so it's not just me :P |
| 20:54 | <Philip`> | jgraham: It's only about five years out of date |
| 20:55 | <jgraham> | Philip`: It misses out > 20% of your life |
| 21:07 | Philip` | 's SVN server is currently doing about 30Mbit/s, which probably isn't a lot in absolute terms but it seems like quite a bit when you've scaled up from an average ~50kbit/s a few days ago |
| 21:13 | <mookid> | you got pr0n on a svn server? |
| 21:14 | <Philip`> | No |
| 22:21 | <Hixie> | what is the Window Modes spec? |
| 22:22 | <Hixie> | oh, a widgets spec |
| 22:22 | <Hixie> | ok |
| 22:22 | <Hixie> | (http://dev.w3.org/2006/waf/widgets-wm/Overview.src.html) |