forked from thymeleaf/thymeleaf.github.io
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathfromhtmltohtmlviahtml.html
More file actions
executable file
·606 lines (567 loc) · 26.8 KB
/
fromhtmltohtmlviahtml.html
File metadata and controls
executable file
·606 lines (567 loc) · 26.8 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>From HTML to HTML (via HTML) - Thymeleaf: java XML/XHTML/HTML5 template engine</title>
<link rel="stylesheet" type="text/css" media="all" href="css/thymeleaf.css" />
<link rel="shortcut icon" href="http://www.thymeleaf.org/favicon.ico" />
<script type="text/javascript" src="https://apis.google.com/js/plusone.js">
{lang:'en', parsetags:'explicit'}
</script>
<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-1276954-9']);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>
<script type="text/javascript" src="sh/scripts/shCore.js"></script>
<script type="text/javascript" src="sh/scripts/shBrushXml.js"></script>
<script type="text/javascript" src="sh/scripts/shBrushJava.js"></script>
<script type="text/javascript" src="sh/scripts/shBrushPlain.js"></script>
<link href="sh/styles/shCore.css" rel="stylesheet" type="text/css" />
<link href="sh/styles/shThemeThymeleaf.css" rel="stylesheet" type="text/css" />
</head>
<body lang="en" dir="ltr">
<div id="page">
<div id="menu">
<ul>
<li><a href="index.html" title="Home">Home</a></li>
<li><a href="features.html" title="Features">Features</a></li>
<li><a href="download.html" title="Download">Download</a></li>
<li><a href="documentation.html" title="Documentation">Documentation</a></li>
<li><a href="ecosystem.html" title="Ecosystem">Ecosystem</a></li>
<li><a href="http://forum.thymeleaf.org" title="User Forum">User Forum</a></li>
<li><a href="issuetracking.html" title="Issue Tracking">Issue Tracking</a></li>
</ul>
</div>
<div id="header">
<a href="index.html" title="Thymeleaf home"><img src="images/thymeleaflogonameverysmall.png" class="logo" alt="Thymeleaf Template Engine"/></a>
</div>
<div id="breadcrumb">
<a href="index.html">thymeleaf</a>
::
<a href="documentation.html">documentation</a>
::
articles
::
<span class="current">from HTML to HTML (via HTML)</span>
</div>
<div id="content">
<h1>From HTML to HTML (via HTML)</h1>
<p>
Knowing the internals of the HTML family of web standards is quite important
when you are using software such as Thymeleaf. At least if you want to understand
what you are doing.
</p>
<p>
The problem is that many people know the technologies they are
using for creating webs, but don't really know where these technologies
come from. It has been a long way since the inception of the first web
interfaces, and since then every new technology has been changing the way
we developed for the web by deprecating a good amount of our work and,
especially, our knowledge.
</p>
<p>
And now, with the arrival of HTML5, things have become even more complicated.
<em>What's it?</em> <em>Why is it HTML instead of XHTML?</em> <em>Wasn't the
HTML tag soup considered harmful?</em>
</p>
<p>
So let's take a step back, and see how we arrived where we are now, and why.
</p>
<h2>Back in the 90s, there was HTML...</h2>
<p>
...and HTML was a standard (or more correctly, a
<em>recommendation</em>) maintained by the <em>World Wide Web Consortium</em>
(a.k.a. W3C). Extending from a language called SGML, HTML defined a
tag-based markup language for writing rich hyper-text documents,
highly coupled to the protocol that was used for serving them and
their related resources across the network: the <em>Hyper-Text
Transfer Protocol</em> (HTTP).
</p>
<p>
HTTP used text <em>headers</em> for defining what
was being served to clients and how, one of which was extremely
important: the <kbd>Content-Type</kbd>
header. This header explained to browsers what type of content was
being served to them in a language called <em>MIME (Multipurpose
Internet Mail Extensions)</em>. And the MIME type used for serving
HTML documents was <kbd>text/html</kbd>:
</p>
<script type="syntaxhighlighter" class="brush:plain;gutter:false"><![CDATA[
Content-Type: text/html
]]></script>
<p>
HTML also defined a way to check whether a
document was <em>valid</em>. Being valid basically meant that the
document was written according to the HTML rules that dictated what
attributes a tag could have, where a tag could appear in the
document, etc.
</p>
<p>
These validity rules were specified using a
language for defining the structure of SGML documents called <em>Document
Type Definition</em> or DTD. A Standard DTD was created for each
version of HTML, and HTML documents had to declare the DTD (and
therefore the version of HTML) they conformed to by means of a clause
that should appear as their first line, the <em>Document Type
Declaration</em> or <kbd>DOCTYPE</kbd> clause:
</p>
<script type="syntaxhighlighter" class="brush:html;gutter:false"><![CDATA[
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
]]></script>
<h2>The Document Object Model and the tag soup</h2>
<p>
HTML was meant for displaying documents in
browsers, and back in the late 90s browsers were made by fiercely
competing companies that wanted to offer the maximum amount of cool
features to their users. Given that HTML only defined rules for
document formatting, many other features were left to the browser
developers' imagination.
</p>
<p>
And one of the most interesting ideas that
appeared in browsers was <em>client-side interactivity</em>. This
interactivity was achieved by executing <em>scripts</em> — in
languages such as JavaScript — inside the browser itself, and
giving these scripts the ability to handle, modify and even execute
events on parts of the document being displayed. For this, browsers
had to model HTML documents as in-memory trees of objects, each of
them with state and events, and thus the <em>Document Object Model</em>
(DOM) was born.
</p>
<p>
The problem was that HTML rules for
well-formedness were quite loose whereas DOM trees were strictly
hierarchical structures, and this meant that different
interpretations of HTML tag positions and sequences could lead to
different DOM object trees in different browsers. Add to this the
fact that these different browsers modelled the API of DOM nodes in
different ways (different names, events, etc) and you will start to
get the idea of how difficult it was to create cross-browser
interactivity back then.
</p>
<p>
What's more: while all this was happening,
browsers had been growing quite forgiving with HTML authors, allowing
them to write HTML documents that were not well formed (<em>tag soups</em>)
by automagically correcting their errors. This lead HTML authors to
create even worse formed documents, and then browsers to allow even
more errors in format, adding to a quite destructive cycle. And guess
what: each browser was correcting all these errors in a different
way. Hooray.
</p>
<p>
The W3C finally standardized the DOM API and a
language for scripting in web browsers: JavaScript (although for some
complex reasons they insisted on calling it ECMAScript). But the
damage done by the world of tag soups coupled with the slow adoption
of these standards in full by browser makers — in many cases
fearing they would damage backwards compatibility — produced
effects that are still influencing the way we create web applications
today.
</p>
<h2>Enter XML</h2>
<p>
Some time after HTML became a widely spread
language, the W3C developed a new specification called XML
(<em>eXtensible Markup Language</em>), aimed at the representation of
general-purpose data (not only web) in the form of hierarchical
markup text.
</p>
<p>
XML was extensible in that it allowed the
definition of purpose-specific languages (tags and their attributes)
to fit the needs of specific scenarios. But HTML documents were not
well formed from the XML perspective, XML and HTML remained in fact
incompatible languages. It was not possible to express HTML as an XML
<em>application</em>.
</p>
<p>
Being strictly hierarchical and removing the
structural ambiguities of HTML, XML documents were more directly
translatable to standardized DOM trees (a process known as <em>XML
Parsing</em>). Also given the fact that XML was a text-based language,
and that text is a sort of technology-agnostic format (as opposed to
binary), XML became especially suited for the cross-platform
interchange of data across the internet. In fact, it led to the birth
of the now-ubiquitous <em>Web Services</em> technologies.
</p>
<h2>HTML + XML = XHTML</h2>
<p>
At some point, driven by the obvious usefulness of
XML and the fact that it could make web documents more extensible and
interoperable (like, for example, producing more predictable DOMs
across browsers), the W3C decided to reformulate HTML as an XML
dialect (or <em>application</em>) instead of and SGML one, and so XHTML
was born.
</p>
<p>
XHTML required web authors to write their
documents as well-formed XML, which introduced some formatting rules
that didn't exist in HTML before: tags should always be closed,
attributes should always be escaped and surrounded by commas, etc.
</p>
<p>
The introduction of XHTML and the transformation
of web documents into well formed XML was generally perceived as a
step forward, because it would allow higher levels of standardization
across browsers, less space for authoring errors that had to be
corrected in browser-specific ways, and easier parsing and automated
processing of web pages.
</p>
<p>
As a part of this, XHTML introduced a
controversial concept coming directly from XML and known as <em>Draconian
Error Handling</em>, which meant that any interpreter of XML —
including now a browser — should fail immediately should any
kind of format error be found in the XML document being processed. In
practice, this meant that XHTML authors would have to create
perfectly well-formed documents or accept the fact that browsers
would never be able (in fact, allowed) to display them at all.
</p>
<p>
For validation, the XHTML 1.0 specification
defined a set of DTDs that could be used in <kbd>DOCTYPE</kbd>
clauses: <kbd>XHTML 1.0 Strict</kbd>,
<kbd>XHTML 1.0 Transitional</kbd>
and <kbd>XHTML 1.0 Frameset</kbd>.
The first one was meant for <em>pure</em> XHTML documents that didn't
use any deprecated tags coming from HTML, the second one for
transitional documents that still made use of deprecated tags and
attributes, and the third one for frameset pages.
</p>
<script type="syntaxhighlighter" class="brush:html;gutter:false"><![CDATA[
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
]]></script>
<p>
But one of the most important aspects of XHTML was
that it also introduced a new MIME type, which was the one that every
web server was supposed to use for serving XHTML so that browsers
knew that they had to use their XHTML parser and engine instead of
their HTML equivalents. This was <kbd>application/xhtml+xml</kbd>:
</p>
<script type="syntaxhighlighter" class="brush:plain;gutter:false"><![CDATA[
Content-Type: application/xhtml+xml
]]></script>
<h2>Crashing down to (XHTML's) reality</h2>
<p>
Just after its introduction, everything looked
bright for XHTML. We developers should just have to wait for browsers
to fully implement it and the world of web development would suddenly
look much happier...
</p>
<p>
Trouble is, that never happened.
</p>
<p>
What happened was that one specific browser simply
denied implementing support for the <kbd>application/xhtml+xml</kbd>
content type. Guess which one. Yeah, exactly, that one. Internet
Explorer.
</p>
<p>
IE6, IE7 and IE8 show a download dialog when you
try to access a document served with XHTML's own content type, and
that of course means that you cannot use that content type if you
want to be able to display your web site to IE users. IE9 seems to be
on the way to correct that, but it is simply too late by now.
</p>
<p>
Fortunately — or maybe unfortunately —
The XHTML 1.0 specification included an appendix that stated that
XHTML 1.0 content could also be served using the old <kbd>text/html</kbd>
content type from the HTML times, in order to ease the transition.
And that's exactly what most of us have been doing the past several
years: creating XHTML 1.0 content, and then serving it as <kbd>text/html</kbd>.
Given that the XHTML 1.0 specification was published in 2000, the
<em>transition</em> has taken long.
</p>
<p>
But the fact is that when you serve content as
HTML instead of XHTML browsers will use their HTML engines for it,
and not the XHTML-specific ones. And although their HTML engines have
been XHTML-enabled, they still have to provide backwards
compatibility for old HTML 4 code — which makes them very
tricky pieces of software — and importantly, they lack some of
the most XML-ish features of XHTML, starting with... Draconian Error
Handling.
</p>
<p>
And if you don't have Draconian Error Handling,
you have a forgiving engine that will let you serve documents that
are not well formed, automagically correcting your errors. And if you
know the browser will correct your errors (in a browser-specific
way), you will probably never correct your documents... and so the
HTML horror story still goes on.
</p>
<p>
Knowing this, think that you've probably never
really created a truly XHTML web site. What you've done is (probably
ill-formed) XHTML documents served and displayed as plain old HTML.
How about that?
</p>
<p>
But it went worse, because in 2002 <kbd>XHTML
1.1</kbd> removed the possibility of using of the HTML content type,
therefore allowing only <kbd>application/xhtml+xml</kbd>.
The problem was that, instead of this forcing Internet Explorer to
support <kbd>application/xhtml+xml</kbd>,
which didn't happen, this restriction simply turned XHTML 1.1 into as
much a mythological creature as Nessie. Almost no one ever used it.
</p>
<p>
In 2009, the W3C allowed again the use of
<kbd>text/html</kbd> with XHTML
1.1 but, again, it was too late.
</p>
<h2>Towards HTML5: A divorce story</h2>
<p>
At some point (specifically, 2004), some browser
makers realised that the existing XHTML specifications were evolving
too slowly to cope with the increasing demands of the web (video,
audio, richer application interfaces...), and that the W3C was
increasingly pushing them towards creating stricter interpretations
of documents that could end up rendering huge amounts of (ill-formed)
existing code useless.
</p>
<p>
They wanted to enhance web applications with
capabilities like video, audio, local storage, or advanced form
processing, and in fact they could do it by just adding those
features in a browser-specific way, but they didn't want to go the
non-interoperable way again. They needed the standards to evolve and
include these new features.
</p>
<p>
Nevertheless, there was a problem with evolving
the existing standards of the time (namely XHTML): there were still
lots and lots of web sites and applications still relying on legacy
HTML out there, and if those cool new features were standardized by
going the XHTML ultra-strict way, all those applications would never
be able to use the new features unless they were completely
rewritten. And everybody wanted a more interoperable and standard
web, but not at the cost of throwing away many years of work done by
millions of web authors.
</p>
<p>
So these makers (along with other individuals)
presented the W3C with the idea of evolving HTML in a way that made
all (or most) existing HTML and XHTML code still valid as <em>new
HTML</em> while providing powerful new features for web
applications and — importantly — clearly defining the way
in which error handling should be done.
</p>
<p>
This latter point meant that instead of failing on
the first error, browsers would know <em>by specification</em> how to
perform the automagical correction of errors created by web authors
and therefore would react to them in exactly the same way,
effectively turning HTML code (be it XML-formed or not) fully
cross-browser. You would still be recommended to create XML-formed
code for new sites, but if you didn't fancy or you still had some
tons of old legacy HTML (and most certainly you had), you would still
be invited to join the party. See that old HTML site there? Let's add
some video to it! It all sounded quite sensible.
</p>
<p>
But the fact is, all of this didn't sound quite as
well to W3C back in 2004, and they rejected the proposal and decided
to go strictly the XHTML way. HTML was dead for them, there was no
reason to resurrect it, and <kbd>XHTML
2.0</kbd> was the future.
</p>
<p>
This led to divorce. The proponents of this new
concept for HTML, a group that included individuals from Opera
Software, the Mozilla Foundation and Apple, left the W3C and founded
the <em>Web Hypertext Application Technology Working Group (WHATWG)</em>
with the aim of defining what we today know as HTML5.
</p>
<p>
Finally, in 2007, the W3C created a working group
for <em>next-generation HTML</em>, which later accepted to join efforts
with WHATWG, effectively adopting HTML5 as their working
specification and future deliverable. W3C and WHATWG were now united
for creating HTML5, and in 2009 the W3C just let XHTML 2.0 die by
closing the group working on its specification.
</p>
<p>
HTML5 was now the <em>only</em> future of web
standards.
</p>
<h2>So what is HTML5?</h2>
<p>
HTML5 is a set of standards — still under
development as of 2011 — evolving from current HTML 4 and XHTML
specifications and aimed at:
</p>
<ul>
<li>
Adding advanced new capabilities to HTML that
effectively move web development slightly away from the
document-oriented philosophy and towards a more application-oriented
one. Such capabilities are called <em>HTML5 features</em> and are in
some cases defined by standards on their own, apart from the HTML5
core one. HTML5 features include, among others: video, audio,
drawing canvas, geolocation, local storage, offline support and
advanced form-related capabilities.
</li>
<li>
Providing a pain-free path for migration from
HTML and XHTML, which enables the adoption of HTML5 with little or
no rewriting of code at all.
</li>
<li>
Providing a standard way of handling code
errors, so that ill-formed HTML5 code will perform in the same
predictable way in all browsers.
</li>
</ul>
<p>
From a practical point of view, this means that
(probably all of) your current HTML and XHTML code will be considered
valid HTML5 just by changing your <kbd>DOCTYPE</kbd>
to the HTML5 one:
</p>
<script type="syntaxhighlighter" class="brush:html;gutter:false"><![CDATA[
<!DOCTYPE html>
]]></script>
<p>
And by serving your content with content type
<kbd>text/html</kbd>:
</p>
<script type="syntaxhighlighter" class="brush:plain;gutter:false"><![CDATA[
Content-Type: text/html
]]></script>
<p>
And here you might be thinking: why does that
<kbd>DOCTYPE</kbd> specify no
DTD at all? Because there isn't one. HTML5 has no DTD because the
rules that define whether a document is valid HTML5 or not are
defined as human-readable text in the specification itself, but
cannot be expressed in the DTD language.
</p>
<p>
But this does not mean that an HTML5 parser and/or
engine cannot validate. It can. It simply has to be a piece of
software especially devoted to HTML5 parsing including specific code
programmed for executing the rules that are involved in validating
HTML5 (as opposed to reading those rules from a DTD file). Even if
the specification is now quite flexible, it still <em>is</em> a
specification, and you have to conform to it.
</p>
<p>
But if there is no DTD, then why have a DOCTYPE
clause at all? Because a DOCTYPE clause is needed in order to make
browsers display documents in <em>Standards Mode</em> (as opposed to
<em>Quirks Mode</em>). The clause <kbd><!DOCTYPE
html></kbd> is the minimum valid DOCTYPE declaration possible,
and that is exactly all we need. It just acts as a switch.
</p>
<h2>Can I use HTML5 already?</h2>
<p>
Yes and no. You can use some of the HTML5 features
that have already been implemented into some browsers, but (as of
2011) there still is no browser that fully implements all of the
HTML5 features. And even if there was, that could change because the
specification itself is still work in progress.
</p>
<p>
Using HTML5 in full will in fact take some time,
to be honest. Think that not only you will have to wait for some
browser to implement all of HTML5, but that in fact you will have to
wait for <em>most</em> browsers to do it, and then wait for your
potential users to upgrade their browsers to these versions. Now
think that a noticeable percent of big companies still use Internet
Explorer 6 (published in 2001) as their standard browser and...
well... cry.
</p>
<p>
But anyway, one thing is for sure: you can switch
your DOCTYPE to HTML5's and you will be doing HTML5. And that is
something you can do today if you feel the need to.
</p>
<h2>And what about XHTML5? Does that exist?</h2>
<p>
In theory, yes. XHTML5 is just HTML5 served with:
</p>
<script type="syntaxhighlighter" class="brush:plain;gutter:false"><![CDATA[
Content-Type: application/xhtml+xml
]]></script>
<p>
But again, this content type is not currently
supported by IE. So in practice, no, it doesn't exist.
</p>
<p>
Be careful though: the difference between HTML5
and XHTML5 is the content type and <em>only</em> the content type,
because an XML-formed HTML5 document is in fact a perfectly valid
HTML5 document. This is quite different to the relation between HTML4
and XHTML 1.0/1.1, which were incompatible languages.
</p>
<h2>OK. The history lesson was great. Now, how does this relate to Thymeleaf?</h2>
<p>
Out-of-the-box (it is extensible), Thymeleaf allows you to create web templates according
to three specifications:
</p>
<ul>
<li>XHTML 1.0 (Strict, Transitional and Frameset)</li>
<li>XHTML 1.1</li>
<li>HTML5</li>
</ul>
<p>
Support for HTML5 has a tricky part, though: Thymeleaf
will make you decide whether your HTML5 templates are XML-formed code
or not, and strongly suggest you that they are.
</p>
<p>
The main reason for this is that at the heart of the default configuration of
Thymeleaf lie an XML parser and a DOM processor, and so Thymeleaf will always
need XML input. If your HTML5 templates are well-formed XML they will
be parsed just as fine as any other XHTML template; but if they
aren't, Thymeleaf will need to execute a previous conversion (basically a
tag balancing operation) to convert your HTML into XML before parsing.
Obviously, this will not be the end of the world, but in some
high-load scenarios it could affect template processing performance.
</p>
<p>
Anyway, truth be told, that should not happen very
often. The main reason HTML5 allows non-XML syntax is legacy
integration, and there is no good reason why you should not be
closing your tags and escaping your attributes in new applications
being developed these days, voluntarily making them difficult to parse
and work with (unless you are Google and transferring the extra bytes
in attribute values over the net would <i>really</i> make a difference to you).
Remember that <em>with power comes
responsibility</em>. You do not want to voluntarily go back to
the olden days of tag soup by relying on how well browsers implement
standardized error handling, do you?
</p>
</div>
<div id="footer">
<div id="googleplus">
<div id="plusone-div" class="plusone"></div>
<script type="text/javascript">
gapi.plusone.render('plusone-div',{"size": "small", "count": "true", "href": "http://www.thymeleaf.org"});
</script>
</div>
<div id="twitter">
<a href="http://twitter.com/thymeleaf" class="twitter-follow-button" data-show-count="false">Follow @thymeleaf</a>
<script src="http://platform.twitter.com/widgets.js" type="text/javascript"></script>
</div>
<div id="copy">
Copyright © The <a href="team.html">THYMELEAF Team</a>. See <a href="documentation.html">applicable licenses</a>.
</div>
</div>
</div>
<script type="text/javascript">
SyntaxHighlighter.all();
</script>
</body>
</html>