W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] (deferred) script tags with document.write built in

From: Adam Barth <w3c@adambarth.com>
Date: Thu, 12 Aug 2010 11:00:29 -0700
Message-ID: <AANLkTikoVHuy+2T-AefQXdESBsdnkYC3jNPDBEAco-ju@mail.gmail.com>
On Thu, Aug 12, 2010 at 3:02 AM, Brett Zamir <brettz9 at yahoo.com> wrote:
> ?On 8/12/2010 4:19 PM, Ian Hickson wrote:
>> On Sat, 24 Jul 2010, Brett Zamir wrote:
>>> Might there be a way that<script/> ?tags could add an attribute which
>>> combined the meaning of both "defer" and "document.write", whereby the
>>> last statement was evaluated to a string, but ideally treated, as far as
>>> the DOM, with the string being parsed and replacing the containing
>>> script node.
>>> For example:
>>> <script ?write>
>>> ? ? '<span ?onmouseover="alert(\''+(new Date())+'\')">I\'ve got the
>>> date</span>'
>>> </script>
>>> If E4X were supported (since we otherwise lamentably have no PHP-style
>>> HEREDOC syntax in JavaScript to minimize the few warts above), allowing
>>> this to be used could be especially convenient:
>>> <script ?write>
>>> ? ? <span ?onmouseover="alert(new Date())">I've got the date</span>
>>> </script>
>>> (Maybe even a new<write/> ?tag could be made to do this exclusively and
>>> more succinctly.)
>>> I chose "defer" as the default behavior so as to be XHTML-friendly, to
>>> allow convenient reference by default to other DOM elements without the
>>> need for adding a listener, and the more appealing default behavior of
>>> not blocking other content from appearing.
>>> Since it doesn't seem that XQuery support will be making it into
>>> browsers anytime soon, it would be nice to be able to emulate its clean
>>> template-friendly declarative style, dropping the need to find and
>>> append to elements, etc..
>> I don't really see what this proposal would solve. Can you elaborate on
>> what this would allow that can't be done today?
> It would simplify and beautify the addition of dynamic content and encourage
> separation of business logic from design logic (at least for content
> displayed on initial load).
> For example, using proposed shorter form <write/>, one might do this:
> <script>
> ? // business logic here
> ? var localizedMsg = "I've got the date: ";
> ? var businessLogicDate = new Date();
> </script>
> <write>
> ? ?"<span>"+localizedMsg.toUpperCase() + businessLogicDate + "</span>"
> </write>
> It would simplify for those with a frequent need for template pages. The
> template(s) expressed by <write/> could succinctly express the design logic
> without need for document.write() used everywhere. The semantically named
> tag would also distinguish such templates from other scripts.
> For XHTML, it would be especially useful in being able to offer
> document.write functionality (since such a tag would be defined as deferring
> execution until the rest of the page had loaded). No need for onload
> handlers, no need for adding and referencing IDs in order to find the
> element, and no need for DOM appending methods in order to provide dynamic
> content.

I agree that a client-side templating system would be very useful.
However, we should design it with security in mind.  The design you
propose above is very XSS-prone because you're concatenating strings.
What you want is a templating system that operates after parsing (and
possibly after tree construction) but before rendering.

Received on Thursday, 12 August 2010 11:00:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:00 UTC