Un petit problème de Cellule.

(reprise du message précédent)

Hélas non, JJK801,
Ça ne fonctionne pas...

Le coup de mettre un "height: 1px" fonctionne très bien dans le cas d'une seule colonne avec deux cellules, comme sur l'exemple ci-dessous :




Mais dans mon cas précis de tableau à trois cellules, ça ne marche pas.
Je pense que c'est le "rowspan" qui est en cause.

j'ai fais le test avec un tableau a 3 cellules et de mon coté, ça fonctionne:

<table width="500" border="1">
  <tr>
    <td rowspan="2"><img src="image.jpg" width="286" height="400"></td>
    <td bgcolor="#408999">&nbsp;</td>
  </tr>
  <tr>
    <td bgcolor="#9a1208" style="height: 1px">Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam luctus faucibus varius. In hac habitasse platea dictumst.</td>
  </tr>
</table>

Edit: en effet, ça ne marche que sous FF...
Modifié par JJK801 (10 Jun 2012 - 22:38)

Bon ben ça marche… (sans table) comme ça:

http://dabblet.com/gist/2911280
Modifié par kustolovic (11 Jun 2012 - 19:00)

Ouai mais le problème c'est que si le texte n'est pas aligné tout en bas, on verra les cables aussi en bas...

tournikoti a écrit :
Et là, on est partie sur une solution avec un table qui n'est plus standard pour faire du positionnement.

Il ne s'agit pas de standards (les tableaux HTML font toujours partie du standard HTML5 par exemple), mais de bonnes pratiques. En effet les bonnes pratiques recommandent d'utiliser au maximum CSS pour la mise en page.

Sauf que dans le cas présent il est probable que les possibilités de CSS 2.1 soient un peu limitées pour réaliser cette mise en page précise, tandis qu'un tableau HTML avec un peu de CSS pourrait faire l'affaire. Et comme le pragmatisme a la priorité sur les bonnes pratiques théoriques, il peut arriver qu'on dise «bon ben vas-y fais un tableau de mise en page», oui.

Quelques points à noter:
- Il y a peut-être un coup à jouer avec du positionnement absolu.
- En CSS 2.1 on a display:table-cell qui peut rendre de fiers services. Sauf qu'ici on aurait besoin d'un rowspan, pas disponible en CSS.
- En CSS 3 on a deux candidats intéressants pour répondre à ce besoin de mise en page: Grid Layout et Flex Box. Pas assez aboutis pour être utilisables aujourd'hui.

J'avoue, étant un grand fan du :before :after dans mes intégration, j'y avais pas du tout pensé!

Chapeau l'artiste.

salut fvsch, merci pour ta réponse ! Désolé d'avoir confondu standard et bonne pratique. Je voulais dire qu'un <table> ne devais pas être utilisé pour ce genre de présentation que l'on doit réaliser en CSS. Sur ce point, je considère qu'il n'y a pas de compromis !

J'ai dû rater un chapitre car je n'arrive pas à comprendre comment vous passez d'un problème de présentation d'image et de texte à un menu ???

tournikoti a écrit :
Je voulais dire qu'un <table> ne devais pas être utilisé pour ce genre de présentation que l'on doit réaliser en CSS. Sur ce point, je considère qu'il n'y a pas de compromis !

Alors tu risques de te sentir un peu seul; tous les professionnels compétents que je connais estiment que le pragmatisme prime sur la pureté théorique.

tournikoti a écrit :
J'ai dû rater un chapitre car je n'arrive pas à comprendre comment vous passez d'un problème de présentation d'image et de texte à un menu ???

J'ai dû en rater un aussi parce que je ne vois de menu nulle part dans cette affaire.
Si tu parles du menu sur cette page, c'est le menu du site qui héberge ce service de test et visualisation de code HTML/CSS/JS (Dabblet, créé par Lea Verou). En dessous du menu tu devrais voir le rendu HTML d'un essai à base de code HTML et CSS et de deux images, et encore en dessous le code HTML et CSS correspondant.

fvsch a écrit :
Alors tu risques de te sentir un peu seul; tous les professionnels compétents que je connais estiment que le pragmatisme prime sur la pureté théorique.

Heureusement d'ailleurs, sinon la théorie n'évoluerai pas et on virai encore dans des cavernes

