- From: Mike <mike@mykanjo.co.uk>
- Date: Tue, 18 Nov 2008 11:39:36 +0000
Smylers wrote: > mike at mykanjo.co.uk writes: > > >> "Would the sender of that link necessarily know all the formats the URL >> provides? Anyway, that's an unrealistic amount of typing -- typically >> round here people just copy and paste a URL into an instant message and >> send it without any surrounding text. >> >> Whereas without any other information, people will generally open URLs >> in a web browser. So it'd be faster just to send the URL of the page >> which contains hypertext links to all the formats; at which point we no >> longer care whether those links specify the format in the URL or >> elsewhere." >> >> - The HTML version of that URL could provide the web page >> representation *and* provide links to all the other content types >> available. > > Indeed it could. In which case the original claimed advantage of the > recipient of the message being able to open a single URL in one of > several different sorts of user-agents is no longer relevant; the links > could specify the format in the URL and this'll work just fine. > > You're completely missing my point here. I'm well aware that you can do conneg in the URL. HTTP provides a way to perform conneg at the protocol level; no mechanism for this is currently provided by HTML. >> "What is the point of doing it in HTTP if it's being done in HTML >> anyway?" >> >> - Nothing is 'done' in HTML, it's a markup language. It's being done >> (at the moment) in the URI. >> > > Sorry; that was what I meant. > Uniform *Resource* Identifier - different content types are different *representations*, not different resources. Protocol level conneg was included in HTTP so that URI's would not have to be responsible.. unfortunately HTML didn't provide adequate mechanisms to make use of this - so everyone is used to conneg happening in the URI. That doesn't make it 'the right way to do it'. Developers should be given the option. > >> HTTP provides conneg, why would you consciously deny developers the >> opportunity to use it in browsers? >> > > HTML 5 implicitly denies things merely by not providing them. And it > provides things which are useful. So the question actually needs to be > asked the other way round: what benefits are there in this being > supported? > > The benefits? Oh I don't know.. a markup language that supports the transfer protocol it runs on?! This isn't a feature request - it's a bug. You're denying developers the ability to choose to use protocol level conneg. >> "Not just browsers, as I pointed out. Also many databases which have >> tables with URL fields would need extra fields adding." >> >> - I suggested the attribute should be optional, so it would make no >> difference; one would simply avoid using it if it was a big problem. >> > > If my database contains URLs of external websites, then it isn't under > my control as to whether this feature gets used. If those sites start > using it, then my URLs are no longer sufficient to uniquely identify > what is downloaded, and I need to change my database schema (and > software that uses it) to remedy that. > > They are completely sufficient, if you provided the link but with no Accept attribute specified.. it would use the browser default (which is, generally, html). So that's a non-issue; It's backwards compatible. >> "True. But if the current way of doing it is good enough, there's no >> incentive to change." >> >> - Define 'enough'..! I don't know why/how you get the authority to >> make that assumption! >> > > I don't, of course! But then, I never made that claim anyway; I said > _if_ it's good enough. > > That is, in order to make this change let's first show that the current > way isn't good enough. > It's not good enough because it's merging representations (conneg) into resources (URIs). This isn't the way HTTP was intended to be used, that's just what people are used to. I'm not suggesting the current way of doing it should be abolished, I'm saying we should give people the choice. There is no choice at the moment (aside from using JavaScript). You're forcing me to repeat myself alot! > >> And before you say it; I'm not assuming any authority myself >> > > Good; the editor has a policy of ignoring appeals to authority! > Like removing the ability to leverage protocol level conneg on the basis that "it works fine in the URI", for example? > >> "There's little point in making browsers implement extra functionality >> and inventing new mark-up and evangelizing it, only to end up with the >> same functionality we started with; there has to be more. And the >> greater the effort involved, the greater the benefit has to be to make >> it worthwhile." >> >> - I'll say it again: I'm encouraging you to help browsers become >> better HTTP clients; surely that is high on the agenda here.. right?! >> > > Why? That's tantamount to an appeal to authority. Fully supporting > HTTP is a means rather than an end. Are there situations in which > supporting this particular part of HTTP provides additional benefit to > users? Or are there many instances of authors tediously coding the same > thing in JavaScript? > So you're taking the authority that the means you've chosen to provision are definitively superior to the alternative I'm proposing? I'm saying "lets do both and let developers decide". > Changes should have some real-world benefit, not just bureaucratically > complying with something for the sake of it. > > Hyper Text Markup Language Hyper Text Transfer Protocol Why would you not do everything in your power to fully support the protocol every way you could? Am I missing something here? >> "Typing that would require my knowing that URL of the PDF also serves >> other formats. >> >> But, moreover, it requires typing. Currently the URL can be pasted in, >> the text that the browser copied to the clipboard. There's no way that >> my browser's 'Copy Link URL' function is going to put on the clipboard >> the exact syntax of wget command-line options. Having to type that lot >> in massively increases the effort in this task -- even if I can type the >> relevant media type in from the top of my head, without needing to look >> it up." >> >> - You're using a command line and complaining about having to type too >> much? >> > > Yes. One reason I find using the command line so efficient is that > there are many features and short-cuts for avoiding having to type > things fully. > > >> If it mattered that much it would be a 2 second job to write a wrapper >> script of some kind.. >> > > That does what? A wrapper script which somehow contacts my web browser > (running on a different computer) to find out what the media type is of > the link that was most recently copied to the clipboard? > > Even if I could work out how to write such a script, why should I have > to? > > Because you're complaining about having to do work to content negotiate with a *content neutral* HTTP client.. You're distracting from the discussion with this - it is possible to set the Accept headers with wget - let it go. >> wget is a developer tool >> > > Is it? I thought it was a program for downloading files from the web. > > >> it's not supposed to be convenient anyway. >> > > Isn't it? I find it most convenient. > > One of the reasons I use it is because its interface is so simple: just > change to the directory I wish to download something to (which is > effectively free, since once the download has finished I'll want a shell > in that directory anyway to work with the downloaded file; and of course > I can enter this without having to type the path in full) then type a > 4-letter command name and paste the URL -- very efficient, and for me > involving far less typing or clicking than navigating a graphical 'Save > As' dialogue box. > > So wget currently _is_ convenient for me. And the defence of a change > which will make this significantly less convenient is that it was my > fault for finding it so convenient in the first place?! > > Well I don't consider having to type 15-20 characters or so a massive inconvenience.. what do your personal reservations and your overly-specific use-case have to do with HTML5? >> "Or what about if I wanted to mail somebody pointing out a discrepency >> between two versions of the report, and wished to link to both of >> them. That's tricky if they have the same URL. Possibly I could do >> it like you have with the wget command-line above, but that requires >> me knowing which browsers my audience use and the precise syntax for >> them." >> >> - separate versions are separate resources, not separate content >> types. That has nothing to do with conneg.. >> > > I was meaning a difference between the HTML version and the PDF version > of the same content (or at least what is supposed to be the same > content) -- how would I link to them? > If they're the same resource they should contain the same information.. just in.. a different format.. "The report is ready for download here - http://example.com/report - you can open it in your web browser or in adobe acrobat. Let me know what you think." Regards, Mike
Received on Tuesday, 18 November 2008 03:39:36 UTC