Come posso scrivere HTML, CSS e JavaScript per semplificare il lavoro degli sviluppatori back-end?

Quando ricevo un disegno da un designer, lo ottengo come file PSD (Photoshop). Mi aspetto sempre i nomi di layer e cartelle corretti, fondamentalmente un PSD pulito e gestito. Da questo desigbn sviluppo HTML, CSS e JavaScript e lo consegno agli sviluppatori back-end. Per renderlo facile da capire, io

• scrivere codice semantico,
• mantenere JavaScript e CSS in file esterni,
• aggiungere commenti utili in file HTML, CSS e JS,
• usa gli sprite CSS (anche se agli sviluppatori non piace),
• utilizzare la piastra della caldaia HTML5,
• usa jQuery per JavaScript,
• prova a usare nuovi tag HTML5 e CSS3 ogni volta che è possibile e
• ha inviato un file zip contenente HTML, CSS, JS e immagini.

Mi aspetto che se sarà necessario apportare piccole modifiche al layout, gli sviluppatori possono gestirlo.

Vorrei sapere dagli sviluppatori back-end e da altri ninja CSS cosa si potrebbe fare di più in termini di organizzazione dei file e mark-up per rendere più semplice l'integrazione con i sistemi back-end (ovvero tecnologie back-end, PHP, .NET , Ruby ecc.) Client diversi utilizzano sistemi diversi.

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

• Lascia spazio nel design del modulo per i messaggi di errore.
• Non mettere etichette nelle caselle di input!
• Inserisci i tuoi CSS e JavaScript in un file separato, a meno che tu non sappia cosa stai facendo e non ti senta male.
• Mantieni gli elementi di design uguali tra le pagine. È esasperante quando un componente di progettazione (come una casella "vista di recente") ha un markup diverso su ogni pagina.
• Non fare ciò che è facile per te, fai ciò che è giusto. <button>i tag fanno schifo. backround-imageper cose che in realtà dovrebbero essere <img>tag fanno schifo.
• Assicurati che se stai creando un componente di pagina, questo possa ridimensionarsi. So che molti bravi sviluppatori di front-end lo fanno, ma ho avuto molti casi in cui qualcuno ha usato una singola immagine in quella che avrebbe dovuto essere una situazione di massimo / minimo. Ai programmatori non piace aprire Photoshop.
• Correggi i tuoi modelli. I programmatori (bravi) sono persone dedicate e orientate ai dettagli. Se iniziano a riscontrare problemi nella progettazione (forse la navigazione a piè di pagina presenta errori di ortografia o ortografia incoerente), li indurrà a porre domande e a rallentare il loro lavoro.

Infine, e forse soprattutto:

• Impara le convenzioni di base della lingua che viene sviluppata nel back-end. Essere in grado di guardare un modello PHP e comprendere la sintassi di base dietro una foreacho una ifdichiarazione e come formattare echoun'istruzione o spostare un <?php ?>tag aumenterà notevolmente il tuo valore come sviluppatore front-end: adoro quando uno sviluppatore front-end ha bisogno per fare una semplice modifica e farlo nel modello invece di consegnarmi una nuova zip di tutti i loro file.
• Come addendum, impara a utilizzare il software di controllo versione. Non devi essere un esperto, ma se posso guardare un diff invece di dover provare a capire cosa è cambiato tra due file zip, questo rende il mio lavoro cento volte più semplice.

Questi sono solo alcuni: sono sicuro che ce ne sono molti altri, ma se realizzi tutti questi, sarai sicuro di guadagnare il rispetto e l'apprezzamento di chi sta trasformando i tuoi modelli in un sito web.

Le cose ovvie a cui riesco a pensare che renderebbero più semplice la vita di un ragazzo di back-end è la semplicità di comportamento. Quando si progettano elementi di una pagina Web che presentano vari comportamenti (roll-over, menu, ecc.), Tutti questi comportamenti devono essere standardizzati in modo comune in modo che lo sviluppatore non debba continuamente tornare a un grafico per determinare quale funzione egli deve chiamare per far comportare una pagina.

Le griglie non dovrebbero richiedere una cella per manipolazione cellulare di dati o funzionalità. 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 i vari aspetti della pagina.

Le aree della pagina non devono oltrepassare specifici limiti di progettazione. Gli articoli di un elemento non devono intromettersi negli articoli di un altro elemento.

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

Si noti che a volte, è necessario fare una scelta tra semplificare la modifica di una soluzione per uno sviluppatore back-end e rendere 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 contano 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 al 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 nella parte inferiore dell'immagine, separatamente dalle altre tre? O lo aggiungi dopo la terza icona, spostando tutto il resto in basso per avere uno spazio vuoto per esso?

Lo stesso viene fornito con 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 sarebbe più difficile apportare modifiche. Ad esempio, se hai modificato un file CSS, devi forzare i browser a scaricare quello nuovo, modificando l'URI nel file in cdn.example.com/g.css?r=2, quindi 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 odierebbe questa sintassi e preferirebbe quella che odio e trovo difficile da leggere (no, non sono pazza):

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

