Vantagens e desvantagens do web standards

[Côcu]

Trio dos padrões WEB


Estrutura: HTML, XHTML, XML
Apresentação: CSS1, CSS2
Comportamento: ECMAScript, DOM


==================================


Características do método de transição apresentado no livro
(tabelas XHTML para layout e CSS p/ apresentação)


Vantagens:


- Garante exibição correta nos novos navegadores e aceitável nos da geração 4.0;
- Recomendado p/ sites que possuam muitos visitantes acessando com
navegadores 4.0;
- Segundo o autor, tática muito apropriada para muitos sites hoje;
- Recomendado nas ocasiões em que tabelas fazem melhor apresentação
layout que o CSS;
- Continuarão a funcionar em sites e dispositivos futuros;
- É uma preparação p/ transição para XML e CSS puro;
- Menos problemas de manutenção com a progressiva eliminação de tags
proprietárias;
- Maior acessibilidade;
- Simplicidade na marcação;


Desvantagens:


- Estrutura e apresentação ainda unidas;
- Maior dificuldade na transição para XML em sistemas de gerenciamento
de conteúdo baseados em XML;
- Dá mais trabalho e despesa que CSS puro p/ layout;


====================================



Características do método de compatibilidade estrita com versões futuras


- Separação total da estrutura e apresentação;
- Tabelas não são usadas para outros fins senão p/ aqueles aos quais
foram criadas;
- Ênfase na estrutura;
- Recomendado p/ qd o site não tiver um alto percentual de visitantes
com navegadores não-compatíveis (normalmente os da geração 4.0);


Benefícios:


- Compatibilidade com versões futuras;
- Alcança mais usuários;
- Geralmente torna-se acessível a todos;
- Elegância, simplicidade e lógica para as marcações;
- Produção e manutenção mais rápida, fácil e barata;
- Mais fácil de ser incorporado em publicações dinâmicas e sistemas de
gerenciamento de conteúdo voltados para modelos;


Desvantagens:


- Em navegadores mais antigos, visualização mais simples;
- Por causa do suporte imperfeito dos navegadores à CSS, ajustes podem
ser necessários;
- Algumas técnicas fáceis de serem conseguidas com tabelas HTML são
difícies ou impossíveis com layout CSS;
- Comportamentos baseados em DOM não funcionarão em navegadores
antigos ou em leitores de tela, navegadores de texto e na maioria dos
dispositivos sem fio. Será necessário uso das tags <noscript> e CGI
para esses dispositivos.


====================================


XHTML


- Tratar XHTML em termos estruturais e não em visuais;
- Evitar < br /> p/ simular elementos estruturais;
- Use elementos de lista para marcar listas;
- Prefira < strong > em vez de < b >, < em > em vez de < i >
- Usar nomes de identificação metaestruturais (nomes que explicam a
função desempenhada pelos elementos contidos dentro da estrutura)
- Se for possível arranjar-se sem o uso do DIV, através de cabeçalhos
e parágrafos comuns, tanto melhor;


Evitar 'classite' e 'divite'


- Não usar, por ex., < div id="text" > para parágrafos, nem < div
id="headline" > para cabeçalhos, pois para isso existem o < p > e o <
h1 >.


Link: The Global Structure of a html document:
http://www.w3.org/tr/rec-html40/struct/global.html


======================================


PRÓLOGO XML


A W3C recomenda começar qualquer documento XML (incluso XHTML)
especificando a versão XML e declarando o tipo de codificação de
caracter. ex:
<?xml version="1.0" encoding="iso-8859-1" ?>


Porém:
- Muitos navegadores não conseguem lidar com esse prólogo;
- É possível especificar a codificação através do elemento
Content-type no < head >.

--
.:côcu
..:projetos p/ internet
...:http://marcello.cocu.nom.br
»» visitem o site http://favelaeissoai.com.br

[Irapuan Martinez]

Côcu wrote:
> Estrutura: HTML, XHTML, XML

Eu fecho tudo isso no mesmo tupporware escrito "mark up".


> Apresentação: CSS1, CSS2

Eu creio que não é correto classificar o CSS em versão 1 e 2. Quando nos
referimos a CSS, estamos nos referindo ao último proposto pelo W3C, o
2.1. E a prática do W3C confere uma característica: O CSS 1 está contido
no CSS 2. O CSS 2 não é uma evolução. É uma adição. O browser
complacente a CSS 2 suporta CSS 1. Bom, duvido que me fiz claro :/


