Opinion ColumnThe Road To Reusable HTML Components

Advertisement

A few weeks ago, I dug up an old article that I wrote for Smashing Magazine, “When One Word Is More Meaningful Than a Thousand1.” While I stand firmly behind all of the HTML development principles I listed back then, the article lacked one important thing: hands-on examples.

Sure enough, the theory behind component-based HTML is interesting in its own right, but without a few illustrative examples, it’s all very dry and abstract. Not that HTML enthusiasts should shy away from that (on the contrary, I would say), but there’s nothing like a good example to clear up some of the finer points of a concept.

So, that’s what I’ve set out to do in this article. In the previous one, I sampled a couple of common content types (such as products, stories and videos) across different websites. Now I’ll stick to four different views of a single content type: the story (or news article). It’s a pretty simple and straightforward content type that most people know and have developed at some point in their career. For some real-world inspiration, I’ll refer to the Boston Globe website (a front-end favorite of mine).

One important disclaimer before we get started. This article isn’t so much about the resulting HTML as it is about the methodology of writing HTML. Your opinion on the class names, structures and source order that I suggest along the way may differ, but that’s not what the article is really about (although I’m not saying it wouldn’t yield some interesting discussion).

The Difference Between This And Other Popular Component-Based Methodologies

Component-based HTML development isn’t exactly new. A couple of months ago, Smashing Magazine has run articles on BEM2, OOCSS3 and SMACSS4. While I don’t have enough information to judge BEM, the other two methodologies are clearly opposed to what I am going to propose here.

Methodologies such as OOCSS and SMACCS were born out of frustration with CSS, but these methodologies try to ease CSS development by altering the HTML code. I think this is definitely not the way to go (and if you check the original presentation by Nicole Sullivan, you’ll find that she proposes an early version of mixins as a better alternative). Writing HTML is about so much more than making sure the CSS has the hooks it needs for you to implement the design; so, coming at it from a CSS angle can only diminish the overall quality of the HTML you write. The problem is not limited to providing the right hooks for CSS and JavaScript; the true challenge is to make sure that every element across a website is identifiable. If you can accomplish that, then you’ve got CSS, JavaScript and whatever other script technology you’re using covered without having to worry about the project’s specifics.

The methodology I will demonstrate below was conceived with reusability and robustness in mind. It is largely independent of project-specific requirements and remains as close as possible to the purity that HTML development deserves, resulting in individual HTML snippets that are as versatile as they are reusable.

Step 1: Gather All Views And Instances Of A Single Component

Let’s take this one step at a time. First of all, we need to state the requirements of our content type. To do that, we would normally run through all of the wireframes of a project, listing and grouping all of the different instances and views of each content type. To keep our example as clear and simple as possible, though, I’ve hand-picked four representative views that I’ve encountered on the Boston Globe5 website.

Boston News

I peeked quickly behind the curtains and found the following hooks in the HTML code:

  1. Shortlist view: .in-section ul li
  2. Thumb view: .feat-thumb
  3. Summary view: div.story
  4. Detail view: div.article (or no root at all)

To be honest, I find this quite messy. If for some reason you wanted to single out all stories on your page or website (whether for CSS, JavaScript, analytics or another reason), you would have to work around quite a few ambiguities. Surely, we can do a better job.

Step 2: Define The Root

<article class="story">
   …
</article>

There! That wasn’t too difficult now, was it? We picked the article element and hooked a single class name to it, which we’ll use as a base indicator for all stories. This way, we make sure that we can target all story instances using a single fixed identifier. As you can see from the Boston Globe examples, though, each view requires unique styling. Relying solely on the context of our story instances is far from flexible, so let’s introduce a specifying class for each view:

  1. Shortlist view: .story.shortlist
  2. Thumb view: .story.thumb
  3. Summary view: .story.summary
  4. Detail view: .story.detail

The reason for adding specifying classes to the root element itself (rather than, for example, to a list surrounding it) is flexibility. If tomorrow you are asked to build a composite list that holds both summary and shortlist views of the story component, you want to be able to do that without breaking a sweat.

Step 3: Defining The Logical Units Inside

With that out of the way, it’s time to look at what’s inside each story component. Rather than writing the HTML for each separate view, we’ll start by going through all of the different views, listing all of the elements (i.e. logical units) that we find inside. For each element, we’ll define the HTML. Mind that these logical units could probably reappear in a different context and that they are usually components by themselves, so chances are high that you’ve already written HTML snippets for them elsewhere in your project.

Heading

There’s always a heading. The heading summarizes all of the content that follows, so it’s one of the most essential parts of your content type (apart from the content itself, of course). All of the views listed above contain a heading, but even if you come across a view that doesn’t visually display a heading, put it in the HTML code anyway and hide it with CSS if necessary. This way, you will always “enter” your content type knowing what it’s going to be about. As for the actual code, that’s pretty straightforward:

<h1>news heading</h1>

Thumbnail

