Smylers wrote:
[EMAIL PROTECTED] 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