> Comportamento: ECMAScript, DOM

Script é uma coisa, DOM, outra. Assim como o trator é diferente da terra
que ele remove.

DOM declara o mark up como uma coleção de objetos, com endereço,
propriedades e conteúdo. Sendo que podem ser editados, criados ou
removidos. Isso assim, atravês de alguma aplicação. Pode ser ECMAScript,
uma fusão entre o Javascript da Sun e da Netscape com o Jscript da
Microsoft. Mas poderia ser VBScript, Actionscript (apenas dentro do SWF,
naturalmente), PHP, ASP, Perl, Cobol, Mumps, Fortram, C, Java, Assembly
e ETC (etc não é uma linguagem, é etecetera mesmo).

DOM pode ser manipulado tanto server side quanto client side. Claro que
para fazer o texto voar na cara do usuário, precisa de algo client side.
E para ampliar a compatibilidade, usar o script mais padronizado. O
ECMAScript.

> Desvantagens:
> - Em navegadores mais antigos, visualização mais simples;

Eu vejo justamente ao contrário. Um layout baseado em CSS funciona muito
bem numa gama maior de clients do que usuários da fatídica quarta
geração de navegadores.

Que todos acessem sem formatação então. Afinal, o que importa é o
conteúdo. Se o usuário implica com a falta de formatação, que atualize
ou migre para um sistema que atenda sua necessidade estética.

> - Por causa do suporte imperfeito dos navegadores à CSS, ajustes podem
> ser necessários;

Mas isso não é culpa dos web standards. É culpa dos fabricantes de
browsers, que não aplicaram o devido suporte por questões
administrativas e econômicas.

> - Algumas técnicas fáceis de serem conseguidas com tabelas HTML são
> difícies ou impossíveis com layout CSS;

E algumas várias coisas conseguidas com CSS são impossíves de serem
conseguidas com sopa de tags. Não me importo em perder a única
característica que web standards não tem em relação a sopa de tags - a
altura de um <td> puxar a de todos os seus vizinhos no mesmo <tr> - dada
a enorme gama de vantagens que um CSS introduz no documento.

> - Comportamentos baseados em DOM não funcionarão em navegadores
> antigos ou em leitores de tela, navegadores de texto e na maioria dos
> dispositivos sem fio. Será necessário uso das tags <noscript> e CGI
> para esses dispositivos.

Inventaram um nome para isso: Graceful degradation. Isso adiciona alguns
neurônios a mais no sacrifício ao deus Cliente, mas como disse no outro
e-mail, quanto mais se pratica, mais sorte se tem.

Gmail e Bloglines com suas complicadas interfaces, impossibilitados de
promover uma graceful degradation, tiveram que disponibilizar versões
alternativas, "light", para atender esse perfil de acesso.

> A W3C recomenda começar qualquer documento XML (incluso XHTML)
> especificando a versão XML e declarando o tipo de codificação de
> caracter. ex:
> <?xml version="1.0" encoding="iso-8859-1" ?>
> Porém:
> - Muitos navegadores não conseguem lidar com esse prólogo;

"Muitos" quem, cara-pálida? Que me lembre, é apenas o IE. O prólogo deve
vir antes do <!doctype> e o IE, ao detectá-lo, chaveia a renderização do
documento em transicional, mesmo com um seco XHTML 1.1 no <!doctype>.

> - É possível especificar a codificação através do elemento
> Content-type no < head >.

Essa questão do prólogo, do XHTML ser ao mesmo tempo HTML e XML rende
muita discussão. Por que uma coisa é um aquivo ASCII começar por <?xml>.
Outra diferente, ele ser servido e interpretado exatamente como XML.

HTML tem o mime/type setado como text/html. XML, usa application/xml.
XHTML deveria usar então application/xml+xhtml. Mas um browser, ao
detectar que o arquivo é "application", abre a caixa de diálogo de
download para baixar o mark up, ao invés de renderizá-lo.

Mas as coisas estão evoluindo e a tendência é esse problema ser
resolvido. CSS ou SWF já passaram por essa mesma questão de mime/type.
Hoje nem lembramos que o problema existe para eles.

