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

[Adam Barth]

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.

Adam