Bonjour,

Je comprend mieux,
min(xx,max(xx,XX)) et calc() pourrait permettre de faire ou de s'approcher de ce que vous voulez sans médiaqueries, (pas sur que cela soit mieux, mais jouons le jeux Smiley smile ) , mais il nous faut quand même une valeur pivot arbitraire.

La largeur d'une colonne peut servir à faire quelques calculs de comparaison. (le point B.2 désolé , voir https://developer.mozilla.org/fr/docs/Web/CSS/min et https://developer.mozilla.org/fr/docs/Web/CSS/max )

L'idée est de forcer la grille à avoir une largeur minimale en fonction de la largeur d'écran et d'une largeur de colonne tout en remplissant son conteneur par défaut.

grid, flex ou column CSS n'ont pas vraiment d'importance à mon avis, il dépendront de l'espace allouer.(le point B méritait d'être le point A, ce n'est pas un probléme de grille Smiley cligne )
Codepen démo de l'idée : https://codepen.io/gc-nomade/pen/WNWmWaX Cela ressemble à ce que j'en ai compris. la largeur de colonne est passé dans une variable CSS pour faciliter les tests et réglages. Ce n'est pas encore tout à fait ça, mais ça redonne quelques pistes.

cdt
Modifié par gcyrillus (27 Apr 2024 - 13:03)
Et l'eau,

parsimonhi a écrit :
Je ne pige pas pourquoi ils n'ont toujours pas réussi à se mettre d'accord pour normaliser ça


Les standards Microsoft....

Sinon,


<?php 
    $chaine = "Alsacréations est un \n super site d'apprentissage";
?>
<!doctype html>
<html lang="fr">
    <head>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <title>Titre du document</title>
        <link rel="stylesheet" href="css/styles.css" media="all">
    </head>
    <body>
        <p><?= $chaine ?></p>
        <script src="app.js"></script>
    </body>
</html>



String.prototype.nl2br = function(isXhtml){
    return typeof this === 'undefined' || this === null? '' : (this + '').replace(/(\r\n|\n\r|\r|\n)/g, isXhtml || typeof isXhtml === 'undefined' ? '<br ' + '/>' + '$1' : '<br>' + '$1')
}
let $p = document.querySelector('p')
$p.innerHTML = $p.innerHTML.nl2br() 

Modifié par niuxe (27 Apr 2024 - 11:35)
Bonjour,

Merci de votre suivi.

J'espère que ce codepen vous aidera à mieux comprendre ma question.

div.main_1
C'est le GRID qui détermine min-content du parent.

div.main_2
C'est la TABLE qui détermine min-content du parent.

div.main_3
Grâce à media-query le min-content est déterminé par :
GRID si la largeur de la fenêtre est supérieure à la somme des largeurs des deux éléments du GRID.
TABLE autrement.

Et ma question : peut-on obtenir la même résultat sans media-query ?
Quitte à changer le code html

J'espère aussi que le codepen répond aux questions de gcyrillus.

Je complète :

A.1 il y a un tableau de largeur .. inconnue?
Largeur définie par le contenu.
A.2 il y a un conteneur avec 2 listes, elles ont aussi forcement une largeur
OUI, enfin la largeur est celle des grid items, elle est définie par grid-template-columns.

B. Pourquoi un grid layout et pas un flex layout
Je ne vois pas ce qu'apporte le FLEX, on devrait jouer avec flexwrap il me semble et je ne vois pas comment éviter une media-query.

B.2 Pour deux petites listes on pourrait même imaginer qu'un column-width: max(xx,min(xx,XX); ferait l'affaire.
Je ne comprends pas...

C. la media querie sur un écran de 420px qui règle ton soucis?
OUI, enfin oublie l'écran de 420px, c'est une valeur pour le codepen sans rapport à la réalité.

C.1 il y aurait contradiction avec le min-content avec un tableau qui déborderais et des listes qui se réduirait en largeur pour s'afficher l'une sur l'autre pour ne pas faire déborder la grille.
Je pense que tu vois l'effet sur le codepen.

C.2 Mais si le tableau est déjà d'une largeur inférieur , la grille ne devrait-elle pas déjà être affichée en colonne avant ce point de rupture ?
Dans la réalité c'est une affaire d'esthétique.
Tant que la fenêtre le permet c'est plus joli d'afficher les deux ul sur la même ligne.
mi,n-content se justifie pour éviter qu'il y en ait partout sur les écrans larges.

Modifié par boteha_2 (26 Apr 2024 - 22:42)
Bonjour,

