Reusing Modules

[cooper.semantics]

Usually, when developing a html page, we try to reuse as much html as possible. My question to everyone is, 'if you are reusing a module(aka box) that is visually being used throughout the entire website in different 'containers' of coding, what would you name these?'

A. box
B. module
c. article
e. neither

If specified neither, throw out some suggestions.

I tend to work on larger based projects, and a lot of the time the same rounded corner box is used on several occasions.

You could use group selectors but, if there are over 20 cases of this being reused it can become a headache.

[rochow]

Box... It's probably not the best name, its good because people can look at it straight away and know what it is. Same with header, footer, sidebar... technically not correct, but everyone knows what it it's referring to straight away (which is great where multiple developers work on the same project)

[cooper.semantics]

So for instance, if you had other 'boxes' on a page that shared the same 'styling' but only changed the background image, would you name them:
<div class="box boxA">, <div class="box boxB">?

box - Being the shared 'styling'.
boxA, boxB - Changing the background image.

A co-worker of mine uses this approach. He was telling me that, there is a time and place for semantics haha

[rochow]

I can't think of any perfect solution. Perhaps per-page/content based - <div class="box services"> - at least that makes a bit more sense than boxA, BoxB.. Box Z.. Box A2, Box B2 - especially if other people are editing it

I was thinking about this last night.

#sidebar-left
#sidebar-right

People will instantly go "OMG but you can swap them around and it's wrong!"

So what else could you use...

#sidebar1
#sidebar2

Well that's wrong straight away - I might decide to delete the first sidebar which then leaves #sidebar2 with no number 1...

Talking generic sidebars here like you'd find on Wordpress Templates - full of so much random stuff you can't really name them anything but something generic. That's something I encounter a lot and haven't found a naming convention I'm happy with.

[cooper.semantics]

Yeah, I totally agree with you. It is hard to come up with the perfect solution.

I myself do not like the A/B approach, because if there is 26 different 'tweaked' boxes then there you have the entire 'english' alphabet

What do you think about this approach?

EX1
<div class="article services">
...
</div>

EX2
<div class="article authorization">
...
</div>

Article replacing the box.
Article - A subdivision of a document.

.article { .... }

.services { ... }
.authorization { ... }

[rochow]

Is it an article though? To me, an article is around 250 words+. If it's a heading with a brief excerpt of the article with a link to the full article, I wouldn't say its an article and using it as the class wouldn't be appropriate - perhaps excerpt, intro, or overview instead. I like box as it's generic - I can use the same styling for a box in the sidebar, a box in the content area, and it still sort of applies. Whereas something like .article could only be used in the content section, couldn't use it on the sidebar to wrap around the latest news section without it being taken out of context.

Adding the additional classes in that manner is how I'd do it.

[oddz]

An article is defined as a object of a specific type. Therefore, I think article is fine.

Actually, you could use it for the sidebar. If you used article along with the objects it contains to describe it. Using this approach it isn't actually a sidebar, but a div that describes what it contains. You can create a sidebar now using CSS without introducing that name into the mark-up.

<div class="article secondary-navigation news">
</div>

I also like the idea of using module. However, a module is essentially an article. So the difficulty is differentiating between an article and a module in usable terms.

A module is essentially a set of independent parts that make a more complex part. So perhaps areas which can used interchangeably or something…

[cooper.semantics]

I have been toggling my 'brain' around names for the past couple weeks hehe

[oddz]

Perhaps they are distinguished in that articles can modules and module can contain articles. However, a article may not contain another article and a module may not contain another module. If a module needs to contain another module a article must be used to palce the module inside it.

<div class="article">

	<div class="module">
	</div>
	
	<div class="module">
	</div>
	
	<div class="module">
	
		<div class="article">
		
			<div class="module">
			</div>
			
			<div class="module">
			</div>
			
			<div class="module">
			</div>
		
		</div>
	
	</div>

</div>

classical layout pattern:

<div class="article">

	<div class="module">
	</div>
	
	<div class="module">
	
		<div class="article">
		</div>
		
		<div class="article">
		</div>
	
	</div>
	
	<div class="module">
	</div>
	
</div>

[rochow]

