This is a somewhat abstract question but here goes.
A company recently partnered with another company for a small project but their brands are not aligned, so in certain areas of their site the pages need to respect the brand guidelines of whatever company they represent.
Currently all of the CSS is geared towards a singular brand e.g.
.solution-featured-video__title {
font-family: CircularStd;
font-size: 40px;
font-weight: 500;
line-height: 1.33;
color: #fff;
}
This is a piece of styling for the title of a solution video.
If the other brand wanted an identical component and I stick loosely to BEM, would it be appropriate to just use modifiers?
E.g.
.solution-featured-video__title--other-brand
In light of the comments I ask because there is also a business rule: whenever someone types easy in any form i.e. Easy, easy, EASY, it needs to be changed to easy.
My idea was to programmatically wrap a span around each instance.
Under BEM (Block, Element, Modifier), I think it would be perfectly acceptable to use the modifier as a means of adding brand specific styling to the element.
.solution-featured-video__title {
font-family: CircularStd;
font-size: 40px;
font-weight: 500;
line-height: 1.33;
color: #fff;
&--brand1 {
color: #000
}
}
You are effectively just modifying the styling of the block based on brand
Related
I have been in contact with the pre-processor SASS for a year and a half now and it's nice to be able to use #extend and #mixins, but a case for using these two has come to my mind and a doubt just popped:
Let's say I have a <h1> tag and I want to style it, both its typography and positioning. If I have a placeholder selector for the specific typography I want to add, for example,
%typography-1 {
font-size: 18px;
line-height: 24px;
}
and I extend it to my <h1> and some other element in my page, let's say a <p> tag, I'll end up getting
scss:
h1,
p {
#extend %typography-1;
}
css:
h1,
p {
font-size: 18px;
line-height: 24px;
}
But I also want to style my <h1>'s positioning with
h1 {
left: 50px;
position: relative;
}
My doubt is: is there any side effect of separating my <h1>'s styling into two blocks?
I know this might sound silly, but it's a curiosity of mine. Probably it doesn't affect performance for sites or e-commerces (correct me if I am wrong), but for big webapps, I was wondering if it would be a problem.
Does anyone have any idea what my external style sheet isn't rendering in my browser?
Both files are in the same directory, I have tried multiple browsers, and I have cleared the cache on all of them multiple times. It is probably something small as this is my first time using an external style sheet but I am completely lost because everything seems correct.
heading {
font-family: arial;
color: red;
}
emphasis {
color: blue;
background-color: yellow;
}
<h1 class="heading">Cascading Style Sheets</h1>
<h2>Benefits</h2>
<p>Cascading Style Sheets offer many benefits to web designers. <em class="emphasis">CSS lets you separate style information from HTML</em>, allowing you to provide style sheets for different destination media as your web site requires. You can control the
display characteristics of an entire web site with a single style sheet, making maintenance and enhancements of display information a less taxing chore. You can express a wide range of style properties that increase the legibility, accessibility, and
delivery of your content. You can build page layouts, either flexible, fixed, or responsive to suit your user and content needs. As you will see in this chapter and through the rest of the book, CSS is easy to learn and apply to your web design projects.</p>
Solution provided by Micheal Platt:
In the external CSS, each class should be preceded with a .
Therefore:
.heading{
font-family: arial;
color: red;
}
.emphasis{
color: blue;
background-color: yellow;
}
Is the correct solution.
missed the dot at the beginning of the statement in css.
.heading {
font-family: arial;
color: red;
}
.emphasis {
color: blue;
background-color: yellow;
}
Is there a way to make font-size and font-weight change more dynamically using Less?
For instance:
#h2font{
font-size: 32px;
font-weight: 700;
}
or is there another solution to this?
I'm not super familiar with less.js but typically if you want to change the font size/weight for ALL h2 tags it would look like:
h2{
font-size: 32px;
font-weight: 700;
}
If you wanted to do it differently you can use id's or classes to setup styling conventions that apply to some but not all.
I'm assuming that your #h2font should just be "h2" but I could be wrong due to my lack of knowledge specifically with less. Otherwise you can use JavaScript/jQuery to dynamically change element styling based on user interaction on the page.
Question: Is the second OOCSS principle really valid?
According to the OOCSS second principle you're not supposed to have location dependent styles:
Quote from https://github.com/stubbornella/oocss/wiki
Essentially, this means “rarely use location-dependent styles”. An object should look the same no matter where you put it. So instead of styling a specific h2 with .myObject h2 {...}, create and apply a class that describes the h2 in question, like h2 class="category".
Lets take a practical example of this. Say I have a standard 2.0 setup with a normal body (white background) and a huge footer (black background). In the body we have black links and in the footer of course we need white. Isn't the simplest and most intuitive way to achieve this simply to:
a{ color: #000; }
.footer a{ color: #FFF; }
If I where to follow OOCSS principles I'd have to first create a class:
.inverted{ color: #FFF; }
Then proceed to add that class to every link I want inverted. That seems like a hassle.
Isn't the purpose of the whole language that styles are made to Cascade?
Am I misunderstanding something here?
I think you are right in the sense that yes, in your specific example.. perhaps doing it your way would be easier. But then again, if you look at the first sentence in the OOCSS page:
How do you scale CSS for thousands of pages?
In that context.. the second principle makes perfect sense.. so using your same example (ie let's assume we implemented your solution).. let's say that a year down the road your company decides to create light grey buttons in the black footer having black text:
<!-- inside footer -->
<a class="button lightGrey">link</a>
in this case.. all the a tags will be white because they're covered by your cascading. So then we will have to go create another sytle just to undo what your solution did:
.footer a.button.lightGrey {
color: #000; /* huh? but i thought we did this before with a {color: #000;} ?*/
}
where as if we simply made a decision that all a tags by default are black (see last note):
a{ color: #000; }
then in the footer we will create a special type of link that are supposed to be white:
.footerLinks { color: #FFF }
then a year later some of the links are still white.. others within the greyLight button will be black:
<a class="button lightGrey">link</a>
then here we don't have to worry about undoing anything.. a tags have a default color.. and that's it. if 2 years later someone decides that the links inside the lightGrey buttons (anywhere on the site, not only withen the footer.. which is the whole point of OOCSS) should be red.. then this would be the OOCSS approach:
.redLink {
color: red;
}
and the html will be
<a class="button lightGrey redLink">link</a>
in this case it won't matter if we take out the .lightGrey class, or we can have this code within or not within a footer .. it's all the same.. it results in more predictable and re-usable code.. which is OOCSS (I'm very glad that they're finally formalising this.. thanks a lot for the post btw).
One last note: To be pure OOCSS, one shouldn't change the default color of a ie a {color: #000;} is wrong!, it should be left to it's default color (which is blue).. whenever anyone wants to change that color.. then they must specify it ie
<a class="redLink">..</a>
so in this case it's more like the default a is the parent class.. and everything else subclasses it and overrides its default behaviour..
update - response to comments:
reputable site argument:
such initiatives are almost always driven by the community then adopted by reputable companies.. and even when they are adopted by larger companies it usually happens from the bottom up through enthusiastic developers who advocate for such change.. I for one was such an advocate when I was working in Amazon. And even when it's adopted.. it's usually at a small scale and not across all units in the org. it wouldn't even be a good idea for the Googles and the Amazons and the facebooks etc to enforce such a rule b/c there will always be a difference of opinion.. not to mention that such micromanagement would constrain the engineer's creativity.. there could be a guideline in a wiki for a team (ie we had one for the Amazon Kindle Touch app store) but to enforce that rule across 10,000 engineers working across the company wouldn't be practical nor desirable.
So in short if you see value in OOCSS, and start implementing on your site, and advocating it to your fellow web devs, and then it becomes a trend, that's when it eventually becomes an industry wide best practice and that's when you can expect to see it on facebook etc.
example:
take a look at this:
simple: http://jsfiddle.net/64sBg/
a bit more detailed: http://jsfiddle.net/64sBg/2/
without going too much detail (I'm sure you will see the pattern) you can see that the granularity in css descriptions allows for subtle changes without any redundancy in style definition. So notice the left arrow vs right arrow.. also the .red and .blue styles can be subsequently applied to tables etc..
also notice that there isn't a single cascading in my css.. so my styles can be completely independently applied (ie implementing the rule An object should look the same no matter where you put it)
lastly.. there is still use for cascading.. you can definitely use it in your jQuery selectors for example.. also cascading happens by default (ie without you having to explicitly set it in your css styles).. so if you take look at the css below.. you will notice that the font properties of body has cascaded down to all the buttons.
<a class="button blue dark">
<div class=" arrowDownWhite rightArrow">Analytics</div>
</a>
<a class="button red dark">
<div class=" arrowDownWhite leftArrow">Actions</div>
</a>
<a class="button grey light">
<div class=" arrowDownRed leftArrow">options</div>
</a>
and css:
body
{
font-family: Trebuchet MS,Liberation Sans,DejaVu Sans,sans-serif;
font-size: 15pt;
}
.button
{
padding: .5em 1em;
display: inline-block;
text-decoration: none;
}
.dark {
color: white;
}
.light{
color: #E40E62;
}
.blue
{
background-color: #51C8E8;
}
.red
{
background-color: #E40E62;
}
.grey
{
background-color: #E0E0E0 ;
}
.arrowDownWhite
{
background-image:url(http://s2.postimage.org/ywam7ec4l/small_Arrow_Down_White.png);
background-repeat:no-repeat;
}
.arrowDownRed
{
background-image:url(http://s2.postimage.org/je5743t2d/small_Arrow_Down_Red.png);
background-repeat:no-repeat;
}
.leftArrow
{
padding-left: 1em;
background-position: left center;
}
.rightArrow
{
padding-right: 1em;
background-position: right center;
}
It is worth the hassle of separating your skin from the container.
Lets look beyond colors. I wish Nicole Sullivan provided better examples than she does. I have 23 web sites that an contain
Menus
Tabs
Toolbars
Horizontal and Vertical Lists of Links
All of them are Skins of the Nav abstraction
I started off created an abstraction class to handle the common code between all of them. I added a few modifiers to change the orientation from horizontal to vertical, and also the floated position of it. I kept all colors out of the abstraction as well as css rules that can change based on the skin I apply to it.
/* Object */
.nav
{
margin-bottom: 1.5em; margin-left: 0; padding-left: 0; list-style: none;
}
/* Modifier */
.nav--stack .nav__item
{
display: block;
}
.nav--right
{
float: right;
}
/* Elements */
.nav__item
{
float:left
}
.nav__item__link
{
display:none;
}
Menu Skin
I needed a skin that made the .nav abstraction look like a sidebar menu. In case you are wondering, I did not put the padding for .nav_item_link above is because it can change based on the skin. The tabs skin has it set for 2px.
/* Object */
.menu
{
}
/* Elements */
.menu .nav__item--current.nav__item__link
{
color: #fff; background: blue;
}
.menu .nav__item__link
{
padding: 4px; border-radius: 4px;
}
.menu .nav__item__link:hover
{
background: #eee
}
Notice to keep things location-independent - I have 0 tag names. I don't style li and a children on .nav like bootstrap does. This code could be used on dls or even divs and has better performance based on how selector engines read rules.
To me the benefit of just having to skin the objects I have for all 23 sites I have is worth any hassle.
I'm going to use version control first time and I read somewhere that Single line CSS is not a good idea for version control
.footer li h3 { margin: 0 0 6px; font-weight: bold; display: inline; color: #e92e2e; }
.footer li h3 a { font-weight: normal; font-size: 1em; color: #e92e2e; }
Which format you would prefer?
Is this below formatting good to use with version control
.footer li h3 {
margin: 0 0 6px;
font-weight: bold;
display: inline;
color: #e92e2e; }
.footer li h3 a {
font-weight: normal;
font-size: 1em;
color: #e92e2e; }
From a standpoint of readability, Yes, the formatting you show makes more sense on multiple-lines because you'll be able to easily see the difference between 2 versions if a new attribute is added.
If you're working with other people on the same code, readability is the #1 most important thing you should focus on in your code (aside from making the code work, of course). A close second is using comments EVERYWHERE. This is just my opinion, of course some people might prefer comments over readability. Even if you're not working with anybody else, it's still very important to write readable code, in case another developer takes over the project in the future.
To answer your question, I prefer the second format, and I guess that most programmers would agree.
In Git you can easily do a word diff and quickly find changes within a line.
What you should really be looking at is making sure the CSS is readable. Use the format that your team is comfortable with. Make sure everyone does the same. See what the CSS community does. I don't think a version control system should be the reason you choose a format.
And of course, if you want compressed / minified CSS ( which is not exacly what you are asking ), it has to be part of build process and the file checked in should not be minified