Pages :
(reprise du message précédent)

clb56 a écrit :


Cet argument n'a strictement aucune valeur !

La question de l'inactivité de javascript est celle de l'accès au contenu et rien d'autre.


Pour celui qui peut y acceder, le graphisme est une sorte de contenu. Si on peut le préserver sans JS, je ne voit pas l'interet de passer par JS....
a écrit :
Pour celui qui peut y acceder, le graphisme est une sorte de contenu. Si on peut le préserver sans JS, je ne voit pas l'interet de passer par JS....


Quand tu vois toutes les limitations que tu as quand tu navigue sans javascript (en plus j'ai vraiment rarement vu ça, même au fin fond de la campagne) que ceux qui n'ont pas js voient mes coins carrés je t'avoue que ça ne me pose aucun probléme de conscience
Administrateur
Hello,

Petit HS en passant...

Pour vraiment passer un bon week-end, voici tout ce qui se fait actuellement en terme de coins arrondis.

Amusez-vous bien Smiley smile

- http://forum.alsacreations.com/faq/#item73
- http://articles.e-t172.net/round/
- http://css-discuss.incutio.com/?page=RoundedCorners
- http://www.smileycat.com/miaow/archives/000044.html (la totale)

Cela dit, je suis plutôt de l'avis de clb56 : pourquoi faire semblant d'avoir une code HTML simple et court alors que finalement ce ne sera pas le cas dans le navigateurs ?
Je préfère effectivement allourdir directement le HTML plutôt que d'utiliser une fonction JS lourde qui va de toute façon m'allourdir le HTML au final.
Cela ne signifie pas que JS me gêne pour ce genre de chose. Je le trouve parfaitement adapté car il s'agit bien d'un apport de fignolage graphique et non de contenu... mais si ce JS contribue à générer du HTML et des imbrications de div, je ne vois pas vraiment l'utilité.

Si seulement IE pouvait comprendre les pseudo-éléments :before et :after, ou :first-child et :last-child, le problème serait en grande partie réglé.
Modifié par Raphael (10 Nov 2006 - 13:58)
a écrit :
Si seulement IE pouvait comprendre les pseudo-éléments :before et :after, ou :first-child et :last-child, le problème serait en grande partie réglé.


ça c'est sur!, en attendant il nous reste quelque année à batailler pour notre ami IE6. Une solution qui est pas mal c'est d'utiliser les bonnes solutions sur les navigateur qui les implémentent, et pour les autres utiliser des commentaires conditionnel

Comme je suis coriace et que je continue à penser que ma solution est valabe, je vous est mit une page de test plus convaincante que la premiére

http://www.smart-com.com.mx/Des-coins-arrondis-avec-les-css-et.html

a écrit :
Je préfère effectivement allourdir directement le HTML plutôt que d'utiliser une fonction JS lourde qui va de toute façon m'allourdir le HTML au final.

Perso je pense le contraire (en plus la fonction ne fait même pas un kilo), avoir un html clair ça a plein d'avantage:
Facile à maintenir, facile à lire, et surtout facile à modifier

Par exemple dans l'exemple suivant, je me contente de modifier la position ou la taille de mes blocks "box" et de mettre mon "rounded" dedans. C'est vraiment simple.

Et le css aussi, ".box1 .tl" par exemple pour le premier coin de la premiére boite, on ne peut pas se tromper.

Enfin ça marche aussi pour des span ce qui permet de faire la même chose pour des liens, des paragraphes, ou d'autres balises.

Dernier avantage et je m'arrête là, mettre cinq divs (ce qui devient vraiment lourd en html), ça permet de mettre des bords à votre boite (voir le troisiéme exemple) pour ne pas avoir à charger une image de 1200px de haut (pour un ombrage par exemple).
Modifié par matmat (12 Nov 2006 - 03:04)
Une chose que je n'avais pas considéré: il doit être possible, en combinant la méthode css du contenu généré d'une part, et la méthode js d'une autre pour IE5 et 6 (avec des commentaires conditionnels) d'obtenir un mix plutot satisfaisant....A méditer
a écrit :
Une chose que je n'avais pas considéré: il doit être possible, en combinant la méthode css du contenu généré d'une part, et la méthode js d'une autre pour IE5 et 6 (avec des commentaires conditionnels) d'obtenir un mix plutot satisfaisant....A méditer


ça doit effectivement un bon mix, j'avais essayer avec moz_radius et niftycube pour IE dans le même esprit et c'est pas mal aussi. Mais avec cette méthode plus les pseudo class, là c'est clair, ce serait vraiment top.
coccimaster a écrit :
Une chose que je n'avais pas considéré: il doit être possible, en combinant la méthode css du contenu généré d'une part, et la méthode js d'une autre pour IE5 et 6


IE7 ne reconnait pas les pseudos classes before et after.
matmat a écrit :
pour ne pas avoir à charger une image de 1200px de haut (pour un ombrage par exemple).


Le problème des images à charger n'est pas leur taille (px) mais leur poids. Si elle sont légères alors elles sont légères.

De plus ce genre d'argument ne vaut que tant qu'il n'est pas contredit. Pense à ton histoire de liste sans titre.
clb56 a écrit :

<edit>
Ah et en plus pas de chance, si pour le malheur de ta structuration html il n'y a pas de titre annonçant ta section de menu alors c'est très très très simple !!! On met une class="first_element" au 1er item dudit menu !!!

comme quoi ya de la ressource...

Je l'ai déjà dit quelque part et je le répète : la divite est avant tout un oubli, quand ce n'est pas une négation complète, du document html réel.
</edit>


Car tu perçois bien j'espère que derrière tout ça il y a un document html avec toute ses ressources (pour les css notamment) et qu'il serait bon de ne pas l'oublier.
Modifié par clb56 (10 Nov 2006 - 20:49)
Une image de 1px par 6px pour un petit degradé d'ombre (voir le dernier exemple de la page) = 80 octets

Une image de 1200px par 6px pour un petit degradé d'ombre = 7kilos

et (voir l'avant dernier exemple) la possibilité de mettre un "border" = 3octets

a écrit :

Car tu perçois bien j'espère que derrière tout ça il y a un document html avec toute ses ressources (pour les css notamment) et qu'il serait bon de ne pas l'oublier.


Bein oui justement, et c'est pas toujours des listes, des fois c'est des paragraphes d'autre fois des liens. Même si c'est des listes, des fois on veut mettre une image d'un petit triangle qui change de couleur...

Tout ça pour dire que c'est pas toujours possible de trouver toutes les ressources necessaires dans le document html pour les css.

Par exemple pour faire un menu à onglets arrondis, ça marche bien tu mets un coin dans le lien, l'autre dans un span ( si tu veux un effet hover, sinon dans le 'li') et voilà. Mais dans d'autre cas c'est trop compliqué, si par exemple tu as le même cadre (ça m'est arrivé) pour un formulaire un encart, un menu, une gallerie... Dans ce cas vive le div class="rounded".
matmat a écrit :
et voilà. Mais dans d'autre cas c'est trop compliqué, si par exemple tu as le même cadre (ça m'est arrivé) pour un formulaire un encart, un menu, une gallerie... Dans ce cas vive le div class="rounded".


Envisager une mutitude de cas ingérables c'est effectivement très facile il suffit de chercher dans cette direction (imaginer un design infaisable). Assez souvent d'ailleurs on a ce genre de "défi" sur ce forum. Qu'on se fait un plaisir de résoudre en deux coup de cuillère à pot (toujours le menu sans titre) sans que cela ne serve à rien d'ailleur tant le défieur n'est que prêt à rester sur son quant à soi ou bien à inventer une nouvelle condition embarassante là où on pourrait en inventer 100.
a écrit :

si par exemple tu as le même cadre (ça m'est arrivé) pour un formulaire un encart, un menu, une gallerie...

Pas de code réel = aucune mise en oeuvre de css possible.
a écrit :

c'est pas toujours des listes, des fois c'est des paragraphes

ça revient exactement au même.

a écrit :

Dans ce cas vive le div class="rounded"

Y compris quand elles ne servent strictement à rien ???
Puisque c'est bien le sens, et le seul, de ma critique. Utiliser un dispositif lourd en production de html généré y compris pour tous les cas (et il seront nombreux) où ça ne sert à rien. pour en finir par ne plus rien comprendre comment tout celà pourrait très bien fonctionné sans ce type de dispositif.

Désolé de le dire mais si un débutant à le malheur de suivre ça, alors ça donnera un "idiot" en css et éventuellement aussi en html.
Je suis complétement d'accord avec toi sur le fond, quand il y les balises necessaires, autant les utliser.

Je vais essayer d'être un peu plus clair sur pourquoi j'utilise ce script, tout a commencé avec ce site (que j'ai modifié hier, en partit à l'aide de vos conseils)
http://www.smart-com.com.mx/sinuscenter/spip.php?lang=en

J'ai commencé a le coder avec ta méthode, c'est à dire le titre un coin, la liste un autre coin...etc. Cette méthode n' a pas tout résolut, j'ai donc du commencer a rajouter pas mal de balise en plus (surtout pour les cadres dans des cadres). Le truc c'est que dans ce site sur la colone de gauche il y des petits encarts, des fois c'est des menus, des fois images, d'autres fois, un formulaire de login, d'autre fois un message de bienvenue. Là c'est devenu encore plus compliquer, surtout au niveau du padding dans mes boites, je me retrouvai une fois sur deux avec un coin au milieu de ma boite. Quand ça fonctionnait pour les listes, ça ne fonctionnait plus pour les paragraphes, bref c'est devenu ingérable. Le fait que ce soit fait avec un cms ne m'aidait pas non plus. Je me suis donc résolu a faire des truc genre
<div class="tl"><div class="tr"><div class="bl"><div class="br">

j'aurait pu faire ça mais ça commencait a devenir problematiques quand il y deux cadres dans un troisiéme:
<div class="cadrerond"><div><div><div>

enfin bref, un des deux celons les cas, en fait j'exagére un peu des fois j'arrivais quand même à mettre un coin dans un titre ou dans un paragraphe.
J'en était là quand j'ai trouvé ma fameuse solution et qui m'a nettement simplifier la vie.
Ceci dit au final le site cumule les deux approches, par exemple pour le cadre principal les deux coins du haut sont dans les sous boites du contenu,et les deux coins du bas dans le footer. Le mini menu du haut c'est un jeux de listes. Par contre mes blocs utilisent le javascript.

Quel est le bilan au niveau du poid?
Effectivement les coins créent par le javascript apparaissent plus lentement que ceux dans le html, par contre la page se charge plus vite. ça a un coté asser logique, d'abord l'essentiel et ensuite les arrondis. Par contre un point négatif c'est que sur IE6, il a tendance à relancer le javascript au changement de page, ce qui fait un petit effet etrange d'"arrondissement", ce qui n'est pas le cas en pur css, moins en tout cas (avec IE6, les autres tout vat bien dans les deux cas).

Quel est le bilan au niveau maintenance?
En fait c'est surtout là, l'avantage du truc, si le site est un peu compliqué, ça évite de devoir reregler les css à chaque changement de fonction surtout si il y a different type de contenu dans le même style de bloc.

a écrit :
Désolé de le dire mais si un débutant à le malheur de suivre ça, alors ça donnera un "idiot" en css et éventuellement aussi en html.

C'est sur que de l'appliquer n'importe comment ça n'a aucun sens, dans 90% des cas c'est possible de trouver une solution sans, et rajouter une ou deux petite balises ça mange pas de pain. Dans mon cas sur le code brut de mes templates j'ai du en virer un centaines grâce à ça, je peu t'assurer que ça fait du bien, on y voit plus clair dans son travail.
Modifié par matmat (11 Nov 2006 - 08:46)
Salut,

a écrit :
Dans mon cas sur le code brut de mes templates j'ai du en virer un centaines grâce à ça, je peu t'assurer que ça fait du bien, on y voit plus clair dans son travail.

Et on parle de site tableless... Comment tu faisais avant ? Smiley cligne
Moi aussi je me suis fait une solution en JavaScript, pour plusieurs raisons. Déjà éviter de devoir découper l'image en coins, gérer pas seulement des coins mais des bordures complète, gérer le redimensionnement, et enfin le PNG-32 chez M. IE6... Ca fonctionne très bien, suffit d'appeller une fonction avec l'élément (ou un groupe d'élément), l'image et les coordonnées des coins et des bordures dans l'images. Et paf, tout est fait automatiquement...
a écrit :
et enfin le PNG-32 chez M. IE6

ça m'intrigue ton truc, ça permettrait de faire la même image avec l'antialiasing sur n'importe quel fond, ce qui serait super.

Pour les transparents jusque là j'utilisais ça, mais toute l'image et transparente, ce qui est different donc pour d'autre utilisation:

back\ground-color: transparent;
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src="image.png", sizingMethod="scale");

Pourrais tu mettre un exemple stp?
Modifié par matmat (11 Nov 2006 - 17:37)
matmat a écrit :
Moi aussi je me suis fait une solution en JavaScript

Laquel utilises tu?
Une solution faite maison Smiley smile Pas encore open-source Smiley lol Faut que j'y fasse des modifs et des optimisations...
Pages :