A module is essentially a set of independent parts that make a more complex part. So perhaps areas which can used interchangeably or something...

Module more often than not refers to the fact it's a "module section" in the backend - which means the naming convention is used basically because of how the content is outputted, not what the content is. Similar to how Wordpress runs around slapping widget on everything it can get its hands on.

An article is defined as a object of a specific type. Therefore, I think article is fine.

An article is a group of text, often of which is a smaller part of something larger. For example an encyclopedia contains lots of articles; a blog contains series of articles; a newspaper is a collection of articles. Navigation and article definitely do not go hand in hand.

[oddz]

article:

article |ˈ&#228;rtikəl|
noun
1 a particular item or object, typically one of a specified type : small household articles | articles of clothing.
2 a piece of writing included with others in a newspaper, magazine, or other publication : an article about middle-aged executives.
3 a separate clause or paragraph of a legal document or agreement, typically one outlining a single rule or regulation : [as adj. ] it is an offense under Article 7 of the treaty.
4 Grammar see definite article , indefinite article .

module

module |ˈm&#228;joōl|
noun
each of a set of standardized parts or independent units that can be used to construct a more complex structure, such as an item of furniture or a building.
• [usu. with adj. ] an independent self-contained unit of a spacecraft.
• Computing any of a number of distinct but interrelated units from which a program may be built up or into which a complex activity may be analyzed.
ORIGIN late 16th cent.(in the senses [allotted scale] and [plan, model] ): from French, or from Latin modulus (see modulus ). Current senses date from the 1950s.

In this case modules are essentially the parts used to construct an article. For example, as Car could be defined as an article. The engine,tires,etc could be modules that make up this more complex object. In this case that object would be a Car. At the same time the engine could be an article in itself that contains pistons,etc.

So this methodology could be applied to web like so.

<ul class="article navigation">
  <li class="module"><a href=""></a></li>
  <li class="module"><a href=""></a></li>
  <li class="module"><a href=""></a></li>
  <li class="module"><a href=""></a></li>
</ul>

The navigation element is essentially the "Car" and the list items are modules that make up that single entity.

[oddz]

Here is a general application:

<div class="article">

	<div class="module logo skybox">
		
		<img class="article logo" width="" height="" alt="">
		<div class="article skybox">
			<div class="module ad-1">
			</div>
			<div class="module ad-2">
			</div>
			<div class="module ad-3">
			</div>
		</div>
		
		<ul class="article nav-primary">
			<li><a href=""></a></li>
			<li><a href=""></a></li>
			<li><a href=""></a></li>
			<li><a href=""></a></li>
		</ul>
	
	</div>
	
	<div class="module">
	
		<div class="article">
		
			<h2>Page Title</h2>
			<p>...</p>
		
		</div>
		
		<div class="article nav-secondary quick-contact newsletter">
		
			<div class="module nav-secondary">
			
				<ul class="article nav-secondary">
					<li><a href=""></a></li>
					<li><a href=""></a></li>
					<li><a href=""></a></li>
					<li><a href=""></a></li>
				</ul>
				
			</div>
			
			<div class="module quick-contact">
			
				<form class="article quick-contact">
				</form>
			
			</div>
			
 			<div class="module newsletter">
			
				<form class="article newsletter">
				</form>
			
			</div>
		
		</div>
	
	</div>
	
	<div class="module">
	
		<ul class="article nav-supp">
			<li><a href=""></a></li>
			<li><a href=""></a></li>
			<li><a href=""></a></li>
			<li><a href=""></a></li>
		</ul>
	
	</div>
	
</div>

The entire concept is based on a module describing what it contains and an article describing what it is:

  <div class="module skybox">
   <div class="article skybox">
   </div>
  </div>

This makes it possible to create more specific selectors:

.module.skybox {
}

.article.skybox {
}

This creates a pattern where a modules are essentially items that hold a number of objects and articles are those single objects.

just brainstorming here…

[cooper.semantics]

@Oddz - Okay, I see what you are saying. An article can be used on a particular item or object. So in your example the logo, skybox, nav-primary, etc. are in actuality articles.

[oddz]

yep

They are articles because they represent the complex object being defined through the modules used to create it.

