-
Notifications
You must be signed in to change notification settings - Fork 85
/
Copy pathpast.html
407 lines (274 loc) · 57.5 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
403
404
405
406
407
<!DOCTYPE html>
<html lang=pt-br>
<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/zenorocha/diveintohtml5/commits/gh-pages.atom>
<link rel=alternate href=http://diveintohtml5.info/past.html hreflang=en>
<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>
<a href="https://github.com/zenorocha/diveintohtml5"><img style="position: absolute; top: 0; right: 0; border: 0;" src="https://s3.amazonaws.com/github/ribbons/forkme_right_darkblue_121621.png" alt="Fork me on GitHub"></a>
<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 devem dançar delicadamente juntos. Você não quer que uma implementação ocorra antes que a especificação esteja completa, pois as pessoas dependem de detalhes da implementação e isso faz parte da especificação. Entretanto, você també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 haja 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> e 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 dela, 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 invisíveis, mas existem ferramentas de desenvolvimento que os tornam visíveis caso necessário. Estes cabeçalhos são importantes, pois eles informam 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” (tipo de conteúdo) 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 deve ser renderizado. 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. (Ele não foi inventado antes de 1994.) Por causa da compatibilidade até 1993, alguns dos navegadores populares da época ignoravam o cabeçalho <code>Content-Type</code> em alguns momentos. (Isto é chamado de “content sniffing.”) Mas como regra geral, tudo que é procurado na web — páginas <abbr>HTML</abbr>, imagens, scripts, videos, PDFs, tudo que tem uma <abbr>URL</abbr> — é exibido com seu <abbr>MIME</abbr> type específico 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 pergunta 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 da <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 "abertos" é 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>) existisse. 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 tipográficos 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 ponto 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 ícone sensitivo a ativação exatamente como um texto de âncora 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 conseguir 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 é uma função necessária no X Mosaic; nós temos isso funcionando, e nós iremos usar internamente pelo menos. Eu estou bastante aberto a sugestões de como isso pode ser feito com HTML; se você tem uma ideia melhor que a minha, 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 falar "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 companhia 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 Navigator.")
<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 possuía 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 algo bastante similar 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 mesma funcionalidade que você propôs na tag <code>IMG</code>, como por exemplo:
<p><code><ICON name="NoEntry" href="http://note/foo/bar/NoEntry.xbm"></code>
<p>A ideia do parâmetro name é de permitir ao navegador o uso de imagens internas. Se o nome for o mesmo que uma imagem interna, ele usará ela ao invés de buscar a imagem. O nome pode atuar também como uma dica para quando o navegador rodar no terminal como um tipo de símbolo para substituir a imagem.
<p>Eu não ligo muito sobre os nomes dos parâmetros ou das tags, mas eles devem ser sensíveis se forem utilizados para mais de uma 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 sobrecarregada, não?
</blockquote>
<p><a href="http://en.wikipedia.org/wiki/MidasWWW">Midas</a> foi um outro dos primeiros navegadores, contemporâneo 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, foi o lugar 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 um 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 ainda estamos no assunto de novas tags, eu tenho outra, de algum modo parecida, tag que eu gostaria de suportar no Midas 2.0.
A princípio ela é:
<p><code><INCLUDE HREF="..."></code>
<p>A intenção aqui é de poder colocar um segundo documento dentro do primeiro documento no ponto que a tag aparece. A princípio o documento referenciado pode ser qualquer coisa, mas o objetivo principal é de permitir imagens (nesse caso de tamanho arbitrário) para ser incluída dentro de documentos. Novamente a intenção é de que quando o HTTP2 surgir, o formato do documento incluído possa ser negociado separadamente.
</blockquote>
<p>“HTTP2” é uma referência ao <a href="http://www.w3.org/Protocols/HTTP/HTTP2.html">HTTP básico definido em 1992</a>. Neste ponto, no início de 1993, ele ainda não estava largamente implementado. O rascunho conhecido HTTP2 foi eventualmente padronizado e implementado como "HTTP 1.0" ( <a href="http://www.w3.org/Protocols/HTTP/1.0/spec.html"> embora não por mais três anos </a>). HTTP 1.0 não incluía a <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 alternativa que considerei foi:
<p><code><A HREF="..." INCLUDE>See photo</A></code>
<p>Eu não gosto muito de colocar mais funcionalidade na tag <code><A></code>, mas a idéia aqui é de manter a compatibilidade entre os navegadores que não podem honrar com o parâmetro <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 incluído (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 técnica de acessibilidade</a> esquecida pela proposta inicial da tag <code><IMG</code> de Marc. Anos depois esse atributo foi incluído 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 Coloque isso quando apresentar
PRESENT Mostre isso sempre que o documento fonte for 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 método para ícones 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 aí</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 específico, 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 áudio e vídeo 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 mídias num navegador WWW, eu não acho que nós devemos incluir especificações idiossincráticas para cada tipo de mídia. 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 padrão do mecanismo; Isso apenas dá a implementação necessária e simples da funcionalidade independente do 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 temporariamente esquecer do MIME, se é o que está atrapalhando. 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 mídias"
<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 áudio.
<p>Isto é muito custo no lugar de usar algo que generalize.
</blockquote>
<p>Com o benefício de termos uma retrospectiva, parece que as preocupações de Jay estavam bem fundamentadas. Levou mais de uma semana, mas o HTML5 finalmente 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 clicáveis nas imagens também são importantes.
</blockquote>
<p>Mais tarde em 1993, <a href="http://www.w3.org/People/Raggett/">Dave Raggett</a> propôs <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 substituída pela <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 já em uso “<a href="http://www.w3.org/MarkUp/html-spec/html-spec_1.html#SEC1.1">Essa especificação reúne, esclarece e formaliza o conjunto de funcionalidades</a> que grosseiramente corresponde as capacidades do HTML que estavam em uso em Junho de 1994.”
<p>Dave mais tarde escreveu a <a href="http://www.w3.org/MarkUp/html3/CoverPage.html">HTML 3.0</a>, baseado no rascunho feito por eles do HTML+. Fora isso existia a referência da W3C do <a href="http://www.w3.org/Arena/">Arena</a>, HTML 3.0 nunca foi implementado, e foi substituído 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 da <a href="http://www.w3.org/TR/html4">HTML 4.0</a>, desenvolveu a <a href="http://tidy.sourceforge.net/">HTML Tidy</a>, e ajudou com as 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 devêssemos pensar numa linguagem procedural genérica para gráficos que com ela nós possamos incluir hyperlinks aleatórios anexados a ícones, 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> foi um projeto de uso de hipertexto 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 utilizado 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 gráficos), 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 _insets_, 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 um inset de qualquer tipo pode ser incluído em qualquer lugar que suporte incorporação. Por exemplo, um inset pode ser incluído em qualquer ponto do texto de um widget de texto, ou em qualquer área retangular de um widget de desenho ou em qualquer célula de uma planilha.
</blockquote>
<p>“Andrew” é uma referência 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 é clicável, você diz? Sim você está certo. Eu suspeito que já tenha uma resposta para isso ser exibido utilizando display postscript. Mesmo que incluir isto ao padrão postscript seja trivial. Definir um comando de âncora 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 renderização 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 substituí-lo por algo completamente diferente <a href="http://dbaron.org/log/20090707-ex-html">aparece de tempos 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 o usuário diga que pode lidar, não apenas os MIME types registrados. Então pode ser feito um experimento. 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> (incluída) e deixe ela se referir a um tipo arbitrário 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ção.
</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 inclusã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 ícones). Por enquanto as imagens incluídas não deverão possuir um content-type específico; 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>Uma linha contínua</h2>
<p>Eu tenho um fascínio incrível por todos os detalhes dessa conversa de quase 17 anos de idade que levou a criação de um elemento <abbr>HTML</abbr> que é utilizado em praticamente todas as páginas da internet. Considere que:
<p class=ss><img src=i/openclipart.org_johnny_automatic_Corsican_Pine.png width=216 height=405 alt="árvore do tipo pinheiro">
<ul>
<li>HTTP continua existindo. HTTP evolui com sucesso de 0.9 para 1.0 e posteriormente para 1.1. <a href="http://www.ietf.org/dyn/wg/charter/httpbis-charter.html">E continua evoluindo</a>.
<li>HTML continua existindo. O formato de dados rudimentar — ele sequer suportava imagens em linha! — evoluiu com sucesso para 2.0, 3.2, 4.0. HTML é uma linha contínua. Uma linha torcida, cheia de nós, embolada, com certeza. Existem diversos "branches mortos" na árvore evolutiva, lugares onde pensamentos estavam a frente das próprias pessoas (e na frente dos autores e desenvolvedores). Mas continua. Aqui estamos, em 2010, e as <a href="http://www.w3.org/People/Berners-Lee/FAQ.html#Examples">páginas da web de 1990</a> continuam sendo exibidas corretamente nos navegadores modernos. Eu acabei de carregar uma no navegador em estado-da-arte do meu celular Android e eu nem recebi uma mensagem dizendo “por favor aguarde enquanto estamos importando formatos legados…”
<li>HTML sempre será uma conversa entre marcações de navegadores, autores, padrões, e outras pessoas que simplesmente apareceram e gostaram de conversar sobre símbolos de maior e menor. A maioria das versões bem sucedidas da HTML foram “retrospectivas,” pegando tudo que existia e tentando empurrar isso para direção certa. Qualquer um que diga a você que a HTML deveria continuar “pura” (presumivelmente ignorando os marcadores dos navegadores, ou ignorando os autores ou ambos) está simplesmente mal informado. A HTML nunca foi pura, e todas as tentativas de purificá-lo foram falhas incríveis, vistas apenas pelas tentativas de substituí-lo.
<li>Nenhum dos navegadores de 1993 continua existindo de uma forma reconhecível. O Netscape Navigator foi <a href="http://en.wikipedia.org/wiki/History_of_Mozilla_Application_Suite#Open_sourcing_of_Communicator">abandonado em 1998</a> e <a href="http://en.wikipedia.org/wiki/History_of_Mozilla_Application_Suite#Rewriting_from_scratch">re-escrito a partir do rascunho</a> para criar a Suite Mozilla, que foi <a href="http://en.wikipedia.org/wiki/History_of_Mozilla_Firefox"> subdivida para criar o Firefox</a>. O Internet Explorer teve diversos “começos” no “Microsoft Plus! for Windows 95,” que foi empacotado junto com alguns temas para área de trabalho e um jogo de pinball. (Mas é claro que também podem ser encontradas <a href="http://en.wikipedia.org/wiki/Spyglass_Mosaic">referências anteriores</a> a este navegador).
<li>Alguns dos sistemas operacionais de 1993 continuam existindo, mas nenhum deles é relevante para internet moderna. A maioria das pessoas que “usa” a internet faz em um PC rodando Windows 2000 ou superior, um Mac rodando Mac OS X, um PC rodando algum sabor de Linux, ou um smartphone como um iPhone. Em 1993, o Windows estava na versão 3.1 (e competindo com OS/2), Macs rodavam System 7 e o Linux era distribuído pela Usenet. (Quer se divertir um pouco? Encontre um dinossauro da internet e sussurre “Trumpet Winsock” ou “MacPPP.”)
<li>Algumas das mesmas <em>pessoas</em> continuam por ai e continuam envolvidas no que nós simplesmente chamamos de “web standards (padrões da internet).” Isso após quase 20 anos. Alguns destes estavam envolvidos com os predecessores da HTML, na década de 80 e anteriores.
<li>Falando dos antecessores… Com a popularidade adquirida da HTML e da internet, é fácil esquecer os formatos e sistemas modernos envolvidos na criação deles. Andrew? Intermedia? HyTime? E o HyTime não foi somente um projeto de pesquisa acadêmico; <a href="http://xml.coverpages.org/hytime.html">ele foi um padrão ISO</a>. Ele foi aprovado para uso militar. Ele era um Grande Negócio. E você pode ler sobre ele por você mesmo… <a href="http://www.sgmlsource.com/history/hthist.htm">na página HTML dele, no seu navegador</a>.
</ul>
<p>Mas nenhuma dessas coisas responde a pergunta original: por que temos um elemento <code><img></code>? Por que não um elemento <code><icon></code>? Ou ainda um elemento <code><include></code>? Por que não temos um link com um atributo <code>include</code>, ou alguma combinação de valores em <code>rel</code>? Por que um elemento <code><img></code>? Simples, porque Marc Andreessen enviou um código com ele e código enviado ganha.
<p>Isso não quer dizer que <em>todos</em> códigos enviados ganham; afinal, Andrew e Intermedia e HyTime enviaram seus códigos também. Código é necessário, mas não o suficiente para o sucesso. E eu <em>com certeza</em> não quis dizer que enviar código antes de um padrão irá produzir a melhor solução. O elemento <code><img></code> de Marc não funcionava com diversos formatos comuns de figuras; ele não definia como o texto ficaria ao redor da imagem; ele não suportava alternativas de texto ou de substituição de conteúdo em caso de falhas em navegadores antigos. E 17 anos depois, <a href="http://tools.ietf.org/html/draft-abarth-mime-sniff">continuamos lidando com o sniffing de conteúdo</a>, e <a href="http://www.securityfocus.com/archive/1/503867"> continuam existindo diversas vulnerabilidades loucas</a>. E você tem como voltar atrás 17 anos e ver a <a href="http://en.wikipedia.org/wiki/Browser_wars">Grande Guerra dos navegadores</a> e voltar para 25 de Fevereiro de 1993 quando Marc Andreenssen simplesmente comentou, “MIME, um dia, quem sabe,” e enviou seu código de todo modo.
<p>Ganha aquele que é enviado.
<p class=a>❧
<h2 id=timeline>Uma linha do tempo do desenvolvimento da HTML de 1997 à 2004</h2>
<p>Em Dezembro de 1997, a World Wide Web Consortium (W3C) publicou a <a href=http://www.w3.org/TR/REC-html40-971218/><abbr>HTML</abbr> 4.0</a> e provavelmente fechou o grupo de trabalho da <abbr>HTML</abbr>. Menos de dois meses depois, um grupo de trabalho separado da <abbr>W3C</abbr> publicou o <a href=http://www.w3.org/TR/1998/REC-xml-19980210><abbr>XML</abbr> 1.0</a>. Três meses depois apenas, as pessoas que faziam parte da W3C deram um workshop chamado: “<a href=http://www.w3.org/MarkUp/future/>Moldando o futuro da <abbr>HTML</abbr></a>” para responder a questão: “A W3C desistiu da HTML?” Esta foi a resposta:
<blockquote cite=http://esw.w3.org/topic/HTML/history>
<p>Nas conversas foi concordado que seria difícil ocorrer uma futura extensão da <abbr>HTML</abbr>, como a conversão da 4.0 para uma aplicação <abbr>XML</abbr>. Foi proposto quebrar com estas restrições e fazer um novo começo para a nova geração da HTML baseada em um conjuto de tags <abbr>XML</abbr>.
</blockquote>
<p>A <abbr>W3C</abbr> recriou o grupo de trabalho da <abrr>HTML</abbr> para criação do seu “conjunto de tags <abbr>XML</abbr>.” O primeiro passo deles, em dezembro de 1998, foi um rascunho de uma especificação interna que simplesmente <a href=http://www.w3.org/TR/1998/WD-html-in-xml-19981205/> reformulou a <abbr>HTML</abbr> no <abbr>XML</abbr></a> sem adicionar nenhum novo elemento ou atributo. Esta especificação posteriormente ficou conhecida como “<a href=http://www.w3.org/TR/xhtml1/><abbr>XHTML</abbr> 1.0</a>.” Ela definiu um novo <abbr>MIME</abbr> type para documentos <abbr>XHTML</abbr>: <code>application/html+xml</code>. Entretando, para realizar a migração das atuais 4 páginas da <abbr>HTML</abbr> existentes, segundo o <a href=http://www.w3.org/TR/xhtml1/#guidelines>Apêndice C</a>, resume nas “principais guias de design para os autores que desejam processar documentos <abbr>XHTML</abbr> nos agentes HTML existentes.” O apêndice C diz também que é permitido ao autor chamar documentos “<abbr>XHTML</abbr>”, mas utilizar ainda o <abbr>MIME</abbr> type <code>text/html</code>.
<p>O próximo objetivo deles foram os formulários web. Em agosto de 1999, o mesmo grupo de trabalho da <abbr>HTML</abbr> publicou o primeiro rascunho da <a href=http://www.w3.org/TR/1999/WD-xhtml-forms-req-19990830><abbr>XHTML</abbr> Extended Forms</a>. Eles colocaram as expectativas <a href=http://www.w3.org/TR/1999/WD-xhtml-forms-req-19990830#intro>no primeiro parágrafo</a>:
<blockquote cite=http://www.w3.org/TR/1999/WD-xhtml-forms-req-19990830#intro>
<p>Depois de uma cuidadosa consideração, o grupo de trabalho da <abbr>HTML</abbr> decidiu que as metas para a nova geração dos formulários são incompatíveis com a retro-compatibilidade com os navegadores desenvolvidos para suportar as versões antigas da <abbr>HTML</abbr>. É nosso objetivo criar um novo modelo de formulários do zero (“<abbr>XHTML</abbr> Extended Forms”) baseado em um conjunto bem definido de requisitos. Os requisitos descritos nesse documento são baseados na experiência adquirida com um grande expectro de aplicações com formulários.
</blockquote>
<p>Alguns meses depois, “<abbr>XHTML</abbr> Extended Forms” foi renomeado para “XForms” e movida para seu próprio <a href=http://www.w3.org/MarkUp/Forms/2000/Charter.html>grupo de trabalho</a>. Este grupo trabalhou paralelamente com o grupo de trabalho da <abbr>HTML</abbr> e finalmente publicou em outubro de 2003 <a href=http://www.w3.org/TR/2003/REC-xforms-20031014/>a primeira edição do XForms 1.0</a>.
<p>Enquanto isso com a transição para o <abbr>XML</abbr> completa, o grupo de trabalho da <abbr>HTML</abbr> colocaram seus esforços na “nova geração da <abbr>HTML</abbr>.” Em maio de 2001 eles publicaram <a href=http://www.w3.org/TR/2001/REC-xhtml11-20010531/>a primeira edição da <abbr>XHTML</abbr> 1.1</a>, que adicionou <a href=http://www.w3.org/TR/2001/REC-xhtml11-20010531/changes.html#a_changes> apenas poucos recursos</a> além dos que haviam na <abbr>XHTML</abbr> 1.0, mas também eliminou a brecha existente no “Apêndice C.” A partir da versão 1.1, todos os documentos <abbr>XHTML</abrr> passam a funcionar a com o <abbr>MIME</abbr> type <code>application/html+xml</code>.
<p class=a>❧
<h2 id=xhtml>Tudo que você sabe sobre XHTML está errado</h2>
<p>Por que os <abbr>MIME</abbr> types são importantes? Por que eu fico voltando a eles? Três palavras: <a href=http://esw.w3.org/topic/HTML/DraconianErrorHandling>draconian error handling</a> (tratamento de erros draconianos). Navegadores sempre foram “tolerantes” com a <abbr>HTML</abbr>. Se você criar uma página <abbr>HTML</abbr> mas esquecer a tag <code></head></code>, os navegadores irão mostrar a página de todo modo. (Algumas tags implicitamente realizam o fechamando da tag <code></head></code> e o inicio da tag <code><body></code>.) Você supostamente aninha as tags de maneira hierárquica — fechando elas da última para primeira — mas, se você criar uma marcação como <code><b><i></b></i></code>, os navegadores simplesmente vão lidar com isso (de algum jeito) sem mostrar nenhuma mensagem de erro.
<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>Como você pode esperar, o fato dessa marcação <abbr>HTML</abbr> “quebrada” continuar funcionando em alguns navegadores, permite que os autores criem páginas <abbr>HTML</abbr> quebradas. Muitas páginas quebradas. Segundo algumas estimativas, cerca de 99% das páginas <abbr>HTML</abbr> na internet hoje possuem pelo menos um erro nelas. Mas como os navegadores não mostram mensagens de erro para isto, ninguém conserta.
<p>A W3C viu que este era o problema fundamental com a web, e, então, eles decidiram corrigir isso. O <abbr>XML</abbr> publicado em 1997 quebrou com a tradição de perdoar os clientes e mandou que todos os programas que consumissem <abbr>XML</abbr> deveriam tratar os erros chamados de “boa-formatação” como erros fatais. Este conceito de falha ficou conhecido como “tratamento de erro draconiano” depois do líder grego <a href="http://en.wikipedia.org/wiki/Draco_(lawgiver)">Draco</a> que foi quem instituiu a pena de morte para quem cometesse menores infrações das suas leis. Quando a W3C reformulou a <abbr>HTML</abbr> como um vocabulário <abrr>XML</abbr>, eles mandaram que todos os documentos servidos pelo novo <abbr>MIME</abbr> type <code>application/xhtml+xml</code> deveriam submeter um tratamento de erro draconiano. Caso houvesse apenas um erro de boa-formação na sua página <abrr>XHTML</abbr> — Como por exemplo esquecer a tag <code></head></code> ou uma colocação errada de tags de início e fim — os navegadores não teriam escolha a não ser parar o processamento e mostrar uma mensagem de erro para o usuário final.
<p>Essa ideia não foi popular universalmente. Com uma taxa estimada de erro em 99% das páginas, a sempre presente possibilidade de mostrar mensagens de erro para o usuário final e a escassez de novos recursos no <abbr>XHTML</abbr> 1.0 e 1.1 que justificassem o custo, os autores web basicamente ignoraram a <code>application/xhtml+xml</code>. Mas isso não significa que eles também ignoraram o <abbr>XHTML</abbr>. Definitivamente eles não fizeram isso. O Apêndice C da especificação do <abbr>XHTML</abbr> 1.0 deu aos autores da web uma nova brecha: “Usar algo que pareça com a sintaxe do <abrr>XHTML</abbr>, mas que continua gerando o <abbr>MIME</abbr> type <code>text/html</code>.” Isso foi exatamente o que centenas de desenvolvedores web fizeram: eles fizeram um <em>upgrade</em> para a sintaxe do <abrr>XHTML</abbr> mas que continuassem gerando o <abbr>MIME</abbr> type <code>text/html</code>
<p>Até hoje, milhões de páginas da internet dizem ser <abbr>XHTML</abbr>; Elas começam com o doctype <abbr>XHTML</abbr> na primeira linha, usam tags com caixa baixa, usam aspas nos atributos e uma barra simples ao final de elementos vazios como <code><br /></code> e <code><hr /></code>; Mas uma pequena fração dessas páginas são realmente servidas com o <abbr>MIME</abbr> type <code>application/xhtml+xml</code> e que façam o tratamento de erro draconiano. Qualquer página que possua o <abbr>MIME</abbr> type <code>text/html</code> — independente do doctype, sintaxe ou estilo de código — será interpretada usando um parseador <abbr>HTML</abbr> tolerante, que silenciosamente ignorará qualquer erro de marcação e nunca alertará os usuários finais (ou qualquer outra pessoa) se a página está tecnicamente quebrada;
<p>O <abbr>XHTML</abbr> 1.0 inclui esta brecha, mas o <abbr>XHTML</abbr> 1.1. a fechou e o nunca finalizado <abbr>XHTML</abbr> 2.0 continuou com a tradição de requerer o tratamento de erro draconiano. É por isso que as bilhões de páginas que dizem ser <abbr>XHTML</abbr> 1.0. e apenas algumas dizem ser <abrr>XHTML</abbr> 1.1 (ou <abbr>XHTML</abbr> 2.0). Então você realmente está usando <abbr>XHTML</abbr>? Verifique o seu <abbr>MIME</abbr> type. (Na verdade, se você não sabe qual <abbr>MIME</abbr> type você está usando eu posso garantir que você continua usando <code>text/html</code>.) A menos que as suas páginas estejam utilizando o <code>application/xhtml+xml</code>, as páginas que você chama de “<abbr>XHTML</abbr>” é <abbr>XML</abbr> apenas no nome.
<p class=a>❧
<h2 id=webapps-cdf>Uma visão Concorrente</h2>
<p>Em junho de 2004, o W3C realizou o <a href=http://www.w3.org/2004/04/webapps-cdf-ws/><span lang="en">Workshop</span> sobre Aplicações Web e Documentos Combinados</a>. Estavam presentes nesse <span lang="en">workshop</span> representantes de 3 fabricantes de <span lang="en">browsers</span>, companhias de desenvolvimento web e outros membros do W3C. Um grupo de partes interessadas, incluindo a Fundação <span lang="en">Mozilla</span> e a <span lang="en">Opera Software</span>, fizeram uma apresentação sobre sua visão concorrente do futuro da web: <a href=http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html>uma evolução do existente padrão <abbr>HTML</abbr> 4 para incluir novos recursos para desenvolvedores de aplicativos web modernos</a>.
<blockquote cite=http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html>
<p>Os 7 princípios a seguir representam o que acreditamos serem os requisitos mais importantes para este trabalho.
<dl>
<dt>Compatibilidade com versões anteriores, com um caminho claro de migração</dt>
<dd>Tecnologias de aplicação web devem ser baseadas em tecnologias em que os desenvolvedores estão familiarizados, incluindo HTML, CSS, DOM e JavaScript.</dd>
<dd>Características básicas de aplicativos web devem ser implementáveis através de comportamentos e se utilizando scripts e folhas de estilo em IE6 hoje para que os autores tenham um caminho claro de migração. Qualquer solução que não possa ser usada com o atual agente de usuário (<span lang="en">user agent</span>) de maior penetração no mercado, sem a necessidade de <span lang="en">plugins</span> binários, é altamente improvável de ser bem sucedida.</dd>
<dt>Tratamento de erro bem definido</dt>
<dd>O tratamento de erros em aplicações web deve ser definido em um tal nível de detalhe que permita que os agentes de usuário não tenham que bolar seus próprios mecanismos de manipulação de erros ou fazer engenharia reversa em outros agentes de usuário.<dd>
<dt>Usuários não devem ser expostos a erros de autoria</dt>
<dd>Especificações devem indicar o comportamento exato de recuperação de erros para cada cenário de erro possível. A manipulação de erro deve ser definida, na maior parte, em termos de recuperação de erro normal (como em CSS) ao invés de erros óbvios e catastróficos (como em XML).</dd>
<dt>Uso prático</dt>
<dd>Todo recurso que entra em especificações de aplicações web deve ser justificado por um caso de uso prático. O inverso não é, necessariamente, verdadeiro: cada caso de uso, não necessariamente, precisa ser o fundamento para um novo recurso.</dd>
<dd>Os casos de uso devem ser, preferencialmente, baseados em <span lang="en">sites</span> reais, nos quais os desenvolvedores utilizaram, anteriormente, uma solução ruim para contornar a limitação.</dd>
<dt><span lang="en">Scripting</span> veio pra ficar</dt>
<dd>Mas deve ser evitado onde marcação mais convenientemente declarativa puder ser usada.</dd>
<dd><span lang="en">Scripting</span> deve ser dispositiva e representativamente neutro, a não ser quando em um escopo bastante específico de dispositivos (por exemplo, a menos que incluso em XBL).</dd>
<dt><span lang="en">Profiling</span> específico de dispositivo deve ser evitado</dt>
<dd>Desenvolvedores devem ser capazes de se valer das mesmas características, sejam elas implementadas em versões <span lang="en">desktop</span> ou móveis do mesmo agente de usuário.</dd>
<dt>Processo aberto</dt>
<dd>A <span lang="en">web</span> foi beneficiada por ter sido desenvolvida num ambiente aberto. Aplicações <span lang="en">web</span> serão o <em><span lang="en">core</span></em> da <span lang="en">web</span> e seu desenvolvimento também deve se valer desse ambiente aberto. Listas de discussão, arquivos e rascunhos das especificações devem estar visíveis ao público.</dd>
</dl>
</blockquote>
<p>Os participantes do <span lang="en">workshop</span> participaram de uma enquete com a pergunta “Deve o W3C desenvolver uma extensão declarativa para HTML e CSS e extensões imperativas para o DOM para tratar do nível médio de requisitos de aplicativos <span lang="en">web</span>, ao contrário das APIs maduras a nível de sistemas operacionais? (proposto por <span lang="en">Ian Hickson</span>, da <span lang="en">Opera Software</span>)”. A votação foi de 11 contra 8. No <a href=http://www.w3.org/2004/04/webapps-cdf-ws/summary>sumário do <span lang="en">workshop</span></a>, o W3C escreveu: “Atualmente, o W3C não pretende colocar quaisquer recursos no terceiro tópico da enquete: extensões para HTML e CSS para aplicativos <span lang="en">web</span>, exceto tecnologias que estão sendo desenvolvidos sob a licença dos atuais Grupos de Trabalho do W3C.”
<p>Ante essa decisão, as pessoas que tinham propostas envolvendo <abbr>HTML</abbr> e formulários <abbr>HTML</abbr> tinham somente duas opções: desistir ou continuar seu trabalho fora do W3C. Eles escolheram a última e registraram o domínio <a href=http://www.whatwg.org/><code>whatwg.org</code></a> e, em junho de 2004, o <a href=http://www.whatwg.org/news/start><span lang="en"><abbr>WHAT</abbr> Working Group</span></a> nasceu.
<p class=a>❧
<h2 id=whatwg><span lang="en">WHAT Working Group</span>?</h2>
<p class=ss><img src=i/openclipart.org_johnny_automatic_big_sandwich.png width=182 height=523 alt="sanduíche grande">
<p>Mas que diabos, afinal, é o <span lang="en"><abbr>WHAT</abbr> Working Group</span>? <a href=http://www.whatwg.org/news/start>Vamos deixá-los explicar</a>:
<blockquote cite=http://www.whatwg.org/news/start>
<p>O <span lang="en">Web Hypertext Applications Technology Working Group</span> é um grupo amplo, não oficial e aberto de fabricantes de navegadores web e partes interessadas. O grupo visa desenvolver especificações baseadas em tecnologias <abbr>HTML</abbr> e afins para facilitar o desenvolvimento de aplicativos web interoperáveis, com a intenção de submeter os resultados a uma organização de padrões. Esta submissão, então, constitui a base de trabalho em formalmente estender o <abbr>HTML</abbr> no caminho dos padrões web.
<p>A criação deste fórum decorre de vários meses de trabalho por e-mail, particularmente sobre as especificações de tais tecnologias. O foco principal, até este ponto, tem sido estender o <abbr>HTML4</abbr> <span lang="en">Forms</span> para suportar as características solicitadas pelos autores sem quebrar a compatibilidade com o conteúdo existente. Este grupo foi criado para garantir que o desenvolvimento futuro dessas especificações será completamente aberto, através de uma lista de discussão aberta publicamente arquivada.
</blockquote>
<p>A frase-chave aqui é “sem quebrar compatibilidade com versões anteriores”. <abbr>XHTML</abbr> (menos o "furo" do apêndice C) não é retrocompatível com <abbr>HTML</abbr>. Ele precisa de um tipo de <abbr>MIME</abbr> inteiramente novo e trabalha com tratamento de erros draconianos para todo o conteúdo servido com aquele tipo de <abbr>MIME</abbr>. <span lang="en">XForms</span> não é retrocompatível com formulários <abbr>HTML</abbr> porque pode ser usado apenas em documentos disponibilizados com o novo tipo de <abbr>MIME</abbr> <abbr>XHTML</abbr>, o que significa que <span lang="en">XForms</span> também funciona com tratamento de erros de forma draconiana. Todos os caminhos levam ao <abbr>MIME</abbr>.
<p>Ao invés de acabar com mais de 1 década de investimentos em <abbr>HTML</abbr> e fazer com que 99% das páginas da web existentes fiquem inutilizáveis, o <span lang="en"><abbr>WHAT</abbr> Working Group</span> optou por uma abordagem diferente: documentar os algoritmos de tratamento de erros "perdoáveis" que os navegadores, efetivamente, utilizam. <span lang="en">Web browsers</span> sempre foram indulgentes com erros de <abbr>HTML</abbr>, mas ninguém jamais se preocupou em escrever sobre como, exatamente, eles fizeram isso. <span lang="en">NCSA Mosaic</span> teve seus próprios algoritmos para lidar com páginas quebradas e a <span lang="en">Netscape</span> tentou o mesmo. Então, o <span lang="en">Internet Explorer</span> tentou se igualar ao <span lang="en">Netscape</span>. Em seguida, o <span lang="en">Opera</span> e o <span lang="en">Firefox</span> tentaram fazer a mesma coisa que o <span lang="en">Internet Explorer</span>. Daí, o <span lang="en">Safari</span> tentou se igualar ao <span lang="en">Firefox</span>. E assim por diante, até os dias de hoje. Ao longo do caminho, os desenvolvedores queimaram milhares e milhares de horas tentando tornar seus produtos compatíveis com os de seus concorrentes.
<p>Se isso soa como uma quantidade insana de trabalho, é porque, realmente, é. Ou melhor, era. Demorou 5 anos, mas (exceto por alguns casos obscuros extremos) o <span lang="en"><abbr>WHAT</abbr> Working Group</span> tem documentado com sucesso <a href=http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html>como analisar <abbr>HTML</abbr></a> de uma maneira que seja compatível com o conteúdo web já existente. Em nenhum ponto do algoritmo final há um passo que exija que o consumidor de <abbr>HTML</abbr> deva parar o processamento a fim de exibir uma mensagem de erro para o usuário final.
<p>Enquanto toda a engenharia reversa estava acontecendo, o <span lang="en"><abbr>WHAT</abbr> Working Group</span> foi, calmamente, trabalhando em algumas outras coisas, também. Uma delas era uma especificação, inicialmente apelidada <a href=http://www.whatwg.org/specs/web-forms/current-work/><span lang="en">Web Forms</span> 2.0</a>, que adicionou novos tipos de controles aos formulários <abbr>HTML</abbr>. (Você aprenderá mais sobre formulários web em <a href=forms.html>Uma Forma De Loucura</a>.) Outra foi um rascunho de uma especificação chamada "<span lang="en">Web Applications</span> 1.0", que incluía grandes novidades, tais como uma <a href="canvas.html">tela para desenhar canvas diretamente</a> e <a href="video.html">suporte nativo para áudio e vídeo, sem <span lang="en">plugins</span></a>.
<p class=a>❧
<h2 id=reinventing-html>De volta ao 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="gato e cachorro segurando um guarda-chuva">
<p>Por dois anos e meio, o W3C e o <span lang="en"><abbr>WHAT</abbr> Working Group</span> se ignoraram mutuamente. Enquanto o <span lang="en"><abbr>WHAT</abbr> Working Group</span> focou em formulários web e novos recursos de <abbr>HTML</abbr>, o W3C <abbr>HTML</abbr> <span lang="en">Working Group</span> estava ocupado com a versão 2.0 do <abbr>XHTML</abbr>. Mas, em outubro de 2006, ficou claro que o <span lang="en"><abbr>WHAT</abbr> Working Group</span> teve seu momento crítico, enquanto o <abbr>XHTML</abbr> 2 ainda estava definhando em forma de rascunho, não implementado por nenhum navegador principal. Em outubro de 2006, <span lang="en">Tim Berners-Lee</span>, o fundador da W3C, em pessoa, <a href=http://dig.csail.mit.edu/breadcrumbs/node/166>anunciou que o W3C poderia trabalhar em conjunto com o <span lang="en"><abbr>WHAT</abbr> Working Group</span></a> a fim de evoluir o <abbr>HTML</abbr>.
<blockquote cite=http://dig.csail.mit.edu/breadcrumbs/node/166>
<p>Algumas coisas ficaram mais claras com o passar dos anos. É necessário evoluir o <abbr>HTML</abbr> de forma incremental. A tentativa de fazer o mundo mudar para <abbr>XML</abbr>, incluindo aspas em torno de valores de atributos e barras em tags vazias e namespaces, de uma só vez, não funcionou. O grande público gerador de <abbr>HTML</abbr> não se moveu, em grande parte porque os navegadores não reclamaram. Algumas grandes comunidades fizeram mudanças e estão colhendo os frutos de sistemas bem-formados, mas não todos. Isso é importante para manter a <abbr>HTML</abbr> de forma incremental, bem como continuar a transição para um mundo bem-formado e desenvolver mais poder nesse mundo.
<p>O plano é constituir um grupo completamente novo de <abbr>HTML</abbr>. Ao contrário do anterior, este será fretado para fazer melhorias incrementais na <abbr>HTML</abbr>, bem como em <abbr>XHTML</abbr>, paralelamente. Ele terá uma cadeira e pessoal diferentes. Ele irá funcionar em <abbr>HTML</abbr> e <abbr>XHTML</abbr> em conjunto. Temos um forte apoio para esse grupo, a partir de muitas pessoas que falaram com, incluindo os fabricantes de <span lang="en">browsers</span>.
<p>Haverá trabalho, também, em formulários. Esta é uma área complexa, já que existem formulários tanto em <abbr>HTML</abbr>, quanto em <span lang="en">XForms</span>. Formulários <abbr>HTML</abbr> são ubiquamente implementados e existem muitas implementações e usuários de <span lang="en">XForms</span>. Enquanto isso, a apresentação de Webforms sugeriu extensões sensatas para formulários <abbr>HTML</abbr>. O plano é, informada pela Webforms, de estender formulários <abbr>HTML</abbr>.
</blockquote>
<p>Uma das primeiras coisas que o recém re-formado W3C <abbr>HTML</abbr> <span lang="en">Working Group</span> decidiu mudar é o nome de "<span lang="en">Web Applications</span> 1.0" para "<abbr>HTML5</abbr>". E aqui estamos nós, mergulhando em <abbr>HTML5</abbr>.
<p class=a>❧
<h2 id=postscript><span lang="en">Postscript</span></h2>
<p>Em outubro de 2009, o W3C <a href=http://www.w3.org/News/2009#item119>descontinuou o Grupo de Trabalho de <abbr>XHTML</abbr> 2</a> e <a href=http://www.w3.org/2009/06/xhtml-faq.html>emitiu esse comunicado para explicar sua decisão</a>:
<blockquote cite=http://www.w3.org/2009/06/xhtml-faq.html>
<p>Quando o W3C anunciou os Grupos de Trabalho de <abbr>HTML</abbr> e <abbr>XHTML</abbr> 2 em março de 2007, indicamos que iríamos continuar a acompanhar o mercado de <abbr>XHTML</abbr> 2. O W3C reconhece a importância de um sinal claro à comunidade sobre o futuro do <abbr>HTML</abbr>.
<p>Embora reconheçamos o valor do Grupo de Trabalho do <abbr>XHTML</abbr> 2 ao longo dos anos, após discussão com os participantes, a gestão W3C optou por permitir a expiração do Grupo de Trabalho no fim de 2009 e não renová-lo.
</blockquote>
<p>Os que ganham são aqueles a bordo.
<p class=a>❧
<h2 id=further-reading>Leitura complementar</h2>
<ul>
<li><a href=http://hixie.ch/commentary/web/history>A História da Web</a>, um projeto antigo de <span lang="en">Ian Hickson</span>
<li><a href=http://esw.w3.org/topic/HTML/history><abbr>HTML</abbr>/História</a>, de <span lang="en">Michael Smith</span>, <span lang="en">Henri Sivonen</span> e outros
<li><a href=http://www.atendesigngroup.com/blog/brief-history-of-html>Uma Breve História do <abbr>HTML</abbr></a>, de <span lang="en">Scott Reynen</span>
</ul>
<p class=a>❧
<p>Este foi o "Como chegamos aqui?". Consulte o <a href=table-of-contents.html>Sumário</a>, caso queira continuar com a leitura.
<div class="pf">
<h4>Você sabia?</h4>
<div class="moneybags">
<blockquote><p>Em associação a <span lang="en">Google Press</span>, O’Reilly está distribuindo este livro em variados formatos, incluindo papel, ePub, Mobi, <abbr>DRM</abbr>-free e <abbr>PDF</abbr>. A edição paga é chamada <span lang="en">“HTML5: Up & Running”</span> e está disponível agora. Este capítulo está incluído na versão paga.
</p><p>Se você gostou deste capítulo e quer mostrar sua apreciação, basta <a href="http://www.amazon.com/HTML5-Up-Running-Mark-Pilgrim/dp/0596806027?ie=UTF8&tag=diveintomark-20&creativeASIN=0596806027">comprar o livro “<abbr>HTML5</abbr>: Up & Running” com esse link afiliado</a> ou <a href="http://oreilly.com/catalog/9780596806033">comprar a edição eletrônica diretamente da O’Reilly</a>. Você vai ganhar um livro, e eu vou ganhar um trocado. Atualmente, não aceito doações diretas.
</p></blockquote>
</div>
</div>
<p class=c>Copyright MMIX–MMXI <a href=about.html><span lang="en">Mark Pilgrim</span></a>
<form action=https://www.google.com/cse><div><input type=hidden name=cx value=014437924039265546826:2nmoshc8y3y><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>
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-4114546-27', 'auto');
ga('send', 'pageview');
</script>
</html>