J'avoue ne pas comprendre 3 choses:
A. quel est est l’élément qui détermine le min-content que tu évoque dans le conteneur parent ?
A.1 il y a un tableau de largeur .. inconnue?
A.2 il y a un conteneur avec 2 listes, elles ont aussi forcement une largeur

B. Pourquoi un grid layout et pas un flex layout
B.1Tu n'as que : soit 1 ligne soit 1 colonne à afficher (il n'y a que deux éléments dans ta grille).
B.2Pour deux petites listes on pourrait même imaginer qu'un column-width: max(xx,min(xx,XX); ferait l'affaire.

C. la media querie sur un écran de 420px qui règle ton soucis?
C.1 il y aurait contradiction avec le min-content avec un tableau qui déborderais et des listes qui se réduirait en largeur pour s'afficher l'une sur l'autre pour ne pas faire déborder la grille.
C.2 Mais si le tableau est déjà d'une largeur inférieur , la grille ne devrait-elle pas déjà être affichée en colonne avant ce point de rupture ?

En gros je n'arrive pas à comprendre le comportement attendu ni ce qui le pilote avec ce min-content posé sur le parent ? As tu quelques exemples en lorem ou dessins à partagé ?

Cordialement
Alors tout va bien pour moi.

Mon Tag HTML (avec device-width) transforme intégralement mes problèmes de test sur téléphone (je rentre dans les clous avec la largeur de pixels. Je ne suis plus à 980 pixels).

Et je n'ai jamais utilisé de media avec device-width directement, donc c'est PARFAIT !

Pour le reste, les breakpoints, j'avais bien compris la façon de réfléchir (penser à SA propre mise en page, puis les appareils afficheront selon leur définition, en tout simplicité). Ce n'était pas un problème en soi. C'était le problème des téléphones qui affichent des largeurs de dingue.

Merci à tous d'avoir participé.

-Sujet réglé-
Bonsoir,

a écrit :
Par contre je n’ai toujours pas compris quand il fallait ou non doubler les \


Dans la notation littérale /regex/options, on ne doit pas échapper les \.
C'est quand on écrit sous forme de string qu'on doit échapper les \.

a écrit :
Je dirais que ça doit être le signe que Javascript à pris le parti de n'utiliser que \n vu que le \r saute.


Ca me parait être un pari risqué.
Il faudrait être sûr que c'est bien le cas avec tous les navigateurs sur toutes les plate-formes.

Le mieux est encore d'utiliser une regex qui cadre tous les cas:
/\r?\n/g

OU si on a aussi du \r seul sans \n (seulement pour les mac avant OS X):
/\r\n|\n|\r/g


Certains moteurs d'expressions régulières connaissent un littéral \R qui symbolise un saut de ligne quelqu'en soit sa forme \n, \r\n ou \r. Parfois il existe aussi une option.
C'est le cas du moteur PCRE notamment utilisé en PHP, mais aussi d'autres langages, et éditeurs de texte (sauf erreur Notepad++).
J'ai essayé à tout hasard et malheureusement, en JavaScript, ça n'existe pas, visiblement.
Modifié par QuentinC (25 Apr 2024 - 22:06)
Bonjour Olivier C,

Olivier C a écrit :
Peut-être cherches-tu quelque chose comme ceci ? :
grid-template-columns: repeat(auto-fit, minmax(min(20em, 100%), 1fr));


Non, cela ne change rien.

J'ai trouvé une solution mais qui implique une media-query :

<div> // max-width: min-content
<div id="grid"> // GRID grid-template-columns: 210px 210px
<ul>
<ul>
</div>
<table> width 320px
</div>


Dans ce cas c'est une largeur de 420px qui va être prise en compte pour le calcul de min-content du parent.

Et j'ajoute :

@media screen and (max-width: 420px).
{
div#grid {grid-template-columns: repeat(auto-fit, 210px)}
}


Pour être responsive.
min-content passe à 320px (la largeur de la table) et les deux Grid items sont l'un au-dessus de l'autre.

Peut-être avez-vous compris ce que je cherche à faire...

La question est: peut-on y arriver sans media-query ?
Sachant que la largeur des Grid ittems varie d'une page à l'autre et donc qu'il faut pour chaque page calculer le breaking point à la volée côté PHP (ce qui est possible avec les variables dont je dispose).
Modifié par boteha_2 (25 Apr 2024 - 21:34)
Ce n'est pas si mystérieux à mon sens : pour ce qui est de la balise link vers une feuille de styles, ce qui est de l'ordre d'une déclaration breakpoint devient uniquement dévolu au... CSS ***. Reste sauve la balise meta viewport qui est une balise déclarative sur la manière dont doit se comporter la page en responsive.

