Reprise du message précédent :

'tain ça m'énerve
je dis pas que vous avez tort loin de là, j'essaye juste de comprendre hein

Et pour moi c'est pas illogique qu'on puisse poser un block dans un inline... Enfin tu peux en tout cas définir un comportement que je trouve logique...
par exemple :

<inline><block />
<block />
<block /></inline><inline>....

Et ça m'énerve parceque je sais que vous êtes globalement pas des tanches sur ce genre de sujet, et que je devrais être d'accord

 
a ce moment autant garder qu'une seule balise : block

Ben c'est pas gênant que des élements aient un comportement par défaut qui puisse être différent, loin de là, donc non, ça je vois pas d'intérêt  

png alpha and background-position under IE6, I winnnnnnnnnnnnn \o/ \o/ \o/

Le contenu de ce message a été effacé par son auteur

sauf que si tu as regardé la question d'origine ( un hover sous IE6 ) , il faut que ce soit dans un a

 
tu es d'accord sur le comportement different des balises block et inline ?

ben oui

Si j'ai bien compris, il se demande pourquoi il est "interdit" de mettre un <div> (block) dans un <a> (inline) alors qu'il est autorisé de mettre un <span> dans un <a> en appliquant un "display: block" à ce <span>

+/- ouais, j'essaye de comprendre la logique derrière

c'est une regle de sémantique.
si tu avais que des éléments blocks dans ton site et que tu n'as pas la CSS, bonjour pour lire le site
et idem si c'etait l'inverse (que des éléments inline)

J'ai jamais voulu avoir que des blocks ou l'inverse
Et je sais que c'est une règle de sémantique. Des règles de sémantiques, y'a a plein de partout, certaines sont justifiés, d'autres sont arbitraires... La règle je la connais, c'est ce qu'il y a derrière qui m'intéresse.

Ben un block dans un inline, ça n'a aucun sens en soi, c'est un peu comme... une maison dans un chien ?

voila tout à fait

EDIT: ou de l'eau dans un bocal.
Un bocal a des dimensions, pas l'eau liquide. Analogie avec inline qui n'a pas de dimensions propres et block qui génère une boîte

On style du code HTML grâce à des instructions CSS.
On peut donc entre autres modifier le type de rendu par défaut d'un élément HTML de type block pour qu'il s'affiche comme un inline (ou table-cell si c'était supporté ou un très connu: display: none; ) mais sa nature profonde d'élément HTML, ça reste block;

structure != rendu

Si on pouvait pas modifier le type de rendu, on se mettrait à utiliser un élément HTML non pas parce que sémantiquement c'est celui qu'il faut à cet endroit-là mais parce qu'il aurait le bon type de rendu

Ben écoute... Si j'avais un chien sous la main, je t'aurais bien prouvé que t'as tort pour ton image telle que tu l'as définie
 
Bon c'est tard, je soutiens demain matin et j'ai pas bossé ma présentation, alors je reviendrai plus tard pour donner un exemple de logique fonctionnant (du moins pour moi) pour des blocks dans des inline

Mais alors le premier qui me parle de la tortue

ça fait vraiment pitié quand tu compare au marché des lettres de l'alphabet

Et quand certains passent 3 pages à optimiser leur requêtes sous MySQL c'est du dev web peut-être ?

Et un site qui s'affiche correctement dans tous les naviagteurs sans modification depuis bientot 10 ans. quel échec

Et pourtant, elle se meut

mod_rewrite is back

En fait à chaque fois que je crée une nouvelle page pour ce site, faut que je prévoie 3 jours en sus ma bite pour bricoler l'htaccess

Ben ouais
Et puis merde, on a plus le droit de pas être d'accord juste pour pas être d'accord ?

allez hop
une blague!
 

non, sauf si tu es d'accord avec moi

Want!

http://forum.hardware.fr/forum2.ph [...] 0#t1750815

HTML Block != CSS Block. Ils auraient dû différencier et utiliser d'autres termes.

parce-qu'il y a une différence entre ce que signifie une balise (sémantique) et le choix qu'on fait pour son affichage (cosmétique)?

Wha IE le sioux ! J'aurais jamais pensé que le fait de pas remplir l'attribut aurait pu avoir un impact tient !

C'est bon faut arrêter de s'exciter, c'est un pauv' test pour voir le comportement du a:hover

Souci étrange.
Je remplis via phpmyadmin des champs en UTF-8 (interclassement utf8_general_ci) avec Firefox (lui même en UTF-8), et pourtant lorsque j'affiche une page avec ces champs (la page est déclaré UTF-8), ben j'ai le droit aux bugs d'affichage (et si je passe FF en occidental, plus de souci d'affichage).
Et je comprends pas pourquoi
Si j'utilise des méthodes php pour remplir ma base, pas de souci, c bien rempli en UTF-8. Pourquoi avec phpmyadmin non
 
Qqun aurait il une idée ?

Idée à la con : quand t'as vérifié avec FF que la page était en UTF-8, t'as bien regardé les infos sur la frame où y'avait ton formulaire ? (et pas sur la frame globale)

Sauf qu'avec certains navigateurs et dans certains modes de rendu (me semble que FF en mode strict le fait parfois), le parseur corrige ton code moisi en:

<a href="">Link</a>
<div id="pouet"><a href="">pouet</a></div>
<a href=""></a>

Le formulaire de
Le formulaire que j'utilise pour remplir ma base c phpmyadmin
Et à part lui dire que les champs sont en UTF-8, je vois pas ce que je peux faire

<a href="">Link</a>
<div id="pouet"><a href="">pouet</a></div>
<a href=""></a>

Je m'en fout de "certains navigateur", on causait pour IE, faut arrêter d'extremisme de base pour se la peter genre moi je connais la norme xhtml par coeur, et le fonctionnement de tous les parseurs du monde
 
 
 
Tu fais pas tes test de dev en "spritant" tes images, en compressant le JS que tu met forcément pas inline mais dans un fichier à part ? Putain le naze !

Le formulaire de phpmyadmin dans la frame de phpmyadmin

Sauf que tu sais absolument pas comment e.g. le parser IE8 va se comporter dans les différents cas, quand tu testes tu essaies de créer un test sain

C'est pas un problème d'extrémisme, simplement de savoir ce qui se passe ou peut se passer et peut polluer des tests avec des problèmes sans rapports.

En l'occurence si
(et les JS dans un fichier à part aussi, js2-mode et nxhtml-mode se combinent mal)

Tient question de PHP :
On peut faire une sorte d'héritant "dynamique" ?
 
J'ai une classe B, et j'aimerais bien pouvoir instancier un objet de type B héritant un coup de A, un autre coup de A', etc.
 
En C++, c'est faisable facilement avec les templates, genre à l'arrache :

Ya moyen avec PHP de ruser et obtenir un truc du genre ?

eval ?

On voit ça comment ?  
Et si c déclaré en occidental, je fais comment pour changer ?

Clic-droit sur la frame où ya ton formulaire -> This Frame -> View Frame Info

Encodage: UTF-8
Merci mais ce n'est pas ça apparement
T'ain je comprends pas

Une fois que ta classe B est définie, comment tu fais avec ton eval pour pouvoir gérer tes deux objets B héritant de deux classes différentes ?

$class = 'A';

$b =  new $class('$parametre);

apres , pour la gestion , si tes objets n'heritent pas d'une classe commune ou n'implementent pas la meme interface, cas sert pas a grand chose