- From: John Foliot - WATS.ca <foliot@wats.ca>
- Date: Fri, 30 Jul 2004 08:04:09 -0400
- To: "'Jesper Tverskov'" <jesper.tverskov@mail.tele.dk>, <w3c-wai-ig@w3.org>
Jesper, Thank-you for this research item and getting to the bottom of the situation re: Content-Disposition Header. Good to know that it's not just us in the web accessibility arena that has troubles with advancing standards <grin>. It seems that while technically using Content-Disposition Header would be "correct", there is also the issue of the end user's "expected behaviours", and this is where I (and seemingly others on the list) take issue. While certain browsers/plug-ins may not exhibit behaviours that in your opinion are user-friendly, that is the current state of the software. How often (for example) do we read on this and other lists about somebody's father/brother/aunt/etc. not knowing how to make simple and useful adjustments to their web browser? Yet, despite the limitations/problems these people experience whilst surfing the web, they've managed to get where they are so far, and, in their (with no offence) ignorance they manage just fine. Could their experience be better? Absolutely! But who's job is it to make it so? If we, as web developers start throwing curveballs at them (by way of unexpected behaviours) on individual pages, are we advancing their experience or hindering it? By my experience, when this type of user (un-experienced, un-informed, non-technical) is confronted by something new, their initial reaction is one of panic, confusion, occasionally frustration... "what's going on?", "that's not what usually happens", "I don't know how that occurred", etc., etc. And this is the conundrum - how do we, as web developers improve and enhance content delivery so that it not only more accessible to those with disabilities, but also a "better", more user friendly experience for *ALL* users. To me, the solution is two-fold: 1) Encourage the user agent developers to make adjustments and enhancements to better reflect the needs of the end users. Opera has listened carefully to users for years and their browser reflects it. The whole Mozilla Project is another example of the "community" developing to the needs of the end users - a broad based consensus driven development, as opposed to a top-down directive styled organization. The web development community has already shown that it's collective muscle can affect browser development... Who on this list has never heard of WaSP (www.webstandards.org)? 2) Education! We as content developers can take the opportunity to educate our users via the sites we make to better use the tools they have. Believe it or not, the major browsers *all* provide a means to download a PDF file directly, without opening it in the browser window: In Internet Explorer, right-click on the resource link and choose "Save Target As...", in Netscape/Mozilla it's "Save Link Target As...", Opera it's "Save Target As..." (Ctrl+Shft+S). To my mind, providing this information to the user in clear text (on the same page as the PDF file) is a simpler, clearer and just as effective method of providing the usability/accessibility you seek, without the downside of requiring server-side convulsions, unexpected (and potentially disrupting) behaviours to the user agent, etc. Same goals - different approach. JF -- John Foliot foliot@wats.ca Web Accessibility Specialist / Co-founder of WATS.ca Web Accessibility Testing and Services http://www.wats.ca 1.866.932.4878 (North America) > -----Original Message----- > From: w3c-wai-ig-request@w3.org > [mailto:w3c-wai-ig-request@w3.org] On Behalf Of Jesper Tverskov > Sent: Friday, July 30, 2004 5:17 AM > To: w3c-wai-ig@w3.org > Subject: Standards compliant webdesign > > > > > Hi list > > We are probably all in favor of standards compliant > webdesign, and we have just had an intermezzo in the other > thread about how to serve pdf files to the user. > > Some members of the list raised the issue that one should > only use standard HTTP headers, and that I should not use the > Content-Disposition Header since it is not yet a standard > only a *proposed* standard. > > I have asked the responsible editor of the IETF, Keith Moore, > about what to do with this *proposed* RFC. His answer is > very interesting, and it gives us an excellent opportunity to > look into the inner workings of a standards organization. > > At least we now know that being "standards compliant" is a > very difficult animal to deal with in the practical world of > web design making web pages. > > I quote the full correspondence. Keith Moore has given my > permission to do so: > > _ _ _ _ _ _ _ _ _ _ > > > From: Keith Moore > Date: July 29, 2004, 14:57 > To: Jesper Tverskov > Subject: Re: Content-Disposition Header > > This is a known problem with the IETF process. lots of > specifications > languish at "proposed standard". it takes a lot of work to move the > specification to "draft standard", which is the (confusingly named) > next stage - you have to do interoperability tests and fix > any bugs in > the specification, which often opens the door to re-editing > the entire > specification (not to make major changes, but to clean up > muddy text). > When you re-edit the specification, you find that > references need to > be updated because those have advanced, and you may find that the > document you're trying to advance depends on references that aren't > advanced yet, which delays the whole process. > > IETF is a "volunteer" organization (meaning that people either put > their own time into IETF activities or - more often - companies pay > their employees to work in IETF toward common industry > goals), and the > reason volunteers put energy into IETF is to produce specifications. > Once the specification exists and has been agreed to, there's little > incentive to advance it along the standards track - unless it's found > to be buggy or ambiguous. Thus many of the specifications > that advance > in grade are those which were problematic when first released. > Content-disposition seems to work pretty well, so there hasn't been > much interest in advancing it. > > IETF is currently discussing how it might change its standard > maturity > levels, to address this and other problems. > > And yes, it is safe to use Content-Disposition in accordance with RFC > 2183. Note that RFC 2231 added a new way to encode (long or > non-ASCII) > parameters that might be used by Content-Disposition. 2231 is not as > widely supported in existing products as 2183. > > Keith > > On Jul 29, 2004, at 5:28 AM, Jesper Tverskov wrote: > > > Hi Keith Moore > > > > Could you tell me please, what happened to: > > > > rfc2183 > > The Content-Disposition Header > > > > Why is it still just *proposed*, and not a standard yet, since all > > browsers seem to support it, and in MS asp.net you can set > it by code: > > > http://support.microsoft.com/default.aspx?scid=kb;EN-US;q260519 > > > > etc.? > > > > Is rfc2183 safe to use, or should we wait until when? > > > > Best regards, > > > > Jesper Tverskov > > www.smackthemouse.com > > > > > > > >
Received on Friday, 30 July 2004 08:05:58 UTC