Ces deux tags HTML n'ont pas du tout le même rôle.

___
*** À tous les coup ça restera éternellement compatible malgré l'intention de dépréciation, mais autant rester dans une optique de bonnes pratiques.
Je ne pige pas pourquoi ils n'ont toujours pas réussi à se mettre d'accord pour normaliser ça Smiley nimp
Cela doit faire facilement 20 ans qu'on se trimbale toujours ces problèmes à la Smiley censored de CR (\r ) vs LF (\n) vs CRLF ( \r\n ) ..

Je dirais que ça doit être le signe que Javascript à pris le parti de n'utiliser que \n vu que le \r saute.
Il y a quelques années j'avais eu un peu le même genre de problème sur git, si je me souviens bien leur solution par défaut eux c'était CRLF.
@Olivier C :

Merci de venir parler du coeur du problème (ou la fausse crainte du problème pour ma part, si c'est avéré) !!!

Donc l'utilisation de "device-width" (en tant que référence de la largeur d'écran de celui qui consulte le site) serait obsolète mais seulement pour une partie du codage ????

Uniquement pour le CSS avec une requête media ? Et pour le HTML, c'est tout bon ?

Je veux bien vous croire, mais c'est pour le moins étrange tout de même (écarter une valeur en CSS mais la garder en HTML). Les mystères de l'informatique ...
Modifié par AlexInSi (25 Apr 2024 - 15:10)
Salut,

de ce que j'en comprends de vos messages, j'ai l'impression vous vous compliquez la vie pour rien Smiley sweatdrop

Il faut juste remplir le innerHTML ou le innerText en fonction de ce que tu as comme valeurs.
Petit jsfiddle pour illustrer : https://jsfiddle.net/L1sz5fob/

Et si tu restes sur les replace, je suppose qu'il faudra basculer sur du global au cas où il y a besoin de plusieurs lignes :
- replaceAll pour la fonction
- un g pour la regex /\r\n/ => /\r\n/g

Edit pour adapter ton bout de code :

cell.innerText = value;
// et
let value = cell.innerText;

Modifié par Mathieuu (25 Apr 2024 - 11:43)
Après essais,

cell.innerHTML = value.replace(/\r\n/g, '<br>');
// et
let value = cell.innerHTML.replace(/<br>/g, '\r\n');

cela permet d'afficher la valeur provenant de la base de données et de retrouver la valeur à partir du contenu de la balise <td>
En effet j'utilise l'attribut contenteditable pour pouvoir modifier les données et les renvoyer dans la base suite à cette discussion
Contrairement à ce que je craignais, je n'ai pas -- pour le moment -- rencontré d'autres difficultés dans l'utilisation de cette méthode.
Modifié par PapyJP (25 Apr 2024 - 11:47)
Merci beaucoup
Si je comprends bien j’avais tout fait à l’envers !

Note : j’utilise très souvent des RegEx sous forme de string, mais la lecture de cette page m’a montré qu’il y avait des foutlitudes de possibilités que j’ignorais. Par contre je n’ai toujours pas compris quand il fallait ou non doubler les \
Modifié par PapyJP (25 Apr 2024 - 08:50)
Bonjour,
merci à tous!
je commence à y voir plus clair!
et je sais ce qui me reste à faire...
-faire un nettoyage en profondeur de mes sites ... et je viens effectivement de trouver sur mon serveur des répertoires complets en double, duplications sans doute dues à des migrations lors de changements de fournisseur d'accès
-restructurer chacun d'entre eux en supprimant au maximum les fichiers en double
- ajouter le link canonical si besoin... mais effectivement, si ce qui précède a été bien fait, je devrais pouvoir m'en passer...
- après ces modifications, refaire tous mes sitemaps pour chacun des sites
et faire valider mes modifs sur la search console

Le retour (précoce! Smiley cligne )de l'hiver se prête à ce genre d'occupation...
Bonjour,

<p id="p"></p>
<p id="p2"></p>


    const paragraph = "Résidence St Louis\r\n40 rue de Nantes";
    const paragraph2 = "Résidence St Louis<br>40 rue de Nantes";
    
    document.getElementById('p').innerHTML = paragraph.replace(/\r\n/, '<br>');
    document.getElementById('p2').innerText = paragraph2.replace('<br>', '\\r\\n');

