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

On Thu, 12 Aug 2010, Brett Zamir wrote:
> 
> 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>

Here's how HTML solves this today:

  <form>
   <span>
    <output name=localizedMsg></output>
    <output name=businessLogicDate></output>
   </span>
  </form>
  <script>
   document.forms[0].localizedMsg.value = "I've got the date: ";
   document.forms[0].businessLogicDate.value = new Date();
  </script>

The current solution seems cleaner to me.


On Thu, 12 Aug 2010, Adam Barth wrote:
> 
> 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.

A templating technology would be an interesting addition to native HTML, 
but we should probably wait until more of the features in the spec are 
solidly implemented before adding things of that complexity!

There is some work ongoing to merge XBL with HTML, which may be of 
relevance here (though that's more late-binding than templating).


On Tue, 17 Aug 2010, Brett Zamir wrote:
> 
> 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.

The XSS risk with your idea is in something like this:

 <script>
    // business logic here
    var localizedMsg = "I've got the name: ";
    var businessLogicName = getName(); // data from server
 </script>
 <write>
     "<span>"+localizedMsg.toUpperCase() + businessLogicName + "</span>"
 </write>

Imagine if the name contains unescaped 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.

Something like E4X would definitely be an aid in reducing XSS in such 
code.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 25 January 2011 18:24:50 UTC