Postscriptum : comme si la pseudo-classe n'existait pas

Salut,

J'ai dans la css :
body > .ueDiv:first-child h1{
	page:headingaprestoc;
}

et

@page headingaprestoc :left {
	@top-left {
		content: "";
	}
	background-color: orange;
}

Je m’attends à ce que ça fasse une page orange seulement pour le premier ueDiv, mais ça le fait à tous. C’est comme si la pseudo-classe :first-child n’avait aucun effet :confused:

@david_rivron

Postscriptum a des restrictions sur les sélecteurs utilisables. Un élément « coupé » va se retrouver dupliqué sur la page suivante, sans la présence de ces frères précédents, donc le sélecteur :first-child sera valide pour chaque page le contenant.
PS ajoute les pseudos classes :-ps-breaked-before et :-ps-breaked-after pour identifier les éléments coupés et traiter ces cas. Exemple :

body > .ueDiv:not(:-ps-breaked-before):first-child h1 {
	page:headingaprestoc;
}

Ok, j’a compris.

Parcontre j’ai mis le code que tu proposes et ça devrait marcher puisqu’en effet, là où je veux que ça s’applique j’ai :
image

Et là où je ne veux pas que ça s’applique j’ai :
image

C-a-d que dans le premier cas je n’ai pas -ps-breaked-before, et dans le 2ème si. Donc il ne devrait pas appliquer le style page:headingaprestoc au deuxième cas.

Or il le fait :confused:

J’avais mal compris ton besoin mais je pense qu’il y a problème d’usage du :first-child. Ce sélecteur ne fonctionnerait pas sur la version non paginée de la page. body > .ueDiv:first-child va sélectionner un .ueDiv si celui-ci est le premier enfant de body, ce qui n’arrive pas avant que PS ne se lance car le premier enfant de body est section.front.

J’ai du mal à comprendre ton besoin : pourquoi vouloir mettre autant en valeur uniquement la première division ? Les autres ont à priori la même importance.

Le besoin est le suivant :
je fais démarrer les chapitres sur une page droite. Ceci à pour effet de mettre une page gauche vide entre la toc et le premier chapitre, et éventuellement une page gauche entre la fin du premier chapitre et le second chapitre.
Le truc c’est que la page gauche après la toc, je ne veux absolument rien dedans, et celle avant le 2ème chapitre je veux certaines choses en entête, numéro de page, …
Donc j’ai besoin de différencier les deux cas.

Ok, je comprends mieux. Pour ce cas, il faut jouer avec le pseudo sélecteur de page :blank et il n’y aurait normalement pas besoin de définir un style de page supplémentaire. Je dis bien « normalement » car cela m’a permis de voir qu’il y a des problèmes à ce niveau.

Je détaille.

On place un saut de page à droite pour chaque section : body > section { break-before: right; }
Et on définit un style de page nommée pour les sections de de partie :

body > .uc,
body > .ua,
body > .quiz,
body > .ueDiv {
	page: part;
}

La règle suivante devrait supprimer la marge de toutes les pages blanches par défaut.

@page :blank {
  @top-left {
    content: none;
  }
  ...
}

Et la suivante la rétablir pour les pages blanches entre les sections de partie :

@page part:blank {
  @top-left {
    content: string(partTitle);
  }
  ...
}

Malheureusement, dans la version actuelle de PS, la page blanche après la toc est « nommé » alors qu’elle ne devrait pas l’être, et cette page ainsi que les autres pages blanches entre les parties sont considérées comme étant les premières du groupe de page alors que cela devrait être la suivante (cad celle portant le titre).

Je vais corriger cela. En attendant, tu peux peut-être t’en sortir en passant en « free », c’est à dire en utilisant directement un sélecteur d’adjacence sur l’élément ps-page. Exemple : ps-page[ps-name=toc] + ps-page {}.

Ça fonctionne. En fait ce hack est très pratique ! On peut aller faire des traitements très particuliers et en plus il suffit d’inspecter le code depuis l’app PS pour voir comment est construit le contenu.
Donc pour que la page suivante à la toc soit vide j’ai simplement fait :

ps-page[ps-name=toc] + ps-page *{
	display: none
}

Il faut tout de même éviter le plus possible ce genre de sélecteur : ces éléments sont internes au fonctionnement de PS et cela pourrait ne plus fonctionner sur les prochaines versions si la façon de gérer les @page change.

ok, entendu.

Pour information, le problème sur les pages blanches a été corrigé et sera dans la prochaine version de l’extension.