Visto che riguarda la validazione, che ha una certa importanza, sarebbe interessante avere un'opinione "ufficiale" sullo spostamento del data-element dal link <a> a un tag contenitore...
Cosa peraltro su cui io sono assolutamente d'accordo: anche noi l'abbiamo fatto, nel nostro fork, più o meno come proposto in questa PR.
Infatti:
1) la documentazione parla di un semplice "tag HTML" qualunque su cui mettere il data-element, non necessariamente un link;
2) il validatore controlla infatti esattamente quello, cioè che un tag ci sia, e che abbia dentro almeno tre caratteri di testo;
3) da un punto di vista "organizzativo", il tag serve alla validazione del Servizio, e dunque sarebbe più giusto che stesse nel template del Servizio, non in una card inclusa, che può venire usata anche altrove e non deve venire "accoppiata" specificatamente con i servizi.
L'implementazione attuale del template Servizio fa confluire le due cose, e i Contatti sono di fatto (solo) l'U.O. responsabile.
A backoffice però, ci sono sia l'UO che i Punti di contatto, distinti (ma entrambi nella stessa sez. Contatti [^1]).
Nelle statiche, l'esempio raffigura solo una U.O. (e nessuna sezione specifica solo per l'UO responsabile).
Lo prendiamo come conferma del fatto che UO e Contatti sono intercambiabili? E dunque che il data-element dovrebbe marcare l'intera sezione contatti (come in questa PR), e non un singolo contatto o UO (come ora nella card)?
[^1]: NB: nello schema di architettura, nel Servizio sia l'UO sia i Punti Contatto sarebbero sempre obbligatori. Va inteso in modo elastico? Se no, si può immaginare che nascerebbe qualche problema pratico con i Comuni, tra l'altro.
Sì, infatti: quindi, averne due nella codebase (il <div> in single-servizio.php e l'<a> in card.php), entrambi con lo stesso attributo data-element, uno dei quali in realtà non viene usato (card)... credo potrebbe creare qualche confusione.
Ad es, qualora si stia investigando la causa di una ev. mancata validazione; ma anche come principio di ordine generale (il codice dovrebbe in un certo senso sempre documentare il proprio senso e scopo, minimizzando le parti inutili e non funzionali).
Tra l'altro, dovessero per caso essere visualizzati entrambi i tag, il validatore con $('[data-element="service-area"]').text() aggregherebbe tutto il testo contenuto in entrambi, falsando il test.
Qualche dubbio sul fatto di avere il data-element sul contenitore invece che sul link era venuto proprio guardando il validatore. Il test viene fatto contando i caratteri, il che ha forse più senso quando si tratta di un singolo nome di una UO (o di un contatto), come sarebbe con un link, piuttosto che con un intero blocco di testo, che magari ha dentro altri elementi.
Ma sono indizi un po' labili, da cui cercare di intuire le "vere intenzioni" del modello.
Fatto sta che ora avere il data-element su un contenitore sarebbe sarebbe più logico.
@enrimk in ogni caso, questo template di card è specifico per Unità Organizzativa, quindi il rischio di essere utilizzato da altre parti dovrebbe essere minino se non zero.
Dopo l'aggiornamento ho notato che quando si crea un nuovo servizio non funziona il pulsante 'pubblica' ma rimane sempre come bozza e non c'è modo, quindi, di creare nuovi servizi.
Tecnicamente no. Però aumenta le interdipendenze tra template, rende meno modulare e più fragile la struttura, più suscettibile a errori, più difficile da eventualm. debuggare e riorganizzare. Magari non di molto, ma di un po' sì. Se è evitabile, lo eviterei.
Infatti, deve essere successo qualcosa del genere nella versione attuale: il template della card è stato modificato (per il Luogo), e il Servizio non si valida più (v. #437 ).
Viene usato sia per l'UO, sia per i Contatti. Nel primo caso il tag viene specificato come *[data-element="service-area"]. Nel secondo, come div[data-element="service-area"], il che renderebbe non conforme l'attuale implementazione (sul tag <a>) . Se il tag div venisse effettivamente controllato dal validatore, cioè; cosa che non è.
Era anche per cercare di evitare l'inseguimento alla cieca dei data-element nei template inclusi, che questa PR proponeva di semplificare spostando il tag alla radice.
Fix che risolve un problema della pagina single-servizio.php.
Descrizione
Il modello non era conforme al Criterio C.SI. 1.3: non era presente un tag
Checklist
Per evitare fraintendimenti, è il caso anche di togliere il data-element dalla card? https://github.com/italia/design-comuni-wordpress-theme/blob/e841b4685839358127ade07cb449a3c0cc3130f2/template-parts/unita-organizzativa/card.php#L43
Così non ci si confonde riguardo a quale tag viene usato per la validazione.
Visto che riguarda la validazione, che ha una certa importanza, sarebbe interessante avere un'opinione "ufficiale" sullo spostamento del data-element dal link
<a>a un tag contenitore... Cosa peraltro su cui io sono assolutamente d'accordo: anche noi l'abbiamo fatto, nel nostro fork, più o meno come proposto in questa PR.Infatti: 1) la documentazione parla di un semplice "tag HTML" qualunque su cui mettere il data-element, non necessariamente un link; 2) il validatore controlla infatti esattamente quello, cioè che un tag ci sia, e che abbia dentro almeno tre caratteri di testo; 3) da un punto di vista "organizzativo", il tag serve alla validazione del Servizio, e dunque sarebbe più giusto che stesse nel template del Servizio, non in una card inclusa, che può venire usata anche altrove e non deve venire "accoppiata" specificatamente con i servizi.
C'è però un punto di ambiguità nella documentazione (o un refuso?), che andrebbe chiarito.
Il data-element "service-area" viene menzionato sia riguardo alla U.O. responsabile, sia riguardo ai Contatti.
L'implementazione attuale del template Servizio fa confluire le due cose, e i Contatti sono di fatto (solo) l'U.O. responsabile. A backoffice però, ci sono sia l'UO che i Punti di contatto, distinti (ma entrambi nella stessa sez. Contatti [^1]). Nelle statiche, l'esempio raffigura solo una U.O. (e nessuna sezione specifica solo per l'UO responsabile).
Lo prendiamo come conferma del fatto che UO e Contatti sono intercambiabili? E dunque che il data-element dovrebbe marcare l'intera sezione contatti (come in questa PR), e non un singolo contatto o UO (come ora nella card)?
[^1]: NB: nello schema di architettura, nel Servizio sia l'UO sia i Punti Contatto sarebbero sempre obbligatori. Va inteso in modo elastico? Se no, si può immaginare che nascerebbe qualche problema pratico con i Comuni, tra l'altro.
il tag non è importante ai fini della validazione
Sì, infatti: quindi, averne due nella codebase (il
<div>in single-servizio.php e l'<a>in card.php), entrambi con lo stesso attributo data-element, uno dei quali in realtà non viene usato (card)... credo potrebbe creare qualche confusione. Ad es, qualora si stia investigando la causa di una ev. mancata validazione; ma anche come principio di ordine generale (il codice dovrebbe in un certo senso sempre documentare il proprio senso e scopo, minimizzando le parti inutili e non funzionali). Tra l'altro, dovessero per caso essere visualizzati entrambi i tag, il validatore con$('[data-element="service-area"]').text()aggregherebbe tutto il testo contenuto in entrambi, falsando il test.Qualche dubbio sul fatto di avere il data-element sul contenitore invece che sul link era venuto proprio guardando il validatore. Il test viene fatto contando i caratteri, il che ha forse più senso quando si tratta di un singolo nome di una UO (o di un contatto), come sarebbe con un link, piuttosto che con un intero blocco di testo, che magari ha dentro altri elementi. Ma sono indizi un po' labili, da cui cercare di intuire le "vere intenzioni" del modello. Fatto sta che ora avere il data-element su un contenitore sarebbe sarebbe più logico.
@enrimk in ogni caso, questo template di
cardè specifico per Unità Organizzativa, quindi il rischio di essere utilizzato da altre parti dovrebbe essere minino se non zero.Non verrà usato per altri oggetti che non siano UO. Però viene senz'altro usato anche in contesti diversi dalla vista dettaglio del Servizio. Ad es. nel Luogo, nella Notizia, nella Persona, nell'Argomento, ecc.
Dopo l'aggiornamento ho notato che quando si crea un nuovo servizio non funziona il pulsante 'pubblica' ma rimane sempre come bozza e non c'è modo, quindi, di creare nuovi servizi.
ma questo non compromette validazione, in quanto non i
data-elementnon vengono cercati ovunque, ma solo in specifiche pagineTecnicamente no. Però aumenta le interdipendenze tra template, rende meno modulare e più fragile la struttura, più suscettibile a errori, più difficile da eventualm. debuggare e riorganizzare. Magari non di molto, ma di un po' sì. Se è evitabile, lo eviterei.
Infatti, deve essere successo qualcosa del genere nella versione attuale: il template della card è stato modificato (per il Luogo), e il Servizio non si valida più (v. #437 ).
Insisterei comunque sulla necessità di rivedere le indicazioni tecniche sulla verifica del data-element="service-area" nella documentazione per C.SI.1.3, perché come dicevo sopra, sono perlomeno ambigue.
Viene usato sia per l'UO, sia per i Contatti. Nel primo caso il tag viene specificato come
*[data-element="service-area"]. Nel secondo, comediv[data-element="service-area"], il che renderebbe non conforme l'attuale implementazione (sul tag<a>) . Se il tagdivvenisse effettivamente controllato dal validatore, cioè; cosa che non è.@zetareticoli Al momento, direi di no: nella #444 il data-element è stato duplicato su card-full.php, ma il template single-servizio carica ancora card.php. https://github.com/italia/design-comuni-wordpress-theme/blob/d6d9e10efc378c3f060cffd0f318f54161da6418/single-servizio.php#L413
Era anche per cercare di evitare l'inseguimento alla cieca dei data-element nei template inclusi, che questa PR proponeva di semplificare spostando il tag alla radice.
Chiamo in causa @tensor5 per verificare che a livello di crawling non si rompa niente.