Argomenti convincenti per 'semantic css' su 'object oriented css'

I due non devono necessariamente combattere, ma generalmente sono d'accordo sul fatto che le persone "OOP CSS" in genere non hanno la minima idea di una buona programmazione o di un buon CSS. Alcuni lo fanno, ma molti non lo fanno.

• Prima di tutto quando le persone parlano di CSS in stile OOP, ciò di cui stanno realmente parlando è uno schema di componentizzazione. Non OOP. Che siano disposti a chiamarlo OOP è un argomento contro di esso in sé e per sé. Kool Aid è stato mixato ed è stato bevuto.

• Le classi multiple utilizzate per comporre gli stili per un elemento sono in realtà molto simili a uno schema di ereditarietà in OOP. Entrambe sono parti uguali stupide e accoppiano inutilmente i problemi rendendo un insieme di proprietà una dipendenza da troppe cose per poterle mai cambiare senza incorrere in tutti i tipi di problemi nell'intera app. Puoi avere categorie di classi che definiscono determinati sottoinsiemi in modo tale che in effetti diventa facile scambiarne uno con un altro con pochi problemi, ma questo pone un carico di competenza piuttosto pesante su tipici sviluppatori che non vedono immediatamente "OOP CSS "per l'ossimoro che è. Ma alla fine non è stato progettato in quel modo, quindi perché farlo così? HTML e CSS funzionano meglio quando si lavora con il loro modo di lavorare, non con il modo in cui un acronimo dall'acronimo serio sembra volerli funzionare.

Detto questo, i CSS non sono realmente progettati come semantici, ma vale la pena seguire una strategia simile. Nei casi in cui l'HTML dovrebbe principalmente descrivere il contenuto, l'ID HTML e i nomi delle classi NON devono descrivere ciò che il CSS o JS associato a loro effettivamente fanno. shiny_red_button IMO è un nome schifoso per una classe CSS. Per quanto riguarda il design, un giorno il tuo pulsante potrebbe non essere così rosso e lucido anche se il pulsante gestisce ancora il panico e dovrebbe quindi essere chiamato 'panico' o forse 'panic_btn' se ti piace il tipo di elementi che in genere si applica a .

Vado con le seguenti regole generali

• Non descrivere aspetti o dettagli di un gestore nei nomi di ID o classe.

Sii un po 'semantico. L'HTML ci dà un'idea generale di ciò che verrà trovato all'interno. Ora diventa un po 'più specifico per il suo scopo di design.

• Utilizza il minor numero possibile di selettori

La cosa a cui lo stile CSS di OOP pensa di reagire è che la specificità viene lasciata a bocca aperta. Fallire. La specificità non è il nemico. È uno strumento che usi bene o usi impropriamente. Quindi, quando qualcuno dice "Non usare ID perché è più difficile ignorarli", schiaffeggiali o chiedi loro di prenderli in considerazione:

#unique_element_container_on_page > a rispetto a .unique.element.container.on.page > a

Se c'è una cosa che dovrebbe offendere profondamente i progettisti, gli sviluppatori di ui e gli sviluppatori orientati a app / server equamente, è necessario! @ # $ contare qualcosa (come dire un metodo java con 20 parametri facoltativi) per capire cosa devi fare dopo.

• gli ID sono a posto.

Ho detto di nuovo perché penso che il lint CSS sia sciocco.

• Lascia che il contesto faccia il polimorfo

L'HTML è fondamentalmente tassonomia. Ampie categorie che si adattano a categorie meno ampie che continuano a funzionare fino a cose specifiche / uniche. I CSS funzionano meglio quando seguono insieme a questo schema. Le sezioni possono avere variazioni su un tema ancora più generale.

Sostituire quel tema con una classe di sezione seguita da qualunque discendente è diverso di solito ha molto più senso della scrittura di una nuova classe di componenti css e di lasciarla cadere su quell'elemento specifico che è diverso da sostituire a quello vecchio. L'intento è più chiaro e hai meno dipendenze per elemento su cui intervenire. Tranne, naturalmente, quando la variazione del tema non è realmente correlata al luogo in cui è posizionato un elemento. Questo è uno di quei rari casi in cui estrometterò una virgola e aggiungerò un selettore a uno esistente e poi definirò le sue proprietà di variante immediatamente dopo con il nuovo selettore. Fai abbastanza cose del genere e puoi cambiare etichetta bianca con una semplice modifica della classe nella parte superiore della pagina nel tuo codice HTML.

• Va bene ripetersi

Usa ASCIUTTO più di un rilevatore di odori della regola d'oro con rare eccezioni che è in programmazione. Nei CSS è molto più comune che due insiemi di proprietà quasi come fossero coincidenti, non perché i loro selettori condividano uno scopo. È meglio lasciarli separati per il giorno in cui qualcuno vorrà cambiare uno e non l'altro. Un file CSS ideale funziona come un pannello di controllo in cui è ragionevolmente facile trovare quello che ti serve per cambiare qualcosa con la certezza che non cambierai anche qualcos'altro per caso.

Personalmente posso salire a bordo con un buon bilanciamento dei due in cui hai degli oocss per aiutanti e hai css semantico per i componenti ... e la decisione di creare un componente verrebbe quando ti troverai ad applicare lo stesso oocss elementi ripetutamente.

Non capisco perché le persone sono così tutto o niente, ci deve essere un equilibrio, una cosa carina di un approccio equilibrato è la possibilità di avere un over-ride su una classe semantica usando l'oocss ... quindi dite hai un contenitore definito che ha tutte le proprietà che vuoi ma vuoi il testo blu invece del nero, puoi usare la tua classe semantica seguita da una classe di colore del testo blu e la gerarchia CSS lo rispetterà. Ciò significa che non devi gonfiare il tuo css con un altro componente semantico quasi identico e non è necessario scrivere alcun css, basta inserire due classi e il gioco è fatto ...

Grazie per i tuoi commenti - Sono stato in grado di chiarire le mie idee al riguardo.

La distinzione tra i due sembra essere sul flusso di lavoro. Il precedente ( css orientato agli oggetti ) è più di un tradizionale approccio basato sulla stampa in cui i colori e gli stili vengono scelti per primi per un obiettivo di branding, e quindi il sito Web viene assemblato da quello successivo. Quest'ultimo approccio ( semantic css ) è più chiaramente collegato all'obiettivo di un sito Web, in cui è possibile costruire un sito e gli stili possono essere facilmente modificati in un secondo momento, senza necessariamente modificare il codice sulla pagina.

Se hai un flusso di lavoro che va al grafico, colori e stile - > css designer - > sviluppatore web, e gli stili non cambieranno probabilmente - quindi un approccio css orientato agli oggetti è più appropriato (ma meno flessibile in seguito).

Se hai un flusso di lavoro in cui il grafico e il css lavoreranno in modo iterativo per ottimizzare il sito Web a un determinato obiettivo, allora semantico css è più appropriato.

Il grande criterio di distinzione è che semantic css consente la personalizzazione del sito cambiando lo stile senza il sito.

(Probabilmente c'è una domanda in sospeso sul fatto che l'obiettivo di progettazione di css ti consentisse di modificare il sito senza modificare il codice della pagina, ma questa è una discussione per un altro giorno)

(Apprezzo i commenti che dicono che una buona nomenclatura è la cosa principale di cui sei preoccupato. Il mio punto è che devi prima nominare gli elementi della pagina e poi costruirli da questi, invece di costruire elementi css e quindi scegliere e sceglierli nella tua pagina)