Re: [CSS1] Appel a relecture

Eric Schreiner <Eric.SCHREINER@agriculture.gouv.fr> [2001/08/1 10:00]

Éric,

> Bonjour à tous,
> bonjour Jean-Jacques,
> 
> Et bien, contrairement à mon espoir initial, ce ne sera pas le dernier
> envoi de remarques.
> Il me reste les parties "8", "9" et les 7 appendices à traiter.

  [...]
  
> ______
> 
> Glossaire :
> - Je crois avoir compris, au 5.6.1, que "boîte de ligne" est une
> nouvelle notion
>   à ne pas confondre ni avec "boîte en ligne" (d'aprés 4.2), ni avec
> "boîte dans la ligne",
>   ni "boîte pour la ligne", ni "boîte par ligne".
>   Si vous confirmez... facile à visualiser mais coton à expliquer, et
> donc à comprendre.
>   Cela doit donner quelque chose comme :
> 
>   ligne avec au début un contenu d'un élément texte puis [début de la
> boîte
>   de ligne et son contenu 'inline' fin]

Tout le modéle de mise en forme de CSS repose sur un concept de boîtes, les unes
pouvant contenir les autres. J'ai utilisé le mot "boîte" qui est le plus proche
équivalent pour l'anglais "box", mais le sens du mot français "cadre" aurait pu
convenir aussi, si ce n'est le risque de confusion avec le canevas.

Ces boîtes sont en général rendues dans une fenêtre de navigateur qui est est
variable. Les boîtes ont donc également des dimensions variables.
Par exemple, soit un paragraphe (inscrit dans sa propre boîte) ne contenant que
du texte. Celui-ci peut ne pas tenir en entier sur une seule ligne, ce qui va
entraîner visuellement une interruption de la ligne et un transfert de la suite
du texte à une ligne suivante, et ainsi de suite.

Chaque ligne de texte s'inscrit dans sa propre boîte, la boîte de ligne
(j'aurais pu transcrire en "boîte de la ligne", peut-être plus clair).
Ainsi quand on voit un paragraphe s'étalant sur plusieurs lignes à l'écran, cela
correspond en fait selon CSS à un empilement de plusieurs boîtes de ligne qui
ont été découpées pour tenir exactement dans la boîte du paragraphe.

Maintenant, si en plus de texte, on rajoute des images ou tout autre élément, il
faut considérer ceux-ci comme autant de boîtes qui viennent "s'emboîter" à leur
tour dans la boîte de ligne. 

Bref, le sens de "boîte de ligne" devrait maintenant t'apparaître et boîte "en
ligne", "dans la ligne" correspondraient à une image telle que dans l'exemple
ci-dessus. Bon, sans vouloir comprimer toute la spécification en 40 lignes, il
faut aussi faire la différence entre les éléments de type "en ligne" et ceux de
type "bloc". La boîte de ces derniers occupant exclusivement toute la largeur de
l'élément contenant : il ne peut y avoir deux types "bloc" sur le même plan
horizontal.

> - On dit "un URL" ou "une URL", ou est-ce indifférent ? cf. 6.4 et ses
> remarques

URL = Uniform Resource Locator. Le genre de "locator" ne peut être que neutre,
donc je mets le tout au neutre, c.à.d. un URL.

> - On peut utiliser "à-régle(s)" et "@régle(s)", mais je préfererais
> qu'un seul des deux soit utilisé.
>   En effet, il s'agit d'une nouvelle notion qu'il est préférable de
> représenter sous la même forme
>   cf. 7.1
>   pour ma part, le "@" me semble mieux adapté
> - idem pour "à-mot-clé" et "@mot-clé"

Le probléme avec la forme "@quelquechose" tient dans le fait que les auteurs de
l'original ont utilisé la prononciation anglaise du caractére "@" (c.à.d. "at").
D'où le nom anglais "at-rules", plus un jeu de mot qu'autre chose. C'est
typiquement le genre de termes impossibles à transcrire dans une autre langue,
sauf s'il existe une possibilité de créer un nouveau mot qui soit aussi issu
d'un jeu de mot comme pour l'original.

Je tiens plutôt pour "à-régle" (ou peut-être "régle-à") que pour "@régle" :
comment prononcer le dernier en français ? Une "autre solution" à envisager :
conserver les termes anglais, dont l'usage est peut-être déjà consacré.

Apparemment, personne ne s'exprime sur le sujet. Les vacances ? La chaleur ?

> Question :
> - non précisé au "6.3 unité de couleur", ni en v.o. ni dans la
> traduction : pour le RGB par code #RGB ou #RRGGBB
>   les chiffres héxadécimaux a..f sont-ils acceptés aussi en majuscule ?
>   Des exemples les utilisent, mais je m'attendais à le voir spécifié
> dans cette partie du document.
>   En fait elle n'apparaît que vers la fin : insensibilité à la casse

Il ne faudrait pas non plus récrire la spécification :-)