This also begins to solve the problem of wrapping elements. The "wrapper" is now a entity that describes what has rather than what it does. Furthermore, that "wrapper" can be selected while avoiding related articles via using .module in the selector. If a module only contains one article than they both can be distinguished via what their function is.

.module.nav-supp {
}

.article.nav-supp {
}

It all amounts to a is a or has a relationship. If it is a logo than it is article. If the item has a logo than it is a module. So a article semantically identifies a is a relationship while a module identifies a has a relationship.

So if you wanted to be even more semantically correct this pattern could use is and has in place of a article and module.

.has.nav-supp {
}

.is.nav-supp {
}

Upon immediately seeing this css I know now that the first selector selects the "wrapper" essentially and the second the actual entity. This is something that is normally very ill separated. However, with this pattern those types of relationships can be immediately identified.

[oddz]

Here is the concept extended. Now a module can only have one article. However, a article(is) can have any number of modules(has).

<div class="is page">

	<div class="has logo skybox nav-primary">
		
		<img class="is logo"></div>
		
		<div class="is skybox">
		</div>
		
		<ul class="is nav-primary">
		</ul>
	
	</div>
	
	<div class="has content">
	
		<div class="is content">
		
			<div class="has main">
			
				<div class="is main">
				</div>
			
			</div>
			
			<div class="has supp">
			
				<div class="is supp">
				</div>
			
			</div>
		
		</div>
	
	</div>
	
	<div class="has nav-supp copyright">
	
		<ul class="is nav-supp">
		</div>
		
		<p class="is copyright"></p>
	
	</div>
	
</div>

[cooper.semantics]

@Oddz

Looks like a thought out execution

[cooper.semantics]

Sorry to 'bring' such an old thread back, but this is the most appropriate place to ask this question

Say I am using 3 modules(boxes) on a page:

Page 1
box: box 1 styles - contact information
box: box 2 styles - event information
box: box 3 styles - service information

Page 2
box: box 1 styles - Article information
box: box 2 styles - .....
box: box 3 styles - ....

and so on...

.module { ... }
.module?
.module?

? module-primary {}
? module-secondary {}
? module-tertiary {}
seem really not the most semantic, but it looks like the only reasonable approach.

Being that these are reusable containers, there is no telling what these things are going to be wrapping.

Anyone have a logical approach?

Group selectors are out of the questions prior to CMS in my case

[cooper.semantics]

What if there are 5 different boxes used throughout the site with no 'knowledge' of what content will be within...

[Erik J]

I think I would follow the source order, calling them box-1 to box-5. Or maybe content-1 ... -5.

[rochow]

I think I would follow the source order, calling them box-1 to box-5. Or maybe content-1 ... -5.

I decide I want the middle box up the top. Now I want to edit the first box so I edit box-1

Numbers aren't a good idea for that reason.

[Stomme poes]

Hmmm, can we just not give more names to the boxes? Like,

#box1, #box2, #box3, #box4 (whatever normal names they already had, not implying they should be numbered names) {
all the styles they share;
}
#box1 {
the one thing it has different from the others;
}

#box2 {
the one thing it has different;
}

While it can be more code than simply stating one class and all the shared styles inside, the nice thing here is you can add and remove boxes from the one large declaration whenever you want instead of changing classes in the HTML, and also, you can change whatever the One Difference is the same way-- without changing the HTML.

An idea.

[Erik J]

I decide I want the middle box up the top. Now I want to edit the first box so I edit box-1

Numbers aren't a good idea for that reason.

My reason is that I give the boxes names regarding order in the source and/or the content they have. As if I view the page without the css.

Edit)
I usually try to follow that order in the css too. That makes it easy to follow for next developer too.

[Stormrider]

It would make sense to use a class for the common properties (like class="box") and an id for individual ones (id="services") would it not?

<div class="box" id="services">
...
</div>

[Stomme poes]

I've done that a few times. It does make a lot of sense.

[rochow]

My reason is that I give the boxes names regarding order in the source and/or the content they have. As if I view the page without the css.

I meant that. Like, I cut box3 and paste it above box1. So the HTML order is wrong, which then becomes confusing in the CSS stage.