views:

72

answers:

3

How Semantic X/HTML mark-up can save time -

  1. when we will write CSS for website
  2. and if any design changes comes from client in future.
  3. And why Table based layouts will take more time always in both condition

Today I've to Explain these thing to students.

I've some example but I want some more good example and ideas to explain nicely.

I want to explain what are benefits Semantic X/HTML mark-up from developers point of view.

Thanks in advance

Update:

The benefits of using semantics mark-up:

  1. It will be readable in good manner to people seeing the document in an environment where CSS cannot be applied.
  2. It will be a lot easier for web developers to maintain the code, and to separate content (HTML) from presentation (CSS).
  3. Semantic markup can reduce the needs of css group selectors in some cases.
+1  A: 
  1. we will write CSS first time for website

Every website has different look/layout, you have to write css for it for the first time unless their is some similarity between your layouts.

  1. and if any design changes comes from client in future.

You can make your websites using MVC design pattern, this will elevate a lot of changes to the design of your site.

  1. And why Table based layouts will take more time always in both condition

Because their markup is designed in way that you have to write more whereas in div based layouts we use clear and float mainly which do great job of quickly creating the layouts.

Sarfraz
my question is why "Semantic X/HTML mark-up" has advantage
metal-gear-solid
+1 but thanks for ur answer
metal-gear-solid
@Jitendra: Semantic markup has nothing to do with speed and you have to write it no matter what. Thanks
Sarfraz
@Sarfraz Ahmed -Semantic markup matter for CSS. Semantic markup can reduce the needs of css group selectors in some cases. the more html we will use, in css we can use HTML selectors. otherwise need to use classes. in nutshell if HTML is written semantically correct then CSS will have less classes. sites with classities and divitis and tables always takes more time to write css
metal-gear-solid
+3  A: 

The main advantage, besides more reliable and controllable code, for developers is clear code. With writing semantic XHTML you can avoid writing vague code which will be hard to decipher by other developers or yourself in the future.

IE. <address> is better for listing an address than using a <div> (which happens a lot...), while having the same flexibility, styling and improving readability.

MysticEarth
Agreed, but address is a bad example: it is not supposed to be used for any address, just for contact details of that particular page's author.
avdgaag
+1  A: 

From my work experience: I had for several times now to look at legacy markup from my predecessor or from completely other people (and actually one or two times from myself as well). Sometimes I had only what came from viewing the source in a browser. My findings so far were:

  • If the author used semantic markup as far as possible, together with clear and logic class names, it was really easy and fun to find out the structure of the page and, e.g., code a new widget or restructure the column layout or stuff

  • If the author used table based layout, and I also had stuff from the end of the 90s to look at, it is a complete mess. You have to figure out, which table row does what, which table cell belongs where and if you start to think you'd get a grip, you have overlooked an rowspan="3" 300lines of markup earlier. Even in Firebug you can become mad with such a tag soup.

    Adding new stuff here can become quite adventurous. If you add content to a table cell, and don't completely fix the width and height of the new stuff, you might find yourself with unpleasing gaps all over the page, and forgetting to open or close <td>s somewhere (with 200 validation errors on the original page you are likely to miss something somewhere) may lead to a completely screwed view.

  • If the author used divs and spans all over the place, but didn't do semantic markup (that is, writing <div class="header1"/> instead of <h1/>), it is still ways better than table layout (at most because of the mentioned rowspan and colspan and because you hav a chance that the page might not fully blow up, if there is a </div> missing somewhere), but you still can go mad on markup like

    </div></div>
    </div>
       </div>
      </div>
    </div></div>
      </div>
    

    Additionally, if I had an accompanying stylesheet, it was mostly a complete mess, too. Differentiating between .header, .header1, div.header_level1 and #middle .h1 forces you to jump back and forth between stylesheet and markup.

Boldewyn