Recentemente, o debate entre layout CSS e layout de tabela surgiu novamente na Internet. Fiquei bastante insatisfeito no início: pensei que o significado do layout CSS estivesse profundamente enraizado no coração das pessoas, mas não esperava que tantos designers e desenvolvedores ainda discordassem.
Depois de me acalmar e observar a discussão de todos, depois de pensar bem, sinto que os motivos podem ser de dois aspectos:
- Por um lado, a presença persistente do IE6 mantém altos os custos de desenvolvimento da Web. Era uma vez uma estatística na Internet e os dados mostravam que a proporção de entrada/saída dos desenvolvedores da Web para o IE6 era a mais baixa. Acredito que a maioria dos engenheiros front-end já passou pela experiência de ser torturado pelo IE6. Em vez de usar o layout CSS, que é tão doloroso, é mais fácil e conveniente usar a tabela.
- Por outro lado, acho que os engenheiros front-end estão se tornando mais pragmáticos e focados na eficiência. Muitos novos recursos do CSS2 e CSS3 não foram amplamente popularizados, e as vantagens do CSS comentadas pelos evangelistas dos padrões da Web muitas vezes encontram compromissos quando implementadas na realidade. Embora eu sempre tenha me comprometido em evangelizar os padrões da Web, tenho que concordar: a compatibilidade do navegador da tabela é a melhor; o layout da tabela é mais fácil de ser usado pelos designers; No que diz respeito ao ambiente nacional, o corte de mesa ainda é a forma mais comum de criação de tópicos de sites de portais ou páginas de promoção de sites de e-commerce, e a sua existência tem a sua racionalidade.
Portanto, embora admiremos o layout CSS, não precisamos desvalorizar a tabela em si para provar sua superioridade. No desenvolvimento diário, não há necessidade de abandonar radicalmente as tabelas. A tabela em si possui semântica, e
deve ser usado ao exibir tabelas de dados no processo de desenvolvimento, não é uma má ideia usar tabela + layout css em algumas situações onde o custo precisa ser ponderado; Nesse sentido, admiro a abordagem pragmática dos engenheiros front-end do Google e do Facebook. Você pode prestar atenção na caixa de diálogo pop-up comum com sombra translúcida no Facebook, que é feita usando , que também é muito requintada. Este debate, combinado com o desenvolvimento de padrões Web nos últimos anos, fez-me pensar sobre a diferença entre melhoria e reforma no desenvolvimento Web.
O XHTML 2 tenta evoluir diretamente para XML, anunciando uma ruptura com o HTML. Isso costumava me assustar, um desenvolvedor HTML tradicional. E quando vi a organização WHATWG propor o HTML5 (que acabou sendo reconhecido pelo W3C), suas pequenas melhorias me fizeram sentir muito mais cordial. Os fatos também provaram que o HTML5 está se aproximando de nós. Douglas Crockford até sentiu que o HTML5 era muito violento e propôs um plano de melhoria para o HTML 4.2.
Olhando para o JavaScript novamente, o ECMAScript 4 mudou drasticamente o JavaScript. Felizmente, o comitê técnico voltou a raciocinar no estágio final, e o recém-proposto ESMAScript 3.1 compatível com versões anteriores foi obviamente reconhecido por mais desenvolvedores que estão realmente lutando na linha de frente.
A melhoria, em vez da reforma sangrenta, pode ser uma forma mais prática e razoável de promover o desenvolvimento tecnológico. Isto é verdade para a evolução dos padrões da web, a atualização de produtos ou projetos e até mesmo a construção de sistemas sociais.
Texto original: http://ued.taobao.com/blog/2009/06/24/web_dev_improve/
