Chemin relatif / absolu p.r. à la partition - compatibilité OS

Bonjour,

J'ai une série de fichiers html qui font références à un css.
Disons que les fichiers html se trouvent dans:
<racine>\data\une sous arborescence\un fichier html
Et que mon fichier css est dans
<racine>\data\WEB_STYLES\

Sous Win 10
Si un fichier html contient
<link rel="stylesheet" type="text/css" href="/data/WEB_STYLES/CSS_DEF_Print_Friendly.css">

Alors sous Win10 cela fonctionne avec Edge 38 et Chrome 49, mais pas avec FF49 ou FF50, est-ce un bug de Firefox ou ma mé-compréhension?

En outre, je voudrais que cela puisse fonctionner en boot Linux sans codage additionnel, les chemins seront du style
/mnt/sda5/data/<mes sous-répertoires>
ou
/media/home/sda5/data/<mes sous-répertoires>
en fonction des distributions Linux.

Merci

P.S. Et si le fichier css se trouve sur une autre partition que celle des fichiers html, que devient le code?
Modifié par artofit (29 Nov 2016 - 15:17)

Bonsoir,

Désolé de te le dire de cette façon, ce n'est sans doute pas la réponse à laquelle tu t'attendais...

Des chemins absolus dans une arborescence de fichiers locale, c'est juste un gros casse gueule.
Oui, parce que tes chemins qui commencent par un / sont bien des chemins absolus, et non pas des chemins relatifs comme tu sembles le croire.
Tu le constates déjà toi-même, il te faut une version différente par OS au minimum.

Ma première question est donc celle-ci: pourquoi veux-tu faire cela ?

Pourquoi ne peux-tu pas utiliser de chemins relatifs ?
Pourquoi veux-tu charger tes pages en utilisant le système de fichiers local ?
pourquoi n'utilises-tu pas un serveur web, même s'il est locale (p.ex. WAMP) ou virtualisé (p.ex. une VM vagrant) ? As-tu une bonne raison pour vouloir t'en passer ?

Le seul cas que je vois où on peut vouloir se passer d'un serveur web, c'est pour une présentation sur CD ou clé USB avec aucun droit pour exécuter un mini-serveur. Dans ce cas évite les chemins absolus pour être sûr.

Pour la réponse technique à pourquoi ça ne marche pas sur Firefox sous windows, c'est tout simplement parce que le protocole file:// n'est pas vraiment standardisé (en tout cas pas dans les détails, à ma connaissance), et donc du coup il y a des différences d'interprétation. Pour windows, bêtement, certains interprètent /a/b comme C:\a\b, alors que d'autres pourraient interpréter / comme étant une racine englobant tous les disques et il faudrait alors écrire /c:/a/b ou /c/a/b pour qui ce soit interprété comme C:\a\b (plus proche de la vision linux). Venant de Firefox je ne serais pas surpris qu'ils aient adopté cette dernière interprétation, tout comme je ne serais pas surpris que Chrome ait choisi la première.
Modifié par QuentinC (22 Nov 2016 - 21:54)

But:
accèder à mes fichiers html sur disque dur ou média USB, soit sous Win10, Linux, ou Android.
Ces fichiers html font références à un css et parfois un fichier js

Win10 interpréte les chemins soit avec \ soit avec /
Linux & Android: les chemins uniquement /

Donc sous Win10, mon fichier e:\data\test.htm pourrait contenir le code

<link rel="stylesheet" type="text/css" href="e:/data/WEB_STYLES/CSS_DEF_Print_Friendly.css">

ou

<link rel="stylesheet" type="text/css" href="e:\data\WEB_STYLES\CSS_DEF_Print_Friendly.css">

Et çà fonctionne.

Mais si je boot sous Linux, ce fichier test n'interprétera pas le css car ma partition Win10 "e:" est sous Linux /mnt/sda5 ou /media/sda5

Si je modifie le chemin par

<link rel="stylesheet" type="text/css" href="/data/WEB_STYLES/CSS_DEF_Print_Friendly.css">

