[whatwg] (deferred) script tags with document.write built in
brettz9 at yahoo.com
Tue Aug 17 01:11:37 PDT 2010
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
>>>> If E4X were supported (since we otherwise lamentably have no PHP-style
>>>> this to be used could be especially convenient:
>>>> <script write>
>>>> <span onmouseover="alert(new Date())">I've got the date</span>
>>>> (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:
>> // business logic here
>> var localizedMsg = "I've got the date: ";
>> var businessLogicDate = new Date();
>> "<span>"+localizedMsg.toUpperCase() + businessLogicDate +"</span>"
>> 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
> 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
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.
More information about the whatwg