6 ms·

Great, now we just have to wait until every IE6 and IE7 user has upgraded to IE8. By then, we'll be on to new browser technologies completely.

by thedob 18y ago

josefresco 18y ago
Browser standards, like traditional industry (cars for example) move pretty slowly. To say that somehow we're going to suddenly leapfrog this tech after years of slow progress would be unlikely.
jamesjyu 18y ago
Yeah, maybe my kids will have the luxury of coding with CSS tables. Think of the kids!
pg 18y ago
Or you could just use html tables.
- staunch 18y ago
  You could but that would clearly be a very big mistake! Sure it will work perfectly in every browser and it's really simple and easy to work with. But it's a big mistake! You'll have to deal with the fact that it's not trendy and cool. You will be looked down upon by those who are flogging themselves at the altar of cargo cult methodology. Come to think of it, quite similar to the situation those of us who still think Perl is awesome face. Try using Perl and HTML tables in 2008! You won't get invited to any of the cool parties...
  - benbeltran 18y ago
    no, it's a mistake because it's semantically incorrect.
    - pg 18y ago
      It's no more meaningful to talk about the semantics of html generated by programs than it is to talk about the semantics of machine code output by a compiler. Complaining about using tables for layout on semantic grounds is like complaining about using shift instructions for multiplication. Semantics applies at the level of abstraction where humans look at something. That's the fundamental mistake of CSS zealots. Without consciously realizing it, they have a model of the world in which one is editing web pages by hand, or at least editing templates that are only a thin layer of abstraction above web pages. Which is actually quite backward.
      - tdavis 18y ago
        I disagree, more or less completely. The semantics of HTML matter to the following: 1. Browsers which render the HTML 2. Machines, such as search engines, which "look" at it 3. People who edit the HTML (in the case that it is a template) Whether your HTML is semantically correct, or even stylistically valid, doesn't much matter to modern browsers because they've been designed under the assumption that most people will be too lazy or inept or uncaring to generate "proper" HTML. Obviously, this issue doesn't exist for compilers, where in the case that a compiler doesn't output proper machine code the program simply doesn't work. When this starts to matter, however, is when someone leaves the comfort of their Firefox 3 on a huge screen and goes to Safari on a iPhone, for instance. Hacker News, for example, does not scale properly on the iPhone which leads to unnecessary and annoying horizontal scrolling past a certain nesting level, among other issues. This is tied to semantics, though whether or not a font element is used doesn't matter -- what does cause this, however, is the ridiculous reliance on tables, which obviously aren't semantically proper since you're not displaying strictly tabular data. What about these limited browsers, and "machines" like Google? If you want a sidebar on the left side of your page, with tables that has to come before the main content. Using proper CSS techniques (semantics of HTML withstanding), you can place this after the actual content. People with smaller browsers could view your main content before your navigation with minimal changes and crawlers such as Google will index your content more accurately because of the placement of content in the source document. Semantics come into the picture when elements are misused or not used, such as header elements. These elements do have meaning to search engines. How about screen readers and other assistive devices? Many of these take context clues from the HTML, such as the type of element used to wrap content and its attributes, as a way to present pages more accurately to the user. Semantics matter a lot when it comes to accessibility. What about page size? The more tables you have on a page, the larger that page becomes to download. Perhaps Broadband is becoming ubiquitous in many places (as far as America goes, at least in somewhat urban areas), but that doesn't mean that it makes sense to waste time transferring bytes. There are a slew of other applications where HTML semantics bleed out into the real world, such as Microformats and the like, but many of these applications haven't gained wide-spread traction so probably aren't worth adding to my argument. The point being here is, semantics matter when whatever is "looking" at something cares about the semantics of it. Machine code is very simple: A machine looks at it and executes it based on strict rules. If a shift instruction is used, it's because that instruction will (assumedly) give some kind of performance benefit, not because the machine views it as having a different "meaning" from any other multiplication method. The fact that you can achieve the same thing with a table as you can with a div or paragraph tag doesn't mean it's correct to do so. If everything was meant to work properly and to its full potential as a table-based element, why have all these other silly layout elements? So, at the end of the day, what do we "CSS Zealots" and semantic HTML proponents get ourselves? Well, we get more maintainable, easier to read, accessible, flexible, more accurately indexed web pages. And in my world (the world of skilled web developers) we all still edit our web pages by hand -- using templates that are just a thin layer of abstraction above web pages. The day you see a META tag that says "Generated by Dreamweaver" on TicketStumbler is the day Dreamweaver has managed to produce equally good or better HTML than I can by hand -- HTML which affords all the advantages and luxuries that the stuff I write does. Edit: As a final note, I'd like to point out that there is a middle ground here. You can create generally "good" HTML without spending a day deciding what a class should be named. TS supports Microformats for events, but running it through an HTML validator would likely produce some menial errors. I'm not suggesting everyone put 10x the time into writing proper HTML and CSS to present it, I'm just suggesting that they put a little time into it -- for the sake of their site, their visitors, the search engines, and the sanity of web developers like me everywhere... if I have to write another XPath string that looks like /table/tr/td/table/tr/td/table/tbody/td[...] I am going to spit on somebody.

