Frontend Development - CSS
Definition und Arbeit mit CSS Bibliotheken sowie vorhanden Klassen und Komponenten[edit]
Feststellung & Diskussion[edit]
Hallo ihr Lieben,
nachdem ich nun schon die ersten Arbeiten in bestehenden und kommenden Projekten vollzogen habe und immer wieder dabei bin Anpassungen vorzunehmen bin ich auf das ein oder andere Hindernis gestoßen. Leider wird mein Weg immer steiniger, so dass sich bei mir die Frage auftut wie wir ab sofort und zukünftig mit dem bestehenden CSS verfahren wollen.
--Rupert 12:46, 31 March 2011 (CEST) The reason for fundamental change should be driven by perspective, not by current details: How much faster/easier can implementation be? Is it the only way to improve the style guide? What components can profit? Anyway "from now on" is too optimistic. The order of things should be: Reasoning, Evaluation, Change. This should go in parallel, not in a mixed way.
Nachfolgend habe ich mal einige Fakten und Ideen niedergeschrieben, damit ihr mir bei meiner Entscheidungsfindung helfen könnt.
Es stellt sich also die Frage:
CSS beibehalten oder umstellen?
Hier habe ich zunächst mal 2 Problemfälle beschrieben, die aus GUI-Sicht dringend sind.
1) Probleme im Pubman:
Gridview - Statussymbole und deren textuelle Beschreibung zentriert ausrichten, derzeit nur über programmiertechnische Lösung
--Rupert 12:46, 31 March 2011 (CEST) As far as I know the current fix is acceptable from style guide point of view.
2) Allgemeine Probleme:
Layoutgestaltung von Webseiten. Das Content-DIV ist zu schmal bemessen, daher enden die horizontalen Linien vor dem rechten Inhaltsende.
--Rupert 12:46, 31 March 2011 (CEST) Should be defined in the following order: Style Guide, Solution, Implementation
Ursache zu 1 und 2
Zu wenig Flexibilität in der DIV-Gestaltung. Es sind feste Breiten definiert, die mit Worten anstelle von Rastereinheiten beschrieben werden. Das finden neuer Wörter wird zunehmend schwieriger bis unmöglich.
Lösungsvorschlag
Benennung von Größeneinheiten anhand von Raster.
Bsp.1: width_r5_3_pLR4_mLRA
-> Breite = 5px * 3 Einheiten = 15px -> Padding = left 4px; right 4px -> zur Verfügung stehende Breite: 7px -> Margin = top & bottom = 0; left & right = auto
Bsp.2: width_r5_3_pLR4
-> Breite = 5px * 3 Einheiten = 15px -> Padding = left 4px; right 4px -> zur Verfügung stehende Breite: 7px
marginLRa
-> Margin = top & bottom = 0; left & right = auto
--Rupert 12:46, 31 March 2011 (CEST) I got the concept. As discussed, The way to get a 'proof of concept' should go in parallel. This means an additional core.css besides the existing. An additional page of the component library could serve as a test run where one or two components can be compared to what we have in place now.
Darüber hinaus ist mir aufgefallen, dass die Zuweisung "!important" sehr häufig verwendet wird. Im Laufe immer weiterer Neudefinierungen von Klassen besteht die zunehmende Gefahr, dass genau diese Zuweisung durch Mehrfachverwendung in unterschiedlichen Klassen sich gegenseitig aufhebt und an Wirkung verliert.
Um über ein neues CSS zu sprechen sollte man auch berücksichtigen wie generell damit umgegangen werden soll:
projektspezifisches CSS[edit]
- individuelle CSS-Klassen
- kein Laden nichtverwendeter Klassen
- projektspezifische Schriftgrößenverwendung
- gleiche Themes können für einzelne Projekte leichter individuell angepasst werden
Bsp: leichte Farbanpassungen, Schriftgrößen
universelles CSS[edit]
- alle CSS-Klassen stehen uneingeschränkt zur Verfügung
- Style-Themes sind immer auf alles anwendbar
Somit bin ich nun bei den Vor- und Nachteilen einer Umstellung angelangt.
PRO altes CSS[edit]
- vorhandene Größeneinheiten durch Pubman
- bekannte CSS-Klassen für einige Entwickler
- annähernd am Styleguide
- berücksichtigt einige Browserbugs
- CSS Bibliothek vorhanden
CONTRA altes CSS[edit]
- begrenzter Spielraum bei neuer Namensvergebung für neue Größeneinheiten
- Widersprüchige Größeneinheiten definiert
- medium_area0 vs. medium_area0_p6
- großer Aufwand bei Schriftgrößenänderung
- nur bedingt an dem Styleguide anpassbar
--Rupert 12:46, 31 March 2011 (CEST) It was initially built to meet the style guide!? That's why it is kept less flexible. Another approach may fit better (proof of concept).
- für neue Projekte fehlen Klassen, die neu definiert werden müssen
--Rupert 12:46, 31 March 2011 (CEST) The project goals should be covered by generic components. There should never be a project specific class (only temporary):
/coreClasses/componentsClasses/pages(JSP)/solution ... project
- zu viele Klassen definiert, die nicht verwendet werden
- je weitere Klassendefinierung wird die Bibliothek immer unübersichtlicher
- Core-CSS wird zu groß
--Rupert 12:46, 31 March 2011 (CEST) Measures? (loading time, stability, user acceptance, lags)
PRO neues CSS[edit]
- genaue Rastereinheiten
- neue Zwischengrößen durch neues Rastering möglich
- klare Strukturierung durch Raster
- Styleguide-konforme Umsetzung
- projektspezifische Styles aus einer CSS Bibliothek
- Core-CSS beinhaltet nur fundierte Eigenschalten - Bsp: floatL, floatR, floatN, cleaning, ...
- mit Datenbankunterstützung
- Bibliothek mit festen Einheiten für die Umrechnung von Pixel in EM
- projektbezogenes Abspeichern der verwendeten Klassen
- geringerer Aufwand bei Schriftgrößenänderung
- (CSS-Dateigenerierung)
CONTRA neues CSS[edit]
- Umgewöhnung auf neues CSS
- Aufwand der Entwicklung
- Definition der Core-Style-Klassen
- CSS Bibliothek muss erzeugt werden
--Rupert 12:46, 31 March 2011 (CEST) Can we limit the question to old and new? Again the order of things would be:
- A common understanding that our current core is 'outdated' or 'limited'
- What is the goal of building a new one
- How does the new one look like (prove of concept) and what is the effort
--Rupert 12:46, 31 March 2011 (CEST) Is there an alternative approach to improve the existing rather that throwing it away and make the architecture fit the core? I could imagine that after IE6 there can be a lot of improvements in the current core and components. Not only !important, but 'overflow', 'flows', 'clears'
Bitte ergänzt noch fehlende Daten und helft mir bei der Entscheidung.
Sorted out from GUI Constraints (may fit to skin-page)
CSS3 Specs[edit]
property index for background, border and shadow:
http://www.w3.org/TR/css3-background/#property-index
shadow[edit]
http://www.w3.org/TR/css3-background/#the-box-shadow
supported in CSS3 from following browser:
- Firefox 3.5+
- Safari 4+
- Google Chrome
box-shadow:0 0 50px #CCCCCC;
-moz-box-shadow:0 0 50px #CCCCCC;
-webkit-box-shadow:0 0 50px #CCCCCC;
box-shadow:
rgba(0,0,0,0.4)
10px 10px;
box-shadow:
rgba(0,0,0,0.4)
10px 10px
inset -- inside shadow
box-shadow:
rgba(0,0,0,0.4)
10px 10px 0
10px /* spread */
box-shadow:
rgba(0,0,0,0.4)
10px 10px 0
10px /* spread */
inset -- inside shadow
border radius[edit]
http://www.w3.org/TR/css3-background/#border-radius
supported in CSS3 from following browser:
- Firefox 3.5+
- Safari 4+
- Google Chrome
border-radius:6px 6px 6px 6px;
-moz-border-radius:6px 6px 6px 6px;
-webkit-border-radius:6px 6px 6px 6px;
border:2px solid #333333;