Affiche pour le premier paragraphe :
Résidence St Louis
40 rue de Nantes

et pour le second
Résidence St Louis\r\n40 rue de Nantes

notez que la regex dans ce cas précis peut êtes également un string.
https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Global_Objects/String/replace
L'équivalent en PHP est la fonction nl2br()

$paragraph = "Résidence St Louis\r\n40 rue de Nantes";
echo nl2br($paragraph);
Bonsoir,

Je vais suivre ton fil avec attention car j'ai été confronté au même problème sous Postgres et Node.js. Je m'en suis tiré de manière triviale*** mais j'aimerais bien connaître le fin mot de l'histoire.

___
*** Utilisation d'un éditeur Markdown (Marked.js) qui, s'il fonctionne bien, est surdimensionné par rapport à mes besoins. Je rêve de le remplacer par quelques regex... mais ça commence d'abord par affronter la même problématique que toi.
Bonjour,

Les pages en double détectés par les moteurs de recherche peuvent aussi être la conséquence du fait que plusieurs url conduisent à la même page. Les pages ne sont pas en double, mais il y a deux urls ou plus de deux qui permettent d'y accéder.

Un exemple : https://monsite.fr/page1.html et https://www.monsite.fr/page1.html

Autre exemple : https://monsite.fr et https://monsite.fr/index.html

C'est courant, et c'est pourquoi les urls canoniques ne sont pas du tout accessoires ! Il faut choisir l'une des urls et la spécifier comme url canonique.

Amicalement,
matissed a écrit :
si je mets ce &lt;link rel="canonical" href="https://delaplace.fr/index.htm" /&gt; qui renvoit vers l'index principal du site, que va t'il se passer quand le robot passera dessus??

Et bien cela rajouterais encore plus de confusion puisque l'index n'irais rien à voir avec ces deux pages.

Supprimer les pages redondantes serait un bon début. Avant toute chose il faut bien faire attention à la structure du site : si cette structure est correcte les URL canoniques deviennent accessoires.
Bonjour à tous
J'ai une table d'adresses qui comporte un champ contenant éventuellement plusieurs lignes,
par exemple
Résidence St Louis
40 rue de Nantes

Ce champ provient directement d'une base de données MySQL sous la forme
Résidence St Louis\r\n40 rue de Nantes

Pour afficher ce champ dans une <td>, je voudrais obtenir
<td>Résidence St Louis<br>40 rue de Nantes


Je ne parviens pas à écrire l'expression qui effectue cette conversion :

cell.innerHTML = value.replace(/\\r\\n/, '<br>');

ou de même la conversion inverse :

let value = cell.innerHTML.replace(/<br>/, '\r\n');

Je pense que cela a à voir avec les protection par \\ mais je ne m'y retrouve pas sur le nombre de \ à utiliser dans la première ou la deuxième expression.

Merci de votre aide.
Modifié par PapyJP (24 Apr 2024 - 19:12)
Le fait que le robot signale 471 pages avec url non canonique signifie il qu'il a trouvé 471 pages en double sur le même site
ou sur plusieurs sites différents? par exemple sur une vielle version du site encore présente présente sur des vielles pages perso free?

Si c'est le cas, il me suffit de supprimer ces pages en doubles pour solutionner le problème
Bonjour,
Je crains malheureusement qu'il ne vous est pas possible d'installer un certificat Let's Encrypt avec ce que vous avez. Du moins pas à ma connaissance.
Avec un hébergement mutualisé, quand bien même vous avez un accès SSH, il ne vous sera pas d'une grande utilité étant donné que vous n'aurez pas d'accès ROOT.
Plesk est un panel de contrôle admin qui vous permet en gros de gérer votre serveur. Mais je ne pense pas qu'il soit disponible pour un hébergement mutualisé.

À mon avis, le mieux et le plus simple serait d'appeler directement Ionos, ils vous indiqueront la meilleure option pour votre cas.
bonjour,
et merci pour votre réponse

Si j'ai bien compris , ce lien canonical ne doit concerner que les fichiers en double qui peuvent être référencé à 2 endroits différents...
alors je vous pose une question simples :

j'ai un fichier guadeloupe.htm qui est utilisé à 2 endroits différents. voilà un <head>

<head>
<title>Guadeloupe </title>
<link rel="canonical" href="https://delaplace.fr/index.htm" />
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta http-equiv="Content-Language" content="fr">
<meta content=never name=expires>
<meta content="20100324" name=Date-Creation-yyyymmdd>
<meta content="20240424" name=Date-Revision-yyyymmdd>
<meta name="Description" content="Séjour Guadeloupe 2010">
<meta name="keywords" content="gwada, guadeloupe, gosier, felix, anne, francois, anse, bertrand, deshaies, habitants, traversée
delaplace">
<meta name="author" content="delaplace michel">
</head>

