There are Template Engines and there are Preprocessors.
List of some Template Engines
Smarty
Twig
TinyButStrong
List of some Preprocessors
Haml
Slim
Jade / Pug
What exactly is the difference?
Haml, Slim, and Jade / Pug don't define themselves as preprocessors or distinct from template engines:
Haml is a markup language that’s used to cleanly and simply describe the HTML of any web document without the use of inline code. Haml functions as a replacement for inline page templating systems.
Slim is a template language...
Pug is a high performance template engine heavily influenced by Haml and implemented with JavaScript
A preprocessor takes input and changes it before it's fed to another program. A template engine might be said to be a type of preprocessor that's specific to documents. The choice of what to call any of these applications that output HTML is largely semantics.
Related
I am using the Liquid templating language with Jekyll. I need to be able to define Liquid variables that have a document scope where a document may contain several pages. Is this possible?
For our HTML templates, we use a content aggregation engine based on a namespaced XML-based markup syntax that has some custom tags defining various fragments of the template. For example, for js code we have:
<foo:js src="http://..." />
<p>
This is regular HTML; this document with the namespaced tags will be
aggregated into HTML by our metalanguage aggregator.
</p>
<foo:js>
console.log('bar');
</foo:js>
I'd be very happy if these could be parsed and edited as JS code or JS reference tags (the self-closing one) in phpStorm. I figured out the "Language injections" settings is designed for that, but I can't find any documentation how to achieve this. The "Places Patterns" seems to be the key to this enigma. So can anyone provide some hints into how to do this using Language Injection(s)?
Also, for the rest of the tags, as a simple form of completion/validation, is it possible to specify a default XML schema (i.e. XSD) for the namespace? I mean, apart from explicit xmlns:foo tags, because our markup files represent fragments so we'd have to add quite a number of these on quite a lot of elements.
The following injection will highlight javascript in all <namespace:js> tags:
I'm trying to understand Markdown's relationship to HTML. If I understand correctly both are markup languages (an umbrella term describing languages that add formatting elements to plain-text documents). Markdown converts plain text to HTML.
My understanding is that Markdown is a superset of HTML:
Markdown is a popular markup language that is a superset of HTML.
I'm assuming that it's a strict or proper superset. Drawing a parallel from What does it mean when one language is a parallel superset of another?, I interpret that to mean that every valid HTML program is also a valid Markdown program (e.g. HTML is understood in a Jupyter Notebook Markdown cell), but that the converse is not true.
What seems conflicting to me is that if Markdown is a superset of HTML, then why is it that Markdown can't do everything HTML can (I would think the opposite to be true since a superset extends the language without removing or changing any of the existing features. Also, I would expect HTML to be a superset of Markdown since HTML is more expressive and more difficult to read by most humans.
Below is a diagram trying to mimic that in What does “Objective-C is a superset of C more strictly than C++” mean exactly?
That documentation is misleading. Markdown itself is not a superset of HTML. The documentation for the original Markdown project is pretty clear:
Markdown is not a replacement for HTML, or even close to it. Its syntax is very small, corresponding only to a very small subset of HTML tags. The idea is not to create a syntax that makes it easier to insert HTML tags. In my opinion, HTML tags are already easy to insert. The idea for Markdown is to make it easy to read, write, and edit prose. HTML is a publishing format; Markdown is a writing format. Thus, Markdown’s formatting syntax only addresses issues that can be conveyed in plain text.
Today there are several flavours of Markdown, many of which add features that were not present in the original version like tables and syntax-highlighted code blocks. This doesn't change the fundamental fact that Markdown covers a subset of HTML.
(Technically speaking, Markdown isn't a subset of HTML either. *, for example, has no special meaning in HTML. Unconverted Markdown documents might be well-formed HTML but the semantics are very different. But Markdown syntax maps to a subset of HTML tags.)
However, the very next paragraph in the original documentation says:
For any markup that is not covered by Markdown’s syntax, you simply use HTML itself. There’s no need to preface it or delimit it to indicate that you’re switching from Markdown to HTML; you just use the tags.
Since you can directly use HTML in Markdown it could be considered a superset of HTML. For example, this is valid Markdown:
# My awesome title
I <em>really</em> like coffee
If you pass an HTML document through a conforming Markdown processor it should come out the other side untouched. Being able to directly use HTML in Markdown is very similar to how one can directly use C in C++. This may be what the Jupyter documentation means.
With HTML 5 up, should we continue using the .dhtml and .shtml file formats?
Why does Js and CSS work even when we use HTML, without DHTML. Is this practice wrong?
Is there any advantage of SHTML over PHP?
If these 2 are not deprecated, why aren't they around?
SHTML
There isn't any difference between using .shtml and .php files other than the languages in which they are parsed. .shtml contains SSI scripting, while .php contains PHP scripts. There isn't any specific reason to choose one over the other - it depends completely upon the developer.
DHTML
DHTML isn't a different language or script from HTML. It just refers to the combined use of a markup language (HTML), a client-side scripting language (JavaScript) and a styling language (CSS). It simply notifies that your HTML page has dynamic content.
None of these are deprecated. It is just that SHTML has gone out of use as many people have switched to PHP and other server-side languages, and that people have minimized the usage of the term DHTML for talking about dynamic HTML pages, as now most of the websites have dynamic content.
I am using HTML to make a websites. I know an alternative languages to markup a website: XHTML, WML. Is there any more markup languages? Can I make a website only with XML or SGML?
Thank you for responses.
There aren't many.
To have a browser make your website viewable, you must provide your website in some language your browser can understand. Just plaintext and HTML work universally, there is quite some SVG and PDF support these days, but the only language you can use that can do all the things most people want a website to be able to do, you will have to use HTML or XHTML in some way. Either through JS or by some templating system, but you'll have to use it to generate what's commonly accepted as being a webpage as far as I'm aware.
That being said, there are some languages like Haml, which can be 'compiled' to HTML so you could use that instead. There are also converters for other XML-based languages and such.
If you want to deliver XML from your server, you can convert it to HTML in the browser using either
(a) XSLT 1.0: nearly all browsers have built in support for XSLT 1.0, which can be invoked using the xml-stylesheet processing instruction embedded in the XML
(b) XSLT 3.0: supported using Saxon-JS, which can be invoked using a small Javascript call in a skeletal HTML page.
(c) CSS: if the XML is reasonably close in structure to what you want to present to the user, you can attach styling properties to the XML elements using CSS.
You can also of course maintain your content in XML and convert it to rendered HTML using XSLT either at publishing time, or when each page is requested using code on the server to do the conversion on demand.
Many scientific journals use XML (actually JATS XML) for publishing scientific articles. XML in this case is transforming to HTML either on server or on client side by javascript. As example you can look here, where taking place client-side transformation. But Google will not index such XML.