The second thing we see is a thumbnail image. Thumbnail images aren’t quite a part of the actual content, although in some cases a thumbnail is little more than a (browser-)resized version of the first image within the story content. It doesn’t have to be, though, because a thumbnail functions mainly as a visual cue that attracts the visitor’s attention to the story. In some cases, it isn’t even featured at all in the story itself, so let’s consider it a standalone item.

Again, the code is pretty simple. We’ve just added a wrapper around the img element so that we can easily add a caption if needed.

<div class="image thumb"><img src="…" alt="…" /></div>

Meta Data

Most content types feature meta data. Meta data isn’t truly a part of the content itself, but it tells you something extra about the content embedded within the content type. In the views above, we find several types of meta data: author, publication date, section indicator and a “first published in [resource]” line.

Coming up with the markup for meta data is a little trickier. If you follow the HTML5 specficiation to the letter, then you are supposed to use a definition list. Meta data is nothing more than a list of label-value pairs, which is exactly what the specification’s authors had in mind when they expanded the semantic range of the HTML5 definition list. But because the markup for definition lists is still missing a wrapper for list items, it’s not very robust, and in many cases styling it proves to be a real hassle (if not impossible). You could invalidate your code by wrapping a div around each dd-dt pair (so that you still enjoy the semantic benefits of the element), but I usually prefer to keep my code valid, sacrificing some tag semantics in the process.

<div class="meta">
    <div class="author">
        <span class="dt">label:</span><span class="dd">value</span>
    </div>
    <div class="publishDate">
        <span class="dt">label:</span><span class="dd">value</span>
    </div>
    <div class="section">
        <span class="dt">label:</span><span class="dd">value</span>
    </div>
    <div class="publishedIn">
        <span class="dt">label:</span><span class="dd">value</span>
    </div>
</div>

Abstract

An abstract is a short summary of or introduction to your content type. In some cases, but not always, it is identical to the actual introductory text. If the abstract is identical to the introductory text, then you could consider it a part of the actual content; if it’s tailored copy, then it should be marked up separately.

As for the HTML, you could use a paragraph tag with a class attached to it, but then you’d limit abstracts to a single paragraph. Looking at the Boston Globe example, it’s fine, but if we want our code to be portable across projects, then keeping our options open is probably best. This results in the following HTML code:

<div class="abstract">
    <p> … </p>
</div>

Action Links

In the detail view of the story, we see a list of actions related to the story itself. Typically, lists such as these include print and mail actions and, of course, the token social sharing options. Instead on relying on source order or numbered classes, we’ll give each link a unique class so that we can play around with it if needed.

<div class="actions">
   <ul>
      <li class="recommend">…</li>
      …
      <li class="print">…</li>
   </ul>
</div>

You’ll notice that the action list is placed above the content, making it a likely candidate to be put inside a header element. While I’ll stick to that as a concession to the design, the links actually belong in the footer element of your content type. These are actions that become relevant once you know the context. You wouldn’t (or at least shouldn’t) share an article based merely on the title; knowing the content is crucial to deciding on your action. Adventurous CSS’ers could leave room in the header and then position the list from within the footer, but that would make the CSS implementation more fragile.

Actual Content

Finally, we get to the crux of the matter, the story itself. What’s actually inside a story often depends on the freedom you’ve given to your content editors. Either you’ve given them a fixed set of templates to work with, or you’ve just dropped a WYSIWYG editor into the CMS and hoped for the best. One thing you need to do, though, is contain the content section, if only as a warning that what follows may be user content.

<div class="content">
    …
</div>

Related Stories

Finally, we find a shortlist of related stories. The most important thing to recognize here is that example one is exactly the same view as the list of related stories that we’re trying to make, so there’s really no reason to differentiate the HTML code between the two instances.

<section class="storyList">
    <div class="main">
      <article class="story"> … </article>
    </div>
</section>

Step 4: Defining Structural Containers

The elements listed above have not only a logical sequence of elements, but also a logical hierarchical structure. Some elements precede the content itself and should be placed separate from the main content. Some elements are afterthoughts or additional information and should be placed after the actual content. To do this, we set up a typical header-main-footer structure.

<article class="story">
   <header> … </header>
   <div class="main"> … </div>
   <footer> … </footer>
<article>

The main wrapper might not look absolutely necessary at first glance, but because it is a logical unit, it deserves a container of its own.

Step 5: Throw Everything Together

Now that all of the HTML snippets are ready, it is time to throw everything together, creating one master component.

<article class="story">
   <header>
      <h1>story heading</h1>
      <div class="image thumb"><img src="…" alt="…" /></div>
      <div class="meta">
         <div class="author">
            <span class="dt">label:</span><span class="dd">value</span>
         </div>
         <div class="publishDate">
            <span class="dt">label:</span><span class="dd">value</span>
         </div>
         <div class="section">
            <span class="dt">label:</span><span class="dd">value</span>
         </div>
         <div class="publishedIn">
            <span class="dt">label:</span><span class="dd">value</span>
         </div>
      </div>
      <div class="abstract">
         <p> … </p>
      </div>
      <div class="actions">
         <ul>
            <li class="recommend">…</li>
            …
            <li class="print">…</li>
         </ul>
      </div>
   </header>
   <div class="main">
      <div class="content"> … </div>
      <aside>
         <section class="storyList">
            <div class="main">
               <article class="story">…</article>
            </div>
         </section>
      </aside>
   </div>
   <footer> (used for read more links, links to comment section, etc.) </footer>