> Remarques générales :
> - "UAs" est traduit par "agent utilisateur" jusqu'au 5.4.5 inclus, puis
> en "client"

Cela était rétabli dans la version de la traduction mise en ligne le 31 juillet.


> Pour chaque remarque je précise :
> - Le numéro et le titre de la section/chapitre,
> - Le paragraphe (§), considérant qu'un exemple, ou qu'un schéma, constitue un
> seul paragraphe,
> - Le texte ou extrait de texte proposé en remplacement,
> - Le texte ou extrait de texte de la traduction en question (selon moi ;-) )
> 
> ___________________
> Liste des remarques
> 
> ___
> 5.4.2
> §2
> - je préfère quelque chose comme "La valeur indiquée par <longueur> s'ajoute
> l'espace par défaut séparant les lettres. ..."
> à "La valeur indiquée par <longueur> s'ajoute à l'espace entre lettres par
> défaut. ..."

Remplacé par : "...à l'interlettrage par défaut."


> ___
> 5.5.17 'border-style'

> §6 'double'
> j'aurais tendance à écrire "entre eux" et non "entr'eux"

Ici c'est vraiment du chipotage ;-)
Bon je change...

> ___
> 5.5.23 et 5.5.24
> §4 bouh c'est compliqué !
> Si ce qui suit n'est pas faux, autant l'écrire quelque chose comme
> "Si les valeurs 'width' et 'height' d'un élément remplaçable sont à 'auto',
> leurs valeurs par défaut, le cas échéant l'élément de substitution aura les
> dimensions de l'élément remplacé."

Remplacé, remplaçable, substitution... ouille.
Que dis-tu de cela :
"Quand les valeurs des propriétés 'width' et 'height' d'un élément remplacé sont
à leur valeur par défaut 'auto', celles-ci adoptent les dimensions intrinsèques
de l'objet qui le remplace."

> ___
> 5.5.25 'float'
> §2
> je préfère "... est considéré comme un type "bloc" ..." ou "... devient de
> type "bloc" ..." plutôt que "... prend un type "bloc" ..."

"acquiert un type "bloc"

> ___
> 5.6.1 'display'

> §4 

> - insérer 'inline' pour avoir "... éléments 'inline' mais ..." au lieu de "...
> éléments mais ..."

Au début du paragraphe, plutôt ceci :
"crée une boîte dans le prolongement de la ligne du contenu qui précède."
et comme indiqué :
" s'appliquent aux éléments ainsi créés mais..."

> ___
> 5.6.2 'white-space'
> §2
> je trouve "... blancs ...(... espaces ...)..." très sioux, entre "blancs entre
les lettres" représentés et "caractères espaces entre les lettres" du contenu.
> si voulu... chapeau !

Sioux ? c'est bien ou c'est tangeant ?
Du coup, je mets "blancs fusionnent" au lieu de "espaces fusionnent".

> ___
> 5.6.5 'list-style-position'
> §1 ERREUR (sauf erratum déjà pris en compte dans la première version proposée
> avec laquelle je travaille)
> la v.o. indique "Inherited : yes" et la traduction "Héritée : non"

Corrigé.

> ___
> 6.3 Unités de couleur
> §2
> juste pour te faire criser, cette énumération de <valeur> devrait à mon sens
> utiliser la charte graphique '<valeur>'
> et donc plein de <'> à insérer (16 fois !) je te laisse faire, même si cela
> m'aurais moins coûter de le faire
> plutôt que de t'écrire tout ça
> (désolé il est très tard, j'aimerais finir cette nuit, et je n'ai pas pu m'en
> empêcher :-))) )

