informatique et high-tech (les meilleures news) %) - Page 152

Oui, je suis d'accord, ils auraient dû prenre h264 comme codec par défaut mais theora Le codec de plus mauvaise qualité, sans implémentation matérielle et le moins supporté de tous les codecs

"de plus mauvaise qualité", c'est apparemment de moins en moins vrai

Flanker (./4529) :

Nil (./4500) :
En réalité, ce ne sont pas les *seules* différences... c'est vraiment au niveau conceptuel que ça se passe... le xhtml est vraiment fait pour faciliter l'analyse par une logique automatique alors que le html est fait pour décrire une production de la pensée. Il suffit de voir qu'il y a énormément de balises qu'on n'utilise plus en xhtml pour utiliser des balises génériques auxquelles on applique un style...

Ben typiquement, en xhtml, on préconise de ne pas utilise de retour chariot (<br />).

C'est une sorte d'exception, non ? plus pratique que de supprimer les marges entre deux paragraphes.

Il y a aussi <basefont>, <nobr>, <wbr>, ainsi que cette fâcheuse habitude de vouloir supprimer totalement les tableaux au profit de cadres (div ou span)...

C'est pas lié au XHTML, ça, mais plutôt à la volonté de séparer forme et fond pour des raisons d'accessibilité, non ?

euh la volonté de séparer forme et fond, ou plutôt structure/sémantique et présentation, a toujours été plus ou moins mal respectée mais elle a toujours été présente à un certain degré dans html toutes versions confondues il me semble.
En fait après la tendance qui avait consisté à ignorer cette séparation en utilisant des balises de présentation (genre font, br etc.) à la place de balises de structure (genre h1, p etc.) même quand en toute logique ces dernières auraient été les plus appropriées, on a eu avec les CSS une tendance, qui ne me semble pas meilleure, à utiliser des balises de pseudo-structure génériques sans sémantique (div, span) avec des styles différents plutôt que des balises de structure avec une sémantique spécifique (toujours h1, p etc.)

Alors ça a un avantage certain sur la situation précédente : on peut utiliser plusieurs feuilles de style différentes avec une même page, donc il y a bien dans une certaine mesure séparation entre structure et présentation. Mais le problème c'est que les classes utilisées ne sont pas standardisées et qu'elles n'ont pas de signification intrinsèque, et qu'elles sont souvent utilisées selon une logique de présentation et pas selon une logique de structure. Du coup souvent une page respectant en apparence cette « séparation » sera illisible sans la CSS qui va avec : le principe reste tout à fait dévoyé...

En particulier, est-ce que tu dis ça dans le vague ou est-ce que tu vois vraiment en quoi utiliser des éléments div et span, qui peuvent correspondre à absolument n'importe quoi et dont les différents usages sont seulement distingués par un nom de classe, qui n'est ni plus ni moins que la référence à un style, permet une meilleure séparation entre forme et fond que d'utiliser des éléments table, tr etc. ?

Bon, pas vraiment une « meilleure news » mais plutôt un « meilleur lien » , dans la doc officielle de l’outil Confluence :
http://confluence.arizona.edu/confluence/renderer/notationhelp.action?section=confluence#atlassian-macro-userlister

c'est juste pour bob@example.com ?

wow.

Sally (./4537) :
euh la volonté de séparer forme et fond, ou plutôt structure/sémantique et présentation, a toujours été plus ou moins mal respectée mais elle a toujours été présente à un certain degré dans html toutes versions confondues il me semble.