<article>

Step 6: Adding Microdata

Even though the HTML code is now flexible and descriptive enough for other scripts to extract or pinpoint whatever structure they need, our component still misses a common vocabulary. Sure enough, we’ve added a .story class to the root element, but what about using .news, .article or .newsItem? They’re still not very semantic. Well, HTML5 provides us with microdata6, a part of the HTML5 specification, which allows us to add a global vocabulary to our HTML code. You can make your own vocabulary if you wish, but if you check a website such as Schema.org7 you’ll see that plenty are already available for the most common objects. As a bonus, search engines such as Google, Yahoo and Bing support microdata already.

The itemscope property should be placed in the root element, together with the itemtype (which specifies a URL for the vocabulary — in this case, the Schema.org website). After that, it’s just a matter of running through the available vocabulary properties and adding them to your code using itemprop. This will give us the following HTML component:

<article class="story" itemscope="itemscope" itemtype="http://schema.org/NewsArticle">
   <meta content="en" itemprop="inLanguage" />
   <header>
      <h1 itemprop="headline">story heading</h1>
      <div class="image thumb"><img src="…" alt="…" itemprop="image"/></div>
      <div class="meta">
         <div class="author">
            <span class="dt">label:</span><span class="dd" itemprop="author">value</span>
         </div>
         <div class="publishDate">
            <span class="dt">label:</span><span class="dd" itemprop="datePublished">value</span>
         </div>
         <div class="section">
            <span class="dt">label:</span><span class="dd" itemprop="articleSection">value</span>
         </div>
         <div class="publishedIn">
            <span class="dt">label:</span><span class="dd">value</span>
         </div>
      </div>
      <div class="abstract" itemprop="description">
         <p> … </p>
      </div>
      <div class="actions">
         <ul>
            <li class="recommend">…</li>
            …
            <li class="print">…</li>
         </ul>
      </div>
   </header>
   <div class="main">
      <div class="content" itemprop="articleBody"> … </div>
      <aside>
         <section class="storyList">
            <div class="main">
               <article class="story" itemscope="itemscope" itemtype="http://schema.org/NewsArticle">…</article>
            </div>
         </section>
      </aside>
   </div>
   <footer> (used for read more links, links to comment section, etc.) </footer>
<article>

Step 7: And Finally…

Now that we have our master component, all that’s left to do is check each view and remove the elements from the master component that are not needed. If this results in any leftover (= empty) structural wrappers, we’ll remove them, too. This will give us the following snippets:

Shortlist View

<article class="story shortlist" itemscope="itemscope" itemtype="http://schema.org/NewsArticle">
   <meta content="en" itemprop="inLanguage" />
   <header>
      <h1 itemprop="headline">story heading</h1>
   </header>
<article>

Thumb view

<article class="story thumb" itemscope="itemscope" itemtype="http://schema.org/NewsArticle">
   <meta content="en" itemprop="inLanguage" />
   <header>
      <h1 itemprop="headline">story heading</h1>
      <div class="image thumb"><img src="…" alt="…" itemprop="image"/></div>
      <div class="meta">
         <div class="section">
            <span class="dt">label:</span><span class="dd" itemprop="articleSection">value</span>
         </div>
      </div>
   </header>
<article>

Summary view

<article class="story summary" itemscope="itemscope" itemtype="http://schema.org/NewsArticle">
   <meta content="en" itemprop="inLanguage" />
   <header>
      <h1 itemprop="headline">story heading</h1>
      <div class="image thumb"><img src="…" alt="…" itemprop="image"/></div>
      <div class="meta">
         <div class="author">
            <span class="dt">label:</span><span class="dd" itemprop="author">value</span>
         </div>
      </div>
      <div class="abstract" itemprop="description">
         <p> … </p>
      </div>
   </header>
   <div class="main">
      <aside>
         <section class="storyList">
            <div class="main">
               <article class="story" itemscope="itemscope" itemtype="http://schema.org/NewsArticle">…</article>
            </div>
         </section>
      </aside>
   </div>
<article>

Detail view

<article class="story detail" itemscope="itemscope" itemtype="http://schema.org/NewsArticle">
   <meta content="en" itemprop="inLanguage" />
   <header>
      <h1 itemprop="headline">story heading</h1>
      <div class="meta">
         <div class="author">
            <span class="dt">label:</span><span class="dd" itemprop="author">value</span>
         </div>
         <div class="publishDate">
            <span class="dt">label:</span><span class="dd" itemprop="datePublished">value</span>
         </div>
         <div class="section">
            <span class="dt">label:</span><span class="dd" itemprop="articleSection">value</span>
         </div>
         <div class="publishedIn">
            <span class="dt">label:</span><span class="dd">value</span>
         </div>
      </div>
      <div class="actions">
         <ul>
            <li class="recommend">…</li>
            …
            <li class="print">…</li>
         </ul>
      </div>
   </header>
   <div class="main">
      <div class="content" itemprop="articleBody">…</div>
   </div>
