- From: David Ornstein <davido@objarts.com>
- Date: Fri, 26 Apr 1996 13:34:03 -0700
- To: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>, www-html@w3.org
At 03:58 PM 4/26/96 -0400, Paul Prescod wrote: >As I understand it, the main argument for embedding inline code is >convenience and performance. > >Convenience: > >I think that the important thing to remember is that a URL represents a web >"object", not a file. You can _encode_ a URL as multiple files (i.e. server >side includes). Or you can use one file to create many URL(i.e. inline CGI). An excellent reminder. So y'all understand my application, I'm working on tools to support server-side scripts, not client... >Inline script code can be converted by the server into a _reference_ to >another URL (where the server stores the script file). That way the author >gets the convenience of "inline coding" and the Web maintains the separation >of code from document content (which results in simpler, smaller, cheaper, >faster, more stable client software). I like this approach, but it's mostly applicable to the client-side processing stuff. >Anyhow, I tend to think that editing problems should be solved in editing >software, not in the interchange language. True. FWIW, on a practical level, I don't think people who are developing serious sites are doing much development with tools other than souped-up editors, though. This means that for a while (at least until we understand what WYSIWYG really *means* in the context of Web authoring) many people will still want the convenience of putting scripts right into their *file*...
Received on Friday, 26 April 1996 16:35:52 UTC