3 ms·

I'd much rather just use custom elements: Assuming a library that makes declaring custom elements very easy[1]: one.html: <template is="quick-element" na

• e12e 12y ago
  I always liked some of the ideas from Zope/Plone's template language, specifically the TAL (most basic) bit. When one adds macros/includes, some of the benefits fades a bit away: but it's nice to be able to have templates that can be rendered as-is in browsers, with a meaningful preview: <html> <!-- ... you'd need to include static css etc --!> <table> <tr tal:repeat="item here.cart"> <td tal:content="repeat.item.number">1</td> <td tal:content="item.description">Widget</td> <td tal:content="item.price">$1.50</td> </tr> </table> </html> https://chameleon.readthedocs.org/en/latest/reference.html#basics-tal https://chameleon.readthedocs.org/en/latest/reference.html#b... With html5 one gets some of the same benefits for free -- I guess the basic insight is to allow there to be demo/dummy content that can be rendered as/is valid html(5) -- and have the templating system replace it gracefully. Also of some interest is the xml/xsl-based theming support for Plone, allowing taking standard html, add a few rules, have diazo write the xsl -- and use the html (content and all) as a template: http://docs.diazo.org/en/latest/index.html http://docs.diazo.org/en/latest/index.html http://www.treebrolly.com/blog/turbo-plone-theming-with-xdv-diazo http://www.treebrolly.com/blog/turbo-plone-theming-with-xdv-... http://www.uwosh.edu/ploneprojects/docs/how-tos/how-to-use-diazo-to-copy-another-sites-theme http://www.uwosh.edu/ploneprojects/docs/how-tos/how-to-use-d... (Note this is actually mixing up two different types of templating, even if both do text-substitution. One is more of the "string interpolation/macro expansion" (aka you could just have used m4 to make the html) -- and the other is more themeing related: twisting appearances while semantics stay the same. They're conflated mostly because semantic html mark-up doesn't a) quite work and b) isn't actually supported by CSS (independent of semantics, because structure confers meaning in html, so with different structure, comes a need to either morph the structure (diazo) or rewrite (parts of) the CSS. The new way to side-step this issue, is to rather than standardize on good/sensible html-markup (aka: the zen garden approach that has worked for some 15 years now), but rather to move from html/xhtml/xml to json -- pretending that just because the tree is wrapped up in curly-braces and semicolons rather than bracket-tags, it's no longer a tree, and order and levels, and siblings magically cease to make a difference (aka the "lisp pipe dream -- we're too cool for assoc, we already have cons"-approach). But as long as we're on the web (and probably in many other places as well, such as desktop ui, we'll have the equivalent of structured documents, where both structure and tagging makes a difference -- and the need to go from various trees to various documents, and to map differently structured documents to each other. And interpolating simple plain-old-data-trees into a template for a document is going to be a different task from translating parts of one document to another. Even if both data and documents are represented as json (or xml or html or xhmtl or...)).