Alors
Sous Win10
* Chrome 54: ok
* MS Edge: ok
* Firefox: NON
Sous Linux
ne fonctionne pas avec tant avec Firefox50 que Chrome 54


>As-tu une bonne raison pour vouloir t'en passer ?
Oui, p.ex si je copie mes fichiers sur un smartphone, je veux y accéder sans le web ou je fais un e copie sur clef USB et j'y accède sur un autre PC.

Pour la réponse technique à pourquoi ça ne marche pas sur Firefox sous windows, c'est tout simplement parce que le protocole file:// n'est pas vraiment standardisé (en tout cas pas dans les détails, à ma connaissance), et donc du coup il y a des différences d'interprétation. Pour windows, bêtement, certains interprètent /a/b comme C:\a\b, alors que d'autres pourraient interpréter / comme étant une racine englobant tous les disques et il faudrait alors écrire /c:/a/b ou /c/a/b pour qui ce soit interprété comme C:\a\b (plus proche de la vision linux). Venant de Firefox je ne serais pas surpris qu'ils aient adopté cette dernière interprétation, tout comme je ne serais pas surpris que Chrome ait choisi la première.

Merci, seulement Chrome 54 devrait alors avoir le même implémentation sous Win10 que Linux.
Alors si je comprends bien il faudrait que le localhost soit déterminé au moment de l'ouverture du fichier et le passer en paramètre en fonction de l'OS?
https://en.wikipedia.org/wiki/File_URI_scheme
Modifié par artofit (27 Nov 2016 - 21:56)

et pourquoi pas utiliser des liens relatifs, ça marchera partout non?

 <link rel="stylesheet" type="text/css" href="../WEB_STYLES/CSS_DEF_Print_Friendly.css">

Modifié par kustolovic (28 Nov 2016 - 13:54)

@kustolovic
Cà fonctionne effectivement uniquement si une seule référence

Je comprends pas.
Je pensais que ../ était équivalent à cd..(Win) ou cd ..(Linux)
aussi je pensais que ../data/WEB_STYLES/CSS_DEF_Print_Friendly.css fonctionnerait car on arrivait à la racine (la même pour le css et html).

Maintenant si mon fichier html contient:

<script type="text/javascript" src="../WEB_STYLES/toc_H1-H4_auto_numbered.js">
 </script>
 <link rel="stylesheet" type="text/css" href="../WEB_STYLES/CSS_DEF_Print_Friendly.css">
<script type="text/javascript" src="e:/data/WEB_STYLES/html-table-of-contents.js"></script>
<link rel="stylesheet" type="text/css" href="e:/data/WEB_STYLES/html-table-of-contents.css">

C'est OK
Mais pas

<script type="text/javascript" src="../WEB_STYLES/toc_H1-H4_auto_numbered.js">
 </script>
 <link rel="stylesheet" type="text/css" href="../WEB_STYLES/CSS_DEF_Print_Friendly.css">
<script type="text/javascript" src="../WEB_STYLES/html-table-of-contents.js"></script>
<link rel="stylesheet" type="text/css" href="../WEB_STYLES/html-table-of-contents.css">

Serait-ce interpréter comme une suite d'éxécution de

cd.. 

???

Quid si
E:\data\fichier.htm
E:\Css\cssglobal.css
Modifié par artofit (29 Nov 2016 - 00:05)

le ../ permet simplement de remonter d'un niveau dans la hiérarchie, pour remonter plusieurs niveaux il faut les chainer: ../../../monchemin/monfichier.css

Il n'y a pas d'état qui perdure entre les appels, si certains documents sont trouvés et d'autres pas, c'est qu'il y a une erreur dans le chemin. Par exemple, si le navigateur trouve e:/data/WEB_STYLES/html-table-of-contents.js mais pas ../WEB_STYLES/html-table-of-contents.js, le document HTML est-il bien dans e:/data/UN_DOSSIER_QUELCONQUE/truc.html ? Que dit la console?

a écrit :

Quid si
E:\data\fichier.htm
E:\Css\cssglobal.css

../Css/cssglobal.css ?

Fichier html dans

E:\data\Skills\ITC How to\MM>