Je reviens sur le problème de cellule.

Effectivement, la solution de fvsch est absolument remarquable...!

Simplicité, efficacité. Génial.

Une petite remarque tout de même :

Les pseudos-classes ":after" ou ":before", ne sont-elles pas trop "récentes", ce qui pourrait provoquer des incompatibilités avec les 5 principaux navigateurs ?

href a écrit :
Les pseudos-classes &quot;:after&quot; ou &quot;:before&quot;, ne sont-elles pas trop &quot;récentes&quot;, ce qui pourrait provoquer des incompatibilités avec les 5 principaux navigateurs ?

Le dernier navigateur à les avoir supporté est IE en version 8 (début 2008). A part si tu dois supporter les 5% (ou moins) de parts de marcher de IE7, tu peux y aller sans problème.

Sur le respect des standards

Si l'on s'en tient à HTML, il y a deux «tests» possibles:

1. La validité de la syntaxe et du vocabulaire. Sur ce plan, les tableaux de mise en page sont tout aussi valides que les tableaux de données.

2. La conformité au standard, qui ne peut être évaluée strictement que via des outils tels que des suites de tests (automatisés ou non) aux critères précis, autrement dit des référentiels de conformité. Il n'y en a pas pour HTML. Bien sûr on peut toujours, en étant moins précis, lire le texte de la spécification et voir si elle interdit les tableaux de mise en page (via notamment des clauses strictes: MUST/MUST NOT), les déconseille simplement (SHOULD/SHOULD NOT), suggère d'autres solutions (MAY), ou ignorent cette problématique. Résultat des courses:
- HTML 4.01: Tables should not be used purely as a means to layout document content […]. Authors should use style sheets to control layout rather than tables.»
- HTML5: «Tables must not be used as layout aids. Historically, some Web authors have misused tables in HTML as a way to control their page layout. This usage is non-conforming […]»

Donc en HTML 4 (ou XHTML 1) il est possible d'utiliser des tableaux pour de la mise en page mais c'est déconseillé, et en HTML5 c'est interdit.

Sur la question du pragmatisme

Mais pour revenir à notre sujet, la conformité stricte à tout prix reste pour moi de la pureté théorique, par opposition à des décisions pragmatiques.

Les effets concrets des tableaux de mise en page sur l'accessibilité sont connus, et il y a des techniques pour éviter les problèmes de ce type (notamment éviter l'utilisation des attributs ou éléments typiques d'un tableau de données bien fichu).

Par ailleurs dans certains cas précis il se peut qu'un tableau de mise en page soit la solution la plus efficace, soit par nécessité de compatibilité avec de vieux navigateurs (IE7), soit parce qu'on a besoin d'utiliser des propriétés de mise en page des tableaux dont CSS 2.1 ne fournit pas l'équivalent (rowspan/colspan notamment).

Sur la question de la bidouille

Le contraire de la bidouille c'est savoir ce que tu fais, pourquoi tu le fais, quelles sont les conséquences principales. C'est aussi veiller à faire du code que d'autres personnes raisonnablement compétentes pourront comprendre, pour limiter les risques de création de bugs lors des maintenances et évolutions du code.

En l'occurrence ici la solution avec un tableau de mise en page est sensiblement plus claire et directe que celle que je propose à coup de double positionnement absolu et de pseudo-élément créé en CSS. Cette dernière est clairement plus haute sur l'échelle de la bidouille (qui est une échelle progressive et pas un un état binaire), et par ailleurs plus limitée car elle s'accommodera
moins bien voire pas du tout de problèmes tels qu'un texte trop long, une image trop petite ou pas chargée.

tournikoti a écrit :
Ce n'est pas parce qu'une solution proposé fonctionne qu'elle est automatiquement correcte.

Exactement. C'est bien pour ça que la solution que je proposais à base de positionnement absolu n'est sans doute pas bonne, même si intéressante à titre d'exercice.

href a écrit :
Effectivement, la solution de fvsch est absolument remarquable...!

C'est gentil mais en fait non, elle n'est pas terrible car pas robuste.
Modifié par fvsch (16 Jun 2012 - 16:00)

merci pour ces précisions fvsch ! Tes explications sont bien plus claires maintenant.

