RE: More scripting thoughts Pt. 2 (was RE: Accessible road maps)

I see the web browser (UA) as a thin client.  I see HTML as a protocol
conveying data.  Now, with this view, there should not be any programming
logic embedded with the HTML. (Hear me out before jumping down my
throat... LOL)  Sort of like the CSS debate and seperation of content and
display.  I see software such as outlook express being more of a thick
client and different from a browser. Hence my distinction between programs
and documents.  NOW, I am not Eeeevil as some would have me be.  I believe
scripting is very useful,  I just dont see the need to turn a thin client
into a thick client via scripting.  If you want a thicker browser, a
plugin is probably a better idea than scripting.  And then there is Java
to write a dedicated interface.  Scripting as an enhancement which does
not eliminate any information when disabled is even probably a beneficial
thing.  But let's keep the processing on the server, or make better UAs or
dedicated programs when processing needs to be done on the client instead
of mixing scripts with data.

-Steve

Mike Barta said:
>
> Oh but it does :)  there isn't much difference between quickbooks et al.
> and what one can do in a 'page'.  There are hybrid releases out already
> that have equivalent clients in binary ( 'rich client' ) and web client.
> E.g. Outlook express and WebNews are siblings sharing the same data
> system for their NNTP metadata, while there are UI difference they are
> market and not technology differences.
> :
> The IM example is, imho, a red herring as the single insurmountable
> difference is the listener socket :)  there is precious little that one
> cannot do in the UI that is distinguishable from a web based UI.  {
> OpenGL, VML, DHTML, GDI religious war omitted for brevity ;) }
>
> But I think we are actually in agreement here, quoting your last:
> "I think we need to make the Web accessible as a document or interface
> medium"
>
> Which is precisely what I, and I believe Matt, are saying.  I'm seeing
> no difference between a doc or an interface that sits on a URI.  As such
> we should be gearing toward accessibility recommendations that provide
> guidance for both paradigms.
>
> /m
>
> -----Original Message-----
> From: Steven Dale [mailto:sdale@stevendale.com]
> Sent: Wednesday, June 02, 2004 2:40 PM
> To: Mike Barta
> Cc: sdale@stevendale.com; jim@e-media.co.uk; foliot@wats.ca;
> accessys@smart.net; Kurt_Mattes@bankone.com; w3c-wai-ig@w3.org
> Subject: RE: More scripting thoughts Pt. 2 (was RE: Accessible road
> maps)
>
> Well, sort of.  I am thinking more of independant processing on the
> client side.  For example, Instant Messaging runs on the client system
> and sends information to another client system.  The Instant Messaging
> software does processing on the clients system.  Whereas, displaying a
> form on a browser window and sending the data to the server is not
> *really* doing any processing of the data.  The form is there for
> collection, what processing that is being done is done solely to send
> the data, maybe correct data if verified on client, to the server.
>
> -Steve
>
> Mike Barta said:
>>
>> It sounds like you are drawing a distinction of statefullness as the
>> criterion of a 'program'.  Yes?
>>
>> -----Original Message-----
>> From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org] On
>> Behalf Of Steven Dale ...
>> Ok what exactly is a webapp?  What program would you write using
>> javascript+html?  All I hear from this list is that we need it to do
>> javascript+fancy
>> rollovers and dynamic menuing,  Partial page updates, form validation.
>> Are these webapps?  I dont think so.
>>
>> Ok to firm up my point.  Have you used Instant Messaging?  That's a
>> networked program, not a web app.  Sure there are some web interfaces
>> to IM but they are interfaces not programs either.
>>
>> -Steve

Received on Wednesday, 2 June 2004 18:14:57 UTC