| 00:37 | <hallvors> | where did TimBL speak about "change in philosophy" from "improving the web" to "letting it fester while describing it" as one of his concerns about HTML5? I'm writing a blog post and trying to find the source of that quote.. #-] |
| 00:39 | <Philip`> | hallvors: http://www.w3.org/2001/tag/2008/09/23-minutes ? |
| 00:39 | <Philip`> | (It doesn't seem clear whether that's his own opinion, or him reporting other people's apparent opinions) |
| 00:42 | <hallvors> | thanks! |
| 00:42 | <hallvors> | 2001 in the URL?! didn't realise it was such an ancient quote |
| 00:42 | <Philip`> | 2008 is in the URL too |
| 00:42 | <ehird> | TAG started 2001 |
| 00:42 | <ehird> | talk was 2008 |
| 00:42 | <hallvors> | right. cool URIs must confuse |
| 00:43 | <hallvors> | :p |
| 00:43 | <ehird> | indeed. |
| 00:43 | <ehird> | /1995/news for stuff happening in 2130 makes soo much sense |
| 00:43 | <ehird> | very durable :p |
| 00:43 | <Hixie> | are you mocking the web's architecture? |
| 00:44 | <Hixie> | careful, you might get in trouble! |
| 00:44 | ehird | gets mauled. |
| 00:44 | <ehird> | By web owls. |
| 00:45 | <ehird> | They're just like regular owls, except they sting you with cool URIs and... um... resource talons. |
| 01:04 | <hallvors> | URLs are just the UI of HTTP. As all UIs they are a pretty bad compromise between what a human can get used to and what a computer can understand. |
| 01:28 | <jwalden> | "modularized"? |
| 01:28 | <jwalden> | sigh |
| 01:30 | <jwalden> | oh, it gets worse, they mention E4X |
| 01:31 | <jwalden> | apparently not seriously, tho, which is a relief |
| 01:34 | <Philip`> | Wasn't it just hsivonen_ who mentioned E4X? |
| 01:34 | <jwalden> | possibly, I don't know who any of these people are except the one obvious one and DanC |
| 02:45 | <MikeSmith> | http://www.w3.org/QA/2008/06/shipbuilding.html#c169011 |
| 02:46 | <MikeSmith> | Dmitry Turin: "Western world does not interested in implementation of progressive ideas, because Indian slaves have been executing job for Western world free of charge"... "Nobody allow me to kill his investments, even it's investment into frankly nonsense (you guessed, what term i implied)"... "P.S. >to produce standards that actually get implemented" |
| 02:49 | <MikeSmith> | I think I like the old mostly just quixotic and relatively conspiracy-theory-free Dmitry Turin better than this one |
| 02:49 | <MikeSmith> | but you do have to give him credit in that even when he thinks conspiracy theory, he thinks big and goes all the way |
| 02:50 | <MikeSmith> | e.g, the entire Western world vs. his ideas |
| 07:29 | <Hixie> | aw, all the threads died out |
| 07:51 | <Hixie> | i guess it makes sense that roy would stop responding after i showed an interest in listening to his feedback |
| 07:51 | <Hixie> | since that would break his world view of us being people who ignore his feedback |
| 08:17 | <Hixie> | where's Philip`'s static copy of the whatwg issues list at again? |
| 08:43 | <Philip`> | Hixie: http://canvex.lazyilluminati.com/misc/cgi/issues.cgi/ |
| 08:43 | <Hixie> | thanks |
| 10:06 | <hsivonen_> | it feels weird that rickg's dated comments in nsIParser and friends are now over ten years old |
| 10:07 | <yecril71> | If a script exhausts browser resources, an exception should be thrown. |
| 10:08 | <yecril71> | (unless the failing action is known to be discardable) |
| 10:11 | <yecril71> | We can define that the HTML token "red" really means "blue", |
| 10:11 | <yecril71> | but I am afraid this is going to cause many misunderstandings. |
| 10:14 | <yecril71> | rel="rev-made" is not very good. |
| 10:14 | <hsivonen_> | yecril71: consider what danbri said about changing author to creator in DC. it wasn't about changing the concept but about effective bikeshedding the English word |
| 10:14 | <yecril71> | rel="made-me" sounds much better. |
| 10:14 | <yecril71> | or rel="made-by". |
| 10:14 | <Philip`> | Where is rev=made defined? |
| 10:15 | <yecril71> | Lynx documentation. |
| 10:15 | <Philip`> | Is there something more like a spec where it's defined? |
| 10:16 | <yecril71> | The only problem with removing rev is that Lynx uses it. |
| 10:16 | <hsivonen_> | for all practical purposes, rev=made is an ancient Lynx-only feature |
| 10:17 | <hsivonen_> | yecril71: we've made IE-only UI-only stuff non-conforming, too. |
| 10:18 | <yecril71> | I thought it was sort a political decision, IE being the equivalent of Dr. No? |
| 10:19 | <yecril71> | Whereas Lynx, as it is used by disabled people, should be treated with some condescending? |
| 10:20 | <Philip`> | More disabled people use IE than any other browser, from what I've heard |
| 10:23 | <yecril71> | There are various disabilities, perhaps IE is good for some of them? |
| 10:24 | <yecril71> | Using numbers in this context is rather dangerous. |
| 10:25 | <yecril71> | Most of the people are not disabled. |
| 10:27 | <mookid> | Hi fans |
| 10:27 | <yecril71> | Hi chief |
| 10:33 | <mookid> | well the email barrage dried up which is a shame! |
| 10:35 | <yecril71> | Time to catch up with things |
| 10:38 | <yecril71> | a rel="in-reply-to" is nonsense. |
| 10:39 | <yecril71> | It can be used as LINK[rel="in-reply-to"] only, to describe this document. |
| 10:42 | <yecril71> | And that would mean THAT document is in reply to THIS document. |
| 10:44 | <yecril71> | In this sense, rel="made" and rev="made" have the same meaning. |
| 10:45 | <yecril71> | rel="made" means THAT made THIS |
| 10:45 | <yecril71> | and so does rev="made". |
| 10:46 | <Hixie> | i think you misunderstand how rev="" was meant to work |
| 10:46 | <Hixie> | but it's academic |
| 10:46 | <Hixie> | since rev="" is gone now |
| 10:49 | <zcorpan> | hsivonen_: here's a feature request that i tried to implement myself but gave up before having a proof of concept impl... |
| 10:49 | <zcorpan> | hsivonen_: have the messages inline with the source |
| 10:50 | <yecril71> | I think we can all agree that LINK[rel="next"] means THAT is next to THIS. |
| 10:51 | <yecril71> | So LINK[rel="made"] means THAT made THIS, doesn�t it? |
| 10:51 | <zcorpan> | hsivonen_: so that you get e.g. |
| 10:51 | <zcorpan> | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">; ↩ |
| 10:51 | <zcorpan> | 1. Error: Almost standards mode doctype. Expected <!DOCTYPE html>. |
| 10:51 | <zcorpan> | <html>↩ |
| 10:51 | <zcorpan> | <head>↩ |
| 10:51 | <zcorpan> | <meta http-equiv="Content-Type" content="text/html; charset=windows-1252">↩ |
| 10:51 | <zcorpan> | 2. Error: The internal character encoding declaration must be the first child of the head element. |
| 10:51 | <zcorpan> | etc |
| 10:52 | <zcorpan> | if there are multiple errors on the same line you have multiple messages for that line |
| 10:54 | <zcorpan> | i tried implementing it by walking unsortedOl and doing a regexp on the location para to get the line and then inserting the message into the line-minus-one-th child of the source ol |
| 10:54 | <yecril71> | I was just trying to figure out what LINK[rel="banana"] would mean. |
| 10:54 | <yecril71> | THAT is MY banana? |
| 10:55 | <hsivonen_> | zcorpan: I think that could be a UI improvement, yes. |
| 10:55 | <hsivonen_> | IIRC, PageValet had something along those lines a few years ago. |
| 10:57 | <hsivonen_> | zcorpan: btw, in case you're wondering about the slow reaction to your recent bug reports, it's because I'm trying to reach a particular calendar goal with HTML5 parsing in Gecko. I'll get back to Validator.nu bugs in due course. |
| 10:57 | <zcorpan> | hsivonen_: no worries |
| 10:58 | <Hixie> | yecril71: it means whatever we define it to mean, these keywords are opaque strings |
| 10:58 | <Hixie> | ok bed time |
| 10:58 | <Hixie> | nn |
| 10:58 | <zcorpan> | i'm used to Hixie's rate of response i.e. somewhere between immediately and a few years :) |
| 11:00 | <yecril71> | But we cannot define rel="banana" to mean something unrelated to bananas. |
| 11:00 | <hsivonen_> | yecril71: yes, we can. |
| 11:00 | <yecril71> | But it would be confusing to the authors. |
| 11:00 | <hsivonen_> | yecril71: yes |
| 11:01 | <yecril71> | I think it is not an accident that the HEAD tag was not renamed QWERTY. |
| 11:01 | <yecril71> | Although QWERTY would be much easier to type. |
| 11:02 | <hsivonen_> | yecril71: there's value in names that make sense, yes. |
| 11:04 | zcorpan | thinks head is easier to type than qwerty |
| 11:05 | <hsivonen_> | Hixie: do I understand correctly that it's possible for document.close() to cause previously document.written data to be discarded? |
| 11:06 | hsivonen_ | tries it |
| 11:08 | <zcorpan> | hsivonen_: do you want me to file a bug about the feature request? |
| 11:08 | <hsivonen_> | zcorpan: preferably, yes |
| 11:08 | <yecril71> | To me, document.close() means that any subsequent document.write() rewrites the document. |
| 11:09 | <hsivonen_> | yecril71: yes, but as far as I can tell, document.close() closes the stream, but the spec says it puts an explicit EOF at insertion point, which seems wrong. |
| 11:09 | <yecril71> | The previous content is discarded only at document.write(). |
| 11:09 | <hsivonen_> | consider |
| 11:09 | <hsivonen_> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cscript%3Edocument.write(%22%3Cscript%3Edocument.write(%27a%27)%3Bdocument.close()%3B%3C\%2Fscript%3EEND%22)%3B%3C%2Fscript%3E |
| 11:11 | <yecril71> | I am unable to evaluate that in Internet Explorer. |
| 11:11 | <hsivonen_> | I'm starting Windows now, but Firefox, Opera and Safari all agree |
| 11:11 | <yecril71> | Takes 94% CPU. |
| 11:12 | <Hixie> | hsivonen_: oh it should probably insert it at the end of the stream |
| 11:12 | <hsivonen_> | Hixie: right. I'll send email. |
| 11:12 | <zcorpan> | hsivonen_: filed. fyi i got the internal error message again (worked fine the last few times) |
| 11:12 | <Hixie> | hsivonen_: didn't think of testing nested document.close() in document.write(), but i'm sure the web does it somewhere :-) |
| 11:12 | <hsivonen_> | zcorpan: thanks. (I still have no clue about the error.) |
| 11:13 | Hixie | hacked the xcode demo npapi plugin today to output the parameters passed to the plugin |
| 11:13 | <Hixie> | mac only, sadly |
| 11:13 | <Hixie> | but should help spec out what safari and firefox do for <embed> a bit better |
| 11:13 | <zcorpan> | Hixie: that would be useful |
| 11:14 | <Hixie> | for some reason it crashes when i use <object> in firefox |
| 11:14 | <Hixie> | (not in safari) |
| 11:14 | <Hixie> | no idea how to debug that |
| 11:14 | <hsivonen> | the IE8 XSS filter is really annoying with the live dom viewer |
| 11:14 | <Hixie> | and i dunno how to make opera accept a plugin |
| 11:15 | <Hixie> | it doesn't seem to use the plugins in the Internet Plugins directory |
| 11:16 | <hsivonen> | yay. it indeed freezes IE8 beta2 |
| 11:17 | <Hixie> | how odd |
| 11:17 | <Hixie> | i wonder why |
| 11:36 | <hsivonen> | I guess I disagree with Dr. Hoffmann about CURIEs |
| 11:49 | <hallvors> | Hixie: add something relevant to plugin path in opera6.ini |
| 11:51 | <zcorpan> | Hixie: it's supposed to look in /Library/Internet Plug-Ins |
| 11:51 | <hallvors> | well.. that's on Windows, I don't really know on Mac. Sorry. |
| 12:12 | <Philip`> | hsivonen: Hixie could modify the Live DOM Viewer to add a header to disable IE8's XSS filter |
| 12:16 | <hallvors> | yes, I suggested that on IRC a while ago. the header is X-XSS-Protection: 0 |
| 12:18 | <hsivonen> | http://twitter.com/drawohara/statuses/1012168434 |
| 12:19 | <hsivonen> | is "the shite" a praise while "shite" isn't? |
| 12:19 | <BenMillard> | hsivonen, it can be |
| 12:20 | <Philip`> | hallvors: http://www.google.com/search?q=site:krijnhoetmer.nl+x-xss-protection suggests it was only me that suggested it on IRC around here :-) |
| 12:20 | <hsivonen> | BenMillard: ok. tweeted spec feedback could be less ambiguous :-) |
| 12:23 | <takkaria> | I think that twitter is missing a "the", but yeah, seems like praise |
| 12:24 | <hsivonen> | takkaria: I thought it was missing "are" |
| 12:27 | <Philip`> | http://www.urbandictionary.com/define.php?term=the+shit is seemingly the intended meaning, not http://www.urbandictionary.com/define.php?term=the+shite |
| 12:29 | <yecril71> | I believe that keywords like rel="author" should be left in English. |
| 12:29 | <yecril71> | They are not meant to be directly visible to the human reader. |
| 12:30 | <BenMillard> | Philip`, looks more like vandalism to me. |
| 12:31 | <BenMillard> | (especially considering the extremely small number of votes) |
| 12:34 | <Philip`> | Hmph, and I thought Urban Dictionary was a trustworthy source :-( |
| 12:34 | <takkaria> | hsivonen: uh,yeah,you're right |
| 12:36 | <Dashiva> | Mr. Last Week seems to be on the ball for once |
| 12:37 | <Philip`> | Hmm, the OED doesn't seem to have the positive definition at all - it just has the dirty ones, and notes "Not now in decent use." |
| 12:37 | hsivonen | notes that the W3C is funded by its corporate masters |
| 12:37 | <Philip`> | Dashiva: Like one of those people at the circus who does clever balancing tricks but often falls off? |
| 12:38 | <hsivonen> | http://www.w3.org/2008/07/ogws-cfp |
| 12:38 | <Dashiva> | Philip`: Yes, and much entertainment is had by all |
| 12:41 | <hallvors> | Philip`: http://krijnhoetmer.nl/irc-logs/whatwg/20081008#l-608 :) |
| 12:42 | <Philip`> | hallvors: Oh, right :-) |
| 12:42 | <Philip`> | Maybe I should have read the logs I was pointing at |
| 13:02 | <zcorpan> | hsivonen: i tried my bookmarklet on http://html5.validator.nu/?doc=http%3A%2F%2Fgoogle.se&showsource=yes and it looks really nice... except for "<body bgcolor=#ffffff text=#000000 link=#0000cc vlink=#551a8b alink=#ff0000 onload="sf();if(document.images)new Image().src='/images/nav_logo3.png'" topmargin=3 marginheight=3>" |
| 13:02 | <zcorpan> | but i'm not sure that's worth optimizing |
| 13:04 | <hsivonen> | zcorpan: I don't follow. Which bookmarklet? |
| 13:04 | <zcorpan> | hsivonen: sorry, in the bug. http://bugzilla.validator.nu/show_bug.cgi?id=325 |
| 13:08 | <hsivonen> | zcorpan: cool! I think it need more styling to distinguish messages and source quotes. |
| 13:08 | <zcorpan> | hsivonen: yeah |
| 13:09 | <zcorpan> | hsivonen: perhaps insert the <li> instead |
| 13:12 | <hsivonen> | I wonder if were feasible to make the source text take 50% of available width and make the messages float into the other 50% of available width and draw a line from the error highlight to the error message CSS box |
| 13:14 | <zcorpan> | interesting idea... not sure it would be better though :) |
| 13:15 | <hsivonen> | Hixie: what do you suggest for block annotations inserted into inline content? |
| 13:15 | <hsivonen> | in terms of content model conformance |
| 13:15 | <hsivonen> | I think there's a use case here :-) |
| 13:17 | <yecril71> | If you want to indicate a representation, you can use A[type="application/pdf"]. |
| 13:17 | <yecril71> | There is no need to introduce A[accept]. |
| 13:20 | <yecril71> | Developers can rig their browsers with all extensions they consider valuable. |
| 13:20 | <mookid> | erm |
| 13:20 | <mookid> | no. |
| 13:20 | <mookid> | maybe if your web app serves a couple of ted in ashed companies |
| 13:20 | <mookid> | ted in a shed* |
| 13:21 | <mookid> | designing enterprise level web applications you need standards |
| 13:21 | <mookid> | not to mention development frameworks |
| 13:22 | <yecril71> | The standard, as it is, reflects what developers are unwilling to do. |
| 13:22 | <mookid> | type doesn't perform that function btw |
| 13:22 | <yecril71> | Why not? |
| 13:22 | <mookid> | ..? |
| 13:22 | <zcorpan> | hsivonen: you just have to split the elements (<b>s and <code>s) in the parent chain until the current element is <li> and then insert a new <ol> there |
| 13:23 | <hsivonen> | zcorpan: ok |
| 13:23 | <mookid> | yecril71: did you read that email I just sent out? |
| 13:23 | <yecril71> | Why isn�t the type attribute good for the purpose? |
| 13:23 | <yecril71> | I am just reading it. |
| 13:25 | <yecril71> | "Getting involved" is not that easy. |
| 13:26 | <yecril71> | I would consider myself happy if I could get involved. |
| 13:26 | <yecril71> | And you surely cannot get involved in everything. |
| 13:26 | <yecril71> | Not because you do not have enough time, because of the trade secrets. |
| 13:28 | <mookid> | well no but the only reason I can find not to do this is "it's too much work" |
| 13:28 | <yecril71> | HTML is not hypermedia, HMML is :-) |
| 13:28 | <mookid> | whatever :P |
| 13:29 | <mookid> | u get the point =) |
| 13:29 | <mookid> | a PDF is not the same thing as an HTML document. |
| 13:29 | <yecril71> | The problem is that it does not help that you are willing to help. |
| 13:30 | <mookid> | well I don't mind not being able to do the work provided someone else does it |
| 13:30 | <hsivonen> | mookid: PDF, ODF, OOXML and .doc can have hyperlinks to HTTP resources. Do you classify them as hypermedia formats? |
| 13:30 | <mookid> | I still ahvent' been given a good reason why this would not be beneficial |
| 13:31 | <mookid> | they will be eventually they aren't used for that currently |
| 13:31 | <mookid> | hsivonen: ^ |
| 13:31 | <yecril71> | It seems nobody is going to work on it. |
| 13:31 | <mookid> | oh great. |
| 13:31 | <mookid> | well at least we have video tags! |
| 13:32 | <hsivonen> | mookid: you have been given reasons why what you are suggesting is bad. Presumably you are classifying the reasons as not "good" reasons. |
| 13:32 | <mookid> | no I havent at all |
| 13:32 | <mookid> | what are those reasons? |
| 13:32 | <hsivonen> | see the logs from yesterday |
| 13:32 | <mookid> | I read them |
| 13:33 | <jcranmer> | mookid: can you name one drawback of your feature? |
| 13:33 | <mookid> | if you look at the conversations I'm having on the mailling list.. I'm constantly repeating myself and referring back to stuff I've already said - just explained differently because peopel aren't comprehending what I'm saying |
| 13:33 | <yecril71> | Nobody is going to free Tibet, or Tuva. |
| 13:34 | <yecril71> | Or cease cutting the rainforest. |
| 13:34 | <yecril71> | There are more dire things to be worried about. |
| 13:34 | <mookid> | my skulls tougher than alot of brick walsl |
| 13:34 | <jcranmer> | I'll take that as a `no' |
| 13:34 | <mookid> | actually there arent - better interoperability of internet applications is paramount to the human race |
| 13:35 | <mookid> | -_- |
| 13:35 | <hsivonen> | mookid: have you considered the possibility that conneg might be a hindrance to interop? |
| 13:35 | <jcranmer> | why do people think that new features come without costs? |
| 13:35 | <mookid> | ITS NOT A NEW FEATURE |
| 13:35 | <mookid> | it's part of the protocol |
| 13:35 | <mookid> | jesus. |
| 13:36 | <Dashiva> | And browsers support it |
| 13:36 | <hsivonen> | mookid: you are suggesting that something be added. ergo, new feature. |
| 13:36 | <mookid> | no they don;t.. javacsript virtual machines do |
| 13:36 | <jcranmer> | mookid: you're adding a feature to HTML |
| 13:36 | <mookid> | I'm "adding" something that should already be there |
| 13:36 | <jcranmer> | you're still adding |
| 13:36 | <mookid> | oh great |
| 13:36 | <mookid> | ok well I guess when the slaves all came along asking for freedom |
| 13:36 | <mookid> | we should've been like |
| 13:36 | <mookid> | you know what |
| 13:36 | <mookid> | I'm busy right now |
| 13:37 | <mookid> | BYE |
| 13:37 | <yecril71> | We shall overcome, some day. |
| 13:37 | <mookid> | Why would I want to free you anyway?? I make lots of money from cheap labour. |
| 13:38 | <yecril71> | That�s my boy. |
| 13:38 | <mookid> | that's a "rational" defense against freeing slaves |
| 13:38 | <mookid> | is it not? |
| 13:38 | <yecril71> | Of course it is. |
| 13:38 | <mookid> | perspective. |
| 13:38 | <yecril71> | You are on the ridge of being plonked. |
| 13:38 | <mookid> | translate..! |
| 13:39 | <yecril71> | killfiled. |
| 13:39 | <Dashiva> | HTTP headers do not have human rights |
| 13:39 | <Dashiva> | Oddly enough |
| 13:39 | <mookid> | really? |
| 13:39 | <hsivonen> | mookid: are you implying that using the Accept header is a moral or human right issue? |
| 13:39 | <mookid> | no it was an analogy |
| 13:39 | <yecril71> | HTTP headers have headerly rights. |
| 13:40 | <mookid> | you know.. the kind of thing you use when you're battling ignorance -_- |
| 13:40 | <Dashiva> | Analogies are like statistics, 87% of them are made up on the spot. |
| 13:40 | <mookid> | yeah it was mostly a joke anyway relax |
| 13:41 | <mookid> | so.. about the problems.. what were they again? |
| 13:41 | <Philip`> | Dashiva: I won't trust your statistics unless you make up a standard deviation too |
| 13:41 | <hsivonen> | mookid: http://krijnhoetmer.nl/irc-logs/whatwg/20081118#l-822 |
| 13:42 | <mookid> | oh dear oh dear |
| 13:42 | <mookid> | you see a URI - and your immediate reaction is that it needs to go through a browser |
| 13:42 | <yecril71> | My mediaeval English is not good enough |
| 13:42 | <Dashiva> | Philip`: Maybe that's what I want you to think |
| 13:43 | <yecril71> | but the weapon is called ep�e in French. |
| 13:43 | <mookid> | There is no pair there at all - if I want to get a resource.. I put the URI into the appropriate UA |
| 13:43 | <mookid> | there's no pairing there at all |
| 13:44 | <yecril71> | OK, it is rapier in English. |
| 13:45 | <mookid> | this is my point - you have your subjective opinion on what a URI should do |
| 13:45 | <hsivonen> | mookid: and you don't? |
| 13:45 | <mookid> | and your projecting it onto developers by restricting the capabilites of browsers |
| 13:45 | <mookid> | I don't know which is 'better' - I just know I want to make good use of HTTP |
| 13:46 | <mookid> | I can't do that in a brwoser unless you support it |
| 13:46 | <mookid> | that's why I suggested it as optional |
| 13:46 | <Dashiva> | You want to make the internet worse for everyone else |
| 13:46 | <mookid> | fuck off |
| 13:46 | <yecril71> | The video tag is not an evidence of hypermedialness. |
| 13:46 | <mookid> | excuse my language |
| 13:46 | <yecril71> | It is evidence for compositeness. |
| 13:47 | <yecril71> | Are you suffering from Turette�s? |
| 13:47 | <mookid> | every time this discussion gets interesting it goes quiet.. |
| 13:47 | <yecril71> | PDF can embed video in exactly the same way. |
| 13:48 | Philip` | sees that Martin McEvoy chooses to interpret the statistics to say that only 0.09% of pages use rev=stylesheet, instead of to say that of the pages that use rev and don't use rev=made (which is redundant with rel=author), 57% use it for rev=stylesheet |
| 13:48 | <mookid> | hsivonen: so... |
| 13:49 | <mookid> | I don't know exactly what a URI should do.. but I'm sure that restricting client capabilities to use HTTP will lead it down one way when there is another available |
| 13:49 | <mookid> | which is why I dont consider "well that's the way its done" an acceptable response |
| 13:50 | <mookid> | and neither should you. |
| 13:51 | <Dashiva> | Have you produced an answer for "Why should the page author control what my user agent wants to accept on my behalf?" yet? |
| 13:51 | <yecril71> | The client is free to use HTTP as it sees fit, within the framework of the HTTP specification. |
| 13:52 | <mookid> | Dashiva: what? how is that any different from specifying the content-type in the URI ? |
| 13:52 | <Dashiva> | mookid: Because that's just a URI, my browser can still Accept: whatever it wants |
| 13:52 | <mookid> | how is saying <a href="foo.pdf">>link</a> not doing that? |
| 13:52 | <mookid> | you don't understand Accept then |
| 13:52 | <mookid> | Accept is an indicator |
| 13:53 | <mookid> | it's not a fixed contract |
| 13:53 | <mookid> | the server can return whatever content-type it wants |
| 13:53 | <yecril71> | If you specify the content type in the URL, it is there. |
| 13:53 | <yecril71> | Otherwise, it is not there. |
| 13:53 | <yecril71> | That is the difference. |
| 13:53 | <mookid> | er, ok |
| 13:53 | <mookid> | :D |
| 13:53 | <Dashiva> | mookid: Accept is a header the user agent controls. The URI is something the server controls. They should stick to their own. It's simple, isn't it? |
| 13:54 | <mookid> | no.. you misunderstand the purpose of accept |
| 13:54 | <mookid> | Accept does nothing at the moment in browsers |
| 13:54 | <mookid> | it's just a catchall essentially |
| 13:54 | <mookid> | it may aswell not be there |
| 13:54 | <yecril71> | Why is it a problem for HTML? |
| 13:54 | <Dashiva> | Okay, that shows how much you know |
| 13:55 | <mookid> | because HTML is how the browser traverses HTTP |
| 13:55 | <yecril71> | The browser does not traverse HTTP at all. |
| 13:55 | <mookid> | you know what I mean - dont be pedantic |
| 13:56 | <mookid> | traverses URIs over HTTP |
| 13:56 | <yecril71> | My guess is that the browser uses HTTP to get data. |
| 13:56 | <mookid> | it's the way that brwosers do HTTP |
| 13:56 | <yecril71> | It does not traverse URIs. |
| 13:56 | <mookid> | yes it does - what is a browser for if it's not for movign around URIs ? |
| 13:57 | <yecril71> | The browser is for surfing the Web. |
| 13:57 | <yecril71> | (or browsing, if you prefer). |
| 13:57 | <mookid> | lay off the crack |
| 13:57 | <Dashiva> | mookid: How about you get a packet sniffer and look at what Accept headers browsers actually send |
| 13:58 | <yecril71> | (Actually, Microsoft�s documentation nowhere says what Internet Explorer is for). |
| 13:58 | <yecril71> | (It only says how cute it is.) |
| 13:58 | <mookid> | they send a long string of preferences.. and then a */* at the end.. |
| 13:58 | <mookid> | so it really makes no differences |
| 13:58 | <mookid> | particularly when, by all of your own admission, it doesnt make a difference because each URI should only serve one content-type |
| 13:59 | <yecril71> | Why is this a problem for HTML? |
| 13:59 | <Dashiva> | Sure, but it lets hardliners like you do it still |
| 13:59 | <Dashiva> | So everyone can be happy |
| 13:59 | <mookid> | what? |
| 13:59 | <mookid> | I'm not 'hard lining' I'm doing the opposite |
| 14:00 | <Dashiva> | You're going on and on about a feature we already have |
| 14:00 | <mookid> | the future we already have? |
| 14:00 | <mookid> | pwahahaha |
| 14:00 | <Dashiva> | For no reason but theoretical purity |
| 14:00 | <mookid> | theoretical purity? |
| 14:00 | <mookid> | your a joke. |
| 14:00 | <mookid> | if that's literally the only criticism you have |
| 14:00 | <mookid> | you're seriously scraping the bottom of the barrel |
| 14:02 | <jcranmer> | Philip`: anyone can use the same stastics to support their case |
| 14:02 | <yecril71> | HTTP is a standard protocol for transmitting HTML documents. |
| 14:02 | hallvors | mangles Opera's support for window.setTimeout() if and only if it's called on nytimes.com from the NYTD.require() method. |
| 14:02 | <mookid> | you're trolling yecril71 :) |
| 14:02 | <yecril71> | Not the other way round. |
| 14:02 | <mookid> | HTTP has nothing to do with HTML |
| 14:02 | <mookid> | what about |
| 14:02 | <yecril71> | I am replying to your letter. |
| 14:02 | <mookid> | RSS |
| 14:03 | <mookid> | Atom |
| 14:03 | <mookid> | xml |
| 14:03 | <mookid> | |
| 14:03 | <yecril71> | They are document formats, IIRC. |
| 14:03 | <hsivonen> | hallvors: how do you undo a patch like that when the site fixes itself? |
| 14:03 | <Dashiva> | browserjs, probably |
| 14:03 | <hsivonen> | hallvors: or how do site owners test their fix? |
| 14:03 | <mookid> | hsivonen: why did you not continue that discussion before? |
| 14:04 | <hsivonen> | mookid: I have work to do |
| 14:04 | <mookid> | oooh |
| 14:04 | <mookid> | i see |
| 14:04 | <jcranmer> | Philip`: yet my reaction was the same as yours upon seeing those states |
| 14:04 | <jcranmer> | s/te/t/ |
| 14:04 | <jcranmer> | "rev=stylesheet is by far the most used rev link" |
| 14:06 | <yecril71> | HTTP is not limited to HTML, but if you want to expose HTTP, you rather choose HTTP to do the job. |
| 14:06 | <yecril71> | If you want to expose HTML, you choose HTTP. |
| 14:06 | <Philip`> | jcranmer: No it's not - rev=made is the most used rev link |
| 14:06 | <krijnh> | I send all my pages to my customers as email attachments |
| 14:07 | <hallvors> | hsivonen: undoing it is as simple as releasing a new browser.js update without that code. Getting site owners to test with opera:config#Browser%20JavaScript set to 0 is somewhat trickier, I admit.. :-o |
| 14:07 | <hsivonen> | hallvors: ok |
| 14:08 | <jcranmer> | Philip`: must have missed that, then |
| 14:08 | <yecril71> | I presume the customers publish krijnh�s pages themselves? |
| 14:09 | <krijnh> | No, they email me, "Hi, I want info about your company" and then I send them back an HTML page with that info |
| 14:09 | <krijnh> | Fuck HTTP |
| 14:10 | <yecril71> | That is rather peculiar, I would say. |
| 14:11 | <jcranmer> | yecril71: needless to say, people send HTML email a fair amount |
| 14:11 | <yecril71> | Sending is not exposing. |
| 14:12 | <yecril71> | All right, in today�s world it is, but it is another story :-( |
| 14:13 | <yecril71> | HTML does not support content negotiation at all, in URIs or not in URIs. |
| 14:14 | <yecril71> | Except maybe for A[type]. |
| 14:14 | <yecril71> | User agents can, and perhaps should, support content negotiation. |
| 14:14 | <yecril71> | But that has nothing to do with HTML. |
| 14:15 | <Philip`> | krijnh: That sounds like Richard Stallman's approach |
| 14:16 | <yecril71> | HTML, as a markup language, does not make use of URIs, it only contains them here and there. |
| 14:16 | <yecril71> | Indeed, being a language, it does not make use of anything. |
| 14:18 | <yecril71> | Actually, SVG tiger is untimately smaller than PNG tiger. |
| 14:20 | <yecril71> | ultimately |
| 14:21 | <yecril71> | You can have multiple e-mail addresses in rev="made |
| 14:21 | <Philip`> | Not if you resize the PNG to be really small |
| 14:22 | <yecril71> | SVG is ultimately smaller. |
| 14:22 | <Philip`> | yecril71: How do you put multiple email addresses in it? |
| 14:22 | <ehird> | but is it AWESOMELY smaller?! |
| 14:22 | <Philip`> | yecril71: I bet I can make a 1x1-pixel PNG of the tiger that's smaller than the SVG version |
| 14:23 | <yecril71> | mailto:a1⊙ec;a2⊙ec |
| 14:23 | <yecril71> | But it is not an equivalent representation any more. |
| 14:27 | <Philip`> | Quite a few people just seem to put their names in the href attribute |
| 14:30 | <Philip`> | yecril71: If a PNG is ever equivalent to an SVG, where is the threshold at which a resized n*n version of the PNG is no longer equivalent to the SVG? |
| 14:31 | <yecril71> | There are various measures. |
| 14:31 | <yecril71> | Quantitative: the spectrum of the histogram. |
| 14:31 | <yecril71> | Qualitative, if B/W: |
| 14:32 | <yecril71> | Graph isomorphism. |
| 14:32 | <yecril71> | The threshold depends on how complicated the image is. |
| 14:33 | <mookid> | if they represent the same image it's the same resource -_- |
| 14:33 | <yecril71> | Fractals cannot be represented as PNG at all. |
| 14:34 | <Philip`> | "Lachy[...] knows more about HTML5 than almost anyone else which is why he's the right guy to write the authoring guide." - hmm, that sounds to me like a reason why he shouldn't write it, because he won't understand HTML5 from the perspective of a typical ignorant developer :-) |
| 14:35 | <Philip`> | mookid: If I have a PNG image and a thumbnail version of it, those are two representations of the same resource? |
| 14:36 | <Philip`> | If so, does HTTP provide any way to request the desired representation from the same URI? |
| 14:36 | <Lachy> | Philip`, where's that quote from? |
| 14:36 | Lachy | was an ignorant developer once, so I'm more than qualified :-) |
| 14:37 | <Philip`> | Lachy: http://www.w3.org/mid/49241573.8080003⊙don |
| 14:37 | <Lachy> | ok |
| 14:37 | <yecril71> | The content type can contain image resolution as an option |
| 14:39 | <Philip`> | Ah, so I can do "Accept: image/png;size=little;q=1"? I suppose that sounds vaguely reasonable |
| 14:40 | <yecril71> | I cannot give you the details, check it up with the registry. |
| 14:40 | <yecril71> | The resolution should be explicit IIRC. |
| 14:43 | <mookid> | Philip`: a thumbnail is a seperate resource right |
| 14:44 | <mookid> | example.com/dog/thumbnail |
| 14:45 | <Philip`> | mookid: Hmm, I don't quite see what makes it a separate resource, since it seems to be representing the same image |
| 14:45 | <mookid> | it's a seperate image - it's a thumbnail of the real image |
| 14:46 | <Philip`> | But a JPEG and a PNG are different representations of the same image (if and only if they decode to the same number of pixels)? |
| 14:47 | Philip` | isn't sure where the distinction lies |
| 14:47 | <mookid> | why would they be a different size? |
| 14:47 | <mookid> | well the distinction lies in what the entity is.. |
| 14:47 | <jcranmer> | but JPEG is lossy and PNG is lossless |
| 14:47 | <mookid> | a thumbnail isn't the image.. that's why it's a thumbnail of the image.. |
| 14:48 | <mookid> | yeah - they're different representation of the same image |
| 14:48 | <Philip`> | mookid: One might be a low-resolution lossy JPEG, and the other a high-resolution lossless PNG |
| 14:49 | <mookid> | what's your point? |
| 14:49 | <Philip`> | (so people might decide which to download based on the speed of their internet connection, because otherwise they're basically the same image) |
| 14:49 | <mookid> | ..? |
| 14:51 | <mookid> | Sorry, I dont understand the point you're trying to make dude |
| 14:51 | <Philip`> | mookid: My point is to try to understand why if I have a low-resolution lossy JPEG (which could act as a thumbnail) and a high-resolution lossless PNG, you seem to be saying they are different resources; but if I have equally-sized JPEG and PNGs, they're just different representations of the same resource |
| 14:52 | <mookid> | That's a design descision obviously |
| 14:52 | <mookid> | there's nothign stopping you from resizing the image |
| 14:52 | <Philip`> | I'm not attempting to prove anything, I just want to get a better understanding of what a resource is, since it seems a bit vague at the moment |
| 14:52 | <mookid> | and specifying Accept jpeg |
| 14:52 | <mookid> | for your thumbnails.. |
| 14:52 | <mookid> | that's application design though right?! |
| 14:53 | <mookid> | well resource is supposed to be vague - that's the poitn I'm trying to get across - you need to be able to accuotn for everyone's interpretation |
| 14:54 | <mookid> | some people think resources are tied to a singl representation for each URI |
| 14:54 | <mookid> | which is fine.. but some people don't and that is the reason Accept exists |
| 14:54 | Philip` | doesn't like things being vague :-( |
| 14:54 | <mookid> | vague is the wrong word.. |
| 14:55 | <mookid> | abstract is better |
| 14:55 | <Philip`> | I wouldn't mind if people had different specific technical interpretations of what a "resource" is, as long as they could each define it, and then we could give them all different names to make it clearer and then it wouldn't be confusing |
| 14:56 | <mookid> | it is defined in fielding's disseratation - there's plenty ofpapers written abuot it |
| 14:58 | <yecril71> | Web authors are not going to read that. |
| 14:59 | <yecril71> | You have to come up with something short to recount and easy to grasp. |
| 14:59 | <mookid> | do yuo have to say things? |
| 14:59 | <mookid> | why dont you not say things.. |
| 14:59 | <mookid> | try that out |
| 14:59 | <Philip`> | "a resource R is a temporally varying membership function M_R(t), which for time t maps to a set of entities, or values, which are equivalent." clears everything up ;-) |
| 15:00 | <mookid> | :P |
| 15:00 | <mookid> | that's explained better in th enext paragrpah by way of explaining the benefits |
| 15:01 | Philip` | wonders why M_R is defined and then seemingly never referred to again |
| 15:02 | <Philip`> | Maybe my concern is that it seems inadequate to use media type as the way to select a representation, since the media type is only meant to be identifying the data format of a representation and you might have multiple distinct representations of the same resource with the same data format |
| 15:03 | <mookid> | how would that work? |
| 15:03 | <mookid> | wtf was that? o.O |
| 15:04 | <mookid> | how would that work? |
| 15:05 | <Philip`> | I could represent my hypertext document as text/html with uppercase tag names, or as text/html with lowercase tag names, and they're distinct representations (since a representation is a sequence of bytes) with the same data format |
| 15:05 | <mookid> | page/uppercase + page/lowercase |
| 15:05 | <mookid> | seperate formats |
| 15:05 | <mookid> | formats |
| 15:05 | <mookid> | lol |
| 15:05 | <mookid> | seperate resoruces |
| 15:05 | <mookid> | not formats |
| 15:06 | <yecril71> | page/uppercase is not registered |
| 15:06 | <Philip`> | But they're the same resource, just with different representations, and it's not nice if I have to pretend they're different resources to hack around HTTP's assumption that URI+media-type is adequate identification |
| 15:07 | <Philip`> | yecril71: I think page/uppercase is intended as a URI, not a media type |
| 15:07 | <yecril71> | you would have to register an option for text/html |
| 15:08 | <Philip`> | That sounds like an awful lot of work, and also impossible |
| 15:08 | <yecril71> | but what if you want every other letter to be capitalized? |
| 15:08 | <Philip`> | because the IETF is not going to listen to me saying "please register text/html;uppercase=yeah" |
| 15:08 | <yecril71> | are x-options allowed? |
| 15:08 | <yecril71> | It depends whether they deem it is important. |
| 15:09 | <yecril71> | In this particular case, it probably is not. |
| 15:09 | <yecril71> | And I would rather say "flavor=uppercase". |
| 15:11 | <Philip`> | The media type is the wrong place for that information anyway, since it's not part of the data format - the data format is still just HTML |
| 15:12 | <yecril71> | I can imagine it can be essential for somebody to have it like that. |
| 15:13 | <yecril71> | As a more real-world example, consider "linewidth=80" versus "indented=pretty". |
| 15:13 | <Philip`> | The aforementioned dissertation doesn't seem to say anything about how you only content-negotiate based on the data format, so I guess if you're using HTTP you should do "X-Accept-Uppercase-Tags: please" or something |
| 15:13 | <mookid> | are they the same resrouce though - it would have a different include for the css |
| 15:14 | <Philip`> | in which case simply adding "Accept" to HTML wouldn't be sufficient to do proper content negotiation, since that's restricted to negotiating the data format :-) |
| 15:15 | <yecril71> | I think all those things belong to the data format as options. |
| 15:15 | <mookid> | right - it's GUI stuff |
| 15:15 | <mookid> | you can do that with css and javascript |
| 15:15 | <mookid> | that's design stuff again |
| 15:17 | <yecril71> | Do what with css and javascript? |
| 15:17 | <yecril71> | I can do everything with JavaScript because it is Turing-complete. |
| 15:17 | <yecril71> | And I am the king of gorillas. |
| 15:18 | <mookid> | this whole uppercase of the same page stuf that's apparently created a massive flaw in RESTful architecture |
| 15:18 | <mookid> | -_- |
| 15:19 | <mookid> | either way - some data is different between the two resources whether it's the css include or the ASCII values |
| 15:20 | <mookid> | how you approach that is a design descision - I shouldn't be the person to say one way is better than the other |
| 15:20 | <mookid> | the same way as I shouldn't be the person to say that using URIs is better one way or the other |
| 15:21 | <mookid> | but neither should anyone else - we just need to support the standarsd (like HTTP) and let developers mak those descisions |
| 15:22 | <mookid> | that's the most pragmatic approach |
| 15:22 | <mookid> | Philip`: did some of the latest email make more sense - I only ask because you seem more intereted in my opinion now :p |
| 15:24 | <yecril71> | I am sorry to say most of id did not make sense. |
| 15:24 | <yecril71> | most of it |
| 15:25 | <mookid> | feel free to respond on tehmailing list |
| 15:25 | <mookid> | :) |
| 15:25 | <yecril71> | The problem is, I am sort of banned. |
| 15:25 | <mookid> | I can understand why |
| 15:26 | <yecril71> | Good for you. |
| 15:26 | <mookid> | yes it is. |
| 15:27 | <Philip`> | mookid: The ASCII values are an artifact of the representation, not of the underlying conceptual resource - if I write <html> or <HTML> then it gets parsed by exactly the same parsing algorithm into exactly the same DOM, and the only difference is the bytes sent over the wire |
| 15:28 | <Philip`> | (I'm not uppercasing the textual content of the document, only the tag names) |
| 15:29 | <Philip`> | (which is a slightly pointless thing to do, but I'm sure there exist more plausible real-world cases for something like this :-p ) |
| 15:29 | <yecril71> | Like linewidth=80 for example. |
| 15:30 | <Philip`> | mookid: I don't remember the latest email saying much that hadn't been said before; I'm just procrastinating by thinking out loud about some of this stuff :-) |
| 15:32 | <Philip`> | Also it's comforting to know that a PhD dissertation doesn't have to actually make sense |
| 15:34 | <jmb> | suits me :) |
| 15:34 | <yecril71> | Why is it comforting? |
| 15:34 | <jcranmer> | who is it that wrote that nonsensical PhD |
| 15:34 | <jcranmer> | ? |
| 15:35 | <Philip`> | jcranmer: Do you mean Roy Fielding's dissertation? |
| 15:35 | <yecril71> | It is rather depressing to me. |
| 15:35 | <Philip`> | jcranmer: If so, Roy Fielding wrote it |
| 15:36 | <Philip`> | yecril71: Because I need to write one, and so I'm happier if I think the bar is lowered :-) |
| 15:36 | <yecril71> | It is depressing because I know I am not shameless enough to follow that path :-( |
| 15:37 | Philip` | has been working for a year and still doesn't quite know what his dissertation is going to be on, but never mind minor problems like that |
| 15:38 | <mookid> | well I'd be interested to hear these real world cases - and also how that relates to content type negotiation |
| 15:39 | <jcranmer> | ah |
| 15:40 | <jcranmer> | Bogdanov |
| 15:40 | <jmb> | Philip`: if it helps, it took me somewhere between 18 & 21 months to work out exactly what I was doing |
| 15:41 | Philip` | notes that he is being mostly unfair in thinking that Roy Fielding's dissertation doesn't make sense, since he hasn't read it in much detail, but it does seem mostly like vague descriptions and post-hoc rationalisations, which isn't great, though it's kind of unavoidable because you can't set up two wildly popular world-wide network systems and evaluate the differences so you just have to guess |
| 15:42 | yecril71 | has been working for half a year to learn that the unjustified assumptions his master�s thesis was based on actually can be defended |
| 15:44 | jgraham | moans about people discussing PhDs here |
| 15:46 | <Philip`> | mookid: I think the not-quite-real-world cases still demonstrate that there is seemingly a disconnect between the abstract REST theory (where a resource has multiple representations and clients can negotiate which one they get) and practical suggestions for adding <a href accept="media-type"> (which is much more limited) |
| 15:47 | <Philip`> | so a good solution to the content negotiation issue should do much more than simply Accept |
| 15:48 | <Philip`> | and would have to allow arbitrary X-... HTTP headers, because that's the only mechanism that lets you properly implement content negotiation |
| 15:50 | <Philip`> | Anyway, real PhD dissertations should just be full of maths rather than woolly words |
| 15:52 | jgraham | suspects that depends somewhat on your thesis topic |
| 15:52 | Philip` | is actually trying to avoid the maths as much as possible, because it's scary |
| 15:52 | <mookid> | Philip`: The accept header would be one component of that |
| 15:53 | <mookid> | why would it not make sense to at least provide the mechanism for that even if it is 'incomplete' |
| 15:54 | <mookid> | beyond that you are getting into additions to the HTTP spec |
| 15:54 | <Philip`> | How come nobody has commented yet on the <link rev="D. Bailey Management" ...> and <link rev="YouTube" ...> and <link rev="text/css" ...> and so on? Those are far more fun than simply mixing rev and rel |
| 15:55 | <Philip`> | mookid: HTTP already explicitly allows extension header fields for server-driven content negotiation |
| 15:56 | <Philip`> | so it wouldn't need additions |
| 15:56 | <mookid> | right - but that's for use in special cases |
| 15:56 | <mookid> | Accept is a standard |
| 15:56 | <mookid> | specific standard |
| 15:56 | <mookid> | I suppose you could go as far as to provide a header attribute instead |
| 15:57 | <Philip`> | There are four other specific standard non-extension header fields that it mentions for negotiation |
| 15:57 | <mookid> | content-encoding? |
| 15:57 | <mookid> | user-agent ? |
| 15:58 | <Philip`> | Accept-{Charset,Encoding,Language}, User-Agent |
| 15:58 | <mookid> | user-agent I'd say is pretty irrelevant for obvious reasons |
| 15:59 | <mookid> | but sure these could also be accounted for |
| 15:59 | <Philip`> | If the problem is that you want to expose control over HTTP content negotiation to HTML pages, then Accept by itself is not a solution to that problem |
| 15:59 | <mookid> | well it's the most useful |
| 15:59 | <mookid> | by far |
| 16:00 | <mookid> | multiple content-types is the most common variation on resource representation |
| 16:00 | <mookid> | I take your point though, maybe it makes sense to ammend my proposal to include all of these |
| 16:01 | <mookid> | or even just a header attribute |
| 16:01 | <mookid> | this is more like it, though thanks for your input :) |
| 16:02 | Philip` | is just trying to make the proposed feature more and more complex, so it's easier to kill it later for being too bloated ;-) |
| 16:02 | <mookid> | haha I did suspect ;P |
| 16:02 | <mookid> | is there no way we can work at this to make it feasible? |
| 16:03 | <mookid> | who can I work through the nitty-gritty with ? |
| 16:04 | <mookid> | I don't think it has to be that bloated necessarily, HTTP isn't a really bloated protocol |
| 16:04 | <mookid> | it's certianly no SOAP. |
| 16:08 | <hsivonen> | http://lists.w3.org/Archives/Public/www-html/2006Feb/0069.html |
| 16:08 | <hsivonen> | last paragraph in particular |
| 16:09 | <hsivonen> | and http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-March/009732.html |
| 16:10 | <jgraham> | mookid: Are you still looking for a way to specify http accept on a link? It seems to me that that, apart from any theoretical issues has significant compatibility issues since it would cause new browsers to return different documents to old browsers |
| 16:11 | <Philip`> | mookid: Given that you don't seem too concerned about supporting e.g. Accept-Charset, I assume you agree that "it is a feature of HTTP, therefore it must be exposed via HTML" is not a convincing argument, because sometimes nobody cares enough about that feature of HTTP to be worth the effort |
| 16:11 | <mookid> | but you're assuming nobody cares becasue noone has the ability to |
| 16:11 | <mookid> | I addressed this |
| 16:12 | <mookid> | that's an unwinnable argument purely on the basis that it's not practical *at the moment* |
| 16:12 | <mookid> | that's the reason I've brought this up |
| 16:12 | <mookid> | to change it so it is feasible.. |
| 16:12 | <Philip`> | mookid: But you seem to care about Accept and not about Accept-Charset, even though you can't control either via HTML |
| 16:12 | <mookid> | in a way which doesn't effect existing implementations |
| 16:12 | <mookid> | right and I've said I'm happy to loko at including that aswell |
| 16:12 | <mookid> | content-type is by far the most common cocnern |
| 16:13 | <jgraham> | mookid: Is this directed at me? I don't understand how one could implement the feature so that it didn't break existing implementations |
| 16:13 | <mookid> | if that's going to make the difference then I am more than happy to include them in my proposal |
| 16:13 | <hsivonen> | mookid: here's the thing is short: If you care about which representation you are linking to, the choice of representation isn't indifferent to you and you need to address a particular representation. We already have an addressing mechanism: URL. |
| 16:13 | <mookid> | jgraham: becaue it's an option attribute |
| 16:13 | <jgraham> | fwiw I also agree with hsivonen |
| 16:13 | <hsivonen> | mookid: so whenever you care about linking to a particular representation, you really have two resources |
| 16:13 | <mookid> | THATS ONE APPROACH |
| 16:14 | <mookid> | I know |
| 16:14 | <mookid> | you can use |
| 16:14 | <mookid> | URLs |
| 16:14 | <mookid> | to do that |
| 16:14 | <Philip`> | mookid: So when looking at something like Accept-Charset, we should consider the possible costs (of language complexity and implementation effort and everything else) and the possible benefits (like what it would enable people to do) in order to decide whether it's worthwhile? |
| 16:14 | <hsivonen> | mookid: if you had only one resource, you by definition wouldn't have to care about linking to a particular representation |
| 16:14 | <mookid> | what? |
| 16:14 | <mookid> | what is this 'link' you talk abuot |
| 16:14 | <mookid> | it's a request |
| 16:14 | <hsivonen> | (aside: it may follow that with this definition, the set of resources with multiple representations is the empty set. If so, so be it.) |
| 16:14 | <mookid> | and a request is more than just GET (URI) |
| 16:15 | <mookid> | thre are headers |
| 16:15 | <mookid> | for a reason |
| 16:15 | <jgraham> | mookid: ? So how does that change the fact that if I do <a href="foo" accept="application/pdf"> a new browser will return a PDF and an old one will not? |
| 16:15 | <mookid> | in my application |
| 16:15 | <mookid> | that's a design descision |
| 16:15 | <mookid> | old applications will continue to work fine |
| 16:15 | <mookid> | with new browsers |
| 16:15 | <hsivonen> | mookid: link is the <a> element with your proposed attribute |
| 16:15 | <mookid> | jgraham: your response to that is..? |
| 16:16 | <jgraham> | You mean you are happy if different users get different representations of the resource? |
| 16:16 | <mookid> | yes - they're just representations |
| 16:16 | <jgraham> | Are your users also happy with that? |
| 16:16 | <jgraham> | I guess not |
| 16:16 | <mookid> | of course I am |
| 16:16 | <mookid> | it's a diffrent way of using URIs |
| 16:16 | <mookid> | which you clearly dont *think* is the 'right' way |
| 16:16 | <hsivonen> | mookid: well then you don't need to specify the accept header in your <a> element! |
| 16:17 | <mookid> | it's not 'right' it's just a way |
| 16:17 | <mookid> | hsivonen: yeah you do |
| 16:17 | <mookid> | of course you do |
| 16:17 | <jgraham> | I would be extremely confused as an end user if clicking the same link consistently returned an HTML document in one browser and a PDF in another |
| 16:17 | <hsivonen> | mookid: you just said you're happy even without it! |
| 16:17 | <mookid> | It's an application design issue.. |
| 16:17 | <jgraham> | Indeed I would assume that the browser that returned the PDF was broken |
| 16:18 | <mookid> | I'm happy that a user would have to either know the UA that was most appropriate |
| 16:18 | <mookid> | and/or the html version of that resource could link their up to date browser |
| 16:18 | <mookid> | to all the representations |
| 16:18 | <mookid> | aswell as provide it's own representation |
| 16:18 | <mookid> | that's an application design descision |
| 16:18 | <mookid> | microsoft office talks HTTP now |
| 16:19 | <Philip`> | jgraham: I think you'd actually blame Adobe for having a broken Acrobat plugin in that case |
| 16:19 | <Philip`> | because they're the easiest target for any PDF-related complaints |
| 16:19 | <jgraham> | I am not a design expert but having a single UI element do different things based on some unspecified external variable is, I expect, never a good idea |
| 16:19 | hsivonen | starts to think "that's an application design descision" is some kind of architect cop-out |
| 16:20 | <mookid> | it's not a single UI element.. |
| 16:20 | <jgraham> | It's a single link |
| 16:20 | <mookid> | how many users use multiple browsers? |
| 16:20 | <jgraham> | Almost all, hopefully |
| 16:21 | <mookid> | If HTML5 did implement that - up to date browsers would understand the markup so that's not a fair point |
| 16:21 | <mookid> | what? |
| 16:21 | <jgraham> | Browsers change with time |
| 16:21 | <jgraham> | Few people still use NS4 |
| 16:21 | <mookid> | yeah.. that's why I'd want it in the HTTP5 spec |
| 16:21 | <Philip`> | It's more of a concern when multiple users, each with a different single browser, communicate and expect web sites to work the same for everyone |
| 16:21 | <mookid> | well up to date browsers taht were HTTP5 compliant would understand the marup for the accept header |
| 16:21 | <mookid> | so I'd be willing to accept that older browsers wouldn't work and insist that my users upgrade |
| 16:22 | <mookid> | that's my descision as a developer |
| 16:22 | <Philip`> | (Do you mean HTML5, not HTTP5?) |
| 16:22 | <mookid> | HTLM |
| 16:22 | <mookid> | yeah |
| 16:22 | <mookid> | my bad ;) |
| 16:22 | <mookid> | what's wrong with that approach - it's just a different way of using URIs I dont see what the big deal is |
| 16:22 | <mookid> | and it's not like it stops you from continuing to use URIs for conneg |
| 16:23 | <jgraham> | Yeah so a user used to one behaviour in an old browser would be surprised if their new browser did something different with a familiar application. This would possibly be enough to convince them that the new browser was broken and that they should not upgrade |
| 16:23 | <mookid> | what |
| 16:23 | <hsivonen> | mookid: over here we don't just make stuff up for choice and vive la difference |
| 16:23 | <mookid> | if a link that says 'pdf version of reoprt' returns a pdf? |
| 16:23 | <mookid> | if you don't indicate that a certain link does something |
| 16:23 | <mookid> | that's a GUI insufficiecy |
| 16:24 | <mookid> | hsivonen: I'm not making anything up - HTTP conneg exists. deal with it. |
| 16:24 | <mookid> | hsivonen: you're opinionated and you're shrouding it in psuedo-logic |
| 16:24 | <mookid> | just admit you want conneg in URIs |
| 16:24 | <hsivonen> | mookid: I'm dealing with the consequences right now |
| 16:24 | <jgraham> | I really don't understand this. You seem to be imaganing that there is actually a single canonical version of the resource e.g. a PDF |
| 16:25 | <jgraham> | If that is the case, just link to is |
| 16:25 | <jgraham> | s/is/it/ |
| 16:25 | <mookid> | what? |
| 16:25 | <mookid> | that doesnt make sense |
| 16:25 | <mookid> | I'm suggesting there's lots of representations |
| 16:25 | <mookid> | of a resource |
| 16:25 | <mookid> | one URI has many content types to return |
| 16:26 | <mookid> | and we need a way of letting browsers negotiate that URI on the fly |
| 16:26 | <mookid> | a PDF reader, rightly so, already has it's Accept headers fixed |
| 16:26 | <jgraham> | So how can you write "pdf version of report" if it might return HTML or plain text or Word? |
| 16:26 | <mookid> | because that's all it accepts |
| 16:26 | <mookid> | it's just data |
| 16:26 | <hsivonen> | http://thedailywtf.com/Articles/The_Complicator_0x27_s_Gloves.aspx |
| 16:26 | <mookid> | fick. |
| 16:26 | <mookid> | dick* |
| 16:27 | <mookid> | passive aggresive is what defensive peopel with no rationale do |
| 16:27 | <jgraham> | Heh |
| 16:27 | <mookid> | grow a pair hsivonen |
| 16:27 | jgraham | has met hsivonen |
| 16:28 | <jgraham> | That is not a good description :) |
| 16:28 | Philip` | thinks the 0x27 in the URL is a bit weird |
| 16:28 | <mookid> | jgraham: you look at web applications differenet to me |
| 16:28 | <mookid> | I see a pdf as the same thing as an html document - just a different format |
| 16:29 | <jgraham> | mookid: I think mos users see them as different, even if they have the same prose content |
| 16:29 | <mookid> | so if I PUT the pdf resource back to the URI it's the same as if I PUT the html or the word doc format back |
| 16:29 | <mookid> | it changes the resource |
| 16:29 | <mookid> | users dont care |
| 16:29 | <mookid> | they do what they're told |
| 16:29 | <mookid> | particularly with html |
| 16:29 | <mookid> | they dont look at the markup |
| 16:29 | <mookid> | or the status bar |
| 16:29 | <Philip`> | Evidence suggests people don't actually do what they're told :-) |
| 16:29 | <mookid> | no - they like to do it their way |
| 16:30 | <takkaria> | well, no. pdfs load adobe acrobat into the browser and make it slow and draggy, and give it an extra set of menu bars. html doesn't. most people understand the stuff you do in web browsers != PDF |
| 16:30 | <mookid> | if you couple content-type to a URI you restrict them |
| 16:30 | <jgraham> | mookid: I don't claim that they care about the markup or about the status bar. They care about the results of their actions though |
| 16:30 | <yecril71> | PUT is not enough to make a resource fork. |
| 16:30 | <mookid> | how will they notice any differnet if the conneg is in the URI or whether it's HTTP then? |
| 16:30 | <yecril71> | Some server magic is needed. |
| 16:31 | <mookid> | like JAX-RS ? -_- |
| 16:31 | <yecril71> | Like vi .htaccess |
| 16:31 | <mookid> | it's not magic that's how modern web apps are being designed |
| 16:31 | <jgraham> | I think the core concept of content negoiation is user-hostile |
| 16:31 | <mookid> | htacces.. |
| 16:31 | <yecril71> | whatever |
| 16:31 | <mookid> | is that a joke? |
| 16:31 | <jgraham> | Or, at least there are very few occasions where I think it is reasonable |
| 16:31 | <yecril71> | How do you configure Apache to do content negotiation? |
| 16:32 | <mookid> | hahaha |
| 16:32 | <mookid> | that says it all |
| 16:32 | <jgraham> | e.g. serving XHTML vs HTML is often OK |
| 16:32 | <jgraham> | Serving PDF or HTML is not |
| 16:32 | <mookid> | do any of you actually develop enterprise applications? |
| 16:32 | <mookid> | -_- |
| 16:32 | <jgraham> | because users interact with those representations very differently |
| 16:32 | takkaria | concludes the Language spec thread on public-html is now entirely bikeshedding |
| 16:33 | <jgraham> | mookid: Fortunatley not :) |
| 16:33 | hsivonen | used to develop enterprise apps but doesn't anymore |
| 16:33 | <mookid> | maybe that's why you dont see this from my perspective |
| 16:33 | <Philip`> | yecril71: It's not a thing for static content that's all handled by Apache; it's for complex dynamic systems written in an Enterprise language like Visual Basic |
| 16:33 | <mookid> | you're seeing html and PDF as seperate |
| 16:33 | smedero | likes his bike shed painted purple |
| 16:33 | jgraham | noticed that after three days away public-html had almost entirely meta discussion and whatwg almost entirely technical discussion |
| 16:33 | <takkaria> | how has enterprise programming got anything to do with how users see html vs pdf? |
| 16:33 | <mookid> | I see HTML and PDF documents at one URI beign generated from the same data store < IMPORTANT |
| 16:34 | <mookid> | and updated to the same store aswell |
| 16:34 | <mookid> | generated.. on the fly.. |
| 16:34 | <yecril71> | Really? So even Apache does not support declarative content negotiation? |
| 16:34 | <jgraham> | mookid: Right but do users care about which representation they get? |
| 16:35 | <mookid> | well if they do they'll use the UA that's appropriate |
| 16:35 | <yecril71> | Then we should probably wait until it does. |
| 16:35 | <mookid> | I can write a content negotating app in JAX-RS right now |
| 16:35 | <mookid> | I just can't get a brwoser to use it properly |
| 16:35 | <jgraham> | mookid: So you expect me to load my PDF viewer to get a PDF version of a resource? |
| 16:36 | <yecril71> | If you cannot do it without writing server-side code, you cannot require it. |
| 16:36 | <mookid> | yecril71: you dont know what you're tlaking about |
| 16:36 | <Philip`> | yecril71: You can just use mod_rewrite if you want to redirect using .htaccess depending on the request headers |
| 16:36 | <mookid> | jgraham: yes, I dont see the big deal with that |
| 16:37 | <yecril71> | Right. However, I cannot do it with PUT. |
| 16:37 | <yecril71> | I have to use another server-side technique to create the fork. |
| 16:37 | <jgraham> | mookid: Ah, I think we are getting closer to the fundamental disagreement here |
| 16:37 | <mookid> | yes! |
| 16:37 | <mookid> | It's design level |
| 16:37 | <Philip`> | yecril71: Not to static files via Apache, which is why this is more relevant for more dynamic systems, where you're updating databases and generating content from them |
| 16:38 | <mookid> | YES |
| 16:38 | <mookid> | thank you Philip` |
| 16:38 | <yecril71> | But mookid said he can PUT. |
| 16:38 | <jgraham> | My PDF viewer doesn't even seem to open URIs |
| 16:38 | <yecril71> | Hie cannot. |
| 16:38 | <Philip`> | I don't think I have any icons on my computer to launch a PDF viewer :-( |
| 16:38 | <mookid> | well then update your PDF viewer then |
| 16:39 | <jgraham> | I believe I have the latest avaliable version |
| 16:39 | <mookid> | or browse to my html pages which will give you the HTML version and link yuo to the other representations using the brand new Accept attribute |
| 16:39 | <mookid> | the fact that the UA's dont support it yet doesnt mean they wont |
| 16:39 | <mookid> | it's all moving that way |
| 16:39 | <mookid> | I should know.. |
| 16:39 | <mookid> | o.O |
| 16:40 | <mookid> | MS office does HTTP |
| 16:40 | <jgraham> | mookid: The point that I was trying to make earlier is that UAs not supporting it today may wel mean that they won't becauseany browser that adds support will change the behaviour of existing applications, so discouraging users from upgrading |
| 16:41 | <Philip`> | jgraham: You should get a better operating system / desktop environment - KDE automatically lets you load URLs into programs like KPDF :-) |
| 16:41 | <mookid> | you moved off 3.5 Philip` ? |
| 16:41 | <Philip`> | mookid: No |
| 16:41 | <mookid> | me neither :> |
| 16:41 | <Philip`> | (Well, I have 4.1 installed but only use it when testing Konqueror) |
| 16:41 | <yecril71> | And a HTTP-compatible file system like HFS that supports forks |
| 16:42 | <yecril71> | HFS+ (HFS supports only two) |
| 16:42 | <Philip`> | yecril71: The filesystem is irrelevant - you write code that sits behind the URLs to do whatever magic it wants to do |
| 16:43 | <yecril71> | If I have to write code, I defect. |
| 16:43 | <yecril71> | I need a declarative interface for maintenance. |
| 16:44 | <ehird> | uh-oh mookid is still blabbing on about that conneg? |
| 16:44 | <ehird> | :P |
| 16:44 | <mookid> | jgraham: I dont understand the point your making, explain please |
| 16:44 | <mookid> | :) |
| 16:44 | <mookid> | it's important stuff |
| 16:45 | <Philip`> | yecril71: If you don't want to write code, this feature is not for you :-) |
| 16:45 | <mookid> | jgraham: you see incompatability between the two methods that isn't there |
| 16:46 | <mookid> | UAs that are not browsers should be setting their Accept headers appropriately |
| 16:46 | <mookid> | so if you specify the conneg in the URI or you don't it shouldn't matter |
| 16:46 | <yecril71> | If it is not supported declaratively server-side, it is not mature enough. |
| 16:46 | <mookid> | yecril71: yes it is |
| 16:47 | <mookid> | becasue you dont' know how to do it doesnt mean it's not possible |
| 16:47 | <yecril71> | I never said it is not possible. |
| 16:47 | <mookid> | well then stop talking. |
| 16:47 | <mookid> | 'not supported' = not possible |
| 16:47 | <yecril71> | I said it is immature. |
| 16:47 | <mookid> | immature |
| 16:47 | <mookid> | just stop. |
| 16:47 | <mookid> | stop please. |
| 16:48 | <mookid> | when in hole and all that |
| 16:48 | <mookid> | why did you say you got banned again? |
| 16:48 | <mookid> | =) |
| 16:48 | <yecril71> | I did not say I got banned again. |
| 16:49 | <mookid> | turn of phrase |
| 16:49 | <yecril71> | I just got banned, indefinitely. |
| 16:49 | <mookid> | I'm tempted to put you on ignore |
| 16:49 | <mookid> | I can't though I'm a liberal |
| 16:49 | <mookid> | damn my awesomeness |
| 16:49 | <yecril71> | Sweet temptations... |
| 16:49 | <takkaria> | putting people on ignore is something you do, not something you talk about. :) |
| 16:50 | <jgraham> | mookid: In browser A I click a link and get a HTML version of a resource with a link to a PDF version. In newer browser B that supports <a accept=> I get a PDF version. I depended on the HTML version. From my point of view browser B is broken. I stick with browser A. |
| 16:50 | <jgraham> | Hence browser B cannot gain marketshare without dropping support for <a accept> |
| 16:50 | <mookid> | right.. that's technical innovation |
| 16:50 | <mookid> | that happens all the time |
| 16:51 | <mookid> | so blu-ray should never have happened |
| 16:51 | <mookid> | because the discs dont work in my dvd player? |
| 16:51 | <yecril71> | Blue ray disks hold more data. |
| 16:52 | <yecril71> | That is an advantage. |
| 16:52 | <yecril71> | But there are innovations that gain acceptance, and there are others that do not. |
| 16:52 | <jgraham> | It's more like playing DVDs in your bluray players and discovering that they suddenly play the remake of psyco rather than the hitchcock original |
| 16:53 | <mookid> | not really those are two seperate resources |
| 16:53 | <mookid> | actually it's more like putting a blue ray disc in a dvd player and getting dvd quality |
| 16:53 | <mookid> | dissapointing but hey.. you're an idiot |
| 16:53 | <mookid> | :) |
| 16:54 | <yecril71> | I have always thought I am an idiot. |
| 16:54 | <jgraham> | They have the same script, same shots, just different versions of them |
| 16:54 | <yecril71> | So now there are two of us... |
| 16:54 | <yecril71> | :) |
| 16:56 | <mookid> | I wasnt actually calling him an idiot |
| 16:57 | <mookid> | I was calling the hypothetical person putting a blu ray disc in a dvd player an idiot |
| 17:00 | <mookid> | jgraham: yeah exactly - so you put the 'blu ray disc' into your cd player and it just plays the audio |
| 17:01 | <mookid> | with someone describing the scene aswell |
| 17:01 | <mookid> | so your cd player representation doesnt lose to much data |
| 17:02 | <takkaria> | no, but you still want to be able to differentiate between the cd/dvd/blu-ray versions |
| 17:02 | <mookid> | you want a seperate disc for each? |
| 17:02 | <mookid> | rather than one you can stick into all the players? |
| 17:03 | <mookid> | you're wierd. |
| 17:03 | <yecril71> | Meaning, having a blue-ray disk and a blue-ray player, you would rather prefer it to play CD audio? |
| 17:03 | <takkaria> | I might do, yeah |
| 17:03 | <yecril71> | For what reason? |
| 17:03 | <takkaria> | you know what directors are like, the DVD release will be closer to the cinema release than the blu-ray |
| 17:03 | <mookid> | yeah *MAYBE* |
| 17:04 | <mookid> | you're confusing yourself |
| 17:04 | <mookid> | -_- |
| 17:04 | <takkaria> | no, I'm just not taking this all as seriously as you are. :) |
| 17:04 | <mookid> | cmon admit - that analogy just killed you :P |
| 17:05 | <takkaria> | see, I think that your argument works fine given your assumptions |
| 17:05 | <takkaria> | I just don't think your assumptions are realistic |
| 17:05 | <mookid> | why - because that's not how it works at the moment? |
| 17:06 | <mookid> | no sh*t! |
| 17:07 | <takkaria> | no, because people sometimes want PDFs and sometimes want HTML, and being able to specify between them is quite useful |
| 17:07 | <mookid> | which you can do.. |
| 17:07 | <mookid> | you just dont get it :/ |
| 17:08 | <takkaria> | I'm sorry you think that |
| 17:08 | <mookid> | specifying between them is conneg |
| 17:08 | <mookid> | HTTP has conneg |
| 17:08 | <mookid> | that's what Accept is for |
| 17:08 | <mookid> | if you can't understand that |
| 17:08 | <mookid> | what m I supposed to do abuot that:? |
| 17:08 | <takkaria> | no, I get that :) but to the user, that's all behind-the-scenes stuff |
| 17:09 | <takkaria> | if you want to paste someone a link to the PDF version of something, you go "copy link location" and paste it to them in an IM window |
| 17:09 | <takkaria> | or in an email, whatever |
| 17:09 | <takkaria> | and as soon as you do that, you lose the invisible metadata hidden in the HTML |
| 17:09 | <mookid> | I appreciate that.. then it's down to how the user wants to use the system |
| 17:10 | <mookid> | that's a design descision |
| 17:10 | <mookid> | you're not comfortable with that.. fair enough |
| 17:10 | <yecril71> | It would work if the negotiated content were an explicit REDIRECT |
| 17:10 | <mookid> | that's possible aswell |
| 17:10 | <mookid> | that's what the location header is for |
| 17:11 | <mookid> | if that was even a requirement |
| 17:11 | <mookid> | which it isnt given my methodology |
| 17:11 | <mookid> | look - it's not about being right |
| 17:11 | <mookid> | I really dont want to say 'my way is better than yours' |
| 17:11 | <mookid> | it's just different - and legitimately so.. HTTP has a conneg mechanism that I want to use |
| 17:11 | <mookid> | it's not for fun.. |
| 17:11 | <yecril71> | What about the type attribute? |
| 17:12 | <yecril71> | Why is it not enough to say type="application/pdf"> |
| 17:12 | <yecril71> | ? |
| 17:14 | <mookid> | that attribute is standard across all referencing tags and specifically tied to the Accept header is it? |
| 17:15 | <yecril71> | I think the A tag is enough. |
| 17:15 | <mookid> | well you would because you dont know what you're talking abuot |
| 17:16 | <yecril71> | Your example contained an A. |
| 17:16 | <mookid> | 'enough' |
| 17:16 | <mookid> | ^compute. understand. |
| 17:17 | <yecril71> | Compute what? |
| 17:17 | <mookid> | look at what you wrote.. and then my response. |
| 17:17 | <mookid> | I was referring to your use of the word enough |
| 17:17 | <yecril71> | And what does it have to do with computing? |
| 17:18 | <yecril71> | Besides, in order to explain things, you have to talk to people who do not know what you are talking about. |
| 17:19 | <yecril71> | That is quite natural, and you should be prepared to explain things to them. |
| 17:19 | <mookid> | compentent people, yeah |
| 17:19 | <yecril71> | Making fun of them will not help you to make your case. |
| 17:19 | <mookid> | I gave you the benefit of the doubt about 24 hours ago |
| 17:19 | <mookid> | you only have yourself to blame |
| 17:20 | <mookid> | it wore thing. |
| 17:20 | <mookid> | thin^ |
| 17:20 | <mookid> | there is no hope |
| 17:20 | <yecril71> | And everything ends in Armageddon. |
| 17:20 | <mookid> | decapitate yourself |
| 17:20 | <yecril71> | But what does it have to do with accept attribute wannabe? |
| 17:21 | <mookid> | ok he's on ignore now |
| 17:21 | <yecril71> | Encouraging people to commit suicide is a criminal offense. |
| 17:21 | <mookid> | takkaria: do you take the point that it's a design descision or not? |
| 17:22 | <yecril71> | At least in my country. |
| 17:26 | <mookid> | Philip`: can you wade in on the mailing list about this? |
| 17:27 | <mookid> | it seems more solid if we do it on there |
| 17:27 | <takkaria> | mookid: a design decision? not really. invisible metadata in cases like this is bad for users |
| 17:27 | <mookid> | in your opinion |
| 17:28 | <mookid> | that's ok I'm comfortable with that |
| 17:28 | <takkaria> | sure, it is a design decision to be hostile to users, but I don't generally think that's something HTML5 should allow in as much as it can stop it |
| 17:28 | <mookid> | if I get context menu when I right click a URI that lets me decide what UA to open it with |
| 17:28 | <mookid> | that would be super cool |
| 17:29 | <mookid> | people associate HTTP with browsers too much |
| 17:29 | <mookid> | takkaria: that's my problem with this - it's not your place to stop it |
| 17:29 | <mookid> | it's part of the HTTP protocol |
| 17:30 | <takkaria> | I think HTML5 in excellent place to stop things which are bad for users |
| 17:30 | <takkaria> | if not HTML5, then where? |
| 17:30 | <mookid> | within the scope of web interfaces |
| 17:30 | <mookid> | not 'how web developers use HTTP' |
| 17:31 | <mookid> | well nowhere - if anywhere in HTTP |
| 17:31 | <mookid> | since that's the protocol |
| 17:31 | <mookid> | we're tlakign about here |
| 17:31 | <mookid> | if you werent supposed to be able to do it with HTTP |
| 17:31 | <mookid> | HTTP wouldnt allow it |
| 17:31 | <mookid> | infact, they actively encourage it |
| 17:31 | <mookid> | by providing protocol level conneg |
| 17:32 | <takkaria> | just because HTTP provides something doesn't mean it's necessarily good for users |
| 17:32 | <mookid> | who are you to decide that? |
| 17:32 | <takkaria> | a user? :) |
| 17:32 | <mookid> | well that's probably the most acurate thing you've said all day |
| 17:33 | <mookid> | why don't you see HTML as somethign to liberate developers ratehr than restrict them |
| 17:33 | <takkaria> | actually, I talked to people about the impact of drug policy on crime earlier today, that was about as accurate as what I said about. :) |
| 17:33 | <mookid> | legalise maaaaaan |
| 17:33 | <takkaria> | why do you see HTML as something to do things users don't want? :) |
| 17:34 | <mookid> | english please |
| 17:34 | <takkaria> | well, you say that HTML is something to liberate developers |
| 17:34 | <takkaria> | I think it should be focusing more on what is helpful to users |
| 17:34 | <mookid> | lol |
| 17:34 | <mookid> | users dont use html |
| 17:34 | <mookid> | html is given to them by developers |
| 17:34 | <takkaria> | sure they do. what else do I use when I browse the web? |
| 17:34 | <mookid> | it's just markup |
| 17:35 | <mookid> | you use a web browser |
| 17:35 | <takkaria> | if developers can't do things that aren't good for users, that's a good thing as far as I'm concerned, as a user |
| 17:35 | <mookid> | who are you to decide what developers should and shouldnt be doing? |
| 17:35 | <takkaria> | a user. :) |
| 17:35 | <mookid> | that's not a good answer |
| 17:35 | <mookid> | I know you think it is, it's not |
| 17:36 | <takkaria> | well, I have as much say in the matter as anyone else, really |
| 17:36 | <mookid> | it's pretty arrogant to assume you have a better grasp than other people and that they can't possibly work it out when you can |
| 17:36 | <mookid> | I just dont understand that perspectife |
| 17:36 | <mookid> | at all |
| 17:36 | <takkaria> | I don't think I said that |
| 17:36 | <mookid> | it's written between the ilines |
| 17:36 | <takkaria> | I just said that as a user, I'd rather developers didn't have the ability to do things that I don't want them to do |
| 17:37 | <takkaria> | like hiding invisible metadata that makes URL copy and pasting difficult |
| 17:37 | <mookid> | right.. and that's your rational for not allowing HTML to provision better control of HTTP conneg? |
| 17:37 | <takkaria> | yup |
| 17:37 | <mookid> | that's YOUR perspective |
| 17:37 | <takkaria> | and yours is yours. :) |
| 17:37 | <mookid> | how do you know that's right? |
| 17:37 | <mookid> | yes.. and I'm saying |
| 17:37 | <mookid> | I dont know definitively what's better |
| 17:38 | <mookid> | I just know that the most appropriate situation is where we can coexist |
| 17:38 | <mookid> | which an optional attribute provides |
| 17:38 | <takkaria> | I'd like to note that the design principles for the HTML WG (http://www.w3.org/html/wg/html5/principles/#priority-of-constituencies) mention: "n case of conflict, consider users over authors over implementors over specifiers over theoretical purity" |
| 17:38 | <takkaria> | so I'd guess that the WG's official position is pretty much in line with mine |
| 17:39 | <mookid> | so you create a conflict and then accuse me of rocking the boat and confusing users with change |
| 17:39 | <mookid> | that sounds like the lazy-boy manifesto right there |
| 17:39 | <takkaria> | I don't think I'm creating a conflict at all |
| 17:39 | <mookid> | congratulaitons you lot completely fooled me |
| 17:39 | <takkaria> | your proposal would make URL copy and pasting, a very common activity, harder |
| 17:39 | <mookid> | glad you're at the helm of HTML |
| 17:39 | <mookid> | no it wouldnt |
| 17:39 | <takkaria> | it would, because there'd be invisible metadata that wouldn't get copy-pasted |
| 17:40 | <mookid> | what is invisible? |
| 17:40 | <takkaria> | and the conflict is between you wanting to make it harder and users wanting it to work |
| 17:40 | <takkaria> | the accept="" attribute |
| 17:40 | <mookid> | the URI indicates where the resource is.. |
| 17:40 | <mookid> | it's done it's job |
| 17:40 | <mookid> | the content negotiation is down to the UA yoru using and the context you are requesting from |
| 17:40 | <mookid> | the fact that you dont see it that way |
| 17:40 | <takkaria> | if someone copy and pastes the link from <a type="application/pdf" href="blah">, then they will lose the fact it was intended to PDF |
| 17:41 | <mookid> | I KNOW THAT |
| 17:41 | <mookid> | that's not complicated. |
| 17:41 | <takkaria> | aye. and that is what the invisible metadata is |
| 17:41 | <takkaria> | and invisible metadata is harmful to users, especially in this case |
| 17:41 | <Philip`> | mookid: I'd rather not wade in since I don't think I have anything valuable to contribute and I'd just get my socks wet |
| 17:41 | <mookid> | a URI indicates a resource |
| 17:41 | <Philip`> | A URI indicates what the developer thinks is a resource, which may not be what the user thinks is a resource |
| 17:41 | <mookid> | yeah sure |
| 17:41 | <mookid> | bbl |
| 17:42 | <Philip`> | (so users might want a way to distinguish what they consider separate resources, even if the developer thought they were one resource and put them at the same URI) |
| 17:42 | <yecril71> | By the way, there are mouses that do not have the right button. |
| 17:43 | <yecril71> | Because they have only one button. |
| 17:44 | <yecril71> | OTOH, it is the same thing with METHOD=POST. |
| 17:45 | <yecril71> | Imagine METHOD=POST returning content that is inaccessible otherwise. |
| 17:45 | <yecril71> | And you cannot put the URL into the clipboard. |
| 17:53 | <Philip`> | POST is non-idempotent so there's a good reason to not let people arbitrarily copy around strings that let them accidentally repeat POST requests |
| 17:53 | <Philip`> | but that reason doesn't apply when you're simply GETting (content-negotiated) files |
| 18:01 | <yecril71> | The problem with hsivonen�s script is caused by the DOM viewer code. |
| 18:02 | <yecril71> | The content rendered separately does not cause Internet Explorer to hang. |
| 18:03 | <Philip`> | Oh, that's a useful observation - I think I saw a bug exactly like that at some point in the past... |
| 18:03 | <Philip`> | https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=366200 |
| 18:07 | <yecril71> | It is not a big problem given that inline frames are not strictly conforming. |
| 18:08 | <yecril71> | My experience shows it is safer to use window.open |
| 18:08 | <yecril71> | Which is nonconforming as well, but it works better at least. |
| 18:08 | <Philip`> | iframes are perfectly conforming in HTML5 |
| 18:09 | <Philip`> | and any browsers shouldn't crash or freeze on any input, regardless of conformingness |
| 18:09 | <Philip`> | s/any/anyway/ |
| 18:09 | <yecril71> | Of course. |
| 18:09 | <yecril71> | Hovewer, HTML5 is not implemented. |