Come posso scrivere HTML, CSS e JavaScript per facilitare gli sviluppatori di back-end?

Molte di queste risposte copriranno un'ampia gamma di idee, ma ecco le mie personali:

• Lascia spazio nella progettazione del modulo per i messaggi di errore.
• Non mettere etichette nelle caselle di input!
• Metti i tuoi CSS e JavaScript in un file separato, a meno che tu non sappia cosa stai facendo e si senta male a riguardo.
• Mantieni gli elementi di design uguali tra le pagine. È esasperante quando un componente di design (come una casella "visualizzata di recente") ha marcature diverse su ogni pagina.
• Non fare ciò che è facile per te, fare ciò che è giusto. % tag di<button> succhia. backround-image per cose che dovrebbero essere veramente <img> tags suck.
• Assicurati che se stai creando un componente di pagina, può ridimensionarlo. So che i migliori sviluppatori di front-end fanno questo, ma ho avuto molti casi in cui qualcuno ha usato una singola immagine in quella che avrebbe dovuto essere una situazione top / bottom cap. Ai programmatori non piace aprire Photoshop.
• Correggi i tuoi modelli. I programmatori (bravi) sono persone dedicate, orientate al dettaglio. Se iniziano a vedere problemi nel tuo progetto (forse la navigazione del piè di pagina ha errori di ortografia o di ortografia incoerente) farà sì che facciano domande e rallentino il loro lavoro.

Finalmente, e forse la cosa più importante:

• Scopri le convenzioni di base del linguaggio che si sta sviluppando nel back-end. Essere in grado di guardare un modello PHP e comprendere la sintassi di base dietro un'istruzione foreach o if e come formattare un'istruzione echo o spostare un tag <?php ?> attorno aumenterà notevolmente il tuo valore come sviluppatore finale: mi piace quando uno sviluppatore front-end deve apportare una modifica semplice e può farlo nel modello invece di passarmi un nuovo zip di tutti i file.
• Come appendice, impara a usare il software di controllo della versione. Non è necessario essere un esperto, ma se riesco a guardare un diff invece di dover cercare di capire cosa è cambiato tra due file zip rende il mio lavoro un centinaio di volte più facile.

Questi sono solo alcuni - sono sicuro che ce ne sono molti di più, ma se riuscirai a realizzare tutti questi aspetti, guadagnerai il rispetto e l'apprezzamento di chiunque stia trasformando i tuoi modelli in un sito web.

Le cose ovvie che posso pensare che renderebbero più facile la vita di un ragazzo di back-end è la semplicità nel comportamento. Quando si progettano elementi di una pagina web con vari comportamenti (roll-over, menu, ecc.), Tutto questo comportamento dovrebbe essere standardizzato in un modo comune in modo che lo sviluppatore non debba continuamente tornare a un grafico per determinare quale funzione ha ha bisogno di chiamare per fare in modo che una pagina si comporti.

Le griglie non dovrebbero richiedere una cella mediante la manipolazione di dati o funzionalità delle celle. Gli elementi di blocco delle pagine dovrebbero essere facilmente definibili come elementi comuni in modo che possano essere facilmente segmentati nel codice sottostante. Ciò aiuterà lo sviluppatore a riutilizzare il codice e / o a facilitare la comunicazione tra vari aspetti della pagina.

Le aree della pagina non devono attraversare confini specifici del progetto. Gli elementi di un elemento non dovrebbero entrare negli elementi di un altro elemento.

Arriva un punto, tuttavia, in cui semplicemente non puoi evitare di far saltare in aria gli sviluppatori. Alcuni elementi dell'interfaccia saranno difficili da costruire per la loro stessa natura.

Tieni presente che a volte devi fare una scelta tra semplificare la modifica di una soluzione per uno sviluppatore back-end e realizzare qualcosa di ottimizzato.

Gli sprite CSS che hai citato sono un buon esempio. Non capisco come qualcuno possa creare un sito Web quando la scalabilità e le prestazioni sono importanti e hanno collegamenti a 100 immagini, 5 CSS e 15 file JavaScript da ogni pagina. D'altra parte, gli sprite CSS non sono facili da mantenere, e lievi modifiche nel design potrebbero richiedere molto lavoro.

Ad esempio se hai tre icone di stato, una sotto l'altra, e devi aggiungere un quarto stato, aggiungi la quarta icona alla fine dell'immagine, separatamente dalle altre tre? Oppure lo aggiungi dopo la terza icona, spostando tutto il resto in fondo per avere uno spazio vuoto?

Lo stesso vale per la combinazione e la minimizzazione di file CSS e JavaScript. Devi farlo per un sito web di qualche scala, ma richiederebbe uno sforzo extra.

È esattamente la stessa cosa per la CDN. Devi usarlo per siti web di grandi dimensioni, ma le modifiche sarebbero più difficili da fare. Ad esempio, se hai modificato un file CSS, devi forzare i browser a scaricare il nuovo, modificando l'URI nel file in cdn.example.com/g.css?r=2 , poi cdn.example.com/g.css?r=3 , ecc.

Inoltre, "più facile" è relativo . Vedi, ad esempio, le linee guida per scrivere il codice CSS: personalmente, preferisco uno stile per riga, senza spazi bianchi:

#TopMenu a{text-decoration:none;color:#fff;padding:5px 10px;float:left;}

mentre la maggior parte delle persone odierà questa sintassi e preferirà quella che odio e trova difficile da leggere (no, non sono pazza):

#TopMenu a
{
    text-decoration: none;
    color: #fff;
    padding: 5px 10px;
    float: left;
}

