This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Templates should have a substitution system, to allow flexible client-side insertion of JSON data. Along with it, we need an IDL API to populate slots in the template. Ideally, the template system should have the following features: - Insert JS values, via parsers (for security: we can have a "plain string" parser to display strings, an "html attribute" parser to escape attribute-related characters such as """, etc.) - Allow to iterate through iterable JS values, such as arrays and objects - Allow conditions based on boolean values - Have built-in parsers but allow user-defined additions - Include templates in templates, allowing recursive templating Open questions: - What should the syntax look like? There was an effort for HTML templates at <http://mdv.googlecode.com/svn/trunk/docs/template.html> that may be of interest. - Should insertion of values allow insertion of HTML directly? It adds power; maybe there should be a parser for that. - I have personally designed a template system named Plate.js [1] (for server-side templating, this time) that allowed to write macros written in JS. Each macro is a way to generate formatted content, given certain data. It proved to simplify many operations. [1] More information, at https://raw.github.com/espadrine/ScoutCamp/master/camp/Readme.md (scroll down the page)
I disagree that templates should _have_ a substitution system, but I fully support the idea that they should make applying a substitution system easy. Rather than try to force a 'one size fits all' model, I suggest it is more worthwhile to provide a good model to define templates in the markup and a useful pattern to plug an "applier" in. There are already numerous existing, well established projects that do substitution on templates as strings and if you look at how different they are in feature and philosophy - it seems infinitely better to allow individual, established (and new upstart) vendors to compete on that front.
(In reply to comment #1) > I disagree that templates should _have_ a substitution system, but I fully > support the idea that they should make applying a substitution system easy. > > Rather than try to force a 'one size fits all' model, I suggest it is more > worthwhile to provide a good model to define templates in the markup and a > useful pattern to plug an "applier" in. There are already numerous existing, > well established projects that do substitution on templates as strings and if > you look at how different they are in feature and philosophy - it seems > infinitely better to allow individual, established (and new upstart) vendors to > compete on that front. This makes sense.
(In reply to comment #1) > I disagree that templates should _have_ a substitution system, but I fully > support the idea that they should make applying a substitution system easy. 100% agreed. > Rather than try to force a 'one size fits all' model, I suggest it is more > worthwhile to provide a good model to define templates in the markup and a > useful pattern to plug an "applier" in. There are already numerous existing, > well established projects that do substitution on templates as strings and if > you look at how different they are in feature and philosophy - it seems > infinitely better to allow individual, established (and new upstart) vendors to > compete on that front. What seems certain for me is that such a substitution system should be hackable in JS, which means that it needs a JS api. The way I see this mechanism is a box (the component), which is ready to receive a certain JSON object. It applies the JSON object one item at a time, making each of the items fit in the patterns it defines, as if in a jigsaw puzzle. What should the template's interface we provide look like? Something like `render(Object model, any data)`? Should we specify the "applier" in the template, not in the renderer? What do you think?
Changing the category: From: WebAppsWG => Components Model To: WHATWG => HTML
Seems this is old feedback about the original design, not against the current specification.