<article>

Reusable HTML Components Make Sense

If you look closely at the core principles of HTML, you will see that HTML leaves little room for variation. The HTML code we write is supposed to describe our content as clearly as possible, independent of the styling; so, there is really no reason to make different structural versions of a single component that appears in different contexts, pages or even projects. A news article is a news article, and while the inner particles may vary, the core structure, tag selection and naming conventions need not be tampered with. Of course, there is still room to accommodate the author’s personality, including minor personal preferences, certain ideologies and overall experience, but one author should ideally stick to a single structure for a single component.

Component-based HTML also has important practical advantages. Of course, the news article above is just one simple example, but you could do the same for all of the components that you use across projects. This might seem like a lot of work at first, but you’ll need to do it only once; after that, you can spend the time that you’ve saved on the dumb monkey work of fine-tuning your library. When I write the HTML for a new website these days, about 80 to 85% of the components are out of the box; the remaining 15 to 20% consist of small changes for project-specific requirements and new components (which might get added to my core library later on). This speeds up HTML development dramatically.

It’s also a tremendous advantage for people who prefer to design in the browser. One of the biggest drawbacks of designing in the browser is that the HTML is usually the least of your worries. You might intend to clean it up later, but if you’re honest with yourself, then you know that the probability that you’ll take the time to perfect an aspect of your work that’s mostly invisible to the client anyway is quite low. By using your own library of components, you won’t need to worry about the HTML anymore. If you need a certain component, you can just pluck it out of the box, knowing that you’re getting quality HTML from the start, and leaving you to focus on the design and CSS.

The most important advantage of component-based HTML is the quality of service you will be providing to your clients. Rather than delivering project-specific (i.e. styled) templates, you can offer them a solid HTML and component framework. This way, you give clients the option to deploy these components across multiple websites. Again, this will greatly speed up HTML development (and back-end implementation) in future projects — projects that can now start as soon as the wireframes are finished, rather than once the graphical designs are done. You could even go so far as to wireframe using your HTML components (with a white-label CSS attached to them). The possibilities seem endless. At the same time, this methodology will introduce an unprecedented level of consistency and predictability in code across all of the client’s websites, two things that are often lacking these days.

The Future Of HTML

The way I see it, reusable, component-based HTML is definitely the way forward, and it’s about time we take this next step in HTML development. Just start from the components that you’ve already built, make yourself a snippet library, and go from there. Of course, some level of customization will always be needed, but I’m confident that the HTML snippet above can handle 90% of all story content types that you’ll find on the Web. The meta data may differ a little sometimes, and certain visualizations might require you to change the source order, but the basics are there to create whatever you need in less than five minutes. This is about applying the DRY principle (“don’t repeat yourself”) not just within a single project, but across multiple websites and even multiple clients.

In the end, methodologies such as OOCSS and SMACSS will only work against this ideal, because they are rooted in visual styling that prohobits the proper reuse of components across different websites. Not only that, but they will slow down the development cycle because the design becomes just another dependency. For now, this means you’ll have to rely on CSS preprocessors if you want maintainable CSS, but in the long run, we’ll benefit greatly from adapting the methodology described above. I’m interested in hearing your thoughts on this.

Image source8 of picture on front page.

(al)

Footnotes

  1. 1 http://www.smashingmagazine.com/2010/07/14/when-one-word-is-more-meaningful-than-a-thousand
  2. 2 http://www.smashingmagazine.com/2012/04/16/a-new-front-end-methodology-bem/
  3. 3 http://www.smashingmagazine.com/2011/12/12/an-introduction-to-object-oriented-css-oocss/
  4. 4 http://www.smashingmagazine.com/2012/04/20/decoupling-html-from-css/
  5. 5 http://bostonglobe.com/
  6. 6 http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html
  7. 7 http://schema.org/
  8. 8 http://www.flickr.com/photos/opensourceway/4749432099/

↑ Back to topShare on Twitter

Niels Matthijs spends his spare time combining his luxury life with the agonizing pressure of blogging under his Onderhond moniker. As a front-end developer he is raised at Internet Architects, investing plenty of time in making the web a more accessible and pleasant place.