Allo stesso modo, usare jQuery non significa che renderà più facile per lo sviluppatore back-end modificare i tuoi file, perché alcuni sviluppatori hanno più esperienza con Prototype o altri framework.

In tutti i casi, una documentazione dettagliata è utile, se lo sviluppatore vuole leggerlo (la maggior parte non lo fa). Puoi anche semplificare la vita di uno sviluppatore chiedendo esattamente allo sviluppatore specifico come preferisce le cose da fare e lavorare fianco a fianco all'inizio, mentre costruisci un framework (ad esempio progettare il flusso di lavoro da utilizzare per ridurre e combinare i file).

Il meglio di tutti i mondi è quando il progettista non sta lanciando un file zip su un muro e sta effettivamente lavorando nel progetto come uno degli sviluppatori. Richiede un po 'di handholding per l'installazione, ma è davvero fantastico quando non c'è alcuna traduzione tra design e dev e tutti possono prendere parte alle stesse iterazioni. Se hai un buon processo agile senza attriti, non è troppo difficile da realizzare.

Mi accontento della maggior parte dei casi per i progettisti che lavorano in una versione controllata e li usano come meccanismo di distribuzione. Non voglio davvero avere a che fare con un grosso file zip ogni volta che c'è una piccola modifica.

La flessibilità per te è in genere la flessibilità per loro. Tutte le best practice che segui sono vincite su entrambi i lati dell'app.

Un punto critico e spesso mancato, tuttavia, sta scrivendo un'interfaccia utente solida. Troppi componenti dell'interfaccia utente sono eccessivamente ancorati a un contesto o a un set di HTML troppo esigente e hanno CSS impostati per fallire.

Se si dispone di un menu a discesa, ad esempio, è molto meno JS lavorare per ancorare un componente con posizionamento assoluto all'interno di un contenitore con clic relativo (senza coordinate necessario) piuttosto che estrarre il martello JQuery e ottenere le coordinate per posizionarlo sopra l'elemento e incollarlo in posizione. È anche molto meno probabile che si rompa nei casi in cui la pagina si sposta o alcune nuove funzionalità del browser rilasciano le informazioni di posizionamento. Quanto più ti affidi alle competenze HTML / CSS per evitare JS, tanto più solida sarà la tua interfaccia utente.

Come regola generale, cerco di assicurarmi che l'unica cosa di cui hanno bisogno i componenti dell'interfaccia utente sia un tag HTML con cui vivere con un ID o una classe appropriati. Più cose si possono fare con quel contenitore senza l'interfaccia utente all'interno di rottura o con il contenitore che si adatta come espansione / restringimento per adattarsi al cambiamento delle dimensioni del contenitore, più può essere facilmente implementato su qualsiasi parte dell'app senza bisogno di un lato client esperto. Tutto quello che devono fare è incollare un corso su di esso.

Preferisci la delega degli eventi sui contenitori ui per assegnare i listener direttamente ai nodi del punto finale come i pulsanti. Quel componente UI potrebbe funzionare con HTML statico ora, ma non si sa mai quando qualcuno vorrà essere in grado di estrarre e riscrivere l'HTML all'interno con innerHTML o qualcosa del genere. Se il contenitore è intatto e tutti gli eventi sono delegati (vedi il metodo 'on' di jquery) non ti devi preoccupare di questo e potrebbero non imparare mai nel modo più duro in cui sostituire HTML interrompe i listener.

Nell'interesse di mantenere la delega in giro come opzione, non utilizzare stopPropagate ovunque ma nodi di endpoint e inviare posta di odio agli sviluppatori di framework idioti che lo inviano ovunque.

Per quanto riguarda il layout, mantieni il codice HTML minimo, semantico ed evita i wrapper div. Minore è l'HTML, più semplici sono i problemi di layout per i debug di layout da diagnosticare.

Utilizza nomi di classe autoesplicativi per i CSS di utilità. È probabile che una classe "riga" sia più chiara ai noob CSS di "clearfix".

Fornisci sempre elementi di sezione unici, ID univoci. Rende molto più facile identificare dove sono le cose specifiche di una sezione, è più facile scavalcare le cose, e può anche essere una vittoria JS di leggibilità e performance.

Ovviamente è una brutta notizia essere eccessiva con uno schema di classe ma più un back end dev può essere impostato semplicemente aggiungendo le classi giuste alle cose, più sarà facile per loro apportare modifiche alla pagina esistente.

E naturalmente all'inizio del progetto far sì che siano d'accordo almeno su questa cosa: il back e il front-end si connettono solo tramite HTML e JSON. Non lasciare che usino cose che "scrivono JavaScript per te!" È un casino sanguinoso e un incubo di manutenzione.

Come per tutte le cose legate allo sviluppo, preferisco ESSERE e minimalismo.

Ancora non mi lascerà solo commentare (così stupido) ma come nota personale, vorrei menzionare, lavoro di nuovo con un codificatore PHP ogni giorno (così come l'assistenza nel suo lavoro) e lo strumento più facile che noi hanno trovato è fare uso della Komodo 's toolbox e elencando le variabili "trasferite" di ogni vista / controller / modello nel toolboxx, in modo che, in qualsiasi momento, se sto guardando la progettazione di una pagina attorno a un insieme di dati inviati a quella pagina, posso cercare nella casella degli strumenti e vedere esattamente quali dati vengono inviati e quale "tipo" "viene inviato in come, così come vice versa sulla sua fine. Solo un suggerimento.