forked from deianvasilev/diveintohtml5
-
Notifications
You must be signed in to change notification settings - Fork 10
/
Copy pathpast.html
403 lines (272 loc) · 53.2 KB
/
past.html
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
<!DOCTYPE html>
<meta charset=utf-8>
<title>Jak to všechno bylo? - Dive Into HTML5</title>
<!--[if lt IE 9]><script src=j/html5.js></script><![endif]-->
<link rel=alternate type=application/atom+xml href=https://github.com/diveintomark/diveintohtml5/commits/master.atom>
<link rel=stylesheet href=screen.css>
<style>
body{counter-reset:h1 1}
</style>
<link rel=stylesheet media='only screen and (max-device-width: 480px)' href=mobile.css>
<link rel=prefetch href=index.html>
<p>Navigace: <a href=index.html>Domů</a> <span class=u>‣</span> <a href=table-of-contents.html#history>Dive Into <abbr>HTML5</abbr></a> <span class=u>‣</span>
<h1><br>Jak to všechno bylo?</h1>
<p id=toc>
<p class=a>❧
<h2 id=divingin>Jdeme na to </h2>
<p class=f><img src=i/aoc-n.png alt=N width=107 height=103>edávno jsem narazil na citaci vývojáře Mozilly <a href=http://lists.w3.org/Archives/Public/public-html/2010Jan/0107.html>týkající se napětí přítomného u vytváření standardů</a>:
<blockquote cite=http://lists.w3.org/Archives/Public/public-html/2010Jan/0107.html>
<p>Implementace a specifikace spolu navzájem tančí v těsném spojení. Nechceme, aby se implementace objevily dřív, než budou specifikace hotové, protože lidé začali být závislí na detailech implementací, což by omezovalo vznikající specifikace. Ovšem současně nechceme, aby specifikace byly dokončeny před tím, než se objeví implementace a zkušenosti uživatelů s nimi, protože potřebujeme znát jejich zpětnou vazbu. Jedná se o napětí, kterému se nedá vyhnout, musíme se skrz něj prodrat.
</blockquote>
<p>Mějte na paměti tuto citaci zatímco budu popisovat, jak <abbr>HTML5</abbr> vzniklo.
<p class=c><img src=i/openclipart.org_johnny_automatic_animals_on_see_saw.png width=526 height=116 alt="zvířata na houpačce">
<p class=a>❧
<h2 id=mime-types>MIME type</h2>
<p>Tahle kniha pojednává o <abbr>HTML5</abbr>, nikoliv o předchozích verzích <abbr>HTML</abbr> nebo nějaké verzi <abbr>XHTML</abbr>. Ovšem pokud máte pochopit historii <abbr>HTML5</abbr> a motivaci stojící za jeho vznikem, musíte napřed porozumět několika technickým detailům. Konkrétně <abbr>MIME</abbr> typům.
<p>Pokaždé, když váš webový prohlížeč požádá o stránku, pošle mu webový server ještě před vlastním obsahem stránky tzv. „hlavičky“. Tyto hlavičky jsou běžně neviditelné (pokud chcete, můžete si je zobrazit pomocí vývojářských nástrojů), ale důležité, protože řikají prohlížeči, jak má interpretovat značkovací jazyk, který následuje. Nejdůležitější hlavičkou je <code>Content-Type</code>, která vypadá takto:
<blockquote><pre>Content-Type: text/html</pre></blockquote>
<p>„<code>text/html</code>“ je název pro „content type“ neboli „<abbr>MIME</abbr> typ“ stránky. Tato hlavička je tím <strong>jediným</strong> způsobem, který udává, o jaká data se doopravdy jedná, což určí, jak je má prohlížeč zobrazit. Obrázky mají své vlastní <abbr>MIME</abbr> typy (<code>image/jpeg</code> pro <abbr>JPEG</abbr>, <code>image/png</code> pro <abbr>PNG</abbr> atd.). Javascriptové soubory mají svůj vlastní <abbr>MIME</abbr> typ. Kaskádové styly mají svůj vlastní <abbr>MIME</abbr> typ. Všechno má svůj vlastní <abbr>MIME</abbr> type. Celý web stojí na <abbr>MIME</abbr> typech.
<p>Ve skutečnosti je to ovšem mnohem složitější. První generace webových serverů (mám na mysli webové servery z roku 1993) neposílala hlavičku <code>Content-Type</code>, protože ta tehdy ještě neexistovala. (Byla vytvořena až roku 1994.) Z důvodů kompatibility, které sahají až do roku 1993, některé populární webové prohlížeče hlavičku <code>Content-Type</code> za jistých okolností ignorovaly. (Říká se tomu „content sniffing“ — „očuchávání obsahu“.) Ovšem odhadem vše, co se tehdy vyskytovalo na webu — <abbr>HTML</abbr> stránky, obrázky, skripty, videa, PDF souborů, zkrátka cokoliv, co mělo vlastní <abbr>URL</abbr> — bylo nabízeno s nějakým specifickým <abbr>MIME</abbr> typem v hlavičce <code>Content-Type</code>.
<p>Dobře si to zapamatujte, ještě se k tomu vrátíme.
<p class=a>❧
<h2 id=history-of-the-img-element>Delší odbočka k tomu, jak se dělají standardy</h2>
<p class=ss><img src=i/openclipart.org_johnny_automatic_monkey_reading.png width=365 height=396 alt="opička čtoucí knížku">
<p>Víte, proč v <abbr>HTML</abbr> existuje prvek <code><img></code>? Takovou otázku neslyšíte každý den. Pochopitelně ho <em>někdo</em> musel vytvořit. Takové věci se neobjeví jen tak samy od sebe. Každý prvek, každý atribut, každá vlastnost <abbr>HTML</abbr>, kterou jste kdy použili — někdo je musel vytvořit, musel rozhodnout, jak mají fungovat a všechno to sepsat. Nebyl to žádný bůh, ale člověk a ti nejsou bezchybní. Jsou to prostě lidé. Určitě chytří lidé. Ale jen lidé.
<p>U standardů, které jsou vytvářeny „veřejně“, můžete na podobné otázky snadno odpovědět. Stačí ze zpětně podívat do jednotlivých debat, které se odehrávaly v mailing listech, jenž byly obvykle archivovány a jsou veřejně prohledatelné. Rozhodl jsem se pustit se do trochy té „e-mailové archeologie“, abych odpověděl na otázku, „Proč v <abbr>HTML</abbr> existuje prvek <code><img></code>?“ Musel jsem se vrátit do doby ještě před tím, než tu byla organizace World Wide Web Consortium (<abbr>W3C</abbr>). Vrátil jsem se až do těch prvních dnů webu, kdy jste ještě mohli počet webových serverů spočítat na prstech rukou.
<p><i>(V následujících citacích najdete několik typografických chyb. Rozhodl jsem se je ponechat neopravené, abych zachoval autenticitu textu.)</i>
<p>25. února 1993 napsal <a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html"><cite>Marc Andreessen</cite></a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html">
<p>Chtěl bych navrnout novou, nepovinnou značku HTML:
<p>IMG
<p>Jejím povinným parametrem je <code>SRC="url"</code>.
<p>Jedná se o název bitmapového nebo pixmapového souboru, který se prohlížeč pokusí ze sítě stáhnout, interpretovat ho jako obrázek a ten vložit do textu na místo výskytu této značky.
<p>Příklad:
<p><code><IMG SRC="file://foobar.com/foo/bar/blargh.xbm"></code>
<p>(Není tu žádná ukončovací značka, jen ta zahajovací.)
<p>Tuto značku můžete vložit do odkazu stejně jako cokoliv jiného; v takovém případě se stane ikonou, kterou je možné aktivovat stejně jako obyčejný textový odkaz.
<p>Prohlížečům by měly mít možnost se rozhodnout, které formáty obrázků budou podporovat. Například Xbm a Xpm jsou pro to dobrými kandidáty. Pokud prohlížeč nedokáže daný formát zobrazit, může s ním provést, co chce (X Mosaic například na jeho misto zobrazí výchozí bitmapu).
<p>Toto je požadovaná pro X Mosaic; už jsme ji implementovali a budeme ji využívat přinejmenším pro interně. Jsem rozhodně otevřený vašim návrhům k zařazení do HTML; pokud máte lepší nápad, než který tu prezentuji, dejte mi prosím vědět. Já vím, že otázka formátů obrázků je nejasná, ale nevidím jinou možnost, než říct „ať prohlížeč udělá, co umí“ a počkat, že se časem objeví ideální řešení (MIME jednoho dne, možná).
</blockquote>
<p><a href="http://en.wikipedia.org/wiki/X_BitMap">Xbm</a> a <a href="http://en.wikipedia.org/wiki/X_PixMap">Xpm</a> byly populární grafické formáty unixových systémů.
<p>„Mosaic“ byl jeden z prvních prohlížečů. („X Mosaic“ byla verze, která běžela na Unixu.) Když <a href="http://en.wikipedia.org/wiki/Marc_Andreessen">Marc Andreessen</a> začátkem roku 1993 tuhle zprávu psal, bylo to ještě před tím, než založil společnost <a href="http://en.wikipedia.org/wiki/Mosaic_Communications_Corporation">Mosaic Communications Corporation</a>, která ho proslavila, i před tím, než začal pracovat na stěžejním produktu této společnosti „Mosaic Netscape.“ (Můžete je spíš znát pod jejich pozdějšími názvy „Netscape Corporation“ a „Netscape Navigator.“)
<p>„MIME jednoho dne, možná“ naráží na <a href="http://en.wikipedia.org/wiki/Content_negotiation">content negotiation</a>, vlastnost HTTP, pomocí které může klient (např. webový prohlížeč) oznámit serveru (např. webovému serveru) jaké typy obsahu podporuje (např. <code>image/jpeg</code>), takže server může vrátit obsah v klientem preferovaném formátu. <a href="http://www.w3.org/Protocols/HTTP/AsImplemented.html">Původní HTTP definované v 1991</a> (jediná verze HTTP, která byla v únoru 1993 implementované) nenabízela klientům možnost, jak říct serveru, jaké formáty obrázků podporují, to bylo dilema, kterému Marc ve svém návrhu čelil.
<p>O několik hodin později <a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0183.html"><cite>Tony Johnson</cite> odpověděl</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0183.html">
<p>Mám něco velmi podobného pro Midas 2.0 (u sebe na SLACu, veřejná verze přijde každýn týdnem), až na rozdíly v názvech. A mám také navíc parametr <code>NAME="name"</code>. Má téměr stejnou funkčnost jako značka <code>IMG</code>, kterou navrhuješ, tj.
<p><code><ICON name="NoEntry" href="http://note/foo/bar/NoEntry.xbm"></code>
<p>The idea of the name parameter was to allow the browser to have a set of „built in“ images. If the name matches a „built in“ image it would use that instead of having to go out and fetch the image. The name could also act as a hint for „line mode“ browsers as to what kind of a symbol to put in place of the image.
<p>I don’t much care about the parameter or tag names, but it would be sensible if we used the same things. I don’t much care for abbreviations, ie why not <code>IMAGE=</code> and <code>SOURCE=</code>. I somewhat prefer <code>ICON</code> since it imlies that the <code>IMAGE</code> should be smallish, but maybe <code>ICON</code> is an overloaded word?
</blockquote>
<p><a href="http://en.wikipedia.org/wiki/MidasWWW">Midas</a> was another early web browser, a contemporary of X Mosaic. It was cross-platform; it ran on both Unix and VMS. „SLAC“ refers to the <a href="http://en.wikipedia.org/wiki/Stanford_Linear_Accelerator">Stanford Linear Accelerator Center</a>, now the SLAC National Accelerator Laboratory, that hosted the first web server in the United States (in fact <a href="http://www.slac.stanford.edu/history/earlyweb/history.shtml">the first web server outside Europe</a>). When <a href="http://www.slac.stanford.edu/history/earlyweb/wizards.shtml#Tony%20Johnson">Tony</a> wrote this message, SLAC was an old-timer on the WWW, having hosted <a href="http://www.slac.stanford.edu/history/earlyweb/firstpages.shtml">five pages</a> on its web server for a whopping 441 days.
<p>Tony continued:
<blockquote>
<p>While we are on the subject of new tags, I have another, somewhat similar tag, which I would like to support in Midas 2.0. In principle it is:
<p><code><INCLUDE HREF="..."></code>
<p>The intention here would be that the second document is to be included into the first document at the place where the tag occured. In principle the referenced document could be anything, but the main purpose was to allow images (in this case arbitrary sized) to be embedded into documents. Again the intention would be that when HTTP2 comes along the format of the included document would be up for separate negotiation.
</blockquote>
<p>„HTTP2“ is a reference to <a href="http://www.w3.org/Protocols/HTTP/HTTP2.html">Basic HTTP as defined in 1992</a>. At this point, in early 1993, it was still largely unimplemented. The draft known as „HTTP2“ evolved and was eventually standardized as „HTTP 1.0“ (albeit <a href="http://www.w3.org/Protocols/HTTP/1.0/spec.html">not for another three years</a>). HTTP 1.0 did include <a href="http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z3">request headers for content negotiation</a>, a.k.a. „MIME, someday, maybe.“
<p>Tony continued:
<blockquote>
<p>An alternative I was considering was:
<p><code><A HREF="..." INCLUDE>See photo</A></code>
<p>I don’t much like adding more functionality to the <code><A></code> tag, but the idea here is to maintain compatibility with browsers that can not honour the <code>INCLUDE</code> parameter. The intention is that browsers which do understand <code>INCLUDE</code>, replace the anchor text (in this case „See photo“) with the included document (picture), while older or dumber browsers ignore the <code>INCLUDE</code> tag completely.
</blockquote>
<p>This proposal was never implemented, although the idea of providing text if an image is missing is <a href="http://diveintoaccessibility.org/day_23_providing_text_equivalents_for_images.html">an important accessibility technique</a> that was missing from Marc’s initial <code><IMG></code> proposal. Years later, this feature was bolted on as the <a href="http://www.w3.org/TR/html4/struct/objects.html#h-13.8"><code><img alt></code> attribute</a>, which Netscape promptly broke by <a href="http://www.cs.tut.fi/~jkorpela/html/alt.html#tooltip">erroneously treating it as a tooltip</a>.
<p>A few hours after Tony posted his message, <a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0186.html"><cite>Tim Berners-Lee</cite> responded</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0186.html">
<p>I had imagined that figues would be reprented as
<p><code><a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure </a></code>
<p>where the relation ship values mean
<pre>EMBED Embed this here when presenting it
PRESENT Present this whenever the source document is presented</pre>
<p>Note that you can have various combinations of these, and if the browser doesn’t support either one, it doesn’t break.
<p>[I] see that using this as a method for selectable icons means nesting anchors. Hmmm. But I hadn’t wanted a special tag.
</blockquote>
<p>This proposal was never implemented, but the <code>rel</code> attribute is <a href="http://diveintohtml5.org/semantics.html#link">still around</a>.
<p><a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0188.html"><cite>Jim Davis</cite> added</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0188.html">
<p>It would be nice if there was a way to specify the content type, e.g.
<p><code><IMG HREF="http://nsa.gov/pub/sounds/gorby.au" CONTENT-TYPE=audio/basic></code>
<p>But I am completely willing to live with the requirement that I specify the content type by file extension.
</blockquote>
<p>This proposal was never implemented, but Netscape did later add support for embedding of media objects with the <code><embed></code> element.
<p><a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0192.html"><cite>Jay C. Weber</cite> asked</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0192.html">
<p>While images are at the top of my list of desired medium types in a WWW browser, I don’t think we should add idiosyncratic hooks for media one at a time. Whatever happened to the enthusiasm for using the MIME typing mechanism?
</blockquote>
<p><a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0194.html"><cite>Marc Andreessen</cite> replied</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0194.html">
<p>This isn’t a substitute for the upcoming use of MIME as a standard document mechanism; this provides a necessary and simple implementation of functionality that’s needed independently from MIME.
</blockquote>
<p><a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0198.html"><cite>Jay C. Weber</cite> responded</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0198.html">
<p>Let’s temporarily forget about MIME, if it clouds the issue. My objection was to the discussion of „how are we going to support embedded images“ rather than „how are we going to support embedded objections in various media“.
<p>Otherwise, next week someone is going to suggest ‘lets put in a new tag <code><AUD SRC="file://foobar.com/foo/bar/blargh.snd"></code>‘ for audio.
<p>There shouldn’t be much cost in going with something that generalizes.
</blockquote>
<p>With the benefit of hindsight, it appears that Jay’s concerns were well founded. It took a little more than a week, but HTML5 did finally add new <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video"><code><video></code></a> and <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#audio"><code><audio></code></a> elements.
<p>Responding to Jay’s original message, <a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0204.html"><cite>Dave Raggett</cite> said</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0204.html">
<p>True indeed! I want to consider a whole range of possible image/line art types, along with the possibility of format negotiation. Tim’s note on supporting clickable areas within images is also important.
</blockquote>
<p>Later in 1993, <a href="http://www.w3.org/People/Raggett/">Dave Raggett</a> proposed <a href="http://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html">HTML+</a> as an evolution of the HTML standard. The proposal was never implemented, and it was superseded by <a href="http://www.w3.org/MarkUp/html-spec/html-spec_toc.html">HTML 2.0</a>. HTML 2.0 was a „retro-spec,“ which means it formalized features already in common use. „<a href="http://www.w3.org/MarkUp/html-spec/html-spec_1.html#SEC1.1">This specification brings together, clarifies, and formalizes a set of features</a> that roughly corresponds to the capabilities of HTML in common use prior to June 1994.“
<p>Dave later wrote <a href="http://www.w3.org/MarkUp/html3/CoverPage.html">HTML 3.0</a>, based on his earlier HTML+ draft. Outside of the W3C’s own reference implementation, <a href="http://www.w3.org/Arena/">Arena</a>, HTML 3.0 was never implemented, and it was superseded by <a href="http://www.w3.org/MarkUp/Wilbur/">HTML 3.2</a>, another „retro-spec“: „<a href="http://www.w3.org/TR/REC-html32.html#intro">HTML 3.2 adds widely deployed features</a> such as tables, applets and text flow around images, while providing full backwards compatibility with the existing standard HTML 2.0.“
<p>Dave later co-authored <a href="http://www.w3.org/TR/html4">HTML 4.0</a>, developed <a href="http://tidy.sourceforge.net/">HTML Tidy</a>, and went on to help with XHTML, XForms, MathML, and other modern W3C specifications.
<p>Getting back to 1993, <a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0209.html">Marc replied to Dave</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0209.html">
<p>Actually, maybe we should think about a general-purpose procedural graphics language within which we can embed arbitrary hyperlinks attached to icons, images, or text, or anything. Has anyone else seen Intermedia’s capabilities wrt this?
</blockquote>
<p><a href="http://en.wikipedia.org/wiki/Intermedia_(hypertext)">Intermedia</a> was a hypertext project from Brown University. It was developed from 1985 to 1991 and ran on <a href="http://en.wikipedia.org/wiki/A/UX">A/UX</a>, a Unix-like operating system for early Macintosh computers.
<p>The idea of a „general-purpose procedural graphics language“ did eventually catch on. Modern browsers support both <a href="http://www.w3.org/Graphics/SVG/">SVG</a> (declarative markup with embedded scripting) and <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-canvas-element"><code><canvas></code></a> (a procedural direct-mode graphics API), although the latter <a href="http://ln.hixie.ch/?start=1089635050&count=1">started as a proprietary extension</a> before being „retro-specced“ by the <a href="http://www.whatwg.org/">WHATWG</a>.
<p><a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0217.html"><cite>Bill Janssen</cite> replied</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0217.html">
<p>Other systems to look at which have this (fairly valuable) notion are Andrew and Slate. Andrew is built with _insets_, each of which has some interesting type, such as text, bitmap, drawing, animation, message, spreadsheet, etc. The notion of arbitrary recursive embedding is present, so that an inset of any kind can be embedded in any other kind which supports embedding. For example, an inset can be embedded at any point in the text of the text widget, or in any rectangular area in the drawing widget, or in any cell of the spreadsheet.
</blockquote>
<p>„Andrew“ is a reference to the <a href="http://www-2.cs.cmu.edu/~AUIS/">Andrew User Interface System</a> (although at that time it was simply known as the <a href="http://en.wikipedia.org/wiki/Andrew_Project">Andrew Project</a>).
<p>Meanwhile, <a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0215.html"><cite>Thomas Fine</cite> had a different idea</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0215.html">
<p>Here’s my opinion. The best way to do images in WWW is by using MIME. I’m sure postscript is already a supported subtype in MIME, and it deals very nicely with mixing text and graphics.
<p>But it isn’t clickable, you say? Yes your right. I suspect there is already an answer to this in display postscript. Even if there isn’t the addition to standard postscript is trivial. Define an anchor command which specifies the URL and uses the current path as a closed region for the button. Since postscript deals so well with paths, this makes arbitrary button shapes trivial.
</blockquote>
<p><a href="http://en.wikipedia.org/wiki/Display_PostScript">Display Postscript</a> was an on-screen rendering technology co-developed by Adobe and NeXT.
<p>This proposal was never implemented, but the idea that the best way to fix HTML is to replace it with something else altogether <a href="http://dbaron.org/log/20090707-ex-html">still pops up from time to time</a>.
<p><a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0221.html"><cite>Tim Berners-Lee</cite>, March 2, 1993</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0221.html">
<p>HTTP2 allows a document to contain any type which the user has said he can handle, not just registered MIME types. So one can experiment. Yes I think there is a case for postscript with hypertext. I don’t know whether display postcript has enough. I know Adobe are trying to establish their own postscript-based „PDF“ which will have links, and be readable by their proprietory brand of viewers.
<p>I thought that a generic overlaying language for anchors (Hytime based?) would allow the hypertext and the graphics/video standards to evolve separately, which would help both.
<p>Let the <code>IMG</code> tag be <code>INCLUDE</code> and let it refer to an arbitrary document type. Or <code>EMBED</code> if <code>INCLUDE</code> sounds like a cpp include which people will expect to provide SGML source code to be parsed inline — not what was intended.
</blockquote>
<p><a href="http://www.hytime.org/">HyTime</a> was an early, SGML-based hypertext document system. It loomed large in early discussions of HTML, and later XML.
<p>Tim’s proposal for an <code><INCLUDE></code> tag was never implemented, although you can see echoes of it in <code><object></code>, <code><embed></code>, and the <code><iframe></code> element.
<p>Finally, on March 12, 1993, <a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0257.html">Marc Andreessen revisited the thread</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0257.html">
<p>Back to the inlined image thread again — I’m getting close to releasing Mosaic v0.10, which will support inlined GIF and XBM images/bitmaps, as mentioned previously. …
<p>We’re not prepared to support <code>INCLUDE</code>/<code>EMBED</code> at this point. … So we’re probably going to go with <code><IMG SRC="url"></code> (not <code>ICON</code>, since not all inlined images can be meaningfully called icons). For the time being, inlined images won’t be explicitly content-type’d; down the road, we plan to support that (along with the general adaptation of MIME). Actually, the image reading routines we’re currently using figure out the image format on the fly, so the filename extension won’t even be significant.
</blockquote>
<p class=a>❧
<h2 id=an-unbroken-line>An unbroken line</h2>
<p>I am extraordinarily fascinated with all aspects of this almost-17-year-old conversation that led to the creation of an <abbr>HTML</abbr> element that has been used on virtually every web page ever published. Consider:
<p class=ss><img src=i/openclipart.org_johnny_automatic_Corsican_Pine.png width=216 height=405 alt="pine tree">
<ul>
<li>HTTP still exists. HTTP successfully evolved from 0.9 into 1.0 and later 1.1. <a href="http://www.ietf.org/dyn/wg/charter/httpbis-charter.html">And still it evolves</a>.
<li>HTML still exists. That rudimentary data format — it didn’t even support inline images! — successfully evolved into 2.0, 3.2, 4.0. HTML is an unbroken line. A twisted, knotted, snarled line, to be sure. There were plenty of „dead branches“ in the evolutionary tree, places where standards-minded people got ahead of themselves (and ahead of authors and implementors). But still. Here we are, in 2010, and <a href="http://www.w3.org/People/Berners-Lee/FAQ.html#Examples">web pages from 1990</a> still render in modern browsers. I just loaded one up in the browser of my state-of-the-art Android mobile phone, and I didn’t even get prompted to „please wait while importing legacy format…“
<li>HTML has always been a conversation between browser makers, authors, standards wonks, and other people who just showed up and liked to talk about angle brackets. Most of the successful versions of HTML have been „retro-specs,“ catching up to the world while simultaneously trying to nudge it in the right direction. Anyone who tells you that HTML should be kept „pure“ (presumably by ignoring browser makers, or ignoring authors, or both) is simply misinformed. HTML has never been pure, and all attempts to purify it have been spectacular failures, matched only by the attempts to replace it.
<li>None of the browsers from 1993 still exist in any recognizable form. Netscape Navigator was <a href="http://en.wikipedia.org/wiki/History_of_Mozilla_Application_Suite#Open_sourcing_of_Communicator">abandoned in 1998</a> and <a href="http://en.wikipedia.org/wiki/History_of_Mozilla_Application_Suite#Rewriting_from_scratch">rewritten from scratch</a> to create the Mozilla Suite, which was then <a href="http://en.wikipedia.org/wiki/History_of_Mozilla_Firefox">forked to create Firefox</a>. Internet Explorer had its humble „beginnings“ in „Microsoft Plus! for Windows 95,“ where it was bundled with some desktop themes and a pinball game. (But of course that browser <a href="http://en.wikipedia.org/wiki/Spyglass_Mosaic">can be traced back further too</a>.)
<li>Some of the operating systems from 1993 still exist, but none of them are relevant to the modern web. Most people today who „experience“ the web do so on a PC running Windows 2000 or later, a Mac running Mac OS X, a PC running some flavor of Linux, or a handheld device like an iPhone. In 1993, Windows was at version 3.1 (and competing with OS/2), Macs were running System 7, and Linux was distributed via Usenet. (Want to have some fun? Find a graybeard and whisper „Trumpet Winsock“ or „MacPPP.“)
<li>Some of the same <em>people</em> are still around and still involved in what we now simply call „web standards.“ That’s after almost 20 years. And some were involved in predecessors of HTML, going back into the 1980s and before.
<li>Speaking of predecessors… With the eventual popularity of HTML and the web, it is easy to forget the contemporary formats and systems that informed its design. Andrew? Intermedia? HyTime? And HyTime was not some rinky-dink academic research project; <a href="http://xml.coverpages.org/hytime.html">it was an ISO standard</a>. It was approved for military use. It was Big Business. And you can read about it yourself… <a href="http://www.sgmlsource.com/history/hthist.htm">on this HTML page, in your web browser</a>.
</ul>
<p>But none of this answers the original question: why do we have an <code><img></code> element? Why not an <code><icon></code> element? Or an <code><include></code> element? Why not a hyperlink with an <code>include</code> attribute, or some combination of <code>rel</code> values? Why an <code><img></code> element? Quite simply, because Marc Andreessen shipped one, and shipping code wins.
<p>That’s not to say that <em>all</em> shipping code wins; after all, Andrew and Intermedia and HyTime shipped code too. Code is necessary but not sufficient for success. And I <em>certainly</em> don’t mean to say that shipping code before a standard will produce the best solution. Marc’s <code><img></code> element didn’t mandate a common graphics format; it didn’t define how text flowed around it; it didn’t support text alternatives or fallback content for older browsers. And 17 years later, <a href="http://tools.ietf.org/html/draft-abarth-mime-sniff">we’re still struggling with content sniffing</a>, and <a href="http://www.securityfocus.com/archive/1/503867">it’s still a source of crazy security vulnerabilities</a>. And you can trace that all the way back, 17 years, through the <a href="http://en.wikipedia.org/wiki/Browser_wars">Great Browser Wars</a>, all the way back to February 25, 1993, when Marc Andreessen offhandedly remarked, „MIME, someday, maybe,“ and then shipped his code anyway.
<p>The ones that win are the ones that ship.
<p class=a>❧
<h2 id=timeline>A timeline of HTML development from 1997 to 2004</h2>
<p>In December 1997, the World Wide Web Consortium (W3C) published <a href=http://www.w3.org/TR/REC-html40-971218/><abbr>HTML</abbr> 4.0</a> and promptly shut down the <abbr>HTML</abbr> Working Group. Less than two months later, a separate <abbr>W3C</abbr> Working Group published <a href=http://www.w3.org/TR/1998/REC-xml-19980210><abbr>XML</abbr> 1.0</a>. A mere three months after that, the people who ran the W3C held a workshop called „<a href=http://www.w3.org/MarkUp/future/>Shaping the Future of <abbr>HTML</abbr></a>“ to answer the question, „Has W3C given up on HTML?“ This was their answer:
<blockquote cite=http://esw.w3.org/topic/HTML/history>
<p>In discussions, it was agreed that further extending <abbr>HTML</abbr> 4.0 would be difficult, as would converting 4.0 to be an <abbr>XML</abbr> application. The proposed way to break free of these restrictions is to make a fresh start with the next generation of HTML based upon a suite of <abbr>XML</abbr> tag-sets.
</blockquote>
<p>The <abbr>W3C</abbr> re-chartered the <abbr>HTML</abbr> Working Group to create this „suite of <abbr>XML</abbr> tag-sets.“ Their first step, in December 1998, was a draft of an interim specification that simply <a href=http://www.w3.org/TR/1998/WD-html-in-xml-19981205/>reformulated <abbr>HTML</abbr> in <abbr>XML</abbr></a> without adding any new elements or attributes. This specification later became known as „<a href=http://www.w3.org/TR/xhtml1/><abbr>XHTML</abbr> 1.0</a>.“ It defined a new <abbr>MIME</abbr> type for <abbr>XHTML</abbr> documents, <code>application/xhtml+xml</code>. However, to ease the migration of existing <abbr>HTML</abbr> 4 pages, it also included <a href=http://www.w3.org/TR/xhtml1/#guidelines>Appendix C</a>, that „summarizes design guidelines for authors who wish their XHTML documents to render on existing HTML user agents.“ Appendix C said you were allowed to author so-called „<abbr>XHTML</abbr>“ pages but still serve them with the <code>text/html</code> <abbr>MIME</abbr> type.
<p>Their next target was web forms. In August 1999, the same <abbr>HTML</abbr> Working Group published a first draft of <a href=http://www.w3.org/TR/1999/WD-xhtml-forms-req-19990830><abbr>XHTML</abbr> Extended Forms</a>. They set the expectations <a href=http://www.w3.org/TR/1999/WD-xhtml-forms-req-19990830#intro>in the first paragraph</a>:
<blockquote cite=http://www.w3.org/TR/1999/WD-xhtml-forms-req-19990830#intro>
<p>After careful consideration, the <abbr>HTML</abbr> Working Group has decided that the goals for the next generation of forms are incompatible with preserving backwards compatibility with browsers designed for earlier versions of <abbr>HTML</abbr>. It is our objective to provide a clean new forms model („<abbr>XHTML</abbr> Extended Forms“) based on a set of well-defined requirements. The requirements described in this document are based on experience with a very broad spectrum of form applications.
</blockquote>
<p>A few months later, „<abbr>XHTML</abbr> Extended Forms“ was renamed „XForms“ and <a href=http://www.w3.org/MarkUp/Forms/2000/Charter.html>moved to its own Working Group</a>. That group worked in parallel with the <abbr>HTML</abbr> Working Group and finally published <a href=http://www.w3.org/TR/2003/REC-xforms-20031014/>the first edition of XForms 1.0</a> in October 2003.
<p>Meanwhile, with the transition to <abbr>XML</abbr> complete, the <abbr>HTML</abbr> Working Group set their sights on creating „the next generation of <abbr>HTML</abbr>.“ In May 2001, they published <a href=http://www.w3.org/TR/2001/REC-xhtml11-20010531/>the first edition of <abbr>XHTML</abbr> 1.1</a>, that added <a href=http://www.w3.org/TR/2001/REC-xhtml11-20010531/changes.html#a_changes>only a few minor features</a> on top of <abbr>XHTML</abbr> 1.0, but also eliminated the „Appendix C“ loophole. Starting with version 1.1, all <abbr>XHTML</abbr> documents were to be served with a <abbr>MIME</abbr> type of <code>application/xhtml+xml</code>.
<p class=a>❧
<h2 id=xhtml>Everything you know about XHTML is wrong</h2>
<p>Why are <abbr>MIME</abbr> types important? Why do I keep coming back to them? Three words: <a href=http://esw.w3.org/topic/HTML/DraconianErrorHandling>draconian error handling</a>. Browsers have always been „forgiving“ with <abbr>HTML</abbr>. If you create an <abbr>HTML</abbr> page but forget the <code></head></code> tag, browsers will display the page anyway. (Certain tags implicitly trigger the end of the <code><head></code> and the start of the <code><body></code>.) You are supposed to nest tags hierarchically — closing them in last-in-first-out order — but if you create markup like <code><b><i></b></i></code>, browsers will just deal with it (somehow) and move on without displaying an error message.
<p style="float:left;margin-right:1.75em"><img src=i/openclipart.org_johnny_automatic_3_birds.png width=187 height=362 alt="three birds laughing">
<p>As you might expect, the fact that „broken“ <abbr>HTML</abbr> markup still worked in web browsers led authors to create broken <abbr>HTML</abbr> pages. A lot of broken pages. By some estimates, over 99% of <abbr>HTML</abbr> pages on the web today have at least one error in them. But because these errors don’t cause browsers to display visible error messages, nobody ever fixes them.
<p>The W3C saw this as a fundamental problem with the web, and they set out to correct it. <abbr>XML</abbr>, published in 1997, broke from the tradition of forgiving clients and mandated that all programs that consumed <abbr>XML</abbr> must treat so-called „well-formedness“ errors as fatal. This concept of failing on the first error became known as „draconian error handling,“ after the Greek leader <a href="http://en.wikipedia.org/wiki/Draco_(lawgiver)">Draco</a> who instituted the death penalty for relatively minor infractions of his laws. When the W3C reformulated <abbr>HTML</abbr> as an <abbr>XML</abbr> vocabulary, they mandated that all documents served with the new <code>application/xhtml+xml</code> <abbr>MIME</abbr> type would be subject to draconian error handling. If there was even a single well-formedness error in your <abbr>XHTML</abbr> page — such as forgetting the <code></head></code> tag or improperly nesting start and end tags — web browsers would have no choice but to stop processing and display an error message to the end user.
<p>This idea was not universally popular. With an estimated error rate of 99% on existing pages, the ever-present possibility of displaying errors to the end user, and the dearth of new features in <abbr>XHTML</abbr> 1.0 and 1.1 to justify the cost, web authors basically ignored <code>application/xhtml+xml</code>. But that doesn’t mean they ignored <abbr>XHTML</abbr> altogether. Oh, most definitely not. Appendix C of the <abbr>XHTML</abbr> 1.0 specification gave the web authors of the world a loophole: „Use something that looks kind of like <abbr>XHTML</abbr> syntax, but keep serving it with the <code>text/html</code> <abbr>MIME</abbr> type.“ And that’s exactly what thousands of web developers did: they „upgraded“ to <abbr>XHTML</abbr> syntax but kept serving it with a <code>text/html</code> <abbr>MIME</abbr> type.
<p>Even today, millions of web pages claim to be <abbr>XHTML</abbr>. They start with the <abbr>XHTML</abbr> doctype on the first line, use lowercase tag names, use quotes around attribute values, and add a trailing slash after empty elements like <code><br /></code> and <code><hr /></code>. But only a tiny fraction of these pages are served with the <code>application/xhtml+xml</code> <abbr>MIME</abbr> type that would trigger <abbr>XML</abbr>’s draconian error handling. Any page served with a <abbr>MIME</abbr> type of <code>text/html</code> — regardless of doctype, syntax, or coding style — will be parsed using a „forgiving“ <abbr>HTML</abbr> parser, silently ignoring any markup errors, and never alerting end users (or anyone else) even if the page is technically broken.
<p><abbr>XHTML</abbr> 1.0 included this loophole, but <abbr>XHTML</abbr> 1.1 closed it, and the never-finalized <abbr>XHTML</abbr> 2.0 continued the tradition of requiring draconian error handling. And that’s why there are billions of pages that claim to be <abbr>XHTML</abbr> 1.0, and only a handful that claim to be <abbr>XHTML</abbr> 1.1 (or <abbr>XHTML</abbr> 2.0). So are you really using <abbr>XHTML</abbr>? Check your <abbr>MIME</abbr> type. (Actually, if you don’t know what <abbr>MIME</abbr> type you’re using, I can pretty much guarantee that you’re still using <code>text/html</code>.) Unless you’re serving your pages with a <abbr>MIME</abbr> type of <code>application/xhtml+xml</code>, your so-called „<abbr>XHTML</abbr>“ is <abbr>XML</abbr> in name only.
<p class=a>❧
<h2 id=webapps-cdf>A competing vision</h2>
<p>In June 2004, the W3C held the <a href=http://www.w3.org/2004/04/webapps-cdf-ws/>Workshop on Web Applications and Compound Documents</a>. Present at this workshop were representatives of three browser vendors, web development companies, and other W3C members. A group of interested parties, including the Mozilla Foundation and Opera Software, gave a presentation on their competing vision of the future of the web: <a href=http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html>an evolution of the existing <abbr>HTML</abbr> 4 standard to include new features for modern web application developers</a>.
<blockquote cite=http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html>
<p>The following seven principles represent what we believe to be the most critical requirements for this work.
<dl>
<dt>Backwards compatibility, clear migration path</dt>
<dd>Web application technologies should be based on technologies authors are familiar with, including HTML, CSS, DOM, and JavaScript.</dd>
<dd>Basic Web application features should be implementable using behaviors, scripting, and style sheets in IE6 today so that authors have a clear migration path. Any solution that cannot be used with the current high-market-share user agent without the need for binary plug-ins is highly unlikely to be successful.</dd>
<dt>Well-defined error handling</dt>
<dd>Error handling in Web applications must be defined to a level of detail where User Agents do not have to invent their own error handling mechanisms or reverse engineer other User Agents’.<dd>
<dt>Users should not be exposed to authoring errors</dt>
<dd>Specifications must specify exact error recovery behaviour for each possible error scenario. Error handling should for the most part be defined in terms of graceful error recovery (as in CSS), rather than obvious and catastrophic failure (as in XML).</dd>
<dt>Practical use</dt>
<dd>Every feature that goes into the Web Applications specifications must be justified by a practical use case. The reverse is not necessarily true: every use case does not necessarily warrant a new feature.</dd>
<dd>Use cases should preferably be based on real sites where the authors previously used a poor solution to work around the limitation.</dd>
<dt>Scripting is here to stay</dt>
<dd>But should be avoided where more convenient declarative markup can be used.</dd>
<dd>Scripting should be device and presentation neutral unless scoped in a device-specific way (e.g. unless included in XBL).</dd>
<dt>Device-specific profiling should be avoided</dt>
<dd>Authors should be able to depend on the same features being implemented in desktop and mobile versions of the same UA.</dd>
<dt>Open process</dt>
<dd>The Web has benefited from being developed in an open environment. Web Applications will be core to the web, and its development should also take place in the open. Mailing lists, archives and draft specifications should continuously be visible to the public.</dd>
</dl>
</blockquote>
<p>In a straw poll, the workshop participants were asked, „Should the W3C develop declarative extension to HTML and CSS and imperative extensions to DOM, to address medium level Web Application requirements, as opposed to sophisticated, fully-fledged OS-level APIs? (proposed by Ian Hickson, Opera Software)“ The vote was 11 to 8 against. In their <a href=http://www.w3.org/2004/04/webapps-cdf-ws/summary>summary of the workshop</a>, the W3C wrote, „At present, W3C does not intend to put any resources into the third straw-poll topic: extensions to HTML and CSS for Web Applications, other than technologies being developed under the charter of current W3C Working Groups.“
<p>Faced with this decision, the people who had proposed evolving <abbr>HTML</abbr> and <abbr>HTML</abbr> forms had only two choices: give up, or continue their work outside of the W3C. They chose the latter and registered the <a href=http://www.whatwg.org/><code>whatwg.org</code></a> domain, and in June 2004, <a href=http://www.whatwg.org/news/start>the <abbr>WHAT</abbr> Working Group was born</a>.
<p class=a>❧
<h2 id=whatwg>WHAT Working Group?</h2>
<p class=ss><img src=i/openclipart.org_johnny_automatic_big_sandwich.png width=182 height=523 alt="big sandwich">
<p>What the heck is the <abbr>WHAT</abbr> Working Group? I’ll let them <a href=http://www.whatwg.org/news/start>explain it for themselves</a>:
<blockquote cite=http://www.whatwg.org/news/start>
<p>The Web Hypertext Applications Technology Working Group is a loose, unofficial, and open collaboration of Web browser manufacturers and interested parties. The group aims to develop specifications based on HTML and related technologies to ease the deployment of interoperable Web Applications, with the intention of submitting the results to a standards organisation. This submission would then form the basis of work on formally extending HTML in the standards track.
<p>The creation of this forum follows from several months of work by private e-mail on specifications for such technologies. The main focus up to this point has been extending HTML4 Forms to support features requested by authors, without breaking backwards compatibility with existing content. This group was created to ensure that future development of these specifications will be completely open, through a publicly-archived, open mailing list.
</blockquote>
<p>The key phrase here is „without breaking backward compatibility.“ <abbr>XHTML</abbr> (minus the Appendix C loophole) is not backwardly compatible with <abbr>HTML</abbr>. It requires an entirely new <abbr>MIME</abbr> type, and it mandates draconian error handling for all content served with that <abbr>MIME</abbr> type. XForms is not backwardly compatible with <abbr>HTML</abbr> forms, because it can only be used in documents that are served with the new <abbr>XHTML</abbr> <abbr>MIME</abbr> type, which means that XForms also mandates draconian error handling. All roads lead to <abbr>MIME</abbr>.
<p>Instead of scrapping over a decade’s worth of investment in <abbr>HTML</abbr> and making 99% of existing web pages unusable, the <abbr>WHAT</abbr> Working Group decided to take a different approach: documenting the „forgiving“ error-handling algorithms that browsers actually used. Web browsers have always been forgiving of <abbr>HTML</abbr> errors, but nobody had ever bothered to write down exactly how they did it. NCSA Mosaic had its own algorithms for dealing with broken pages, and Netscape tried to match them. Then Internet Explorer tried to match Netscape. Then Opera and Firefox tried to match Internet Explorer. Then Safari tried to match Firefox. And so on, right up to the present day. Along the way, developers burned thousands and thousands of hours trying to make their products compatible with their competitors’.
<p>If that sounds like an insane amount of work, that’s because it is. Or rather, it was. It took five years, but (modulo a few obscure edge cases) the WHAT Working Group successfully documented <a href=http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html>how to parse <abbr>HTML</abbr></a> in a way that is compatible with existing web content. Nowhere in the final algorithm is there a step that mandates that the <abbr>HTML</abbr> consumer should stop processing and display an error message to the end user.
<p>While all that reverse-engineering was going on, the <abbr>WHAT</abbr> working group was quietly working on a few other things, too. One of them was a specification, initially dubbed <a href=http://www.whatwg.org/specs/web-forms/current-work/>Web Forms 2.0</a>, that added new types of controls to <abbr>HTML</abbr> forms. (You’ll learn more about web forms in <a href=forms.html>A Form of Madness</a>.) Another was a draft specification called „Web Applications 1.0,“ that included major new features like <a href=canvas.html>a direct-mode drawing canvas</a> and native support for <a href=video.html>audio and video without plugins</a>.
<p class=a>❧
<h2 id=reinventing-html>Back to the W3C</h2>
<p class=ss><img src=i/openclipart.org_johnny_automatic_a_dog_and_a_cat_with_an_umbrella.png width=356 height=329 alt="cat and dog holding an imbrella">
<p>For two and a half years, the W3C and the WHAT Working Group largely ignored each other. While the WHAT Working Group focused on web forms and new HTML features, the W3C HTML Working Group was busy with version 2.0 of XHTML. But by October 2006, it was clear that the WHAT Working Group had picked up serious momentum, while XHTML 2 was still languishing in draft form, unimplemented by any major browser. In October 2006, Tim Berners-Lee, the founder of the W3C itself, <a href=http://dig.csail.mit.edu/breadcrumbs/node/166>announced that the W3C would work together with the WHAT Working Group</a> to evolve <abbr>HTML</abbr>.
<blockquote cite=http://dig.csail.mit.edu/breadcrumbs/node/166>
<p>Some things are clearer with hindsight of several years. It is necessary to evolve HTML incrementally. The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didn’t work. The large HTML-generating public did not move, largely because the browsers didn’t complain. Some large communities did shift and are enjoying the fruits of well-formed systems, but not all. It is important to maintain HTML incrementally, as well as continuing a transition to well-formed world, and developing more power in that world.
<p>The plan is to charter a completely new HTML group. Unlike the previous one, this one will be chartered to do incremental improvements to HTML, as also in parallel xHTML. It will have a different chair and staff contact. It will work on HTML and xHTML together. We have strong support for this group, from many people we have talked to, including browser makers.
<p>There will also be work on forms. This is a complex area, as existing HTML forms and XForms are both form languages. HTML forms are ubiquitously deployed, and there are many implementations and users of XForms. Meanwhile, the Webforms submission has suggested sensible extensions to HTML forms. The plan is, informed by Webforms, to extend HTML forms.
</blockquote>
<p>One of the first things the newly re-chartered W3C HTML Working Group decided was to rename „Web Applications 1.0“ to „HTML5.“ And here we are, diving into <abbr>HTML5</abbr>.
<p class=a>❧
<h2 id=postscript>Postscript</h2>
<p>In October 2009, the <abbr>W3C</abbr> <a href=http://www.w3.org/News/2009#item119>shut down the XHTML 2 Working Group</a> and <a href=http://www.w3.org/2009/06/xhtml-faq.html>issued this statement to explain their decision</a>:
<blockquote cite=http://www.w3.org/2009/06/xhtml-faq.html>
<p>When W3C announced the HTML and XHTML 2 Working Groups in March 2007, we indicated that we would continue to monitor the market for XHTML 2. W3C recognizes the importance of a clear signal to the community about the future of HTML.
<p>While we recognize the value of the XHTML 2 Working Group’s contributions over the years, after discussion with the participants, W3C management has decided to allow the Working Group’s charter to expire at the end of 2009 and not to renew it.
</blockquote>
<p>The ones that win are the ones that ship.
<p class=a>❧
<h2 id=further-reading>Further Reading</h2>
<ul>
<li><a href=http://hixie.ch/commentary/web/history>The History of the Web</a>, an old draft by Ian Hickson
<li><a href=http://esw.w3.org/topic/HTML/history>HTML/History</a>, by Michael Smith, Henri Sivonen, and others
<li><a href=http://www.atendesigngroup.com/blog/brief-history-of-html>A Brief History of HTML</a>, by Scott Reynen
</ul>
<p class=a>❧
<p>Dočetli jste kapitolu „Jak to všechno bylo?“ Pokud chcete pokračovat, přejděte na <a href=table-of-contents.html>celý obsah knihy</a>.
<div class=pf>
<h4>Víte že?</h4>
<div class=moneybags>
<blockquote><p>O’Reilly spolu s Google Press nabízí anglickou verzi této knihy v řadě formátů včetně tištěné pdoby, ePub, Mobi, and <abbr>DRM</abbr>-free <abbr>PDF</abbr>. Placená verze se nazývá „HTML5: Up & Running,“ a můžete ji mít ihned.
<p>Pokud se vám tahle kapitola líbila a chcete autora anglického originálu podpořit, <a href="http://www.amazon.com/HTML5-Up-Running-Mark-Pilgrim/dp/0596806027?ie=UTF8&tag=diveintomark-20&creativeASIN=0596806027">kupte si „HTML5: Up & Running“ skrze tento affiliate odkaz</a> nebo <a href=http://oreilly.com/catalog/9780596806033>elektronickou verzi přímo od O’Reilly</a>. Vy dostanete knihu, já peníze. V současnosti nepřijímám přímé dary.
</blockquote>
</div>
</div>
<p class=c>Copyright MMIX–MMXI <a href=about.html>Mark Pilgrim</a>, Czech translation <a href="http://labs.met.cz/">Martin Hassman</a>
<form action=http://www.google.com/cse><div><input type=hidden name=cx value=013556084273090989037:f1s-wnbz68q><input type=hidden name=ie value=UTF-8><input type=search name=q size=25 placeholder="powered by Google™"> <input type=submit name=sa value=Hledat></div></form>
<script src=j/jquery.js></script>
<script src=j/dih5.js></script>
<script type="text/javascript"><!--
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-25728182-1']);
_gaq.push(['_setDomainName', '.html5.cz']);
_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>