On 8/13/2010 2:00 AM, Adam Barth wrote:
On Thu, Aug 12, 2010 at 3:02 AM, Brett Zamir<bret...@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
