Lists Home |
Date Index |
- From: "Simon St.Laurent" <SimonStL@classic.msn.com>
- To: "Paul Prescod" <firstname.lastname@example.org>, "Xml-Dev (E-mail)" <email@example.com>
- Date: Mon, 20 Oct 97 12:48:35 UT
>Scriptlets allow the componentization of scripting code so that you can
>put less of it in your actual document and more of it in external
>scripts. That seems to me to be a step in the right direction. A
>applet. I have no problem with that. They aren't meant to be indexed,
>edited in WYSIWYG editors, formatted for print, added to website table
>of contents or any of the other things that we expect to do with real
Scripts have been 'componentizable' for several years now through the SRC
attribute of the SCRIPT element. Scriptlets are not about componentizing
script. While you could write a scriptlet in 100% script, you'd probably be
wasting your time. Scriptlets may well have to be formatted for print and
added to TOCs in certain situations. They aren't 'real documents' (however
you want to define that), but they are considerably more than scripts.
>in my document by ID or element type, rather than by "textual
>building HTML documents is textual replacement, not structural assembly.
Explorer 4.0, at least for the ID.
<SPAN ID="changeme">The contents of this material are subject to
document.all["changeme"].innertext="The formatting of this material is subject
document.all.changeme.innerHTML="The <I>formatting</I> is subject to change.";
document.all.changeme.style.display="none"; //makes it invisible
document.all.changeme.style.display=""; //makes it visible again
changeme.outerHTML="<SPAN ID="newelement">This is new material</SPAN>";
This is not a real application, obviously, and I haven't checked the code, but
you get the idea of some of the things that are possible. Addressing elements
by ID is a piece of cake - and much cleaner than document.write(). While the
examples above are pretty useless hacks, in combination they can produce
industrial-strength interfaces. (Microsoft of course did Asteroids, but it
has considerable _practical_ use for creating client-side applications.) XML
offers even more advantages to live pages than it does to static, providing a
far more useful structure on which to build than HTML.
I'm hoping that the W3C figures out the element type end of this and makes it
>But good luck indexing it properly! Have you ever done an AltaVista
>search and got a hit like this:
>0) && (y1>=0) && (x1. =0) && (leftValue>=0)) markSquare (bottomValue,
>leftValue) if ((topValue>=0) && (rightValue>=0)) openSquare(topValue,
> http://www.geocities.com/Wellesley/2159/minesweeper.html - size 13K -
>13-Aug-97 - English
XML should take care of this indexing issue, if the search engine developers
simply tell their machines to ignore the content of SCRIPT tags. They could
have done this with HTML, but chose to ignore markup intead. When they update
to XML, they'll be paying more attention to markup. Structured indexing, not
full-text indexing should be the indexing model for XML.
>> As I said before, we'll see what people actually do with the stuff soon
>Sure. And we'll see again what they decide to do after they have had
>some more experience with the headaches of intermingling the two.
It sounds like one of us has some severe static in his crystal ball. We can
sort out which one of us it is in a few years.
In the meantime, CDATA types for elements (or the lack thereof) are a more
Dynamic HTML: A Primer
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)