June 6, 2016 #css

If you’re not happy with the default text-decoration: underline, want to tweak the thickness of the underline or vertical space between the text and the underline, then you may want to the background trick introduced in this post. Medium is also using this kind of technique.

// use background image to draw the underline
// this way we can tweak the vertical space between text and underline
a {
  text-decoration: none;

  background-image: linear-gradient(to bottom, rgba(0,0,0,0) 50%, rgba(0,0,0,.6) 50%);
  background-repeat: repeat-x;
  background-size: 2x 2x;
  background-position: 0 22px;
}

A quick demo of how it looks like:

text underline with background image demo

One caveat of this approach is, the position and thickness of the underline is depending on the font size. So if you’re using a different font-size as I do in the demo, you may need to change the background-position to fit your design.

Also if you want to apply it to different part of your page which all have different font-size, you will need to figure out the exact size for each part.

In my blog I’m using SCSS variables to document this behavior.

$post-font-size: 20px;
$underline-size: 2px;

background-size: $underline-size $underline-size;
background-position: 0 ($post-font-size + $underline-size);
January 1, 2016 #css #html

Happened to read a HTML and CSS style guides in http://codeguide.co when listening to Mark Otto - Bootstrap 4 and CSS architecture at scale | Full Stack Radio, as any style guides most of the commonly known ones are nothing new but still found these are pretty helpful, and is reflecting something I've learned from my current project.

I'll just paste those guides and demo code as a reference, credit to Mark Otto (@mdo), and full list is in http://codeguide.co.

Reducing markup

Whenever possible, avoid superfluous parent elements when writing HTML. Many times this requires iteration and refactoring, but produces less HTML. Take the following example:

<!-- Not so great -->
<span class="avatar">
  <img src="...">
</span>

<!-- Better -->
<img class="avatar" src="...">

Declaration order

Related property declarations should be grouped together following the order:

  1. Positioning
  2. Box model
  3. Typographic
  4. Visual

Positioning comes first because it can remove an element from the normal flow of the document and override box model related styles. The box model comes next as it dictates a component's dimensions and placement.

Everything else takes place inside the component or without impacting the previous two sections, and thus they come last.

.declaration-order {
  /* Positioning */
  position: absolute;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
  z-index: 100;

  /* Box-model */
  display: block;
  float: right;
  width: 100px;
  height: 100px;

  /* Typography */
  font: normal 13px "Helvetica Neue", sans-serif;
  line-height: 1.5;
  color: #333;
  text-align: center;

  /* Visual */
  background-color: #f5f5f5;
  border: 1px solid #e5e5e5;
  border-radius: 3px;

  /* Misc */
  opacity: 1;
}

I've always wanted some guides on this topic, putting positioning and box-model related stuff first does make sense.

Media query placement

Place media queries as close to their relevant rule sets whenever possible. Don't bundle them all in a separate stylesheet or at the end of the document. Doing so only makes it easier for folks to miss them in the future.

We used to have a separated single file called responsive.css to write all those media queries for various screen sizes, but later found that it was hard for anyone else to track these changes.

.element { ... }
.element-avatar { ... }
.element-selected { ... }

@media (min-width: 480px) {
  .element { ...}
  .element-avatar { ... }
  .element-selected { ... }
}

But different than the code above, I'd like to nest the media queries right inside the selector, instead of separating and grouping them in another place. This way you don't have to rewrite the selector another time and also can see them in one place so you won't miss it.

.element {
  ...
  @media (min-width: 480px) {
    ...
  }
}
.element-avatar {
  ...
  @media (min-width: 480px) {
    ...
  }
}

.element-selected {
  ...
  @media (min-width: 480px) {
    ...
  }

Shorthand notation

Strive to limit use of shorthand declarations to instances where you must explicitly set all the available values. .. Excessive use of shorthand properties often leads to sloppier code with unnecessary overrides and unintended side effects.

/* Bad example */
.element {
  margin: 0 0 10px;
  background: red;
  background: url("image.jpg");
  border-radius: 3px 3px 0 0;
}

/* Good example */
.element {
  margin-bottom: 10px;
  background-color: red;
  background-image: url("image.jpg");
  border-top-left-radius: 3px;
  border-top-right-radius: 3px;
}

I'm still having problem for 3-value syntax like margin: 0 0 10px;, 2-value and 4-value syntax are fine, whenever I see it I still need a few extra seconds to convert it to top, left and right, bottom accordingly. I've seen some other guides recommending always using the shorthand notation but I guess might be good to have some exceptions. So personally really want to give this style a try: avoid excessive use of shorthand properties.

April 15, 2015 #css #oocss #bem #smacss #oo

After all these years of web development I still haven't found a compelling way to organize and name css, once we all seemed to agree with the semantic naming methodology but as the project grows the magic aura disappears.

Recently my team has started the transition to apply OOCSS, SMACSS and BEM techniques to current project. I tried it a while and really think this is the best way so far to cleanly organize your css(code and files), make it scalable and reusable, with simple intuitive naming methomelodgy.

Recommendations

Here are the reading materials I found pretty easy to follow:

Organizing CSS: OOCSS, SMACSS, and BEM - MattStauffer.co

High level introduction to each terms, with simple example. Read it and you'll get the big picture.

MindBEMding – getting your head ’round BEM syntax – CSS Wizardry – CSS, OOCSS, front-end architecture, performance and more, by Harry Roberts

Have an excellent guide on when to use BEM and not.

The Pros and Cons of Modular Sass — Planet Argon Blog

Great article on the idea behind modular css in general. And the argument over semantic class names convinced me.

Semantic markup is important in communicating the meaning of a webpage and is only becoming increasingly important; however, class names are for the developer. The exception to this relates to the use of microformats, in which case it is necessary to use specific semantic class names. It’s always important to consider names and what they communicate to you, your team, and future developers, but there is no dogmatic reason to avoid classes like “grid-1” or “pull-left” just because they describe presentation. People have conflated the use of semantic HTML (which relates to optimizing content for assistive technologies, browsers, the multitude of devices, and software that recontextualizes and reframes your content) with avoiding presentational class names for years, and I’m not quite sure why.

Support for BEM modules in Sass 3.3 | Mike Fowler

How to write BEM in Sass.

Full Stack Radio - 1: Matt Stauffer - CSS Semantics

A podcast. You'll get more out of it if you already some idea and experience about these terms, as in the podcast there're deep discussions on the very details of daily development.

That's it. Hope this could help you find your starting point.