Une question tout de même : "Est-ce encore un tableau si tu utilises sous HTML 5 une encapsulation de balise <div>, dont en CSS, le display de chaque balise <div> est soit "display:table", "display:table-row" et "display:table-cell" ?"

Autrement dit : "est-ce autorisé ?"

Sinon, tu ne m'as pas répondu au sujet du hard copy de ce que j'obtiens chez moi ? Est-ce normal que j'ai un écran avec aucune image à l'intérieur ? N'aurais-je pas oublié de faire quelque chose ?
Modifié par tournikoti (16 Jun 2012 - 20:15)

fvsch a écrit :

href a écrit :
Effectivement, la solution de fvsch est absolument remarquable...!

C'est gentil mais en fait non, elle n'est pas terrible car pas robuste.

Aïe, ...dommage. C'était vraiment l'idéal.

Si je comprends bien, il va falloir que je revienne à ma solution du début de ce topic :
c'est à dire une <table> incluse dans une autre <table>. Ce n'est pas que ça soit gênant techniquement car ça fonctionne très bien sur tous les navigateurs, mais c'est juste... comment dirais-je... pas élégant.

Mais y'a t-il une élégance en HTML ?

href a écrit :
Si je comprends bien, il va falloir que je revienne à ma solution du début de ce topic :
c'est à dire une <table> incluse dans une autre <table>.

Euh non une seule TABLE (trois TD, un colspan).

Ou alors... (inspiration du moment)... combiner du display:table-cell (pour gérer les colonnes de même hauteur et l'alignement vertical) avec un élément ou pseudo-élément positionné en absolu (toujours dans l'optique où une image en background sur la colonne de droite n'est pas possible, ce qui n'est pas tout à fait certain). Ce qui donnerait:
http://dabblet.com/gist/2945450

Avantage sur la solution précédente: plus d'effets de bord du positionnement absolu en cas de texte trop long et/ou image trop petite ou manquante. C'est donc une solution robuste dans les navigateurs qui la supportent (a priori IE8+).

Soit (pour archive ici):

<figure>
  <div>
    <img src="..." alt="Description de l'image.">
  </div>
  <div>
    <figcaption>
      Du texte...
    </figcaption>
  </div>
</figure>

figure {
    display: table;
}
figure > div {
    display: table-cell;
    vertical-align: bottom;
    overflow: hidden;
}
figcaption {
    position: relative;
}
figcaption:before {
    content: "";
    position: absolute;
    top: -1000px;
    bottom: 100%;
    left: 40%;
    right: 40%;
    background: rgba(255,0,0,.5);
}

Modifié par fvsch (17 Jun 2012 - 21:07)

bonsoir,

j'arrive aprés la bataille et je suis surpris du choix du positionnement absolu ?

Inline-block ou display:table se suffisent , non ?

Faut-il ces bordures autour des 'cellules' ?

A ce que je comprend, je vois la chose comme ceci (inline-block).
http://dabblet.com/gist/2945466 avec l'overflow sur le contenu.

Ignorez moi si je suis a coté de la plaque .

++

gc-nomade a écrit :
A ce que je comprend, je vois la chose comme ceci (inline-block).
http://dabblet.com/gist/2945466 avec l'overflow sur le contenu.

Limites:
- max-height en dur;
- border-bottom opaque (le but est d'avoir ce décalage en gardant la transparence, et sans montrer d'image par dessous).

fvsch a écrit :

Limites:
- max-height en dur;
- border-bottom opaque (le but est d'avoir ce décalage en gardant la transparence, et sans montrer d'image par dessous).

Les bordures peuvent être compenser en marges, l'image relayé en fond dans un :before démesuré en absolu et la hauteur exprimé en % et inline-block conservé, ce qui rejoint fortement la demo en absolu. .

href a écrit :

• Le texte à droite (la cellule rouge), pourra représenter plus de la moitié de la hauteur de l'image de gauche. Jusqu'à 90% de cette hauteur dans certains cas. Si le contenu de cette cellule rouge devient trop important, il y aura un &quot;overflow:scroll&quot;.

En fait, le max-height s'impose
MAJ : http://dabblet.com/gist/2945466

Cordialement.
Modifié par gc-nomade (18 Jun 2012 - 15:34)