javascript src - HTML5 Boilerplate vs.HTML5 Reset



empty responsive (5)

Ciao a tutti - HTML5 Boilerplate e HTML5 Reset sono due modelli HTML, CSS e JavaScript con un sacco di best practice moderne integrate. I loro obiettivi sono in gran parte gli stessi:

  • Sviluppo Web veloce, robusto e moderno
  • HTML5 (duh!)
  • Normalizzazione cross-browser (incluso supporto per IE6 e browser per dispositivi mobili)
  • Miglioramento progressivo e degradazione aggraziata
  • Ottimizzazioni delle prestazioni
  • Non un framework, ma il punto di partenza per il tuo prossimo progetto

Ovviamente, sono molto simili nella funzione. In che modo le loro implementazioni sono diverse (ad esempio, forse le correzioni CSS specifiche per IE sono ottenute utilizzando tecniche diverse)? Sono del tutto diversi nella portata? Sembra che HTML5 Boilerplate sia un po 'più grande (strumenti di compilazione, configurazione del server, ecc.), Ma è difficile sapere dove va oltre il reset di HTML5 quando si tratta del sito reale che le persone vedranno.


Answers

Puoi usare uno dei due ...

Come @murtaugh ha detto (http://5by5.tv/bigwebshow/45) non hai bisogno di imparare nulla quando si avvia per la prima volta con Reset. Nella mia esperienza, lavorando in un reparto R & D, quando hai bisogno di demo o fai iterazioni veloci puoi usare Reset (o Boiler se lo conosci già). Quando ho bisogno di costruire il prodotto per la distribuzione, mi rivolgo a Boiler solo perché ha più materiale. Funziona per me ma ora perché so che posso facilmente usare entrambi.


In realtà, voglio quasi dire che usare il tradizionale reset.css è il migliore ... Non trovo problemi con la compatibilità nelle mie app mobili. Tuttavia, sto sviluppando queste app utilizzando il framework mobile di jQuery.

Quindi immagino sia davvero condizionale su quale tipo di strumenti stai usando. PhoneGap non sembra avere problemi nel compilare il mio codice in tutto il sistema operativo. E vedere il mio codice sorgente in emulatori sembra perfettamente a posto ...

Quindi davvero non vedo il punto di un piano d'appoggio a meno che non stiate provando a raggiungere i polifori.


In generale, entrambi i progetti si proponevano di fornire un solido punto di partenza per gli sviluppatori che lavorano su progetti web. Entrambi si liberano di un sacco di noiosi, alcuni, di un codice che è soggetto a errori e che molti sviluppatori si ritrovano a ricreare per ogni progetto. I dettagli su come si comportano sono leggermente diversi, ma per la maggior parte raggiungono gli stessi risultati.

Come hai notato, HTML5Boilerplate ha aggiunto alcune parti di script build per aiutare gli sviluppatori a seguire le best practice per accelerare le loro pagine in termini di elementi sul lato server, come ad esempio le future estensioni, ecc. Dove, come il progetto HTML5Reset, è più focalizzato sulla semantica, sul contenuto e sullo stile. Ad esempio, HTML5Reset ha più struttura di esempio per il contenuto della pagina in HTML5 (per mostrare agli utenti come utilizzare alcuni dei nuovi elementi), mentre HTML5Boilerplate no.

Le parti in termini di tempo di risposta e velocità della pagina che HTML5Boilerplate include diventano sempre più importanti man mano che un numero maggiore di utenti si trova su piattaforme mobili e, con l'aumento di Google, i tempi di risposta della pagina sono al livello di pagina . Ci sono molti documenti che mostrano un piccolo aumento nel tempo di risposta della pagina ha un impatto negativo misurabile su come il tuo sito è usato e percepito ( specialmente in un ambiente eCommerce ... spesso una pagina più lenta di 100ms otterrà una percentuale in meno di cose vendute).

Sul fronte CSS, la maggior parte della sezione di stile di reset per entrambi i progetti è praticamente la stessa, con alcune piccole differenze in ciò che è impostata sulla linea di base. Le correzioni specifiche per IE, tuttavia, sono in gran parte le stesse, con HTML5Boilerplate che asserisce un po 'più di controllo rispetto a HTML5Reset su come IE elabora alcune cose come gli elementi del modulo (ad esempio, pulsanti di selezione / radio e stati validi / non validi)

Due principali aree CSS che HTML5Boilerplate copre che HTML5Reset non sono classi helper comuni per aiutare a rendere i siti più accessibili, come .hidden e .visuallyhidden , così come alcune modifiche sostanziali agli stili di stampa che servono sia a rendere la stampa più simile attraverso browser, così come alcuni risparmi e accessibilità, come rendere le immagini di sfondo trasparenti (per non sprecare toner) e aggiungere l'URL effettivo ai collegamenti e il titolo alle abbreviazioni.

Consiglio vivamente di leggere le informazioni di entrambi i progetti e il modo in cui fanno le cose in un confronto affiancato perché le somiglianze e anche le differenze (e il ragionamento alla base) sono abbastanza istruttive e mi hanno aiutato a decidere meglio quali parti di ciascuno che volevo usare.

In definitiva, proprio come qualsiasi tipo di progetto "bibliotecario", tu come sviluppatore devi capire cosa stai facendo e probabilmente dovresti modificare la tua baseline per soddisfare le particolari esigenze del progetto.


Lavoro in un ambiente in cui gli sviluppatori precedenti hanno costretto la società a utilizzare sia JQuery che Prototype ... ed è un disastro. Non solo dobbiamo lavorare fuori dalla modalità di compatibilità, ma basti pensare al sovraccarico extra che provoca. Quando esegui il debug, proteggi i messaggi di debug "hijacks" in Firebug, il che porta a un lavoro ancora maggiore. E la parte esasperante è che sto rovinando questo casino da mesi e sto appena iniziando ad avvicinarmi al fatto di averlo fatto ... e proprio quando sto per staccare la spina su Prototype mi sembra sempre di trovarne un'altra sezione che si basa su di esso ...

È per questo motivo che discuto ogni volta contro combinazioni di quadri che hanno scopi simili. Ad esempio, non importa quanto si possa pensare che YUI Grids sia, se si carica l'intero framework YUI è meglio non fare Jquery, Moo o Prototype. Saresti semplicemente inutilmente impantanato. Uccide il tempo di caricamento (che distrugge l'esperienza dell'utente ) e dà solo mal di testa agli sviluppatori e lavoro inutile.

Guarda questa fase del tuo sito come costruire le fondamenta. Hai l'opportunità di usare qualsiasi cosa tu voglia usare, ma devi stare attento a non "dipingerti in un angolo" per così dire. Quindi, utilizza strumenti costruiti appositamente e di prima classe disponibili in base alle tue risorse. Non usare semplicemente qualcosa per essere carino! Siamo fortunati perché molti strumenti di altissima qualità sono gratuiti, quindi abbiamo una scelta. Ma sappi che stai guidando la direzione del tuo sito per il futuro, e potresti essere la persona come me che deve affrontare le conseguenze se le tue decisioni sono prese frettolosamente.

Quindi, a meno che tu non abbia MAI intenzione di usare un altro framework, sostengo Reset ... o anche solo facendo CSS conformi agli standard di alta qualità.


Per far funzionare questo lavoro in Safari ho trovato che aggiungere! Importante alla regolazione del webkit costringe a nascondere il pulsante di selezione.

input::-webkit-outer-spin-button,
input::-webkit-inner-spin-button {
    /* display: none; <- Crashes Chrome on hover */
    -webkit-appearance: none !important;
    margin: 0; /* <-- Apparently some margin are still there even though it's hidden */
}

Sto ancora avendo problemi a trovare una soluzione per Opera.





javascript html css html5 boilerplate