Fonctionnement exacte de la commande “copy” depuis une page web

Hibou57

Comme-même (tm)
VIB
Il apparaît que la commande « copier », ou aussi les commandes similaires, comme « couper » ou glisser, ne s’appliquent pas seulement qu’à ce qui est directement sélectionné. Elle semblent presque toujours s’appliquer aussi aux éléments parents de ce qui est copié. Le problème est de savoir comment est déterminé la racine au delà de laquelle les éléments parents ne sont plus inclus dans la copie, parce que ce que je constate, est inconstant. Je ne trouve aucune référence à ce sujet. Si des gens en connaissent une, ça m’intéresse.

Juste d’abord un autre cas, pour montrer comment les références ont des lacunes. La commandes « copier » fait souvent une copie en ajoutant un attribut “style”, qui est souvent à rallonge. J’ai cherché sur le site du WHATWG, et je ne trouve rien qui spécifie ce comportement. Pourtant, tous les navigateurs le font depuis longtemps. C’est seulement un standard de fait implicite ou c’est spécifié dans un standard que je n’ai pas trouvé ?

Pour en revenir à la question d’origine et donner un exemple de l’inconstance dont je parlais.

Si par exemple il y a dans une page quelque chose comme <H1>Et ici et là</H1>. Si je sélectionne seulement « ici », ce qui sera copié sera <H1>ici</H1> au lieu du fragment de nœud texte, « ici ». Ça peut se comprendre. Maintenant si j’ai <H1>Et <SPAN>ici et là</SPAN></H1> et que je copie « et », ce n’est pas seulement <SPAN>et</SPAN> qui sera copié, c’est <H1><SPAN>et</SPAN></H1>. C’est ce que je voulais dire en disant que la copie remonte dans les éléments parents. Mais elle ne va pas jusqu’à la racine du document. Si dans l’exemple précédent, H1 est dans un DIV, le résultat sera le même.

Déjà là, il faudrait avoir une spécification pour savoir jusqu’où la copie remonte, et je ne trouve rien. Mais ce n’est pas que ça, c’est surtout que c’est inconstant. Si je fais les mêmes choses que plus haut, mais en plaçant le tout dans un contentEditable, alors la copie remonte toujours jusqu’à l’élément qui est contentEditable. C’est à dire que cette fois, avec le H1 dans un DIV, le DIV sera inclue dans la copie, et même l’élément dans lequel se trouve ce DIV.

Ça pose des problèmes, parce que pour savoir comment interpréter une commande « coller », il faut savoir comment se comporte précisément la commande «copier », et comme dit plus haut, ce n’est même pas constant.

Il existe une référence qui définit ces comportements ou il n’y a pas d’autre choix que de bricoler en jouant aux devinettes ?
 

Hibou57

Comme-même (tm)
VIB
Sinon, une solution est, en parant de la racine, de récursivement sortir de son élément parent, un élément qui est le seul élément de son élément parent. Ça me semble une bonne solution et je n’en voit pas de meilleure. Reste que j’aimerais bien savoir si le comportent de la commande « copier » est spécifié quelque part, et si oui, où.
 

Hibou57

Comme-même (tm)
VIB
[…] Si je fais les mêmes choses que plus haut, mais en plaçant le tout dans un contentEditable, alors la copie remonte toujours jusqu’à l’élément qui est contentEditable. C’est à dire que cette fois, avec le H1 dans un DIV, le DIV sera inclue dans la copie, et même l’élément dans lequel se trouve ce DIV.
[…]
Ce n’est même pas constant non‑plus, ça dépend. Ça n’intéresse que peu de gens, mais je rapporte juste au cas où : le comportement dépend aussi du types des éléments englobants. Ce que je souligne en gras dans la citation, valait pour le cas où l’attribut contentEditable est vrai sur un élément PRE, mais depuis que j’utilise un élément OUTPUT, la copie va moins loin dans les ancêtres. Idem, je me demande si c’est spécifié quelque part ou pas.

