- From: Alex Russell <slightlyoff@google.com>
- Date: Wed, 19 Oct 2011 09:31:08 +0100
- To: Anne van Kesteren <annevk@opera.com>
- Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>, Rafael Weinstein <rafaelw@google.com>, Adam Klein <adamk@google.com>, Erik Aarvidson <arv@google.com>
On Wed, Oct 19, 2011 at 8:12 AM, Anne van Kesteren <annevk@opera.com> wrote: > I just noticed https://bugzilla.mozilla.org/show_bug.cgi?id=695577 (removing > E4X from ES "use strict") which reminded me of a discussion we had on the > DOM mailing list about a simpler way to create elements and tree structures > without resorting to string concatenation. String concatenation can lead to > injection attacks (see SQL, PHP, etc.) and correctness checking happens > (too) late in the game. The Quasi Litteral syntax for ES.next is providing a possible solution here: http://wiki.ecmascript.org/doku.php?id=harmony:quasis String that don't use quasis do still present a problem, but the same hazard will always be available for users of JS who use innerHTML naively. > Markup literals in ECMAScript (i.e. E4X) solve these problems. They make > creating a DOM structure easy. They allow for templating. It is our belief on the Chrome team that templating is not desirable in the absence of data binding. We have a prototype built with ES.next features in mind that explores what we think is a more promising way forward: http://code.google.com/p/mdv/ > Mistakes are > noticed at compile time. We should probably add an easy way to add event > listeners or at least event handlers without resorting to strings, but since > only Mozilla implements markup literals thus far we should be able to make > changes, I think. > > We should also make some simplifications. Supporting XMLComment, XMLCDATA, > and XMLPI seems unneeded. Namespaces should probably go and instead we > should favor what HTML allows for, i.e. HTML, SVG, and MathML. Instead of > XPath we could use Selectors. We can simplify the API. We could even add > some HTML features, such as unquoted attributes, for ease of authoring. I have a larger concern here, which is that we're implicitly forcing literals to be XML, while the rest of the document is HTML. The closer we can get to HTML for something like this, the better (IMO). > And now the W3C and TC39 have closer coordination we should be able to more > tightly couple it with the DOM, to make this a feature that is really quite > useful to authors. > > Thoughts? > > > -- > Anne van Kesteren > http://annevankesteren.nl/ > >
Received on Wednesday, 19 October 2011 08:32:12 UTC