W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2004

RE: Standards compliant webdesign

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>
Message-ID: <007a01c4762d$7501bab0$6601a8c0@bosshog>


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.

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

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:29 UTC