Advertising
  1. 1

    This will for sure speed up HTML development. As a front-end developer, I can definitely see this in the future.

    0
  2. 2

    /me looks back and just notices that JSF has been doing this for ages by now :)

    0
  3. 3

    Great post! This will definitely help. But why Micro Data as opposed to Microformats or RDFa? I’m not sold on any of them, so I’d love to see a post on that!

    0
    • 4

      My three reasons for picking microdata:

      1/ It’s a html5 proposed standard and since I’ve used html5 for the rest of the code, why not?
      2/ Since our first priority is targeting search engines, it helps that Google, Microsoft (Bing) and Yahoo all helped to write the microdata standard (+ their search engines already interpret the code, so it’s not just some theoretical standard).
      3/ http://schema.org is very ease to use. Microformats documentation is hell and RDFa docs are even worse. For an html guy, microdata is jeasy and it feels natural.

      Still, if you prefer microformats the core of the article remains intact. Just add the microformats data to your component and off you go :)

      0
      • 5

        Gunnar Bittersmann

        October 24, 2012 2:18 am

        1/ Microdata is part of the WHATWG spec, but is not included in the W3C HTML5 spec. It has been taken out in order to let RDFa/RDFa Lite co-exist.
        RDFa/RDFa Lite is a thought-out solution by a bunch of people, while microdata is a one-night hack of Hixie’s.

        2/ Search engines support RDFa/RDFa Lite as well.

        3/ Don’t confuse vocabulary and syntax! You can use the schema.org vocabulary in RDFa Lite syntax.

        To me, RDFa Lite seems more reasonable and easier to use than microdata. (What’s the sense behind the need for @itemscope when there’s @itemtype in microdata?)

        Check out http://manu.sporny.org/2012/mythical-differences/

        0
        • 6

          A very insightful article, thanks for sharing Gunnar.

          Now, to link it back to my article … change the html of your component to the RDFa Life syntax once and you’re good to go for all your future projects (and/or updating older projects).

          0
    • 7

      After having being forced to use microformats in a school project, i can tell you why you WONT use microformats:
      1: its old outdated and forgotten.
      It is rarely updated, several years ago since it was the last time a keyword was implemented, and over a year since the last draft specification update. Documentation is messy. And it relies on major browsers and websites to adobt the specification since its just a bunch of people who made microformats that lobby to increase its usage. They have no affiliation with groups like W3C. This low adoption rate means you are forced to use unreliable plugins to read microformat data. Also microformats is bad for your markup, in some cases it doesnt even validate, and messes with screen readers (all of this is a big NO-NO if you want to make a truly accessible website for both vision and hearing impaired). Heck even BBC advised against using microformats.
      And when spambots have taken over microformats wiki, then you know it is in a sorry state.

      Microdata on the other hand, is a soon-to-be integrated part of HTML5. Already here it gains an upper hand compared to all rivals. Also it is not only backed by, but also authored by the likes of Google and Microsoft and many other major players, so you know there will be huge compatibility in the near future.

      RDFa i have no experience with, but from the looks of it, still better than microformats.

      0
  4. 8

    For me; good categorization (what this is all about) => optimization, so nothing new :)) But article is very good.
    BR

    0
  5. 9

    I really love the idea of keeping semantics with the HTML and less leverage on the CSS to modularize your markup. Sounds great in theory, but I wonder how easy it is to ‘pull from the toolbox’ when client demands can vary so often.

    Also, I agree with @joseph on getting more information about the decision to go with micro data vs microformats or RDFa

    0
  6. 10

    You know it seems to me that the definition of <dl> went something like “one or more” …

    If that’s the case instead of using div’s, classes and a bunch of spans – one might propose:

    <div class="meta">
      <dl class="author">
        <dt>...</dt><dd>...</dd>
      </dl>
      <dl class="publishDate">
        <dt>...</dt><dd>...</dd>
      </dl>
    ...
    </div>
    

    Just a thought to save a lot of typing.

    0
  7. 13

    Although I really like the concept underlying this article and it’s certainly a strategy I’d employ there its this small nagging voice in the back of my head. The voice is telling me to use a different technique altogether to get to the place this article its leading me, namely XML and XSLT.On the other hand in my work as web developer and CMS consultant I am still bit sure what I’d rather use .the jury its still hung on my case :)

    0
  8. 14

    Very Good. Thanks for the article.

    0
  9. 15

    This is legit.

    0
  10. 16

    I think that this is a great idea: limit the number of components that you make based on the content that you have. But I think that it doesn’t need to be separate from OOCSS. The way that I like to write CSS is to create components and subcomponents coming from three sources:

    1) Describing how the content is presented to the user
    2) Describing the content
    3) Describing a function for an interactive control

    In your example, you create your component (article.story) solely from the nature of the content (source #2 above), which allows you to keep the amount of components low relative to the amount of markup you have and allows good reusability across different views. I have never really gone this far into applying the same component across such different views before because of the case of view 1 and 2. In view 1 and 2 you are describing the content as “story”, but you only have either a single line of text (headline) or an image along with some text, which isn’t technically a story in itself. I am not saying that your approach is incorrect – actually the simplicity intrigues me – I merely mean to explain why it hasn’t occurred to me before and why I may have some reservations applying it so far across the board.

    But that is beside the point. Let’s continue with your components and how I think they can fit into OOCSS. The next logical step would be to style the four different views that you have, in which case I would use a modifier on your base component. This is where you would get the following, using my method of modifying components:

    article.story.-shortlist
    article.story.-thumb
    article.story.-summary
    article.story

    No need for a modifier in the last view, because that is the natural view for a story to have.

    I have done something similar before (albeit a bit more presentational), where I used a .story component with modifiers to describe and style content (see the full .story at the top right of the page beside the image, and then the .story.-short at the bottom):

    http://www.galerierammer.at/de/projekte/fankultur-macht-kunst

    I would be really interested to see a further merging of this style with more OOCSS ideals, just to see how far content-describing components can be pushed! I am slowly gathering a component library of my own right now ( https://gist.github.com/3492398 ), but I have been neglecting the content-description angle of component creation. Thanks again for re-awakening me to it!

    0
    • 17

      These days I make two distinctions when it comes to OOCSS.

      1/ The underlying concept. I think OOCSS really helped people to bring more structure to their work. To think in components, to work with components. There are definitely some things to be learned from it, so conceptually it helped us along just fine.

      2/ The practical implementation. Which is where I start to have some reservations. You can go as far as you like with OOCSS of course, but if you really separate your styles in reusable components this means that in theory these styles (classes) could be applied to whatever html-hook you have in your code. Now if you use html components, it becomes increasingly difficult to make your components dynamic as every html hook you have in your component could accept an unlimited number of OOCSS classes. Remember, the ideal is to reuse these components cross-project, even cross-client, so you have to build your html without any known styling variables. OCCSS makes things very messy on the html side of things.

      The way I see it, OOCSS works until the point where you need to add extra classes to your html. Using preprocessors you can still modularize your css and keep your html clean. I know that for now this means filesize overhead (but make sure to test exactly how big the impact is, because what you lose in performance you gain in maintainability) .

      As for making abstractions (what is a story and what is not) I believe that even a headline referencing a story is enough to mark it up as a story. If you have a component listing the five latest articles, it doesn’t really matter what’s inside each item. It could just be a headline, maybe they’ll add a thumb later and in the next iteration a publish date could be added. The idea behind the list item is still the same: an internal advertisement to your actual story. Marking it up as a story ensures that whatever data extraction or statistics gathering you’ll do afterwards, you can always recognize it as a story with one single hook (the story class).

      Oh, and as for not using story.detail (since it’s the base variant), it’s tricky because styling can vary quite a lot between views. Sometimes the shortlist/thumb/list views are so different from the detail view that you’ll be overwriting a lot of css. To be sure I always include a class for each view. If you don’t need it that’s fine, if you do need it (which happens a lot in my experience) you’ll be glad it’s there :)

      0
      • 18

        Thanks for your reply. I’m not entirely convinced that OOCSS will make the html all that much messier. It will add one extra modifier class (such as “-shortlist”) to the root element, and then it will add subcomponent classes to the title, subtitle, etc (such as “story_title”). Aside from that we wouldn’t need any more classes in these cases.

        If you compare that to the amount of extra markup that the Schema.org microdata is adding, you’ll see that it is not really all that bad.

        I am glad you have taken the time to write this article, because it allows me to consider another angle in creation of components and how to reduce the number of components I create.

        0
  11. 19

    Excellent idea! It makes sense to flesh out all the components of an article first and THEN whittle down the different views that will show up throughout a website.

    0
  12. 20

    I’m not sure what you’re talking about with this:

    “To be honest, I find this quite messy. If for some reason you wanted to single out all stories on your page or website (whether for CSS, JavaScript, analytics or another reason), you would have to work around quite a few ambiguities. Surely, we can do a better job.”

    The only difference is that they use the story class on a DIV and you use it on an ARTICLE. How is that “messy?”

    0
    • 21

      I listed some of the other possibilities based on their code in the article already. It’s not just div.story, it’s also .feat-thumb, .in-section ul li and div.article. All these selector point to the same thing: a story.

      Since you could be interesting in tracking stories across different views, that’s four different selectors you need to maintain, rather than one. That’s messy (not to mention pointless).

      0
  13. 22

    I think this is a good idea. It will definitely speed my work. Thanks for a good tip.

    0
  14. 23

    Good summary. Altho you could just use a CMS!

    0
  15. 24

    Thank you for a very nice article. It diggs into the abstraction of components even deeper than I do :-). One suggestion though: try to be as semantic and as brief as possible. There are more appropriate tags than those you use in the example above that fit the needs of a semantic HTML code of article. Why to mess around with a bunch of DIVs, SPANs and unnecessary classes where you can use DL or TIME? But again – nice article, I like the idea of writing down all the components of the element and then adjusting the different views.

    0
    • 25

      Alex: in my defense, I anticipated this question and already handled it in the article itself. Maybe a more practical explanation could clear things up?

      The problem I have with dl-dd-dt structures is that they lack a list container (in my example the named divs containing the div.dd and div.dt elements). Meta data is a typical collection of elements where logical and visual structure often don’t match. Just take the Boston Globe example again (4th story) and see how “article published in” is aligned to the right while the others are set to the left.

      Not being able to position the unit _as_ a unit is a serious enough drawback for me to leave the dl-dd-dt structure for what it is and to built my own (alternative) structure. I’m sure I can come up with some kind of css structure to mimic the styling above, but remember that I want to use this component not only for this case, but the following 10 projects too.

      To take it even a bit further, for me data presentation and data input are very much related in nature. Both are label-value structures, the only difference is that the value part of data presentation is the actual data, where the value part of data input is the input control. This means that in both cases I’ll be using pretty much the same html and marking up forms with dl-dd-dt structures is simply too limiting in my experience.

      Then again, if you feel confident enough, just go ahead. :)

      0
  16. 26

    In Step 1, Gathering all views and instances of a component, you write: “To do that, we would normally run through all of the wireframes of a project, listing and grouping all of the different instances and views of each content type.”

    Wouldn’t it be stellar if the IA producing the wireframes was already thinking in terms of modular components and used the wireframe document as a means of identifying each base component and variations for each type of instance?

    I like this approach to mark-up a lot, thanks for sharing it.

    0
    • 27

      Absolutely. It gets even better when you add some simple visualizations for each component (whitelabel css – dare I say responsive behavior) and you offer a way for wireframers to use your components to “compose” the wireframes. You’d be surprised how far you can get with 50-60 base components. Of course there’s always some level of customization needed, but before you know it the wireframers are writing the html for you while you can spend your time on perfecting the components!
      There just one important distinction to make: this works well for drawing out each and every screen, not so much for conceptual wireframing (which I believe is a more creative task and shouldn’t be bound to existing frameworks).

      0
  17. 28

    Yep! Very nice and sane principle! I think I am going to start using it properly, as you suggested, from now on!

    0
  18. 29

    Nice article, HTML structure is something that often gets overlooked and I like the idea of having a go-to component library. I don’t see though how this approach is so at odds with OOCSS or SMACSS other than a few extra classes. I like the idea of crafting the HTML before starting any styling – in which case what you came up with is brilliant. Then taking a OOCSS approach I might add some additional classes to components. For instance class=”image thumb” might become class=”image thumb rounded” – I see no problem with this. Sure I could use Sass’ extend functionality here instead, but would that be a whole lot different?

    0
    • 30

      Darren: the problem with those “extra classes” is that they could pretty much be placed anywhere within your component (of course depending on how far you take the OOCSS principles). This is fine if you use the html components as simple code-shortcuts, but we’ve went ahead and are already using them in a more dynamic environment. There is of course some customization allowed, but making the components so you can add classes on each and every html tag through customization doesn’t really help to keep them clean and manageable. Back-end devs will be facing the same problem … they too work with modules and components, when using methodologies like OOCSS there are just too many variables that should be taken into account. On the other hand, by using less or sass you can keep the html (implementation) clean and just fix everything in css itself, containing the problem to a place where it actually belongs (the css file). It’s overall a much cleaner solution, especially as html changes are usually more expensive than css changes.

      0
    • 31

      The problem I’d have with your example is the “rounded” class that is hooked into your HTML. It doesn’t belong there, as it says something about presentation, not about meaning. Many will claim this is practical and harmless. I agree to a point only. If your image thumbs are to be changed to non-rounded looks, you will have to update all existing HTML, also if it is a CMS. Or, you could keep the rounded class, after which it becomes confusing to maintain.

      I like the core concept of OOCSS where you are forced to think in reusable components. But please, keep it as semantic as possible. Otherwise it will not solve a problem, it will only move it to HTML.

      0
  19. 32
  20. 33

    Thanks Niels, I was just thinking about this exact topic yesterday. Good HTML architecture is key.

    0
  21. 34

    Excellent work Niels, it’s an art in itself trying to keep re-usable components light and modular enough so that they can either operate as standalone items or can be lightly modified with ease. I wrote about my own “Airfix” workflow recently which agrees with a lot of what you have already said – http://www.jordanm.co.uk/post/32866575759/the-airfix-responsive-workflow

    0
  22. 35

    Thanks for the write up.

    2 questions:

    1)
    Shortlist view: .story.shortlist
    Thumb view: .story.thumb
    Summary view: .story.summary
    Detail view: .story.detail

    Why are none of those classes added to your final code samples?

    2) Why have you not chose to use a ul for things that are obviously lists by design – storyList?

    0
    • 36

      1/ My mistake! They are now added.
      2/ I remember reading somewhere that a list of articles does not need to be wrapped in an ul-li/ol-li structure, sadly I can’t find the source anymore. If you check the w3c html5 article spec though, they state an example of a blog post with comments and they’re not using li’s either, so I’m sure I didn’t just dream it up.

      0
  23. 37

    A well-written article. I definitely agree with your idea of a snippet library. I maintain my own too, based on Jeremy Keith’s Pattern Primer. If maintained, it certainly helps to keep the focus on reusability within the code. I am a big fan of SMACSS and OOCSS though, and although it does create a few extra classes, I found I can still create fairly generic modules without too much of a problem. One slight concern with your method that I would have is the length of selectors and specificity issues that may come about using fairly generic class names. It all depends on how much variety of different content you have maybe. I like how it puts the focus on content strategy however.

    0
  24. 38

    Asking questions are truly nice thing if you are not understanding anything entirely, but this paragraph offers pleasant understanding yet.
    http://Www.proprofs.com/

    0
  25. 39

    Hey Niels,

    I really enjoyed reading this article. I’m not entirely sure about your reservations about the OOCSS/SMACSS methodologies, although I agree that they are quite difficult to implement if you dont have full control over all the markup all the time (like with CMSes). While these methodologies won’t work in their most literal interpretation, it might work when you start leveraging exend functionalty of a preprocessor instead of movig the class burden to the HTML.

    I can see both approaches working together quite nicely that way, making both the HTML and CSS modularized and reusable. Given this right degree of abstraction and decoupling you could build a visual pattern library in an OOCSS/SMACSS manner, applying these to your structural pattern library, what’s your take on this?

    0
  26. 40

    Thanks for this great article. I have exactly the same reservations regarding OOCSS, SMACSS & Co and I’m always happy when people who can phrase things much better than me put this into well written words. Hope this leads to a change of perspectives or at least to some rethinking in some heads. I’m not saying that OOCSS etc. do not have any right to exist, but I’m clearly missing people who question and challenge those approaches.

    Apart from that you’ve put microdata in the spotlight a bit which still seems to be unknown to a lot of web developers. Nice side effect :)

    0
  27. 41

    Funny, you mention BEM in passing, but miss the chance to integrate it with your example. But instead it’s suggested that Devs build a snippet library. Meh.
    Unless you have an automated system to help manage and compile the snippets into a site, you’re only halfway there to actualizing any productivity gains. BEM excels at this. And the other area where this directly applies is CMS templating.
    This method goes well with a CMS that supports multiple “views” of content: full, line, list, panel, thumb, paginated, etc. Because you only have to create mark-up for each view once. (I prefer eZpublish CMS for such view/template managing.)
    Finally, beware the lure of the “one true mark-up.” There are many ways, methods and requirements for marking-up content. The minimum is best.

    0
  28. 42

    This will for sure help me getting things done faster and with better quality!

    0
  29. 43

    There’s a kind-of-related movement which helps you share components and easily deliver them to the browser, which also works with JS and CSS: https://github.com/component/component.

    Already 160+ components: https://github.com/component/component/wiki/Components

    0
  30. 44

    Hi,

    Great article here. As a Front-End developer I find articles like this very helpful in order to simplify my processes during a project.

    I’ve built a basic (responsive) framework with Html5 and Sass which has helped me to reduce the time I spend on creating basic structure for my site. The naming conventions I used where messy after a while because it was really hard to name things if you are working on a big project. However, after reading this article I’ve realised that I was naming my CSS selectors depending on the the content not the context.

    One thing that I still struggle with is html5 tags. I use the ‘header’ – ‘footer’ – ‘article’ tags for most of my sites but I believe I’m not using them in a proper manner. In this article header is used for the title area of a post/page whereas I only use it for the header of the site ( same with the footer ).

    My question is: is ‘header’ (for example) correctly used for both main nav area and content headlines? they both work very different on a site so I would like to know if keeping ‘header’ as the menu wrapper is better than having it as a article headline wrapper.

    Many thanks!

    0
  31. 45

    Very helpful article, but I’d love to hear how you (@author, Niels) organize all this HTML markup for reuse? Any special tips, do you use any special software for that, use macros, code snippets, … ? I am quite sure you don’t have it stored in some folder in your computer and then everytime find that folder, open it up and find the right piece of code. If so, then zencoding is faster, IMHO.

    Would love to sense some feedback for my question.

    0
    • 46

      Well, we have a custom developed xml-based system we use, coupled to svn. The repository contains a list of base components (around 40) we can use off the bat in every new project we start. We just reference the components with a couple of configuration options and assemble our html like that. Not open source I’m afraid :)

      0
  32. 47

    I always thought that working with HTML is – let me say – kinda crappy.
    But know I realise that you can put more magic on your own page if you studied all kinds of HTML structures and execute them in any kind of CMS.
    This article was very helpful! Thanks! Installeren Joomla

    0
  33. 48

    Very nice article. I’m using this small software during my code work: http://softfinder.com/html5-validator-for-windows-8

    0
  34. 49

    Web Components - Really ? Can we help Jack the 10 year old ?

    July 26, 2013 6:18 am

    I am a 12 year old (assumption) high school student and need a simple x-y plot for my coursework and I need to publish it to my class site as HTML.

    Is there anything out there tagged as a “COMPONENT” that I can grab and use with my little knowledge of Internet? (oh, I know about tags OK!)

    So I start googling charts and there it is “HighCharts” with pretty much everything that I need.

    But I don’t know Javascript ! A dead end.

    If somehow there was a “REAL COMPONENT” out there that I could simply call like:

    PlotXY(label-x, label-y, )

    I would be sooooo happppy….

    A VOICE FROM ABOVE: Listen Jack; you are out of luck !
    You need to learn javascript and when you think you understand arrays, loops, parsing and stuff like that and ALSO learn HightCharts; then there is hope.
    Really people! with all the technology we have, we can not make Jack happy ?

    You can see how I can help Jack with his project. No pre-requisite other that what he already has.

    Head over to http://Sandbox.Melify.com and see for yourself.
    No HTML, NO JavaScript, No CSS. Its just a component like our English Dictionary explains and I quote:

    “A smaller, self-contained part of a larger entity. Often refers to a manufactured object that is part of a larger device. A CPU is a component of a computer.”

    Can you help Jack ?

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top