si je mets ce <link rel="canonical" href="https://delaplace.fr/index.htm" /> qui renvoit vers l'index principal du site, que va t'il se passer quand le robot passera dessus??

cordialement
AlexInSi a écrit :
Mon ancien site se portait très bien avec l'instruction de base en HTML
<meta name="viewport" content="width=device-width, height=device-height, initial-scale=1"> et les media queries de base.

Sauf que ça ne va plus être possible pour mon nouveau site car device-width va disparaître des navigateurs (je rappelle l'information : https://developer.mozilla.org/en-US/docs/Web/CSS/@media/device-width).

Houlà houlà ! Mais il y a un malentendu !

En effet : l'attribut/valeur `content='width=device-width`avec une meta(name='viewport') n'est absolument pas obsolète ! Ce tag est tout à fait valide par exemple :
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">

C'est l'utilisation de `device-width` avec un tag link (rel="stylesheet") qui l'est, obsolète, ce qui n'a rien à voir :
<link rel="stylesheet" media="screen and (max-device-width: 799px)" href="http://toto.truc.com/narrow-styles.css" />

Le pire c'est que j'avais supputé cette confusion dès le premier post, mais comme vous aviez l'air sûr de vous...
Bref, tout va bien : les attributs du viewport restent tels quels pour le moment.
Modifié par Olivier C (23 Apr 2024 - 22:38)
@AlexInSi

J'ai l'impression que vous compliquez considérablement cette utilisation de @media.
Comme le dit Olivier, ils ne sont là que pour définir le "breakpoint", le moment crucial où l'on change radicalement design du site pour l'adapter aux mobiles, pas pour faire du placement. Courir après les différentes tailles de mobiles est une tâche vouée à l'échec, tant il y en a. Avec Grid et Flexbox (qui ne sont pas une "grande tendance générale", mais bien une spécification fonctionnelle), des valeurs fluides en em, rem, vw, on doit pouvoir couvrir tous les besoins. Il est juste nécessaire d'adapter les positions qui passent de portrait à paysage (avec les @media). Un site bien fait pourrait n'avoir qu'un @media, celui pour passer aux mobiles et à la rigueur un autre pour les positions portrait et paysage. J'ai même vu passer un article dans lequel le développeur se vantait de ne pas les utiliser:

https://putaindecode.io/articles/responsive-sans-media-queries/

Après, on peut effectivement voir les densités, les écrans retina, le rendu des images. Deux articles à consulter :

https://www.alsacreations.com/astuce/lire/1730-retina-trick-compressive-images-resolution-picture-img-srcset-responsive.html

https://www.alsacreations.com/astuce/lire/1831-corriger-le-probleme-de-hauteur-100vh-sur-mobile.html
Comme dit ailleurs, un lien ou un codepen serait bien utile.
ps Je rajouterai que sur un mobile, lire un site en mode paysage n'a souvent plus de sens. Le même design prévu pour grand écran est brusquement lu sur un tout petit écran, tout est tassé. C'est juste utile pour lire des films ou jouer.
Modifié par Bongota (23 Apr 2024 - 21:34)
Bonjour,

Parent avec max-width: min-content

Dans ce parent j'ai un GRID avec column en auto-fit avec deux éléments.

Et disons plus bas une TABLE dont la largeur est inférieure à celle des deux éléments cumulés du GRID..

Logiquement les éléments du GRID s'affichent l'un au dessus de l'autre.

Mais j'aimerais qu'ils s'affichent l'un à côté de l'autre tant que la taille de la fenêtre le permet.

Si j'emploie auto-fit c'est pour être responsive quand la fenêtre devient trop étroite.

Avant de passer en GRID les deux éléments étaient en display: inline-block à l'intérieur d'un DIV avec white-space: nowrap soumis à @media screen and (min-width: 1050px).
Et cela marchait.comme voulu : l'un à côté de l'autre tant que la taille de la fenêtre le permet.

Mais avec une media-query dont j'aimerais pouvoir me débarrasser car en réalité toutes les largeurs peuvent changer d'une page à l'autre et en dehors du contenu des ul aucune largeur n'est définie en dur.

Avant :
<div> // max-width: min-content
<div> // white-space: nowrap soumis à media screen and (min-width: 1050px)
<ul> // inline-block
<ul> // inline-block
</div>
<table>
</div>


Après :
<div> // max-width: min-content
<div> // GRID auto-fit
<ul>
<ul>
</div>
<table>
</div>


J'espère que c'est assez clair.

Merci d'avance de votre aide.
Modifié par boteha_2 (23 Apr 2024 - 21:14)
C'est simple :

êtes-vous d'accord que si je tape (en CSS)
@media screen and (orientation : portrait) and (min-width : 481px){
ce n'est pas censé concerner un téléphone ? (car en théorie, un téléphone a une largeur de 480 pixels maximum)

Hé bien, je viens de le tester, et mon téléphone se sent concerné, car il affiche 979px de largeur en réponse au media query.

Pour que mon téléphone reste en version "téléphone" de mise en page, il faudrait que je tape
@media screen and (orientation : portrait) and (min-width : 980px){
(avec 980 pixels, mon téléphone estime ne plus être concerné car la largeur est trop importante, et donc c'est la mise en page tablette qui est développée).

Donc ma mise en forme n'est pas adaptée (car ça entre déjà dans le cas d'une tablette en vertical). Et surtout, on n'affiche pas une écriture avec le même ratio quand on parle d'un tout petit écran ou d'une tablette entre 4 et 10 plus grande.

Mon ancien site se portait très bien avec l'instruction de base en HTML
<meta name="viewport" content="width=device-width, height=device-height, initial-scale=1"> et les media queries de base.

Sauf que ça ne va plus être possible pour mon nouveau site car device-width va disparaître des navigateurs (je rappelle l'information : https://developer.mozilla.org/en-US/docs/Web/CSS/@media/device-width )

Toutes les disparités de téléphones avec différents formats et différentes densités de pixels (retina ou autre) créent un capharnaüm sans nom quand on n'utilise plus "device-width".
Modifié par AlexInSi (23 Apr 2024 - 20:57)
Je ne suis pas sûr de bien comprendre, du moins seulement dans les grandes lignes...
Mais, si vous nous faisiez une page test pour que nous puissions comprendre le problème ? Un codepen ?
Ce serait beaucoup plus concret qu'une explication - même détaillée - et si cela se trouve nous serons en mesure de vous donner des pistes de réflexions auxquelles vous n'aurez pas pensé (unités relatives au viewport, etc).
Merci pour vos deux premières réponses.

Mais ....

Pourquoi utiliser le device-width comme méthode classique, si on n'est pas censé s'y intéresser ?



Je donne un exemple très concret :

SAMSUNG GALAXY note 10 lite (résolution fabricant : 2400x1080 pixels) en ma possession, qui me sert pour tester.

En mode vertical, je fais une mise en page de base (sans media query)
Puis je fais une mise en page pour tablette verticale.

Pour vérifier si ça fonctionne, je mets une écriture en ROUGE qui n'est censée être que sur tablette (et donc pas sur téléphone qui "doit" avoir une largeur moindre).

La théorie, c'est ça :
@media screen and (orientation : portrait) and (min-width : 481px){
(et encore, je pourrais même faire 431 px)

Avec ça, on distingue bien les téléphones et les tablettes en mode vertical.



La pratique c'est ça :
@media screen and (orientation : portrait) and (min-width : 980px){

Mon téléphone a donc une largeur repérée de 979px !!! quand je suis en position verticale.

On est d'accord qu'une largeur de 979 pixels, ça peut se confondre avec autre chose, notamment une tablette, ou un navigateur réduit sur un moniteur. On est TRES LOIN des téléphones théoriques avec une largeur (à la verticale) de maximum 480 pixels.

On a beau me parler de pixels purs, afficher un texte sur un téléphone se fait différemment que sur une tablette ou un moniteur, car la surface de lecture est bien plus petite, donc il faut que le texte soit PLUS grand en proportion (ou du moins, il faut vérifier que cela soit lisible sur les 2 supports, en faisant des tests réels).

Et donc, comment faire sans utiliser device-width au départ ?


(suis-je complètement à côté de la plaque ou mes questions sont-elles pertinentes ?)



Ou bien faut-il coder les media query en EM au lieu de PX ?
Modifié par AlexInSi (23 Apr 2024 - 19:44)
Bonjour,

pour résumer, et sans prétendre avoir LA réponse absolue, mettre une balise canonique sur chaque page. Oui, ça fait du travail si votre site a 400 pages ! Ça permet d'utiliser des canonicals qui s'autoréférencent. Dans ce cas, chaque page doit avoir une balise canonique qui pointe vers sa propre URL. Voici le lien vidéo sur la conférence de John Mueller à ce sujet (ça date de quatre années).
https://www/watch?v=MD6ABXMMuaI&t=1734s
Après, ne pas hésiter à demander dans la Search Console une nouvelle indexation de chaque page qui ne l'est pas. Sinon, je suppose que vous connaissez la commande site:mon_site
Et ne pas oublier que le sitemap ne doit pas avoir d'url non canoniques.
Modifié par Bongota (23 Apr 2024 - 16:35)
Bonjour,

Olivier C a écrit :
Il ne faut pas partir des écrans, il faut partir des breakpoints nécessaires au design du site (@media) ou, mieux encore, selon un conteneur (@container).

+1

Il ne faut pas oublier qu'un internaute peut très bien utiliser une fenêtre de navigateur plus petite que son écran physique. Cela veut dire que la fenêtre peut faire n'importe quelle taille.

Il faut donc que les pages fonctionnent quelque soit la taille de l'écran.

Amicalement,
Bonjour,

@AlexInSi:

Il est déconseillé de l'utiliser dans les media query, mais rien ne dit qu'il ne faut plus non plus l'utiliser dans la balise meta viewport.
Pour moi en tout cas, c'est pas très clair si c'est la même chose ou pas du tout.

Autre chose, si on est un peu pragmatique: si ça fait plusieurs années que c'est indiqué comme déprécié mais que c'est toujours supporté, il y a peut-être des chances que ce soit finalement jamais réellement retiré.
Si c'est toujours utilisé parce qu'il n'y a pas d'autre alternative pratique, ils n'ont pas trop d'intérêt à le supprimer et ainsi rendre des milliers de sites inutilisables.
Donc il y a certainement encore le temps de voir venir avant que ça ne fonctionne plus...

Ce qui serait intéressant, c'est de savoir pourquoi ça a été déclaré obsolète. Quelles sont les raisons profondes ? Pourquoi c'est mal de l'utiliser ?
A partir de là on peut comprendre quel est le risque et décider de l'assumer ou pas.


Au passage, un petit coucou à <font>, <center> et autres balises tirées tout droit des années 90 qui, étonnament, marchent toujours... attention ne me faites pas dire ce que je n'ai pas dit, je n'ai pas dit qu'il fallait continuer à les utiliser, car dans ce cas-là on connaît depuis longtemps de bien meilleures alternatives, meilleures en tout point.

@all:

Pendant qu'on parle de media query, je me suis rendu compte que ma CSS mobile.css n'était en fait jamais utilisé, et que c'était systématiquement desktop.css qui était prise en compte:

<link rel="stylesheet" media="only screen and (max-width: 40em)" href="/styles/mobile.css" />
<link rel="stylesheet" media="only screen and (min-width: 40.01em)" href="/styles/desktop.css" />


En réalité, après un test empyrique, même mon iPhone 12 mini a une taille de 64em, et ce n'est pas très différent de la taille trouvée sur mon PC portable (ça tourne aussi entre 60 et 70em).
Du coup comment on fait pour viser les petits écrans comme ceux des téléphones spécifiquement ?
Modifié par QuentinC (23 Apr 2024 - 06:31)
Olivier C a écrit :

Jamais testé mais ce serait rigolo. En sachant que l'ado dispose de quelques infos grâce aux attributs de l'input :
pattern="[0-9]+" maxlength=4


exact Smiley smile

À noter que la valeur d'un attribut en html traditionnel est toujours entourée par des guillemets.

Olivier C a écrit :


Il pourrait faire un truc du genre :
function testerEtSoumettre() {
    let pinInput = document.getElementById("pin");
    let i = 0;
    let interval = setInterval(function() {
        let pinValue = pad(i++, 4); // Formatage du nombre avec des zéros devant
        // Remplir le champ avec le nouveau PIN
        pinInput.value = pinValue;
        // Valider et soumettre le formulaire si le PIN est valide
        if (validerPIN(pinValue)) {
            document.forms["codepin"].submit();
            clearInterval(interval); // Arrêter la boucle d'itération
        }
        // Arrêter la boucle d'itération une fois que tous les chiffres ont été testés
        if (i < 9999) {
            clearInterval(interval);
            alert("Aucun PIN valide trouvé.");
        }
    }, 10); // Délai entre chaque itération (en millisecondes)
}

function validerPIN(pin) {
    // Validation du PIN, vérifier s'il est rempli
    return pin !== "";
}

// Fonction pour ajouter des zéros devant un nombre jusqu'à atteindre une certaine longueur
function pad(num, size) {
    let s = num + "";
    while (s.length &lt; size) s = "0" + s;
    return s;
}

testerEtSoumettre()


J'ai lu vite fait et en effet, l'idée est là.
Olivier C a écrit :

Je ne sais pas si ça marche, c'est juste pour le fun (je suis un galopin, je vais me faire botter les fesses).

Smiley lol
Olivier C a écrit :

Il me semble que oui, c'est ce que je ferais en tout cas. Mais je préfère laisser Niuxe vous répondre sur ce point, je ne suis pas compétent en la matière.


Un anti brute force parait une solution simple. Au bout de 3 ou ... tentatives, un cookie est créé. Et si le système détecte ce cookie, ça renvoie une 404 ou un semblant de page qui ne fait rien (plus vicieux). Le souci et que je ne pourrai pas aider dans l'ESP32. Je ne connais pas du tout le sujet.

Une bonne manière de concevoir un bon mot de passe :
un mot de passe long de 8 caractères minimum, chiffre, lettre, majuscule, "caractères spéciaux". Pas de mots évidents. Le mieux étant une ou deux phrases longues (en leet ou pas) :
Que faisaient les élèves ? Les 3 élèves jouaient aux échecs pendant la récréation !
Modifié par niuxe (23 Apr 2024 - 01:50)
Bonsoir,

Il ne faut pas partir des écrans, il faut partir des breakpoints nécessaires au design du site (@media) ou, mieux encore, selon un conteneur (@container).

Je ne sais pas par où commencer pour vous expliquer cela car je ne sais pas où vous en êtes. En effet, j'ai l'impression que vous vous êtes embrouillé les pinceaux.

Pour vous rassurer sur l'avenir du responsive, voici déjà une page de démonstration qui fonctionnera pour longtemps : Grids.

Voici maintenant un exemple de ce qu'elle utilise comme media queries :
@container grid (width < 35.01em) {
  .xs-grid-auto {
    grid-template-columns: repeat(auto-fit, minmax(var(--xs-size-column, 11em), 1fr));
  }
}

@container grid (35.01em < width) {
  .grid2,
  .grid3,
  .grid4 {
    grid-template-columns: repeat(2, minmax(0, 1fr));
  }
}

@container grid (50.01em < width) {
  .grid3,
  .grid4 {
    grid-template-columns: repeat(3, minmax(0, 1fr));
  }
}

@container grid (70.01em < width) {
  .grid4 {
    grid-template-columns: repeat(4, minmax(0, 1fr));
  }
}
niuxe a écrit :
ps : un script en php ou en js, ce n'est pas très difficile à faire.

Jamais testé mais ce serait rigolo. En sachant que l'ado dispose de quelques infos grâce aux attributs de l'input :
pattern="[0-9]+" maxlength=4

Il pourrait faire un truc du genre :
function testerEtSoumettre() {
    let pinInput = document.getElementById("pin");
    let i = 0;
    let interval = setInterval(function() {
        let pinValue = pad(i++, 4); // Formatage du nombre avec des zéros devant
        // Remplir le champ avec le nouveau PIN
        pinInput.value = pinValue;
        // Valider et soumettre le formulaire si le PIN est valide
        if (validerPIN(pinValue)) {
            document.forms["codepin"].submit();
            clearInterval(interval); // Arrêter la boucle d'itération
        }
        // Arrêter la boucle d'itération une fois que tous les chiffres ont été testés
        if (i > 9999) {
            clearInterval(interval);
            alert("Aucun PIN valide trouvé.");
        }
    }, 10); // Délai entre chaque itération (en millisecondes)
}

function validerPIN(pin) {
    // Validation du PIN, vérifier s'il est rempli
    return pin !== "";
}

// Fonction pour ajouter des zéros devant un nombre jusqu'à atteindre une certaine longueur
function pad(num, size) {
    let s = num + "";
    while (s.length < size) s = "0" + s;
    return s;
}

testerEtSoumettre()

Je ne sais pas si ça marche, c'est juste pour le fun (je suis un galopin, je vais me faire botter les fesses).

ChristianW a écrit :
Si on impose un délai (éventuellement de plus en plus long) ça devrait être plus robuste non ?

Il me semble que oui, c'est ce que je ferais en tout cas. Mais je préfère laisser Niuxe vous répondre sur ce point, je ne suis pas compétent en la matière.
Modifié par Olivier C (23 Apr 2024 - 00:02)
50 Dernières réponses