Récemment, le débat entre la disposition CSS et la disposition des tableaux a ressurgi sur Internet. Au début, j'étais assez insatisfait : je pensais que la signification de la mise en page CSS était profondément ancrée dans le cœur des gens, mais je ne m'attendais pas à ce qu'autant de concepteurs et de développeurs soient toujours en désaccord.
Après m'être calmé et avoir regardé la discussion de tout le monde, après y avoir bien réfléchi, j'ai l'impression que les raisons peuvent provenir de deux aspects :
- D'une part, la présence persistante d'IE6 maintient les coûts de développement Web élevés. Il existait autrefois une statistique sur Internet, et les données montraient que le ratio entrées/sorties des développeurs Web pour IE6 était le plus bas. Je crois que la plupart des ingénieurs front-end ont l'expérience d'être torturés par IE6. Au lieu d'utiliser la mise en page CSS qui est si pénible, il est plus facile et plus pratique d'utiliser un tableau.
- D’un autre côté, je trouve que les ingénieurs front-end deviennent plus pragmatiques et axés sur l’efficacité. De nombreuses nouvelles fonctionnalités de CSS2 et CSS3 n'ont pas été largement popularisées, et les avantages du CSS évoqués par les évangélistes des standards du Web se heurtent souvent à des compromis lorsqu'ils sont mis en œuvre dans la réalité. Même si j'ai toujours été déterminé à évangéliser les standards du Web, je dois être d'accord : la compatibilité avec les navigateurs de table est la meilleure ; la disposition des tableaux est plus facile à utiliser pour les concepteurs. En ce qui concerne l'environnement domestique, le découpage de table reste le moyen le plus courant de créer des sujets de sites Web de portail ou des pages de promotion de sites Web de commerce électronique, et son existence a sa rationalité.
Par conséquent, même si nous admirons la mise en page CSS, nous n’avons pas besoin de dévaloriser la table elle-même pour prouver sa supériorité. Dans le développement quotidien, il n’est pas nécessaire d’abandonner radicalement et complètement les tables. Le tableau lui-même a une sémantique et
doit être utilisé lors de l'affichage des tableaux de données ; dans le processus de développement, ce n'est pas une mauvaise idée d'utiliser la disposition table+css dans certaines situations où le coût doit être pris en compte. À cet égard, j'admire l'approche pragmatique des ingénieurs front-end de Google et Facebook. Vous pouvez prêter attention à la boîte de dialogue contextuelle commune avec une ombre translucide sur Facebook, créée à l'aide de , qui est également très exquise. Ce débat, combiné au développement des standards du Web ces dernières années, m'a fait réfléchir à la différence entre amélioration et réforme du développement Web.
XHTML 2 tente d'évoluer directement vers XML, annonçant une rupture avec HTML. Cela me faisait peur, moi qui suis un développeur HTML traditionnel. Et quand j'ai vu l'organisation WHATWG proposer HTML5 (qui a finalement été reconnu par le W3C), ses légères améliorations m'ont fait sentir beaucoup plus cordial. Les faits ont également prouvé que HTML5 se rapproche de nous. Douglas Crockford a même estimé que HTML5 était trop violent et a proposé un plan d'amélioration pour HTML 4.2.
En regardant à nouveau JavaScript, ECMAScript 4 a radicalement changé JavaScript. Heureusement, le comité technique est revenu à la raison dans la phase finale, et le nouveau ESMAScript 3.1 rétrocompatible proposé a évidemment été reconnu par davantage de développeurs qui se battent en première ligne.
L’amélioration, plutôt que la réforme sanglante, pourrait constituer un moyen plus pratique et plus raisonnable de promouvoir le développement technologique. Cela est vrai pour l’évolution des standards du web, la mise à niveau de produits ou de projets, ou encore la construction de systèmes sociaux.
Texte original : http://ued.taobao.com/blog/2009/06/24/web_dev_improve/