Great, now we just have to wait until every IE6 and IE7 user has upgraded to IE8. By then, we'll be on to new browser technologies completely.

by thedob 18y ago

Great, now we just have to wait until every IE6 and IE7 user has upgraded to IE8. By then, we'll be on to new browser technologies completely.

josefresco 18y ago

Browser standards, like traditional industry (cars for example) move pretty slowly. To say that somehow we're going to suddenly leapfrog this tech after years of slow progress would be unlikely.

jamesjyu 18y ago

Yeah, maybe my kids will have the luxury of coding with CSS tables. Think of the kids!

pg 18y ago

Or you could just use html tables.

staunch 18y ago
You could but that would clearly be a very big mistake! Sure it will work perfectly in every browser and it's really simple and easy to work with. But it's a big mistake! You'll have to deal with the fact that it's not trendy and cool. You will be looked down upon by those who are flogging themselves at the altar of cargo cult methodology. Come to think of it, quite similar to the situation those of us who still think Perl is awesome face. Try using Perl and HTML tables in 2008! You won't get invited to any of the cool parties...
- benbeltran 18y ago
  no, it's a mistake because it's semantically incorrect.
  - pg 18y ago
    It's no more meaningful to talk about the semantics of html generated by programs than it is to talk about the semantics of machine code output by a compiler. Complaining about using tables for layout on semantic grounds is like complaining about using shift instructions for multiplication. Semantics applies at the level of abstraction where humans look at something. That's the fundamental mistake of CSS zealots. Without consciously realizing it, they have a model of the world in which one is editing web pages by hand, or at least editing templates that are only a thin layer of abstraction above web pages. Which is actually quite backward.
    - tdavis 18y ago
      I disagree, more or less completely. The semantics of HTML matter to the following: 1. Browsers which render the HTML 2. Machines, such as search engines, which "look" at it 3. People who edit the HTML (in the case that it is a template) Whether your HTML is semantically correct, or even stylistically valid, doesn't much matter to modern browsers because they've been designed under the assumption that most people will be too lazy or inept or uncaring to generate "proper" HTML. Obviously, this issue doesn't exist for compilers, where in the case that a compiler doesn't output proper machine code the program simply doesn't work. When this starts to matter, however, is when someone leaves the comfort of their Firefox 3 on a huge screen and goes to Safari on a iPhone, for instance. Hacker News, for example, does not scale properly on the iPhone which leads to unnecessary and annoying horizontal scrolling past a certain nesting level, among other issues. This is tied to semantics, though whether or not a font element is used doesn't matter -- what does cause this, however, is the ridiculous reliance on tables, which obviously aren't semantically proper since you're not displaying strictly tabular data. What about these limited browsers, and "machines" like Google? If you want a sidebar on the left side of your page, with tables that has to come before the main content. Using proper CSS techniques (semantics of HTML withstanding), you can place this after the actual content. People with smaller browsers could view your main content before your navigation with minimal changes and crawlers such as Google will index your content more accurately because of the placement of content in the source document. Semantics come into the picture when elements are misused or not used, such as header elements. These elements do have meaning to search engines. How about screen readers and other assistive devices? Many of these take context clues from the HTML, such as the type of element used to wrap content and its attributes, as a way to present pages more accurately to the user. Semantics matter a lot when it comes to accessibility. What about page size? The more tables you have on a page, the larger that page becomes to download. Perhaps Broadband is becoming ubiquitous in many places (as far as America goes, at least in somewhat urban areas), but that doesn't mean that it makes sense to waste time transferring bytes. There are a slew of other applications where HTML semantics bleed out into the real world, such as Microformats and the like, but many of these applications haven't gained wide-spread traction so probably aren't worth adding to my argument. The point being here is, semantics matter when whatever is "looking" at something cares about the semantics of it. Machine code is very simple: A machine looks at it and executes it based on strict rules. If a shift instruction is used, it's because that instruction will (assumedly) give some kind of performance benefit, not because the machine views it as having a different "meaning" from any other multiplication method. The fact that you can achieve the same thing with a table as you can with a div or paragraph tag doesn't mean it's correct to do so. If everything was meant to work properly and to its full potential as a table-based element, why have all these other silly layout elements? So, at the end of the day, what do we "CSS Zealots" and semantic HTML proponents get ourselves? Well, we get more maintainable, easier to read, accessible, flexible, more accurately indexed web pages. And in my world (the world of skilled web developers) we all still edit our web pages by hand -- using templates that are just a thin layer of abstraction above web pages. The day you see a META tag that says "Generated by Dreamweaver" on TicketStumbler is the day Dreamweaver has managed to produce equally good or better HTML than I can by hand -- HTML which affords all the advantages and luxuries that the stuff I write does. Edit: As a final note, I'd like to point out that there is a middle ground here. You can create generally "good" HTML without spending a day deciding what a class should be named. TS supports Microformats for events, but running it through an HTML validator would likely produce some menial errors. I'm not suggesting everyone put 10x the time into writing proper HTML and CSS to present it, I'm just suggesting that they put a little time into it -- for the sake of their site, their visitors, the search engines, and the sanity of web developers like me everywhere... if I have to write another XPath string that looks like /table/tr/td/table/tr/td/table/tbody/td[...] I am going to spit on somebody.