De la formation 2019 : les suites début 2020

Achevant en juin 2019 une formation de Développeur web et web mobile (DWWM) chez WebForce3, je pensais me remettre à D3.js. C'était sans compter sur l'offre faite par le centre de formation de rester en tant que stagiaire. J'ai eu la chance de me consacrer alors à un projet passionnant : une interface web de suivi financier.
Des données tabulaires, des calculs entre elles, une interface aux petits oignons (responsive, accessible, valide), du JavaScript "orienté objet" (exploité dans sa base prototypale), du back PHP, une persistance MySQL, des API…

C'est ce projet que j'ai soutenu pour obtenir le titre professionnel.

Avant de pouvoir, en décembre, ajouter au projet la couche de dataviz que je m'étais promise (D3, quand tu nous tiens…), j'ai intégré une formation faisant suite à DWWM : Concepteur développeur d'applications, chez Simplon (à la fois partenaire et concurrent de WebForce3).
Après PHP, une super immersion dans l'environnement Python. Avec toute l'exigence et le bénéfice d'une pédagogie axée sur l'autonomie et la solidarité.

Entre temps, Rosalie Debesse m'avait fait le grand plaisir de me demander, pour son travail de community manager chez WebForce3, d'allier communication et syntaxe CSS : .web{ top: 100%; }, ou code.experience{ background: gold; }…

Du côté de Photoshop enfin, continuant un apprentissage du photomontage entrepris en juin 2018, j'ai repris la publication sur mon compte Instagram 'gaetlan'. En me promettant un montage par semaine.
Je sais le risque de telles promesses ; mais si je l'écris ici, avec beaucoup de chance ça n'aura pas été innocent.

2-3 ans après

Retour à D3.js, étant sur le point d'achever une formation full-stack - en complément de mon expérience front-end.

Dans le même temps, un bug que j'avais signalé sur Bugzilla en février 2017, concernant un problème de rendu SVG sur Firefox (rendu en lien avec la taille des caractères ; bug de priorité 3), a trouvé ces jours-ci une solution.

Edit du 8 septembre :
en stage chez WebForce3, d'où je sors en tant qu'étudiant, j'approfondis ma pratique du JavaScript (principalement natif) ainsi que mes compétences dans la réalisation d'une interface en lien avec des données.
Bref, une bonne partie de ce que j'apprécie en front-end, tout en plongeant dans les arcanes du back. Last but not least, l'ambiance y est des meilleures.

CSS alternatifs aux pseudo-classes avec PHP et Modernizr

PHP paramètre JavaScrit qui charge le cas échéant des CSS alternatifs : eux-mêmes générés via PHP uniquement dans les cas nécessaires…
exemple.

Il est difficile lors de l'exécution PHP, d'anticiper des particularités telles que la présence de JavaScript, l'interprétation de HTML5, le niveau de CSS supporté etc. Il faut en général générer une page qui s'adaptera aux contraintes du front une fois chargée par le navigateur.

Il reste possible de ne générer de solutions alternatives aux CSS avancés que dans les cas précis où cela soit nécessaire.

Notes d'animation et de stylage

Une interface de losange animé pour rassembler quelques notes :
equatorium.net/e1/an--animations/an-losange.html

Enchaînement de durées "aléatoires" pour 'transition'

Chaîner des transitions CSS de durée pseudo-aléatoire sur le mode 'toggle' sans latence.

:target : pseudo-classe rafraîchie avec pushState()

En évoquant il y a trois jours ':target' et son manque d'harmonie avec une url re-formulée par "pushState()", se posait la question du problème sur IE 10 - Windows ne fait pas l'écran à la maison le week-end.
Le problème y est identique. Les solutions proposées alors fonctionnent bien sur IE 10 et 11, mais sans le déplacement dans l'historique - boutons "back" et "forward" via notamment le clavier.

Rafraîchir ':target' sans s'occuper du DOM

:target : pseudo-classe à concilier avec pushState(), et IE 8

Edit du 31/07/2014 : voir aussi :target : pseudo-classe rafraîchie avec pushState().

La pseudo-classe CSS 3 ':target' sélectionne l'élément du DOM pouvant correspondre à une ancre dans l'url. Une navigation interne à la page, d'ancre en ancre, se fait en général directement, et l'un des soucis serait alors de savoir si l'on veut tenir compte d'Internet Explorer 8.

Et IE 8

Il y a une réponse avec 'onhashchange' : La pseudo-classe ':target‘ : alternative pour IE 8.

"pushState()" ne rafraîchit pas ':target'

Dès que l'on rajoute une couche de liaison entre navigation interne et l'url de la page, une question épineuse se pose.

Outil CSS : générer des pseudo-classes CSS ':nth-child()'

J'ai mis en ligne un générateur de pseudo-classes CSS "nth-child(in+o)" : Générer des pseudo-classes CSS ':nth-child()' \ Canopée / Equatorium.

Avec le projet de le compléter : avec une couche WAI-ARIA ; et avec des graphiques SVG - reste à voir si je saurais porter l'accessibilité dans le SVG.

Note janvier 2016 : en cours de refonte totale.

Note CSS : unités accessibles pour font-size

Cf. article de Matthieu Bué : Font-size, Responsive et Accessibilité : le Bon, la Brute et le Truand » Webdesign Friday (#wdfr)

Elément body réglé à cinq huitièmes (62,5%) de 16px (réglage agent par défaut) càd élément body réglé à 10px obtenu au 'reset' par :
body {font-size: 62.5%}

L'unité 'em' est préférable à l'unité 'px' quand on tient compte d'utilisateurs accoutumés au maniement de vieux IE ;
et formellement aussi, de référentiels d'accessibilité
(et du gadget A⁺)
avec l'inconvénient de calculs pour compenser les héritages.

CSS3 résout la question de l'emboîtement avec l'unité 'rem' ('r' pour "root")
NB : non encore personnellement testé

En tentant a priori 'rem' CSS3 avec compatibilité IE7-8  :
h2{font-size: 2.2em; font-size: 2.2rem;}
comment traiter théoriquement les niveaux intermédiaires ?
- si l'on y évite 'font-size', quelle utilité alors pour 'rem' ?
- sinon multiplication des calculs :
.divpourh2 {font-size: 1.1em;}
h2 {font-size: 2em; font-size: 2.2rem;}
rendant de nouveau 'rem' superflu.

"Commentaires" le 4 mars 2014

1) Ce n'est pas une bonne idée de régler une font-size de base.
Eviter 62.5% car on ne sait pas de quoi in fine,
certains rares navigateurs n'adoptant pas 16 px par défaut 
- le 13 juin 2014 : la détection de '.css("font-size")'
par jQuery renvoie une valeur en pixels, 
qui est celle de ce réglage si l'élément s'affiche en '1em'.
Et surtout liberté de l'utilisateur d'adapter
ses possibilités de lecture via le paramétrage du navigateur.

2) Pour savoir de quoi sont 62,5%, il faudrait contrarier
d'éventuelles préférences utilisateur, avec
html {
 font-size: 16px;
}
NB : mais en ce cas autant imposer directement
html {
 font-size: 10px;
}
sans prendre la peine du 62.5

Faut-il contrôler le rendu à ce point ?

Sans doute vaut-il mieux :

- s'abstenir de définir 'font-size' pour html et pour body, 
et prendre la peine de calculer en em en prenant 
comme base probable 16px - avec, dans certaines zones au pixel près
(mentions légales ?), une zone intermédiaire à 10px,
pour avoir en-dessous de l'em décimalement précis

- dans des projets à trop forte contrainte graphique :
html {
 font-size: 10px;
}
"et basta"