Aussi, c’est plus tordu que rapporté dans le premier message. Le navigateur, au moins Chrome (à voir avec les autres), ne fait pas que inclure des ancêtres dans le copie, il créé aussi parfois des éléments qui n’existaient pas. Je ne sais pas si c’est toujours le cas, mais dans mes observations c’est toujours un SPAN, avec dans l’attribut style une chose suspecte qui me semble le trahir : “display: inline !important”. C’est ce détail qui pour être utile à connaitre pour les quelques gens que la question intéresserait aussi.

Toujours la guerre contre le navigateur, ça ne change pas même depuis le temps. Quel cirque …
 
.... Le navigateur, au moins Chrome (à voir avec les autres), ne fait pas que inclure des ancêtres dans le copie, il créé aussi parfois des éléments qui n’existaient pas. Je ne sais pas si c’est toujours le cas, mais dans mes observations c’est toujours un SPAN, avec dans l’attribut style une chose suspecte qui me semble le trahir : “display: inline !important”. C’est ce détail qui pour être utile à connaitre pour les quelques gens que la question intéresserait aussi.

Il y a effectivement des attributs qui sont ajoutés par défaut chez Google Chrome. Cela peut créer des espaces blancs dans tes blocs surtout dans le header.

Il existe 3 solutions pour éliminer ça.

1) Utiliser un sélecteur universel avec un padding et à margin à 0.

Code:
* {
    padding: 0;
    margin: 0;
}

2) Utiliser un body avec un padding et un margin à 0.

Code:
body {
    padding: 0;
    margin: 0;
}

3) Utiliser la méthode brute en ajoutant les attributs du margin avec des valeurs négatives.

Code:
.header {
  background-color: #470ff4;
  height: 80px;
  margin-top: -0.3em;
  margin-bottom: 0em;
  margin-left: -0.3em;
  margin-right: -0.3em;
}

Ce problème d'espacement ne touche pas uniquement certains navigateurs mais aussi certains IDE online notamment Stackblitz.com.
J'ai dû ajouter cette ligne:

Code:
.header {
  background-color: #470ff4;
  height: 80px;
  margin-top: -0.3em;
  margin-bottom: 0em;
  margin-left: -0.3em;
  margin-right: -0.3em;
}


Voici le code:

component.HTML
Code:
<div class="header">
    <div class="languageSelect">
        <a href="#" *ngFor="let l of supportedLangs;" (click)="switchLanguage(l); false; ">
            {{ l | uppercase}} <span> | </span>
        </a>
    </div>
</div>
<h2>{{ 'demo.text' | translate }}</h2>

component.TS