Fichiers css & js dans

E:\data\WEB_STYLES>

<!DOCTYPE html>
<head>
 <meta charset="UTF-8">
 <link rel="stylesheet" type="text/css" href="../WEB_STYLES/CSS_DEF_Print_Friendly.css">
   
<script type="text/javascript" src="e:/data/WEB_STYLES/html-table-of-contents.js"></script>
<link rel="stylesheet" type="text/css" href="e:/data/WEB_STYLES/html-table-of-contents.css">

sous Win10:
* OK avec Chrome 54 & MS Edge
* pas de CSS_DEF_Print_Friendly.css appliqué avec Firefox 50, l'autre css et le js sont exécutés.

<!DOCTYPE html>
<head>
 <meta charset="UTF-8">
 <link rel="stylesheet" type="text/css" href="../WEB_STYLES/CSS_DEF_Print_Friendly.css">
   
<script type="text/javascript" src="../WEB_STYLES/html-table-of-contents.js"></script>
<link rel="stylesheet" type="text/css" href="../WEB_STYLES/html-table-of-contents.css">

Sous Win 10, aucun browser n'applique tant les css que le js

Si je déplace le fichier dans le répertoire E:\data\WEB_STYLES> cela fonctionne avec tous les browser, normal puisque cela revient à la commande cd.. alors que je pars cette fois de E:\data\WEB_STYLES>

Je pensais que la synthax correcte des liens vers mes css était ../data/WEB_STYLES/
mais il faut que je remonte à la racine quel soit la profondeur des sous-répertoire sous e:/data/
p.ex.
e:/data/rep1/test1.htm
e:/data/rep1/repA/test1A.htm

Et mettre le chemin e:/data/WEB_STYLES/moncss.css ne fonctionne que sous Windows et pas sous Linux ou Android

RE: http://www.alsacreations.com/astuce/lire/78-quelle-est-la-diffrence-entre-les-chemins-relatifs-et-absolus.html

<!DOCTYPE html>
<head>
 <meta charset="UTF-8">
 <link rel="stylesheet" type="text/css" href="/data/WEB_STYLES/CSS_DEF_Print_Friendly.css">
   
<script type="text/javascript" src="/data/WEB_STYLES/html-table-of-contents.js"></script>
<link rel="stylesheet" type="text/css" href="/data/WEB_STYLES/html-table-of-contents.css">
<title>FFmpeg</title>
<style type="text/css">

Sous Win10:
* Chrome54 & Ms Edge : OK
* FF50: pas d'éxécution css et js

Mais ne fonctionne pas sous Linux, le chemin étant

/mnt/sda5/data/Skills/ITC How to/MM/

je suppose que le browser construit
/mnt/data/WEB_STYLES/ et non /mnt/sda5/data/WEB_STYLES/ comme je m'y attendais

Conclusion:
Window: e:/
Linux: /mnt/sda5/
sous Linux, la partition est montée en sous répertoire...

Le / du chemin absolu fait remonter à la racine système et non à la racine de la partition
Modifié par artofit (29 Nov 2016 - 15:13)

Un chemin absolu sur du protocole file, c'est mort de toute façon.

Par contre le relatif doit fonctionner:

a écrit :

Fichier html dans
E:\data\Skills\ITC How to\MM>

Fichiers css & js dans
E:\data\WEB_STYLES>

=>

  <link rel="stylesheet" type="text/css" href="../../../WEB_STYLES/CSS_DEF_Print_Friendly.css">
  <script type="text/javascript" src="../../../WEB_STYLES/html-table-of-contents.js"></script>

a écrit :

sous Win10:
* OK avec Chrome 54 & MS Edge
* pas de CSS_DEF_Print_Friendly.css appliqué avec Firefox 50, l'autre css et le js sont exécutés.

en relatif ça doit fonctionner avec tous ou avec aucun, soit (comme c'est le cas ici) tu t'es brouté sur les paths et tu as peut-être du cache, soit tu analyses mal les fichiers trouvés contre ceux en échec.
Modifié par kustolovic (29 Nov 2016 - 16:26)