Why shouldn't you do Frontend?
@mathieuspil
Sorry
I am the biggest security hole in the company
The goal:
Have a discussion on how to improve quality by saying no sometimes.
!new-projects
Display: none;
A client asks if you can up the limit of slideshow items from 5 to 50.
<ul class="slider">
<li class="slider__item slider__item--active"><img src="image1.png" /></li>
<li class="slider__item"><img src="image2.png" /></li>
<li class="slider__item"><img src="image3.png" /></li>
<li class="slider__item"><img src="image4.png" /></li>
<li class="slider__item"><img src="image5.png" /></li>
</ul>
.slider__item {
display: none;
}
.slider__item--active {
display: block;
}
<ul class="slider">
<li class="slider__item slider__item--active"><div style="background: url(image1.png);"></div></li>
<li class="slider__item"><div style="background: url(image2.png);"></div></li>
<li class="slider__item"><div style="background: url(image3.png);"></div></li>
<li class="slider__item"><div style="background: url(image4.png);"></div></li>
<li class="slider__item"><div style="background: url(image5.png);"></div></li>
</ul>
.slider__item {
display: none;
}
.slider__item--active {
display: block;
}
What can we take from this?
Sometimes it's not clear if a task is backend or frontend.
Tasks like this shouldn't be done alone.
class-based styling !== writing css-selectors
A client asks if the news-items on the frontpage can be filtered differently for logged-in users only.
Here is how it goes
1) Duplicate the view
2) Make sure the old view is anonymous users only
3) Make sure the new view is logged-in users only
4) See the new view, and find out the styling is broken.
5) You don't want to ask a frontend-person to fix this, because it is probably just a missing selector.
.view-display-id-panel_pane_1 {
background: green;
font-size: 1.2em;
.view-header {
margin-bottom: 1rem;
}
.news-item {
h3, h4 {
color: red;
display: inline-block;
background: green;
}
}
}
.SCSS
.view-display-id-panel_pane_1 {
background: green;
font-size: 1.2em;
}
.view-display-id-panel_pane_1 .view-header {
margin-bottom: 1rem;
}
.view-display-id-panel_pane_1 .news-item h3,
.view-display-id-panel_pane_1 .news-item h4 {
color: red;
display: inline-block;
background: green;
}
.css
.view-display-id-panel_pane_1,
.view-display-id-panel_pane_2 { // <= ADDED
background: green;
font-size: 1.2em;
.view-header {
margin-bottom: 1rem;
}
.news-item {
h3, h4 {
color: red;
display: inline-block;
background: green;
}
}
}
.SCSS
.view-display-id-panel_pane_1,
.view-display-id-panel_pane_2 {
background: green;
font-size: 1.2em;
}
.view-display-id-panel_pane_1 .view-header,
.view-display-id-panel_pane_2 .view-header {
margin-bottom: 1rem;
}
.view-display-id-panel_pane_1 .news-item h3,
.view-display-id-panel_pane_1 .news-item h4,
.view-display-id-panel_pane_2 .news-item h3,
.view-display-id-panel_pane_2 .news-item h4 {
color: red;
display: inline-block;
background: green;
}
.css
.view-news {
background: green;
font-size: 1.2em;
.view-header {
margin-bottom: 1rem;
}
.news-item {
h3, h4 {
color: red;
display: inline-block;
background: green;
}
}
}
.SCSS
Whats the point?
.view-news {
background: green;
font-size: 1.2em;
.view-header {
...
}
.news-item {
...
}
}
.view-news--red {
background: red;
}
.view-news--smaller-font {
font-size: 0.8rem;
}
<div class="view-news">...</div>
<div class="view-news view-news--smaller-font">...</div>
<div class="view-news view-news--red">...</div>
<div class="view-news view-news--red view-news--smaller-font">...</div>
If you keep every variation of an element in a separate class, the possibilities of combinations expand exponentially, instead of expanding your css.
If you are interested
What can we take from this?
Grey zone of stuff that can be done by both
We have to stay billable.
BEM + CSS-specificity
A client asks why the contact submit-button suddenly has a green background, and wants it blue again.
You open up the inspector and this comes out:
<a href="#" class="button button--submit">Submit</a>
Bad solutions
a.button {
background: green;
}
.button--submit {
background: blue !important;
}
Bad solutions
a.button {
background: green;
}
a.button--submit {
background: blue;
}
Bad solutions
a.button {
background: green;
}
.button.button--submit {
background: blue;
}
Bad solutions
a.button {
background: green;
}
#edit-submit {
background: blue;
}
Good solutions
.button {
background: green;
}
.button--submit {
background: blue;
}
What can we take from this?
Break down the barrier of asking for silly stuff.
Cross-country resources?
SMACSS & Atomic design
A client asks to make the search-block in the footer only 25% of the width of the full page.
Most common solution:
.region-footer .search-block {
width: 50%;
}
Atomic design
We’re not designing pages, we’re designing systems of components.
Styling stuff based on the region it is in, has become a bad practise
.search-block--tiny {
width: 25%;
}
But in what css-file do I write this in?
Drupal-SMACSS
- Base — CSS reset/normalize plus HTML element styling.
- Layout — macro arrangement of a web page, including any grid systems.
- Component — discrete, reusable UI elements.
- State — styles that deal with client-side changes to components.
- Theme — purely visual styling (“look-and-feel”) for a component.
ul {
list-style-type: disc;
list-style-image: none;
margin: 0.25em 0 0.25em 1.5em;
}
ol {
list-style-type: decimal;
margin: 0.25em 0 0.25em 2em;
padding: 0;
}
Base
.layout-container {
max-width: 860px;
margin-left: auto;
margin-right: auto;
box-sizing: border-box;
}
Layout
.button {
...
}
.button:hover {
...
}
.button:focus {
...
}
.button:active {
...
}
Component & state
.maintenance-page {
background-color: #e0e0d8;
background-repeat: repeat;
background-position: left top, 50% 50%; /* LTR */
min-height: 100%;
}
Theme
.search-block {
width: 50%;
}
.search-block--tiny {
width: 25%;
}
What can we take from this?
it's not rocketscience, go ahead and try it.
But let review happen on stuff you aren't 100% sure about.
False assumptions
when changing something in the backend, the frontend shall break.
<article class="speaker speaker--teaser">
<a class="speaker__link" href="#" rel="bookmark">
<div class="speaker__photo">...</div>
<h4 class="speaker__title">Mister X</h4>
<div class="speaker__function">...</div>
</div>
</a>
</article>
It's impossible to know on which class to style on drupal
<article class="speaker speaker--teaser">
<a class="speaker__link" href="#" rel="bookmark">
<div class="speaker__image">...</div>
<h4 class="speaker__title">Mister X</h4>
<div class="speaker__function">...</div>
</div>
</a>
</article>
.speaker__image {
width: 100%;
border-radius: 50%;
}
.speaker--teaser .speaker__image {
float: left
width: 50px;
}
No one has enough confidence to bluntly rewrite css not written by himself.
Scope support
After a couple of years of maintaining a theme, over time it becomes harder and harder to maintain
#content-top .content-size-small .field-ns-prod-entrpr-media, #content-top .panels-ipe-portlet-content > .box-small, #content-top .view-filters .views-exposed-widgets .panels-ipe-portlet-content > .views-exposed-widget, .view-filters .views-exposed-widgets #content-top .panels-ipe-portlet-content > .views-exposed-widget, #content-top > .box-small, .view-filters .views-exposed-widgets #content-top > .views-exposed-widget, #content-top .box-small, #content-top .view-filters .views-exposed-widgets .views-exposed-widget, .view-filters .views-exposed-widgets #content-top .views-exposed-widget, #content-bottom .content-size-small .field-ns-prod-entrpr-media, #content-bottom .panels-ipe-portlet-content > .box-small, #content-bottom .view-filters .views-exposed-widgets .panels-ipe-portlet-content > .views-exposed-widget, .view-filters .views-exposed-widgets #content-bottom .panels-ipe-portlet-content > .views-exposed-widget, #content-bottom > .box-small, .view-filters .views-exposed-widgets #content-bottom > .views-exposed-widget, #content-bottom .box-small, #content-bottom .view-filters .views-exposed-widgets .views-exposed-widget, .view-filters .views-exposed-widgets #content-bottom .views-exposed-widget, #content .content-size-small .field-ns-prod-entrpr-media, #content .panels-ipe-portlet-content > .box-small, #content .view-filters .views-exposed-widgets .panels-ipe-portlet-content > .views-exposed-widget, .view-filters .views-exposed-widgets #content .panels-ipe-portlet-content > .views-exposed-widget, #content > .box-small, .view-filters .views-exposed-widgets #content > .views-exposed-widget, #content .box-small, #content .view-filters .views-exposed-widgets .views-exposed-widget, .view-filters .views-exposed-widgets #content .views-exposed-widget
But we live in a drupal-world!
Everything is there in D8, let's not ignore it.
Questions?
@MathieuSpil
Why you shouldn't do frontend
By Mathieu Spillebeen
Why you shouldn't do frontend
Wundercon Riga presentation on how projects become messy.
- 1,748