مهران رسا
شنبه 17 اردیبهشت 1390, 16:32 عصر
Semantic mark-up is one of those phrases trotted out by website developers that few clients immediately grasp – but it’s one that’s well worth understanding.
When I’m talking to clients, I do try to avoid speaking in the jargon of my industry. It’s not helpful and can leave clients feeling frustrated or even patronised.
Let’s face it, clients don’t want to have to understand all the detail of how a website works any more than most drivers want to become experts on engine monitoring systems just so they can drive a car. Clients want their websites to – well, just work.
The flip side of this is that the better informed a client is, the better decisions she or he can make – so, part of my modus operandi is to educate clients during the natural process of developing and managing a website.
So, now and again I’ll come across a phrase that does require some explanation. High on the list of such phrases is semantic mark-up or semantic page structure.
Of course, most people know what semantics are: the study of meaning in words. But what does this mean in terms of website development, and why is it important?
Well, underneath every website page is HTML. It’s not really ‘code’ but a mark-up language which describes what each piece of content is. For example, if some text is a paragraph, it’s wrapped in a P tag. P for paragraph, get it?
The code itself – and the specific tags used – aren’t necessarily apparent on the page itself, since every tag can be styled (made to look like) pretty much anything. As an example, one can make a paragraph 36-point black text, and make a heading 11-point black text, so that the paragraph looks like a heading and the heading looks like a paragraph.
So what’s the point of that? Well, text within a website has meaning. But that meaning doesn’t have to be reflected in an obvious way. On a typical website, a news story page may have a heading (H1, or heading level one), the date of the news story might be a heading (H2, or heading level two) and the synopsis of the news story might be a heading also (H3, or heading level three). These can then be styled to look however we desire. But – to non-humans (specifically search engines) the tags are describing the semantics of the page. The heading levels tell Google how to index the page, what’s of relative importance on the page and so on.
This is a very simple example, but it’s easy to grasp how important this is. Each of those three headings could be tagged as paragraphs and then styled as three different sizes of text; they would look exactly the same. But this would tell Google nothing. Tagging them semantically tells Google everything.
Amazingly, lots of website designers don’t bother to do this, or do it wrong.
A classic example of bad coding from a semantic perspective is the use of tables. Tables can be styled so that the table cells are themselves invisible and then the table can be used as a page layout device – to place text in rows and columns, for example. The problem with this is that it isn’t semantically sound unless the data in the table is tabular in nature (like a price list). Using tables to place things in specific positions on a page may be fine visually, but semantically it may separate information (into different cells) that actually should be together.
Doing this makes the page less understandable from Google’s perspective. It also requires far more HTML to display/render the design – often up to three times as much, which affects page load times.
Within HTML, up to version 4, there are some semantic issues which stem from the fact that website pages have to do far more than was originally intended. So, there’s no tag for menus, or for image captions – just as two examples. Good developers get around this by choosing the closest equivalent. In the case of a menu, it’s normally a bulleted list of links (which, if you think about it, is what a menu is). Using stylesheets, the bullets can be removed, the text styled into buttons and the links put in a horizontal row – giving both the required visual effect and the required semantic structure.
(In the next version of HTML, HTML 5, these kinds of elements do finally have tags, but that’s largely ‘jam tomorrow’.)
There are several benefits of working in this way. First, it usually leads to logical, sensible and trim HTML that’s easier to maintain. Next, it typically delivers significantly better search engine results – a good example is how this approach contributed to a website that got three times as much traffic from Google after this was implemented. But actually, another way to look at it is ‘why would you not do this?’ – it’s no more work than doing things in a non-semantic way, after all.
As I said earlier, many website developers have a poor understanding of semantic mark-up, but in our view this isn’t optional. It’s a part of working to best practice – and it’s one area where website owners really do benefit from a little inside knowledge.
When I’m talking to clients, I do try to avoid speaking in the jargon of my industry. It’s not helpful and can leave clients feeling frustrated or even patronised.
Let’s face it, clients don’t want to have to understand all the detail of how a website works any more than most drivers want to become experts on engine monitoring systems just so they can drive a car. Clients want their websites to – well, just work.
The flip side of this is that the better informed a client is, the better decisions she or he can make – so, part of my modus operandi is to educate clients during the natural process of developing and managing a website.
So, now and again I’ll come across a phrase that does require some explanation. High on the list of such phrases is semantic mark-up or semantic page structure.
Of course, most people know what semantics are: the study of meaning in words. But what does this mean in terms of website development, and why is it important?
Well, underneath every website page is HTML. It’s not really ‘code’ but a mark-up language which describes what each piece of content is. For example, if some text is a paragraph, it’s wrapped in a P tag. P for paragraph, get it?
The code itself – and the specific tags used – aren’t necessarily apparent on the page itself, since every tag can be styled (made to look like) pretty much anything. As an example, one can make a paragraph 36-point black text, and make a heading 11-point black text, so that the paragraph looks like a heading and the heading looks like a paragraph.
So what’s the point of that? Well, text within a website has meaning. But that meaning doesn’t have to be reflected in an obvious way. On a typical website, a news story page may have a heading (H1, or heading level one), the date of the news story might be a heading (H2, or heading level two) and the synopsis of the news story might be a heading also (H3, or heading level three). These can then be styled to look however we desire. But – to non-humans (specifically search engines) the tags are describing the semantics of the page. The heading levels tell Google how to index the page, what’s of relative importance on the page and so on.
This is a very simple example, but it’s easy to grasp how important this is. Each of those three headings could be tagged as paragraphs and then styled as three different sizes of text; they would look exactly the same. But this would tell Google nothing. Tagging them semantically tells Google everything.
Amazingly, lots of website designers don’t bother to do this, or do it wrong.
A classic example of bad coding from a semantic perspective is the use of tables. Tables can be styled so that the table cells are themselves invisible and then the table can be used as a page layout device – to place text in rows and columns, for example. The problem with this is that it isn’t semantically sound unless the data in the table is tabular in nature (like a price list). Using tables to place things in specific positions on a page may be fine visually, but semantically it may separate information (into different cells) that actually should be together.
Doing this makes the page less understandable from Google’s perspective. It also requires far more HTML to display/render the design – often up to three times as much, which affects page load times.
Within HTML, up to version 4, there are some semantic issues which stem from the fact that website pages have to do far more than was originally intended. So, there’s no tag for menus, or for image captions – just as two examples. Good developers get around this by choosing the closest equivalent. In the case of a menu, it’s normally a bulleted list of links (which, if you think about it, is what a menu is). Using stylesheets, the bullets can be removed, the text styled into buttons and the links put in a horizontal row – giving both the required visual effect and the required semantic structure.
(In the next version of HTML, HTML 5, these kinds of elements do finally have tags, but that’s largely ‘jam tomorrow’.)
There are several benefits of working in this way. First, it usually leads to logical, sensible and trim HTML that’s easier to maintain. Next, it typically delivers significantly better search engine results – a good example is how this approach contributed to a website that got three times as much traffic from Google after this was implemented. But actually, another way to look at it is ‘why would you not do this?’ – it’s no more work than doing things in a non-semantic way, after all.
As I said earlier, many website developers have a poor understanding of semantic mark-up, but in our view this isn’t optional. It’s a part of working to best practice – and it’s one area where website owners really do benefit from a little inside knowledge.