Re: A brief analysis of dynamically generated web pages and

aloha, charles!

thank you for articulating more succinctly and precisely than i was capable my
client side model...  
        gregory.

At 08:15 PM 11/22/99 -0500, you wrote:
>In Gregory's model, as I understand it, the user (client) has access to
>specialised style sheets, which suit their individual needs. They can apply
>that to well-structured content to get  document htat fits their personal
>requirements much more precisely than a server-sided approach can approximate
>the requirements of a class of users. In addition, the client can determine
>whether they want images, or audio content, or other separate pieces at the
>time they read. They can use bookmarks that are the same whether they are
>sighted, deaf, blind, etc.
>
>In some cases there is value in serving content of different types according
>to diffferent requests. (An obvious one is the tablin service that linearises
>tables and adds headers according to specified options). But in many cases
>the best solution is still to serve well-created content the first time
>around.
>
>Charles
>
>On Mon, 22 Nov 1999, Scott Luebking wrote:
>
>  Hi, Gregory
>  
>  I'm not sure we are using the same analysis.  Let's break this up into
>  two pieces.  First there is the selection of what is delivered to the
>  browser.  The server is making the decision here.  In your model, which
>  is also a version of many-sizes-fits-all approach, the server generates
>  a web page and chooses the style sheets all of which are sent to the
>  browser.  In my model, the server looks at the information, chooses a
>  format and generates the web page which is then sent to the browser.  In
>  your model, the server is limited to the style sheets its knows about.
>  In my model, the server can use some intelligence in creating the web
>  page.  As a result, the model I'm talking about for the server side is
>  much more flexible than the server side model your talking about.  (If
>  your model uses inline style, what is the benefit of you model over my
>  model?)  My model has the added benefit of avoiding having to worry about
>  the differences among implementations CSS without losing any flexibility.
>  
>  When a server is interacting with information, it has a better understanding
>  about the purposes or concepts which relate to the different aspects
>  of the page.  For example, the server would better know which links are
>  for advertising and which are for the web site.  As a result,
>  the server can group links by categories.  Or, for example, the server
>  could know which functions are probably most likely to be used and
>  could improve blind user's efficiency by letting them be activated
>  by keyboard events.  When a page is created, these various concepts
>  of relationships on the page disappear.  The DOM cannot capture them.
>  
>  To understand what I'm discussing, you need to understand the
>  "concept-barrier" that is a problem in all of computer science
>  including access technology.  This is a tough one for many people
>  to understand.  Let me know if you want some elaboration.
>  
>  Scott
>  
>  
>  > aloha, scott!
>  > 
>  > you are still, in my opinion, attempting to impose a many-sizes-fits-all 
>policy
>  > on content delivery -- an approach which is doomed for you cannot possibly
>  > predict (nor can you reasonably expect content providers to know) what the
>  > individual blind user needs in order to make sense of, and interact 
>with, the
>  > content being delivered...
>  > 
>  > yes, the server should assume half of the burden (which can be done via
>  > responsible browser sniffing, so that the stylesheet and inline style
>  > declarations delivered with the content, for example, won't crash the
>  > requesting UA nor cause the content to be rendered in unexpected and
>  > incomprehensible ways), but the client side should handle the quote blind
>  > tailorization unquote -- particularly if the requester is using an AT 
>that can
>  > access his or her user agent of choice's DOM...  and even if the blind
>  > individual requesting the content isn't using a user agent that has 
>implemented
>  > the DOM, or is incapable of supporting it, then an intermediary proxy, 
>of the
>  > sort that len kasday and i have been talking about in WAI circles since 
>1997,
>  > could do the client side work for a client that doesn't have the 
>resources or
>  > access to the DOM needed by the UA slash A.T. combination described in my
>  > scenario...  of course, the proxy would have to be heuristic, and 
>constantly
>  > updated, so as to take into account new scenarios and combinations, but 
>  > 
>  > gregory.
>  
>
>--Charles McCathieNevile            mailto:charles@w3.org
>phone: +1 617 258 0992   http://www.w3.org/People/Charles
>W3C Web Accessibility Initiative    http://www.w3.org/WAI
>MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA
>

--------------------------------------------------------
He that lives on Hope, dies farting
     -- Benjamin Franklin, Poor Richard's Almanack, 1763
--------------------------------------------------------
Gregory J. Rosmaita <unagi69@concentric.net>
   WebMaster and Minister of Propaganda, VICUG NYC
        <http://www.hicom.net/~oedipus/vicug/index.html>
--------------------------------------------------------

Received on Monday, 22 November 1999 21:50:36 UTC