Allo stesso modo, l'utilizzo di jQuery non significa che sarà più semplice per gli sviluppatori back-end modificare i file, poiché alcuni sviluppatori hanno maggiore esperienza con Prototype o altri framework.

In tutti i casi, una documentazione dettagliata è utile, se lo sviluppatore vuole leggerlo (molti di loro non lo fanno). Puoi anche semplificare la vita di uno sviluppatore chiedendo precisamente allo sviluppatore specifico come preferisce le cose da fare, e lavorando fianco a fianco all'inizio, mentre costruisci un framework (ad esempio progettando il flusso di lavoro da usare per minimizzare e combina i file).

Il meglio di tutti i mondi è quando il designer non sta lanciando un file zip su un muro e sta effettivamente lavorando al progetto come uno degli sviluppatori. Richiede un po 'di maneggevolezza da configurare, ma è davvero fantastico quando non c'è alcuna traduzione tra design e sviluppo e tutti possono prendere parte alle stesse iterazioni. Se hai un buon processo agile senza attrito, non è troppo difficile farlo accadere.

Nella maggior parte dei casi mi accontenterei dei progettisti che lavorano in una versione controllata e usano quello come meccanismo di distribuzione. Non voglio davvero occuparmi di un grosso file zip fat ogni volta che c'è un piccolo cambiamento.

La flessibilità per te è la flessibilità per loro in genere. Tutte le best practice che stai seguendo 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 eccessivamente esigente e hanno CSS impostato per fallire.

Se hai un menu a discesa, ad esempio, è molto meno lavoro di JS per ancorare un componente di rilascio posizionato in modo assoluto all'interno di un contenitore cliccato relativo-set (non sono necessari corde) di quanto non sia estrarre il martello JQuery e ottenere le coordinate per posizionarlo sopra l'elemento e incollalo in posizione. È anche molto meno probabile che si rompa nei casi in cui la pagina si sposta o alcune nuove funzionalità del browser scaricano le informazioni di posizionamento. Più ti affidi alle competenze HTML / CSS per evitare il lavoro di JS, più robusta sarà la tua UI.

Come regola generale, cerco di assicurarmi che l'unica cosa di cui i miei componenti dell'interfaccia utente hanno bisogno sia un tag HTML per vivere con un ID o una classe appropriati. Più cose puoi fare con quel contenitore senza che l'interfaccia utente si rompa all'interno o con il contenitore effettivamente adatto come espansione / riduzione per adattarsi al variare 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 è attenersi a una lezione.

Preferisci la delega degli eventi sui contenitori dell'interfaccia utente all'assegnazione dei listener direttamente ai nodi del punto finale come i pulsanti. Quel componente dell'interfaccia utente potrebbe funzionare con HTML statico ora ma non si sa mai quando qualcuno vorrà essere in grado di estrarre e riscrivere l'HTML interno con innerHTML o qualcosa del genere. Se il contenitore è intatto e tutti gli eventi sono delegati (vedi il metodo jquery 'on') non devi preoccupartene e potrebbero non imparare mai nel modo più duro che la sostituzione dell'HTML rompe gli ascoltatori.

Nell'interesse di mantenere la delega in giro come opzione, non utilizzare stopPropagate altrove ma nodi end-point e inviare e-mail agli sviluppatori di framework idioti che lo spammano ovunque.

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

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

Fornisci sempre elementi sezionali unici, ID univoci. Rende molto più facile identificare dove stanno accadendo elementi specifici di una sezione, è più semplice sovrascrivere elementi e può anche essere una vittoria per JS leggibilità e prestazioni.

Ovviamente è una brutta notizia diventare eccessivi con uno schema di classi, ma più uno sviluppatore di back-end può impostare semplicemente aggiungendo le classi giuste alle cose, più sarà facile per loro apportare modifiche alla pagina esistente.

E ovviamente all'inizio del progetto farli concordare almeno su questa cosa: il back-end e il front-end si connettono solo tramite HTML e JSON. Non lasciare che usino cose che "scrivono JavaScript per te!" È un casino sanguinante e un incubo per la manutenzione.

Come per tutte le cose legate allo sviluppo, preferisci DRY e minimalismo.

Non mi permette ancora di commentare (così stupido) ma, come nota personale, vorrei menzionare, lavoro quotidianamente con un programmatore PHP (oltre a fornire assistenza nel suo lavoro) e lo strumento più semplice che abbiamo trovato è per utilizzare la cassetta degli attrezzi di Komodo e elencare le variabili "trasferite" di ciascuna vista / controller / modello nella cassetta degli attrezzi, in modo che in qualsiasi momento, se sto cercando di progettare una pagina attorno a un insieme di dati inviati a quella pagina, io può guardare nella casella degli strumenti e vedere esattamente quali dati vengono inviati e in quale "tipo" "vengono inviati, così come viceversa dalla sua parte. Solo un suggerimento.