Certes, il y a toujours eu cette idée, mais elle n'était pas autant à la mode, c'est ce que je voulais dire (tout comme la mode de l'accessibilité)
En plus, elles sont de moins en moins utilisées en HTML comme en XHTML, et comme on peut toujours les utiliser en XHTML, cette perte n'est pas liée au XHTML ^^

En fait après la tendance qui avait consisté à ignorer cette séparation en utilisant des balises de présentation (genre font, br etc.) à la place de balises de structure (genre h1, p etc.) même quand en toute logique ces dernières auraient été les plus appropriées, on a eu avec les CSS une tendance, qui ne me semble pas meilleure, à utiliser des balises de pseudo-structure génériques sans sémantique (div, span) avec des styles différents plutôt que des balises de structure avec une sémantique spécifique (toujours h1, p etc.)

Alors ça a un avantage certain sur la situation précédente : on peut utiliser plusieurs feuilles de style différentes avec une même page, donc il y a bien dans une certaine mesure séparation entre structure et présentation. Mais le problème c'est que les classes utilisées ne sont pas standardisées et qu'elles n'ont pas de signification intrinsèque, et qu'elles sont souvent utilisées selon une logique de présentation et pas selon une logique de structure. Du coup souvent une page respectant en apparence cette « séparation » sera illisible sans la CSS qui va avec : le principe reste tout à fait dévoyé...

Avec HTML5, il y a de nouvelles structures pour la sémantique, il me semble

(j'ai édité pour rajouter un paragraphe)
Moui à propos de mode je ne sais pas trop. Enfin il y a eu un moment où la mode était de tout mélanger allègrement, je crois, effectivement, mais avant ça c'était plus rigoureux et après aussi, non ? d'ailleurs je sais pas si c'est vraiment un effet de « mode » à proprement parler, en fait à vue de nez je dirais :
— avant = quand le html était écrit à la main
— cette « mode » correspondrait à l'avènement des logiciels de création de pages qui génèrent du html tout pourri n'utilisant que les balises de présentation... sachant que des gens ont aussi pu s'initier au html en lisant le code source généré par ces trucs...
— ensuite elle passe quand on réagit contre le gros bordel que ça a foutu et qu'on se rend compte des problèmes que ça pose, et aussi avec l'amélioration des logiciels.

Par contre l'accessibilité me semble en effet être une nouvelle mode ^^

Sinon c'est très bien qu'il y ait de nouveaux éléments standards pour d'autres structures sémantiques, mais justement c'est aussi ce que disait Nil, il faudra les utiliser et ne pas se contenter d'éléments génériques avec des styles ^^

Sally (./4541) :
Moui à propos de mode je ne sais pas trop. Enfin il y a eu un moment où la mode était de tout mélanger allègrement, je crois, effectivement, mais avant ça c'était plus rigoureux et après aussi, non ? d'ailleurs je sais pas si c'est vraiment un effet de « mode » à proprement parler, en fait à vue de nez je dirais :
— avant = quand le html était écrit à la main
— cette « mode » correspondrait à l'avènement des logiciels de création de pages qui génèrent du html tout pourri n'utilisant que les balises de présentation... sachant que des gens ont aussi pu s'initier au html en lisant le code source généré par ces trucs...— ensuite elle passe quand on réagit contre le gros bordel que ça a foutu et qu'on se rend compte des problèmes que ça pose, et aussi avec l'amélioration des logiciels.

Certes, c'est pas mal lié aux logiciels (et maintenant, les logiciels utilisent des balises génériques, ça vient aussi de là )

Par contre l'accessibilité me semble en effet être une nouvelle mode ^^

Mais pas forcément mauvaise en soi

Sinon c'est très bien qu'il y ait de nouveaux éléments standards pour d'autres structures sémantiques, mais justement c'est aussi ce que disait Nil, il faudra les utiliser et ne pas se contenter d'éléments génériques avec des styles ^^

(mais du coup, je ne vois pas tellement le rapport entre XHTML et non-utilisation des balises sémantiques... au contraire, c'est 'achement plus simple de parser du XML avec des balises... Typiquement, quel dictionnaire en ligne utilise les balises prévues pour les définitions ? Alors que ça serait tellement plus simple à parser !

squalyl (./4539) :
c'est juste pour bob@example.com ?
wow.

Nan, c’est pour la liste complète des 3 utilisateurs mis en exemple.
Enfin après, si tu ne sais pas qu’« il s’appelait Robert Paulson », je ne peux rien faire d’autre que te rediriger vers la vidéothèque ou le torrent du coin .

(cf. fork)

Ce sujet a été coupé en 2 afin de séparer la discussion principale des posts ./4494 ./4495 ./4496 ./4497 ./4498 ./4499 ./4500 ./4501 ./4502 ./4503 ./4504 ./4505 ./4506 ./4507 ./4508 ./4509 ./4510 ./4511 ./4512 ./4513 ./4514 ./4529 ./4530 ./4531 ./4532 ./4533 ./4534 ./4535 ./4536 ./4537 ./4540 ./4541 ./4542 ./4544 . Pour vous rendre sur le nouveau sujet, merci de cliquer sur ce lien

./4513 et ./4514 ont été embarqués par erreur dans le panier à salade avec les autres  !

http://www.pcinpact.com/actu/news/51814-franck-riester-commission-affaires-culturelles.htm
On prend les mêmes et on recommence  !
L’Histoire est une éternelle répétition, paraît-il…

une éternelle répétition à fabriquer de l'inédit, ouais

http://www.gizmodo.fr/2009/07/07/gmail-sort-enfin-de-beta.html
Pas pressés chez google

http://www.clubic.com/actualite-286930-chrome-os-google-systeme-exploitation.html

Si le futur OS de Google tire son nom de ce navigateur, c'est qu'il occupera une place centrale au coeur du système, composé d'un simple noyau Linux auquel la firme de Mountain View greffera une interface utilisateur fenêtrée, et minimaliste.

Ça a l'air sérieux en plus

Ils vont garder le logo en forme de Pokéball ?

Enfin un Linux qui ne ressemble pas à Fedora ! y en a un qui doit enrager d'être kické

Chrome OS

et sur ton dossier perso, tu seras sur ton Chrome OS Home

Dommage que ça ne soit pas Chrone OS, ça aurait pu permettre pas mal de jeux de mots...

Cross, pas mal vince, pas mal

vince (./4555) :
et sur ton dossier perso, tu seras sur ton Chrome OS Home

Merde, trop tard, je voulais la faire

Joli vince ^^

edit http://bugbrother.blog.lemonde.fr/2009/07/08/les-internautes-ce-douloureux-probleme/#xtor=RSS-3208