Re: Cascading and scripting (was: The concept of cascading)
> > BUT, I obviously feel that exposing stylesheet functions - that is,
> > presentation attributes - to script engines through the object model is
> > incredibly powerful and goes a long way into turning applications using
> > the Web platform into truly interactive experiences. I think it's silly
> > to recommend that someone write J*Script just to write basic stylesheets
> > - but I think it's great to be able to write
> > "ONMOUSEOVER="this.style.fontWeight='bold'" to get hover effects. Check
> > out the IE4 demo pages, and you'll see what I mean, if it's not
> > blindingly obvious.
> The example you present is entirely resaonble, elegant and has NOTHING to
> do with manipulating the content at runtime (adding elements, removing
> elements, etc.) You have just created a flow object that responds to
> mouse movement. Great! This is absolutely NOT what I am afraid of. What
> I am afraid of is that people want to make document elements be created and
> destroyed at runtime. The "document" then becomes a virtual concept that is
> unvalidatable, unindexable, unconvertable and, in the end, unmaintainable.
What you are afraid of is precisely what will happen -- the demos provided with IE4
explicitly demonstrate the short of dynamic content generation and page reflowing that
For Web s/w developers, however, this is the exciting feature of the document object
model. The reason, of course, is that this functionality lets developers turn the
browser into a general-purpose software interface, using 'standard' markup and scripting
languages to program the GUI. Of course, this plays fast and loose with the concept
of a "document." but this is a fait accompli, and must be treated as such.
I think the reason for much of the recent debate about CSS and it's role is the fact
that HTML/CSS/scripting has become the generic "front-end" output rendering system
for (a) professional hypertext documentation systems, (b) client-server application
GUI interfaces, (c) transient 'hype' marketing pages and (d) Joe Averages' personal
X-files home page. THe question is then how to create a language/markup system that
satisfy the needs (functionality; ease of use by naive users) of these groups. The
answer is, in my view, that you can't, without omitting some functionality from current
Web tools (HTML/CSS...) and moving this functionality onto server-side management
systems, where appropriate. To my mind this is exactly the current process.
Thus I believe that, if an organization really wants validated, indexable, convertable
and maintainable 'document-based' resources, then they need real SGML/XML tools to store
and maintain the documents, and translation technologies to convert resources into the
more limited Web accesible formats.