Ce sont des erreurs à signaler à qui de droit. Je te laisse la paternité de
cette découverte ;-)

> ___
> 6.4 URL
> - §1 : "une URL", §3 "l'URL proprement dit", puis "l'URL elle-même", §4 "une
> URL", §5 "un URL"
> - dernier § : l'exemple en v.o. est "url(yellow)" et dans la traduction
> "url(yellow.png)"
> erratum pris en compte ? je suis sûr de travailler sur la version du 27/07 de
> la traduction !

Ici, c'est mon interprétation. C'est plutôt sans danger.
La dernière version en date sera celle que j'envoie tout de suite, donc en date
du 1er août.
<http://www.yoyodesign.org/doc/w3c/css1/> (230ko)
ou bien
<http://www.yoyodesign.org/sip/css1.zip> (63ko)

> ___
> 7 Conformité au CSS1

> §4
> je préfère "donne un rendu des feuilles de style CSS1 valides" à "produit des
> feuilles de style CSS1 valides"
> §5
> même remarque en moins clair, "produit" introduit pour moi une notion de
>génération de fichier dans ce contexte
> je préfère quelque chose comme "Un agent utilisateur qui s'appuie sur CSS1
> pour afficher les documents et donne le rendu des feuilles de style CSS1..."
> à "Un agent utilisateur qui utilise CSS1 pour le rendu de documents et pour la
> production de feuilles de style CSS1" 

Pour §4 et §5, joker !
On peut considérer deux aspects :
Le terme "agent utilisateur" revêt un sens très général (je pense que c'est
voulu) où il peut tout aussi bien signifier un logiciel de création comme
d'interprétation des feuilles de style. Et c'est bien ce qui ressort de la
progression du chapitre 3 vers le chapitre 5 :
1 - l'agent est conforme s'il interprète correctement
2 - l'agent est conforme s'il produit correctement
3 - l'agent est conforme s'il interprète et produit correctement. S'il
interprète correctement mais produit du n'importe quoi, il n'est pas conforme.
Il est vrai que l'interprétation et la production (des feuilles de style) sont
généralement séparées, mais il me semble que Netscape dans certaines versions
soit capables des deux (Composer) et peut-être que les auteurs ont-ils voulu
tenir compte de cette situation.


> ___
> 7.1 Compatibilité ascendante de l'interprétation

> §... euh, juste après : { causta: "}" + ({7} * '\'') }
> il me semble que "Un ensemble de règle consiste en une chaîne de
> sélecteurs..."
> est plus conforme que "Un règle consiste en une chaine de sélection..."
> à la v.o. (ruleset) et à "Terminologie" en début du document (sélecteur)
> - occurences de "chaine de sélection" si remarque prise en compte
> § euh + 3
> - occurences de "chaine de sélection" si remarque prise en compte
> §euh +6

C'est un peu le même genre de difficulté rencontrée pour la traduction de
"line-box" qui a été résolue assez facilement en "boîte de ligne".
On a le choix entre garder ce "chaîne de sélection" et un hybride, à l'anglaise
"chaîne-sélecteur". La partie "string" du mot composé anglais se réfère à
"chaîne de caractères" plutôt qu'à une notion de sélecteurs qui se suivent en
chaîne. Je ne change pas, mais je note la typo sur "Un règle...".

> - je propose "doivent aller par paire(s)" au lieu de "... doivent aller de
> pair. ..."
>   car je ne suis pas sûr de l'utilisation correcte de "pair"

Aller de pair = aller par deux ou aller ensemble

> §euh II + 4, point 5
> "(c.-à-d., "\7B" " est conforme à la v.o. mais pas "(c.-à-d., "\7B" ({)" 

Pour une fois que j'essayais d'être un peu pédagogue...
Il y en a beaucoup qui savent que la représentation de l'accolade ({) est "7B"
en notation hexadécimale ? :-)

> bon j'arrête là car je suis HS et commencer des listes de références, de noms
et une grammaire ne me tente pas avant d'avoir fait dodo
> a plus

Merci,

JJS.
--
/* home page <http://www.yoyodesign.org/> */
/* public key id: 9eb99ddb <http://www.keyserver.net/> */

Received on Wednesday, 1 August 2001 11:40:59 UTC