[Márcio Sancho]

> > Comportamento: ECMAScript, DOM
>
> Script é uma coisa, DOM, outra. Assim como o trator é diferente da terra
> que ele remove.
>
> DOM declara o mark up como uma coleção de objetos, com endereço,
> propriedades e conteúdo. Sendo que podem ser editados, criados ou
> removidos. Isso assim, atravês de alguma aplicação. Pode ser ECMAScript,
> uma fusão entre o Javascript da Sun e da Netscape com o Jscript da
> Microsoft. Mas poderia ser VBScript, Actionscript (apenas dentro do SWF,
> naturalmente), PHP, ASP, Perl, Cobol, Mumps, Fortram, C, Java, Assembly
> e ETC (etc não é uma linguagem, é etecetera mesmo).

Essa do "ETC" foi hilária...kkkkkkkkkk
Valeu as elucidações irmão. A galera da lista agradece.


Márcio J. S. Sancho
"Abra sua mente..."

[Leandro Nunes]

Mto bom Ira, bem posicionado !!
Infelismente somos escravos da maior praga da internet imposta a força
nos desktops caseiros e/ou usuários "normais", porém é com esses que
devemos nos preocupar e é justamente aí que temos que arrumar tantas
alternativas para tentar sempre atender ao maior número possível de
usuários.

Seria utópico pensar nnum dia onde teremos apenas que nos preocupar
com deficientes físicos onde a necessidade para eles não foi escolha
e/ou algo imposto, mas sim consequência do destino? Conseguiremos
"driblar" as barreiras impostas por medidas totalmente capitalistas e
dominadora?

[]'s

--
Macromedia RuleZ, Google OwnS

Portfólio - http://www.dr1.com.br
Powered by: ISAT / DGL
http://www.DGL.com.br
http://www.ISAT.com.br

[Irapuan Martinez]

Leandro Nunes wrote:
> Infelismente somos escravos da maior praga da internet imposta a força
> nos desktops caseiros e/ou usuários "normais", porém é com esses que
> devemos nos preocupar e é justamente aí que temos que arrumar tantas
> alternativas para tentar sempre atender ao maior número possível de
> usuários.

Desenvolvemos para o IE por que ele é o mais usado? Mas daí nossos
códigos só funcionarão no IE e todo mundo será obrigado a usá-lo,
aumentando ainda mais o motivo para justificar os desenvolvedores se
preocuparem só com ele.

Monopólio é como o paradoxo de Tostines. Se retroalimenta. Mas alguma
hora precisamos parar de dar comida pra esse dinossauro.

Há meio termo? Há. Você tem que ceder em usar recursos tentadores para
compensar a deficiência do IE. Ou seja, você se restringe por que alguém
do outro lado do hemisfério não fez seu trabalho corretamente, ao criar
um browser.

> Seria utópico pensar nnum dia onde teremos apenas que nos preocupar
> com deficientes físicos onde a necessidade para eles não foi escolha
> e/ou algo imposto, mas sim consequência do destino? Conseguiremos
> "driblar" as barreiras impostas por medidas totalmente capitalistas e
> dominadora?

Primeiro, faça um favor aos portadores de necessidades especiais:
Esqueça deles. Esqueça deles, dos chineses, dos usuários do Lynx, dos
usuários do Netscape 1.2, dos que insistem em usar celular para navegar
na web. Você não precisa pensar neles. Cuide da complacência aos padrões
do seu código, que eles serão atendidos. Web standards foram feitos para
justamente isso, atender qualquer um independente de dispositivo.

Você tem em mãos uma belíssima e refinada tecnologia, proposta pelo W3C.
Aquilo é uma obra de arte de cunho social, se a gente viajar demais na
batatinha ao especular suas implicações.

E o fato do browser que monopolisa o mercado não ser complacente a esta
tecnologia, não é culpa desta última. Web standards abriu-se ao invés de
fechar-se sob rogoroso controle. Isso a curto prazo permitiu a
desastrosa guerra dos browsers. A longo prazo está se sedimentando como
a melhor maneira de se publicar informação no ambiente on line. Em
homenagem ao Diógenes, é como comparar com uma Harley Davidson: Arranca
devagar, mas depois que embala, run like hell.