W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2011

Re: Reviving E4X (H4E)?

From: Anne van Kesteren <annevk@opera.com>
Date: Thu, 20 Oct 2011 11:36:56 +0900
To: "Alex Russell" <slightlyoff@google.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>
Message-ID: <op.v3mpjuql64w2qv@annevk-macbookpro.local>
On Wed, 19 Oct 2011 17:31:08 +0900, Alex Russell <slightlyoff@google.com>  
> 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.

They do I suppose if you want to create your DOM structures using strings.  
But that seems really ugly. It seems much more natural to be able to do:

   node.append(<div class="widget"><a href="/contact">Contact us!</a></div>)
   node.innerHTML = <p>Hello World!</p>

>> 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/

HTML at one point had data templating and binding. It was not really  
workable. Anyway, maybe templating is too much of a distraction here.  
Really this proposal is about improving working with the DOM.

>> We should also make some simplifications. Supporting XMLComment,  
>> 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).

Well yeah, that is what I am suggesting. I am not sure how close we can  
get given the complexity of HTML, but we should be able to work something  

Anne van Kesteren
Received on Thursday, 20 October 2011 02:37:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:04 UTC