forked from zenorocha/diveintohtml5
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathpast.html
391 lines (262 loc) · 52.9 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
<!DOCTYPE html>
<meta charset=utf-8>
<title>Como chegamos aqui - 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>Você está aqui: <a href=index.html>Home</a> <span class=u>‣</span> <a href=table-of-contents.html#history>Dive Into <abbr>HTML5</abbr></a> <span class=u>‣</span>
<h1><br>Como chegamos aqui?</h1>
<p id=toc>
<p class=a>❧
<h2 id=divingin>Mergulhando</h2>
<p class=f><img src=i/aoc-r.png alt=R width=107 height=103>ecentemente, me deparei com uma citação de um desenvolvedor da Mozilla <a href=http://lists.w3.org/Archives/Public/public-html/2010Jan/0107.html>sobre a tensão que existe ao criar padrões</a>:
<blockquote cite=http://lists.w3.org/Archives/Public/public-html/2010Jan/0107.html>
<p>Implementações e especificações tem uma dançam delicadamente. Você não quer que uma implementação ocorra antes que a especificação esteja completa, pois as pessões dependem de detalhes da implementação e isso faz parte da especificação. Entretando, você ambém não quer que a especificação esteja completa antes da implementação e dos testes feitos pelo autor com esta implementação, pois você precisa de um feedback. É inevitável que aja uma tensão aqui, mas isso é só uma pequena confusão.
</blockquote>
<p>Mantenha esta citação na sua mente, e me deixe explicar como a <abbr>HTML5<abbr> surgiu.
<p class=c><img src=i/openclipart.org_johnny_automatic_animals_on_see_saw.png width=526 height=116 alt="animals on a seesaw">
<p class=a>❧
<h2 id=mime-types>MIME types</h2>
<p>Este livro é sobre <abbr>HTML5</abbr>, não sobre as versões anteriores da <abbr>HTML</abbr>, não sobre qualquer versão de <abbr>XHTML</abbr>. Mas para entender a história da <abbr>HTML5</abbr> e as motivações por trás disso, você precisa entender primeiro de alguns detalhes técnicos. Especificamente, <abbr>MIME</abbr> types.
<p>Toda vez que o seu navegador chama uma página, o servidor web envia “cabeçalhos”(headers) antes de enviar a marcação de página em si. Esses cabeçalhos normalmente são invisiveis, mas existem ferramentas de desenvolvimento que o torna visivel caso você precise. Esses cabeçalhos são importantes, pois eles dizem ao navegador como interpretar a marcação da página. A parte mais importante do cabeçalho é chamada de <code>Content-Type</code>, e se parece com isso:
<blockquote><pre>Content-Type: text/html</pre></blockquote>
<p>“<code>text/html</code>” é chamado de “content type” ou “<abbr>MIME</abbr> type” da página. Este cabeçalho é a <strong>única</strong> coisa que determina o que um recurso realmente é, e portanto como ele é renderizao. Imagens tem seu próprio <abbr>MIME</abbr> types (<code>image/jpeg</code> para imagens <abbr>JPEG</abbr>, <code>image/png</code> para imagens <abbr>PNG</abbr>, e por ai vai). Arquivos JavaScript tem seu prórpio <abbr>MIME</abbr> type. Folhas de estilo <abbr>CSS</abbr> tem seu próprio <abbr>MIME</abbr> type. Tudo tem seu próprio <abbr>MIME</abbr> type. A web funciona por causa dos <abbr>MIME</abbr> types.
<p>Claro que a realidade é um pouco mais complicada que apenas isso. A primeira geração de servidores web (e eu estou falando de servidores web de 1993) não enviavam o cabeçalho <code>Content-Type</code>, pois ele ainda não existia. (Eles não existiam antes de 1994.) Por causa da compatibilidade até 1993, os navegadores populares ignoravam o cabeçalho <code>Content-Type</code> em algumas circunstancias. (Isto é chamado de “content sniffing.”) Mas como regra geral, tudo que é procurado na web<abbr>HTML</abbr> paginas, imagens, scripts, videos, PDFs, tudo que tem uma <abbr>URL</abbr> — é exibido com seu <abbr>MIME</abbr> type especifico no cabeçalho <code>Content-Type</code>.
<p>Guarde isto na sua cartola. Nós voltaremos a esse assunto.
<p class=a>❧
<h2 id=history-of-the-img-element>Uma longa digressão entre os padrões que foram feitos</h2>
<p class=ss><img src=i/openclipart.org_johnny_automatic_monkey_reading.png width=365 height=396 alt="monkey reading a book">
<p>Porque existe um elemento <code><img></code>? Esta não é uma questão que você vê todo dia. Obviamente <em> alguém</em> criou ela. Estas coisas não aparecem do nada. Todo elemento, todo atributo, toda funcionalidade do <abbr>HTML</abbr> que você já usou alguma vez foi criada por alguém, que decidiu como ela deveria funcionar, e escreveu todo o código. Estas pessoas não são deuses ou invencíveis. São apenas pessoas. Pessoas inteligentes, com certeza. Mas apenas pessoas.
<p>Uma das grandes coisas sobre padrões desenvolvidos "em aberto" é que você pode voltar no tempo e poder responder esse tipo de perguntas. As discussões ocorrem em listas de emails, que geralmente são arquivadas e podem ser procuradas depois. Então eu decidi fazer um pouco de "arqueologia de email" para tentar responder a seguinte pergunta, "Porque nós temos um elemento <code><img></code>?" E eu tive que voltar para antes que uma organização chamada World Wide Web Consortium (<abbr>W3C</abbr>). Eu voltei aos primeiros dias da web, quando você ainda podia contar o número de servidores web com as duas mãos e talvez alguns dedos do pé.
<p><i>(Tem alguns erros tipograficos nas citações abaixo. Eu decidi deixar eles intactos para manter a precisão histórica)</i>
<p>Em 25 de Fevereiro de 1993 <a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html"><cite>Marc Andreessen</cite> escreveu</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html">
<p>Eu gostaria de propor uma nova tag HTML:
<p>IMG
<p>O argumento obrigatório é: <code>SRC="url"</code>.
<p>Ela serve para apontar um arquivo bitmap ou pixmap para o navegador interpretar como uma imagem no meio do texto no momento de ocorrência da tag.
<p>Como exemplo temos:
<p><code><IMG SRC="file://foobar.com/foo/bar/blargh.xbm"></code>
<p>(Não há uma tag de fechamento; é uma tag standalone.)
<p>Esta tag pode ser usada como link como qualquer outra coisa; quando isto acontece, ela vira um icone sensitivo a ativação exatamente como um texto de link comum.
<p>Navegadores devem ter flexibilidade para os formatos de imagem que irão suportar. Xbm e Xpm são bons para suportar, por exemplo. Se um navegador não consegue renderizar o formato dado, ele pode fazer o que quiser (No X Mosaic irá aparecer um bitmap padrão como substituto da imagem).
<p>Isso requer a funcionalidade de renderizar no X Mosaic; nós temos isso funcionando, e bem ao menos no nosso uso interno. Eu estou bastante aberto a sugestões de como isso pode ser feito com HTML; se você tem uma ideia melhor que a que eu estou apresentando agora, por favor me informe. Eu sei que é difícil lidar com formatos de imagem, mas eu não vejo uma alternativa além da que eu acabei de dizer "deixe o navegador fazer o que ele consegue" e esperar que a solução perfeita apareça (MIME, um dia, quem sabe)
</blockquote>
<p><a href="http://en.wikipedia.org/wiki/X_BitMap">Xbm</a> e <a href="http://en.wikipedia.org/wiki/X_PixMap">Xpm</a> eram formatos gráficos populares no Unix.
<p>"Mosaic" foi um dos primeiros navegadores web. ("X Mosaic" era a versão que rodava no Unix.) Quando ele mandou essa mensagem no início de 1993, <a href="http://en.wikipedia.org/wiki/Marc_Andreessen">Marc Andreessen</a> ainda não havia fundado a compania que fez ele famoso, <a href="http://en.wikipedia.org/wiki/Mosaic_Communications_Corporation">Mosaic Communications Corporation</a>, nem tinha começado a trabalhar no principal produto da empresa "Mosaic Netscape." (Você deve conhecer melhor pelos nomes posteriores, "Netscape Corporation" e "Netscape Navigador.")
<p>“MIME, um dia, quem sabe” é uma referência a <a href="http://en.wikipedia.org/wiki/Content_negotiation">negociação de conteúdo</a>, que é uma funcionalidade do HTTP onde um cliente (como um navegador web) diz ao servidor (como um servidor web) qual tipo de recursos ele suporta (como <code>image/jpeg</code>) para que então o servidor retorne para o cliente no seu formato preferido<a href="http://www.w3.org/Protocols/HTTP/AsImplemented.html">O protocolo HTTP original foi definido em 1991</a> (a única versão que havia implementada em Fevereiro de 1993) não possuia nenhuma maneira dos clientes dizerem aos servidores que tipo de imagens eram suportadas, o que levou ao dilema de design que Marc encontrou.
<p>Algumas horas depois, <a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0183.html"><cite>Tony Johnson</cite> respondeu</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0183.html">
<p>Eu tenho bastante simular no Midas 2.0 (em uso aqui no SLAC, e haverá um release público a qualquer semana), exceto que todos os nomes são diferentes, e tem um argumento extra <code>NAME="name"</code>. Tem quase exatamente a meesma funcionalidade que você propôs na tag <code>IMG</code>, como no exemplo:
<p><code><ICON name="NoEntry" href="http://note/foo/bar/NoEntry.xbm"></code>
<p>A idéia do parametro name é de permitir ao navegador imagens intenas. Se o nome for o mesmo que uma imagem interna, ele usará ela ao invés de buscar a imagem. O nome pode atuar tambem como uma dica para quando o navegador rodarem no terminal como um tipo de simbolo para ser colocado no lugar da imagem.
<p>Eu não ligo muito sobre os nomes dos parametros ou das tags, mas eles devem ser sensíveis se forem utilizados para mesma coisa. Eu não ligo muito para abreviações, ou seja porque não <code>IMAGE=</code> e <code>SOURCE=</code>. Eu prefiro <code>ICON</code> uma vez que é menos que <code>IMAGE</code>, mas talvez <code>ICON</code> seja uma palavra superutilizada, não?
</blockquote>
<p><a href="http://en.wikipedia.org/wiki/MidasWWW">Midas</a> foi um outro dos primeiros navegadores, contemporaneo ao X Moisac. Ele era multiplataforma; funcionava tanto no Unix quando no VMS. "SLAC" refere-se ao <a href="http://en.wikipedia.org/wiki/Stanford_Linear_Accelerator">Stanford Linear Accelerator Center</a>, agora SLAC National Accelerator Laboratory, que hospedou o primeiro servidor web dos Estados Unidos (na verdade <a href="http://www.slac.stanford.edu/history/earlyweb/history.shtml"> o primeiro servidor web fora da Europa</a>). Quando <a href="http://www.slac.stanford.edu/history/earlyweb/wizards.shtml#Tony%20Johnson">Tony</a> escreveu essa mensagem, SLAC era uma especie de ancestral da WWW, e hospedava <a href="http://www.slac.stanford.edu/history/earlyweb/firstpages.shtml"> cinco páginas</a> por gritantes 441 dias.
<p>Tony continuou:
<blockquote>
<p>Enquanto nós estamos no assunto de novas tags, eu tenho outra, de algum modo similar, tag que eu gostaria de suportar no Midas 2.0.
A principio ela é:
<p><code><INCLUDE HREF="..."></code>
<p>A intenção aqui é de poder colocar um segundo documento dentro do primeiro documento no ponto onde a tag aparece. Em principio o documento referenciado pode ser qualquer coisa, mas o objetivo principal é de permitir imagens (nesse caso de tamanho arbitrário) para ser incluida dentro de documentos. Novamente a intenção é de que quando o HTTP2 surgir o formato do documento incluido possa ser negociado separadamente.
</blockquote>
<p>“HTTP2”é uma referência a<a href="http://www.w3.org/Protocols/HTTP/HTTP2.html">HTTP básico definido em 1992</a>. Neste ponto, no inicio de 1993, ele ainda não estaa largamente implementado. O rascunho conhecido HTTP2 foi eventualmente padronizado e implementado como "HTTP 1.0" (embora <a href="http://www.w3.org/Protocols/HTTP/1.0/spec.html"> embora não incluisse por mais três anos </a>). HTTP 1.0 não incluia <a href="http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z3"> requisição de cabeçalhos para negociação de conteúdo</a>, a.k.a. “MIME, um dia, quem sabe.”
<p>Tony continuou:
<blockquote>
<p>Uma alternatica que eu considerei foi:
<p><code><A HREF="..." INCLUDE>See photo</A></code>
<p>Eu não gosto muito de colocar mais funcionalidade a tag <code><A></code>, mas a idéia aqui é de manter a compatibilidade entre os navegadores que não podem honrar com o parametro <code>INCLUDE</code>. A intenção é que os navegadores que entendam <code>INCLUDE</code>, alterem o texto do link (nesse caso "See photo") com o documento incluido (foto), enquanto os navegadores antigos ou burros ignorem completamente a tag <code>INCLUDE</code>.
</blockquote>
<p>Esta proposta nunca foi implementada, no entanto a ideia de colocar um texto quando a imagem não é encontrada é uma<a href="http://diveintoaccessibility.org/day_23_providing_text_equivalents_for_images.html">importante tecnica de acessibilidade</a> esquecida pela proposta inicial da tag <code><IMG</code> de Marc. anos depois esse atributo foi incluido como <a href="http://www.w3.org/TR/html4/struct/objects.html#h-13.8">a tag<code><img alt></code></a>, que o Netscape mostrava erroneamente <a href="http://www.cs.tut.fi/~jkorpela/html/alt.html#tooltip"> o nome quando se colocava o mouse em cima da imagem</a>.
<p>Algumas horas depois que Tony enviou aquela mensagem,<a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0186.html"><cite>Tim Berners-Lee</cite> respondeu</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0186.html">
<p>Eu imaginei que figuras poderiam ser representadas como
<p><code><a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure </a></code>
<p>onde a relação entre os valores significaria
<pre>EMBED Área onde a figura seria apresentada
PRESENT Presente onde quer que o documento fonte foi apresentado</pre>
<p>Veja que você pode ter diversas combinações disso, e se um navegador não suporta nenhuma, ele não quebra
<p>[Eu] vejo que usando esse metódo para icones selecionáveis significam links. Hmmm. Mas eu não quero nenhuma tag especial
</blockquote>
<p>Esta proposta nunca foi implementada, mas o atributo <code>rel</code><a href="http://diveintohtml5.org/semantics.html#link">continua por ai</a>.
<p><a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0188.html"><cite>Jim Davis</cite> adicionou</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0188.html">
<p>Seria legal se houvesse um content type especifico, por exemplo:
<p><code><IMG HREF="http://nsa.gov/pub/sounds/gorby.au" CONTENT-TYPE=audio/basic></code>
<p>Mas eu estou completamente disposto a viver com a necessidade de especificar o content type pela extensão do arquivo.
</blockquote>
<p>Esta proposta nunca foi implementada, mas o Netscape posteriormente incluiu o suporte de inserir audio e video com o elemento <code><embed></code>.
<p><a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0192.html"><cite>Jay C. Weber</cite> perguntou</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0192.html">
<p>Enquanto imagens estão no topo da minha lista de tipos de midia num navegador WWWW, eu não acho que nós devemos incluir especificações idiossincrátiacs para cada tipo de midia. O que aconteceu com o entusiasmo de usar um mecanismo de MIME type?
</blockquote>
<p><a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0194.html"><cite>Marc Andreessen</cite> respondeu</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0194.html">
<p>Isto não é um substituto para o futuro uso do MIME como um documento padrão do mecanismo; Isso apenas dá uma implementação necessária e simples da funcionalidade independente do MIME.ndependently from MIME.
</blockquote>
<p><a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0198.html"><cite>Jay C. Weber</cite> respondeu</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0198.html">
<p>Vamos esquecer temporariamente esquecer do MIME, se ele atrapalha o problema. Minha objeção é a discussão sobre "como nós iremos incluir o suporte a imagens" e não sobre "como nós vamos suportar os diversos problemas nas diversas midias"
<p>De outra maneira, semana que vem alguém vai sugerir "vamos colocar uma nova tag<code><AUD SRC="file://foobar.com/foo/bar/blargh.snd"></code>" para audio.
<p>Isto é muito custo no lugar de algo que generalize.
</blockquote>
<p>Com o beneficio de termos uma retrospectiva, parece que as preocupações de Jay estavam bem fundamentadas. Levou mais de uma semana, mas o HTML5 finalmenta inclui os novos elementos<a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video"><code><video></code></a> e <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#audio"><code><audio></code></a>.
<p>Respondendo a mensagem original de Jay, <a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0204.html"><cite>Dave Raggett</cite> disse</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0204.html">
<p>Verdade! Eu gostaria de considerar toda a gama de possibilidade de tipo de arte em imagens, além da possibilidade de negociação do formato. A mensagem de Tim sobre áreas clicaveis nas imagens também são importantes.
</blockquote>
<p>Mais tarde em 1993,<a href="http://www.w3.org/People/Raggett/">Dave Raggett</a> propos <a href="http://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html">HTML+</a> como uma evolução do padrão HTML. Esta proposta nunca foi implementada, e foi substituida pelo<a href="http://www.w3.org/MarkUp/html-spec/html-spec_toc.html">HTML 2.0</a>. HTML 2.0 foi uma "retrospectiva", o que significa que formalizou as funcionalidades que já estavam em uso “<a href="http://www.w3.org/MarkUp/html-spec/html-spec_1.html#SEC1.1">Essa especificação reune, esclarece e formaliza o conjunto de funcionalidades</a> que grosseiramente corresponde as capacidades do HTML que estava em uso em Junho de 1994.”
<p>Dave mais tarde escreveu o <a href="http://www.w3.org/MarkUp/html3/CoverPage.html">HTML 3.0</a>, baseado no rascunho feito por eles do HTML+. Fora isso a referência da W3C do <a href="http://www.w3.org/Arena/">Arena</a>, HTML 3.0 nunca foi implementado, e foi substituido pelo <a href="http://www.w3.org/MarkUp/Wilbur/">HTML 3.2</a>, outra "retrospectiva":“<a href="http://www.w3.org/TR/REC-html32.html#intro">HTML 3.2 incluiu largamente outras funcionalidades</a> como tabelas, applets e textos ao redor de imagens, enquanto mantinha a retro-compatibilidade com o padrão existente: HTML 2.0.”
<p>Dave mais tarde foi co-autor do desenvolvimento do <a href="http://www.w3.org/TR/html4">HTML 4.0</a>, desenvolveu o <a href="http://tidy.sourceforge.net/">HTML Tidy</a>, e ajudou com a especificações do XHTML, XForms, MathML, e outras especificações modernas da W3C.
<p>Voltando para 1993, <a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0209.html">Marc respondeu a Dave</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0209.html">
<p>Na verdade, talvez nós devessemos pensar numa linguagem procedural genérica para graficos que com ela nós possamos incluir hyperlinks aleatórios anexados a icones, imagens, ou texto, ou qualquer coisa. Alguém vê as capacidades Intermedia disso?
</blockquote>
<p><a href="http://en.wikipedia.org/wiki/Intermedia_(hypertext)">Intermedia</a> era um projeto hypertexto da Brown University. Ela foi desenvolvida de 1985 até 1991 e rodava no <a href="http://en.wikipedia.org/wiki/A/UX">A/UX</a>, um sistema operacional Unix-like utilizados nos primeiros computadores Macintosh.
<p>A ideia de "uma linguagem procedural genérica para gráficos" foi eventualmente implementada. Navegadores modernos suportam tanto<a href="http://www.w3.org/Graphics/SVG/">SVG</a> (marcação declarativa com scripts embutidos) e <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-canvas-element"><code><canvas></code></a> (uma API procedural e direta para graficos), mesmo que <a href="http://ln.hixie.ch/?start=1089635050&count=1">começasse como uma extensão proprietária</a> antes de começar a ser "revista"pela <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> respondeu</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0217.html">
<p>Outros sistemas para olharmos que tem alguma noção disso (bastante válida) são Andrew e Slate. Andrew foi feito com _insetos_, e cada um deles tem um tipo interessante, como texto, bitmap, desenhos, animações, mensagens, planilhas, etc. A noção de inclusão arbitrária e recursiva está presente, então se um inseto de qualquer tipo pode ser incluido em qualquer lugar que suporte inclusa. Por exemplo, um inseto pode ser incluido em qualquer ponto do texto de um widget de texto, ou em qualquer área retangular de um widget de desenho ou em qualquer célular de uma planilha.
</blockquote>
<p>“Andrew” é uma referencia a <a href="http://www-2.cs.cmu.edu/~AUIS/">Andrew User Interface System</a> ( nessa época era conhecida apenas como <a href="http://en.wikipedia.org/wiki/Andrew_Project">Andrew Project</a>).
<p>Ao mesmo tempo,<a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0215.html"><cite>Thomas Fine</cite> teve uma ideia diferente</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0215.html">
<p>Esta é a minha opinião. A melhor maneira de usar imagens na WWW é utilizando MIME. Eu tenho certeza que postscript é um tipo suportado no MIME, e que lida tranquilamente com a mistura de texto e imagens.
<p>Mas isto ainda não é clicavel, você diz? Sim você está certo. Eu suspeito que já tenha uma resposta para isso ser exibido utlizando display postscript. Mesmo que incluir isto ao padrão postscript seja trivial. Definir um comando de link que especifica a URL e o uso do caminho atual como uma região próxima ao botão. Desde que o postscript lide bem com os caminhos, isto faz com que formatos de botões aleatórios sejam triviais.
</blockquote>
<p><a href="http://en.wikipedia.org/wiki/Display_PostScript">Display Postscript</a> era uma tecnologia de renderizamento na tela co-desenvolvida pela Adobe e NeXT.
<p>Esta proposta nunca foi implementada, mas a idéia de um jeito melhor de consertar HTML e substitui-lo por algo completamente diferente <a href="http://dbaron.org/log/20090707-ex-html">aparece de tempso em tempos</a>.
<p><a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0221.html"><cite>Tim Berners-Lee</cite>, 2 de Março de 1993</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0221.html">
<p>HTTP2 permite que um documento contenha qualquer tipo que usuário diga que pode lidar, não apenas os MIME types registrados. Então pode ser feito um experimetno. Sim eu acho que tem algum caso que funciona postscript com hipertexto, Eu não entendo de display postscript o suficiente. Eu sei que a Adobe está tentando estabelecer seu próprio tipo de postscript "PDF" que terá links e poderá ser lido pelos leitores proprietários deles.
<p>Eu penso que uma linguagem genérica para links entre camadas (baseados em Hytime?) pode permitir padrões hipertexto e imagens/video que envolva-os separadamente, que pode ajudar ambos.
<p>Deixem que a tag <code>IMG</code> possa ser <code>INCLUDE</code> (incluida) e deixe ela se referir a um tipo arbitrario de documento. Ou <code>EMBED</code> se <code>INCLUDE</code> parece com um include do cpp e que as pessoas possam esperar por um código fonte SGML para ser interpretado — o que não é a intençao.
</blockquote>
<p><a href="http://www.hytime.org/">HyTime</a> foi um dos primeiros sistemas de documentos hipertexto baseado em SGML. Ele teve uma grande importância nas primeiras discussões sobre HTML e posteriormente sobre XML.
<p>A proposta de Tim para uma tag <code><INCLUDE</code> nunca foi implementada, no entanto pode-se ver ecos dela nos elementos <code><object></code>, <code><embed></code>, e <code><iframe></code>.
<p>Finalmente em 12 de Março de 1993,<a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0257.html">Marc Andreessen revisitou a thread</a>:
<blockquote cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0257.html">
<p>Voltando a thread sobre inclusão de imagens — eu estou chegando perto de lançar o Mosaic v0.10, que irá suportar a inculsão de GIF e imagens/bitmaps XBM, como eu disse anteriormente. ...
<p>Nós não estamos preparados para suportar as tags <code>INCLUDE</code>/<code>EMBED</code> nesse momento. ... Então nós provavelmente iremos usar as tags <code><IMG SRC="url"></code> (não a tag <code>ICON</code>, dado que nem todas as imagens podem ser propriamente chamadas de icones). Por enquanto as imagens incluidas não deverão possuir um contet-type especifico; futuramente, nós planejamos dar suporte a isto (junto com a adaptação do MIME). Na verdade, a rotina de leitura de imagens que nós estamos utilizando lida com o formato da imagem no momento de renderizar, então a extensão do arquivo não é tão relevante.
</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 umbrella">
<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>This has been “How Did We Get Here?” The <a href=table-of-contents.html>full table of contents</a> has more if you’d like to keep reading.
<div class=pf>
<h4>Did You Know?</h4>
<div class=moneybags>
<blockquote><p>In association with Google Press, O’Reilly is distributing this book in a variety of formats, including paper, ePub, Mobi, and <abbr>DRM</abbr>-free <abbr>PDF</abbr>. The paid edition is called “HTML5: Up & Running,” and it is available now. This chapter is included in the paid edition.
<p>If you liked this chapter and want to show your appreciation, you can <a href="http://www.amazon.com/HTML5-Up-Running-Mark-Pilgrim/dp/0596806027?ie=UTF8&tag=diveintomark-20&creativeASIN=0596806027">buy “HTML5: Up & Running” with this affiliate link</a> or <a href=http://oreilly.com/catalog/9780596806033>buy an electronic edition directly from O’Reilly</a>. You’ll get a book, and I’ll get a buck. I do not currently accept direct donations.
</blockquote>
</div>
</div>
<p class=c>Copyright MMIX–MMXI <a href=about.html>Mark Pilgrim</a>
<form action=http://www.google.com/cse><div><input type=hidden name=cx value=017884302975346027366:bgclqh8nvse><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=Search></div></form>
<script src=j/jquery.js></script>
<script src=j/dih5.js></script>