28172 sujets

CSS et mise en forme, CSS3

[Résolu] Faire un retour à la ligne dans un h2

Bonjour,

sur un site en html pur, j'ai un pavé dans lequel j'écris un h2. Ce pavé faisant 400*400px, je voudrais optimiser l'écriture de mon titre en forçant un retour à la ligne.
Aujourd'hui j'ai :
Bénéficiez d'une
assistance

et je voudrais :
Bénéficiez
d'une assistance

Le but étant de faire ça proprement pour que ça marche sur mobile.
Comment puis-je faire ? Je me rappelle qu'il y avait un truc à mettre après "Bénéficiez" mais il me semble que ce n'était pas un br.
Merci pour votre aide et bonne soirée !
Bonsoir !

<br /> ou <br>, c'est très propre et c'est fait pour ça.

Il y a d'autres méthodes mais celle-là me parait la plus simple et la plus adaptée...

Smiley smile
Administrateur
Tu peux même tenter de "désactiver" le <br> sur grand écran :

@media (min-width: 543px) {
br {display: inline;
}

(Je n'ai pas testé mais ça me semble jouable)
Modérateur
@raphael ,
 display:none;
serait plus universel

Selon les navigateur le br est peu ou pas stylable dans le flux . 
position:absolute/fixed
... permettrait aussi de le mettre hors jeu .

Cdt.
Modifié par gcyrillus (28 Jul 2016 - 21:38)
Bonsoir,

Gcyrillus, je pense qu'en sortant le break-row du flux, il y a fort à parier que la seconde ligne vienne se juxtaposer à la fin de la première.

La solution de Raphaël permettrait très certainement de simuler un espace en le maintenant dans le flux mais en court-circuitant sa fonction primaire.

Dans ce genre de situation, lorsqu'il s'agit d'un texte fixe comme une étiquette, une marque ou un slogan, j'ai pris pour habitude d'utiliser des non-breakable spaces soit en les intégrant en lieu et place dans le code, soit en effectuant un tout bête remplacement côté serveur lorsque la données provient d'une Bdd.

<h2>Bénéficiez d'une<br>assistance</h2>
<!--


         devient


-->
<h2>Bénéficiez d'une&nbsp;assistance</h2>


Simple mais efficace ! Smiley biggrin
Modifié par Greg_Lumiere (28 Jul 2016 - 21:52)
Greg_Lumiere a écrit :
Dans ce genre de situation, lorsqu'il s'agit d'un texte fixe comme une étiquette, une marque ou un slogan, j'ai pris pour habitude d'utiliser des non-breakable spaces soit en les intégrant en lieu et place dans le code, soit en effectuant un tout bête remplacement côté serveur lorsque la données provient d'une Bdd.

&lt;h2&gt;Bénéficiez d'une&lt;br&gt;assistance&lt;/h2&gt;
&lt;!--


         devient


--&gt;
&lt;h2&gt;Bénéficiez d'une&amp;nbsp;assistance&lt;/h2&gt;


Simple mais efficace ! Smiley biggrin

Perso, j'utilise l'attribut CSS @white-space avec la valeur "nowrap"...
Modifié par sepecat (28 Jul 2016 - 21:58)
sepecat a écrit :

Perso, j'utilise l'attribut CSS @white-space avec la valeur "nowrap"...

Dans ce cas, comment faire dire à Css qu'on préfère une césure après "Bénéficiez" plutôt qu'après "une", quand il n'y vraiment pas la place de tout mettre ?
Greg_Lumiere a écrit :

Dans ce cas, comment faire dire à Css qu'on préfère une césure après "Bénéficiez" plutôt qu'après "une", quand il n'y vraiment pas la place de tout mettre ?

Attention... j'ai bien pris la peine d'isoler la citation qui portait sur les espaces insécables.
S'il doit y avoir césure, c'est évidemment incompatible avec le "nowrap" par défaut.
Cependant, si tu affectes "nowrap" à la balise Hn et que tu insère une balise BR dans le source, cela devrait fonctionner, puisque l'attribut @nowrap, à ma connaissance, ne devrait s'appliquer qu'au texte du Hn.
Il me semble bien avoir procédé ainsi sur des titres de documents cadrés à droite et comportant des retours à la ligne.
A vérifier toutefois.

EDIT : Code HTML testé OK sur Firefox (espaces insécables + retour ligne) :
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8"/>
<style type="text/css">
h1
{
white-space:nowrap;
}
</style>
</head>
<body>
<h1>Ceci est un texte un peu long<br/>devant s'afficher sur plusieurs lignes<br/>mais comportant des espaces insécables</h1>
</body>
</html>

Modifié par sepecat (29 Jul 2016 - 00:15)
re-Bonjour,

Sepecat, tu vas croire que je t'en veux et ce n'est pas le cas mais ton exemple me laisse sceptique.

En effet, tel que le problème est décrit, j'établis le cahier des charges suivant:
* le contexte est un titre principal donc relativement court (en théorie même s'il existe des cas inverses).
* sur une surface suffisamment large, le titre s'affiche sur une seule ligne.
* quand la zone d'affichage est réduite, le passage à la ligne est autorisé mais doit être maîtrisé au point que la césure doit s'effectuer à des endroits stratégiques qui reste à la libre appréciation du codeur.

Dans ton exemple Sepecat, le second point ne me paraît pas être respecté ; en tout cas pas avec uniquement ce code. En effet, à moins de styliser la balise hr, lorsque l'affichage le permet, l'affichage ne permettra aucun espace entre les mots reliés par cette balise.
Ce qui va donner 
Ceci est un texte un peu longdevant s'afficher sur plusieurs lignesmais comportant des espaces insécables
Évidement qu'il reste possible de remplacer les br par un espace simulé en Css (quoique c'est pas si évident que ça - voir note) mais dans l'exemple fournit par le demandeur, il s'agirait de titres courts qui sont des données qui n'ont pas tendance à être modifiées.

C'est pourquoi je reste persuadé qu'insérer stratégiquement des espaces insécables en html est une solution très simple et redoutablement efficace (dans un contexte de texte multi-ligne (paragraphe ou autre, je suis d'accord avec toi pour favoriser l'utilisation des propriétés css mais moins quand à l'assertion de break-row ; je les utilises avec parcimonie).

Que pense de tout ça l'auteur de la problématique ?

Note: Remplacer un break-row par un espace en Css :
La balise br est très peu personnalisable et cette manipulation peut vite devenir un casse tête. Nativement cette balise n'accepte que peu de propriétés. Les navigateurs restreignent à leur gré cette liste.
Modifié par Greg_Lumiere (29 Jul 2016 - 07:19)
Puisque @Greg_Lumiere le demande si gentiment, voici mon point de vue sur les deux méthodes.

Sans être expert en la matière, je trouve effectivement que @Greg_Lumiere répond de manière plus "juste" au problème en plaçant un espace insécable aux endroits voulu.

@Sepecat pour sa part, prends le problème à l'envers en ne créant des espace sécable que sur demande.


Donc même si l'on peut arriver au bon résultat dans les deux cas,

Pourquoi faire simple quand on peut faire compliqué ? Smiley cligne
Bonjour !

Raphael a écrit :
Tu peux même tenter de "désactiver" le <br> sur grand écran :

@media (min-width: 543px) {
br {display: inline;
}

(Je n'ai pas testé mais ça me semble jouable)


J'ai testé et... par défaut sur Firefox le <br> est en 'display : inline'. Donc pas de différence. Seul 'display : none' semble fonctionner... en ne laissant aucun espace.

(Edit : sauf si on a pris la précaution de laisser un espace avant ou après le <br>. Il n'est pas visible quand le <br> est actif.)

Les <br> ne sont vraiment pas coopératifs. Smiley sweatdrop

Smiley smile
Modifié par Zelena (29 Jul 2016 - 11:13)
Zelena a écrit :

(Edit : sauf si on a pris la précaution de laisser un espace avant ou après le &lt;br&gt;. Il n'est pas visible quand le &lt;br&gt; est actif.)

D'ailleurs cette méthode apporte un problème lorsqu'on désire que ce texte soit centré. La ligne avant la balise br se termine par un espace qui compte dans la largeur du texte (si on a mis l'espace avant le br).

Finalement un problème qui peut sembler si simple peut vite devenir un cauchemar en css Smiley smile

Zelena a écrit :

Les <br> ne sont vraiment pas coopératifs. Smiley sweatdrop

Smiley smile
C'est pourquoi je tente d'éviter au maximum leur utilisation.

Edit: A la limite il vaudrait mieux ajouter un span avec une classe css dédiée plutôt qu'un break-row. Smiley cligne
Modifié par Greg_Lumiere (29 Jul 2016 - 11:30)
Greg_Lumiere a écrit :
D'ailleurs cette méthode apporte un problème lorsqu'on désire que ce texte soit centré. La ligne avant la balise br se termine par un espace qui compte dans la largeur du texte (si on a mis l'espace avant le br).


Curieux. J'ai vérifié sur Firefox et à moins de changer la valeur par défaut de white-space, l'espace n'apparait pas... Que l'espace soit avant ou après le 'br'...

Smiley smile
Modifié par Zelena (29 Jul 2016 - 11:48)
Zelena a écrit :


Curieux. J'ai vérifié sur Firefox et à moins de changer la valeur par défaut de white-space, l'espace n'apparait pas... Que l'espace soit avant ou après le 'br'...

Smiley smile
Certains navigateurs effectuent un trim sur le code qu'ils parse.
Zelena a écrit :


Curieux. J'ai vérifié sur Firefox et à moins de changer la valeur par défaut de white-space, l'espace n'apparait pas... Que l'espace soit avant ou après le 'br'...

Smiley smile

À ma connaissance, tout caractère espace placé en début ou fin de noeud texte dans le DOM est supprimé d'office à moins qu'un environnement englobant n'ait défini une valeur nowrap imposant de, justement, voir ces espaces comme significatifs.
C'est le même principe en XML où la conservation d'un texte strict, c'est à dire avec ses espaces de début et de fin requiert d'utiliser une section CDATA ou de configurer un,"preserve space" ailleurs.
Si aucun nowrap n'est actif, le navigateur prendra texte "trimé" pour le positionnement centré.
dann a écrit :
Puisque @Greg_Lumiere le demande si gentiment, voici mon point de vue sur les deux méthodes.

Sans être expert en la matière, je trouve effectivement que @Greg_Lumiere répond de manière plus "juste" au problème en plaçant un espace insécable aux endroits voulu.

@Sepecat pour sa part, prends le problème à l'envers en ne créant des espace sécable que sur demande.


Donc même si l'on peut arriver au bon résultat dans les deux cas,

Pourquoi faire simple quand on peut faire compliqué ? Smiley cligne

En fait, comme je le précisais dans mon commentaire initial, ma réponse se voulait plutôt comme un complément sur la gestion des espaces insécables dans un texte et non une solution stricto sensu au problème posé, hormis la gestion du saut de ligne via une balise BR.
Ceci dit et à titre de simple suggestion, pourquoi ne pas laisser la balise H2 vierge de tout CSS et introduire des traits d'union conditionnels (entité shym) dans les mots composant le titre ?
Le navigateur pourrait ainsi afficher un texte conforme à la typographie française et s'adaptant à toute configuration en évitant l'effet "drapeau" peu esthétique si le titre comporte des mots un peu longs.
J'utilise le shym régulièrement sur mon blog et cela améliore, à mon sens, nettement l'aspect général des articles, notamment sur portable.
Perso, c'est la solution que j'adopterais dans le cas présent, mais tu as probablement d'autres contraintes...
sepecat a écrit :

Ceci dit et à titre de simple suggestion, pourquoi ne pas laisser la balise H2 vierge de tout CSS et introduire des traits d'union conditionnels (entité shym) dans les mots composant le titre ?
Le navigateur pourrait ainsi afficher un texte conforme à la typographie française et s'adaptant à toute configuration en évitant l'effet "drapeau" peu esthétique si le titre comporte des mots un peu longs.
J'utilise le shym régulièrement sur mon blog et cela améliore, à mon sens, nettement l'aspect général des articles, notamment sur portable.
Perso, c'est la solution que j'adopterais dans le cas présent, mais tu as probablement d'autres contraintes...
En complément à, ta réponse, j'invite à consulter CSS Tricks - Hyphens (en anglais).
Merci pour l'info Sepecat, voila bien une piste pour améliorer la gestion des césures. Smiley lol
Modifié par Greg_Lumiere (29 Jul 2016 - 13:05)
Greg_Lumiere a écrit :
En complément à, ta réponse, j'invite à consulter CSS Tricks - Hyphens (en anglais).
Merci pour l'info Sepecat, voila bien une piste pour améliorer la gestion des césures. Smiley lol

Et cela permet d'utiliser la valeur justify pour l'attribut text-align des paragraphes composant un article un peu long, histoire d'améliorer l'esthétique d'ensemble et abandonner la présentation dite "en drapeau" moyennant, il est vrai, un investissement non négligeable pour placer les tirets conditionnels aux bons endroits.
Pour ceux qui veulent la justification sans trop d'effort et acceptent javascript sur leurs pages HTML, il reste la solution hyphenator.js, que je n'ai pas testée.
Pour mon générateur HTML, j'ai a priori opter pour une solution à base de dictionnaire à partir duquel seront placés tous les traits d'union de façon automatique lors de la sérialisation des blocs de texte.
Faut avouer qu'un long texte justifié avec des espaces inter mots réduits au minimum cela reste sympa visuellement et plus confortable à lire.
A priori "opté" et non "opter"...
Foutue complétion clavier sur portable. Si on n'y fait pas gaffe elle faut des choix pas forcément judicieux.
Sujet clos
Aller à