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

[Brett Zamir]

  On 8/13/2010 2:00 AM, Adam Barth wrote:
> 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.

If the concern is to accommodate people who use blacklists of tags 
(which they shouldn't), then instead of <write/>, I also mentioned 
<script write/>. The latter, as a derivative of script, would be prone 
to XSS, but it would most likely be caught by existing blacklists.

In order for a templating system to have enough robustness while not 
unnecessarily adding yet another syntax or making undue restrictions, I 
think regular JavaScript would work fine, just cutting out the 
unnecessary cruft of load events and element finding needed by XHTML and 
cut out the need for document.write calls for both XHTML and HTML.

I think E4X would be far more elegant than strings and ideal (e.g., see 
https://developer.mozilla.org/en/E4X_for_templating ) and a logical 
choice, but I proposed the string concatenation to hopefully minimize 
the changes that would be necessary to add such support in browsers that 
don't support E4X.

Brett