Code:
@Component({
  selector: 'my-app',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent implements OnInit {
  supportedLangs: string[];
  constructor(
    private translate: TranslateService,
    private LS: LocalStoreService,
    public _location: Location,
    @Inject(DOCUMENT) private _document: Document
  ) {}
  ngOnInit() {
    this.supportedLangs = ['fr', 'nl', 'en', 'de', 'es', 'it', 'pt'];
    this.translate.setDefaultLang('fr');
    console.log('hello ' + this.supportedLangs);
  }
  switchLanguage(lang) {
    if (lang == 'uk') {
      lang = 'en';
    }
    this.translate.onLangChange.subscribe((event: LangChangeEvent) => {
      this.LS.setItem('LX_Current_Language', event.lang);
    });
    this.translate.use(lang);
  }
}

component.CSS

Code:
body {
  margin: 0;
  padding: 0;
}
a {
  text-decoration: none;
  color: #fff;
}
.header {
  background-color: #470ff4;
  height: 80px;
  margin-top: -0.3em;
  margin-bottom: 0em;
  margin-left: -0.3em;
  margin-right: -0.3em;
}
.languageSelect {
  float: right;
  right: 75px;
  position: relative;
  top: 8px;
  padding: 25px;
}
 

Hibou57

Comme-même (tm)
VIB
Que dit la w3c ? C’est le cas sur tous les navigateurs ?

++
Le W3C n’est plus en charge de ce standard, maintenant c’est le WHATWG. Ils ne mentionnent rien de ça et alors je me demandais d’où viennent ces comportements qu’on retrouve dans tous les navigateurs, mais chacun à leur manière.

J’en suis venu à penser que les éléments avec l’attribut contenteditable sont vus comme des éditeurs what you see is what you get, que les navigateurs les implémentent en se souciant plus de l’apparence visuel du texte, plus que des données qu’il représente. Si c’est un standard de fait, j’imagine qu’il il y a peu de chances que ça change un jour.
 
Dernière édition:
Mon lien ne fonctionne plus, voici le code:


PS: Stackblitz.com est vraiment un bon joujou pour apprendre la programmation.
 

AbuIlyass

la ilaha illa Allah wahdaho la charika lah.
Il apparaît que la commande « copier », ou aussi les commandes similaires, comme « couper » ou glisser, ne s’appliquent pas seulement qu’à ce qui est directement sélectionné. Elle semblent presque toujours s’appliquer aussi aux éléments parents de ce qui est copié. Le problème est de savoir comment est déterminé la racine au delà de laquelle les éléments parents ne sont plus inclus dans la copie, parce que ce que je constate, est inconstant. Je ne trouve aucune référence à ce sujet. Si des gens en connaissent une, ça m’intéresse.

Juste d’abord un autre cas, pour montrer comment les références ont des lacunes. La commandes « copier » fait souvent une copie en ajoutant un attribut “style”, qui est souvent à rallonge. J’ai cherché sur le site du WHATWG, et je ne trouve rien qui spécifie ce comportement. Pourtant, tous les navigateurs le font depuis longtemps. C’est seulement un standard de fait implicite ou c’est spécifié dans un standard que je n’ai pas trouvé ?

Pour en revenir à la question d’origine et donner un exemple de l’inconstance dont je parlais.

Si par exemple il y a dans une page quelque chose comme <H1>Et ici et là</H1>. Si je sélectionne seulement « ici », ce qui sera copié sera <H1>ici</H1> au lieu du fragment de nœud texte, « ici ». Ça peut se comprendre. Maintenant si j’ai <H1>Et <SPAN>ici et là</SPAN></H1> et que je copie « et », ce n’est pas seulement <SPAN>et</SPAN> qui sera copié, c’est <H1><SPAN>et</SPAN></H1>. C’est ce que je voulais dire en disant que la copie remonte dans les éléments parents. Mais elle ne va pas jusqu’à la racine du document. Si dans l’exemple précédent, H1 est dans un DIV, le résultat sera le même.

Déjà là, il faudrait avoir une spécification pour savoir jusqu’où la copie remonte, et je ne trouve rien. Mais ce n’est pas que ça, c’est surtout que c’est inconstant. Si je fais les mêmes choses que plus haut, mais en plaçant le tout dans un contentEditable, alors la copie remonte toujours jusqu’à l’élément qui est contentEditable. C’est à dire que cette fois, avec le H1 dans un DIV, le DIV sera inclue dans la copie, et même l’élément dans lequel se trouve ce DIV.

Ça pose des problèmes, parce que pour savoir comment interpréter une commande « coller », il faut savoir comment se comporte précisément la commande «copier », et comme dit plus haut, ce n’est même pas constant.

Il existe une référence qui définit ces comportements ou il n’y a pas d’autre choix que de bricoler en jouant aux devinettes ?

Salam,

ça ressemble pas à ça ton problème?

 

Hibou57

Comme-même (tm)
VIB
Salam,

ça ressemble pas à ça ton problème?

Non, parce que le text/plain n’est pas une solution convenable, vu que les éléments sont attendus, seuls ceux ajoutés ne le sont pas. L’attribut style est facile à supprimer, mais il est plus difficile de supprimer des éléments ajoutés par le navigateur, faute de savoir exactement lesquels le sont. J’ai déjà trouvé une solution approximative que j’avais rapporté.
 
Haut