Good question David. You could have dismissed my comments as puerile nit-picking but you had enough respect to ask a good question. What do I mean by semantics? Not what you thought it meant? Youíre probably referring to the Webster's definition, I quote, "se-man-tic, a. [Gr. semantikos, significant meaning.] 1. of meaning, especially meaning in language: as, syllable stress is a semantic factor." The previous statement translated from Webster's Unabridged Dictionary into geek, se-man-tic, a. [Gr. semantikos, significant meaning.] 1. of meaning, especially meaning in Web pages: as, make sure your tags have meaning. I like Steven and I appreciate his efforts to improve the club's Web site but I actually liked Hal's informal design better. It was quaint, friendly and aesthetically pleasing. I'm rather serious here, Steven's proposed site is unsemantic because it's laid out with nested tables instead of meaningful tags. A tag, like, <dive id="sidebar"> has meaning and appropriate styles, for example, #sidebar {float: right;} can be applyed to it. Tables are great when they're used to display tabular data. Then their tags really mean something. In a table of baseball statistics for instance, the caption and heading tags are meaningful and can have styles applied to them in appropriate fashion. Tables used for layout are "old school," remnants of the browser wars of the last millennium. You can catch divitis and/or classitis by including a tag like, <div class="thisorthat"> inside a table used for layout in order to imbue it's data with meaning. XML tags are semantic. For instance, in, " <lineitem><name></name><description ></description><price></price></lineitem>," the tags inside the root element have meaning, and styles can be applied to them in a meaningful ways with xslt. If we continue this discussion very long we'll redesign klug.org right here on the list. After all, Hal has kept the site simple (keep Internet site simple [kIss]). I thank cymor for introducing me to, Designing with Web Standards by Jeffery Zeldman and Web Standard Solutions the Markup and Style Handbook by Dan Cederholm. Both of these books emphasize the significance of tags. We need these books in the clubís library.
Handuma
P.S. Yes, Brian, I'd like some new features too. Emm, maybe streaming media, and a database for the clubs library.
mike@handuma.com wrote:
to them in appropriate fashion. Tables used for layout are "old school," remnants of the browser wars of the last millennium. You can catch divitis and/or classitis by including a tag like, <div class="thisorthat"> inside a table used for layout in order to imbue it's data with meaning. XML tags are semantic. For instance,
Well color me a philistine, then. If CSS layout is so great, why is it mind-numbingly difficult to do something as simple as a multi-column display? Before you respond and say "it IS simple, you just do <x />!" note that a quick Google search for "three-column CSS" yields hundreds (perhaps thousands) of how-to pages that show various approaches that are either a) complex or b) don't work well.
When laying out the latest incarnation of the Ethereal web site, I wanted to display three columns of information. I tried various CSS layouts. None of them worked well for me. The problem turned out to be the way I size my browser window. I prefer to have the approximate aspect ratio of a sheet of paper oriented portrait-wise. This is what Mosaic used in 1993. It's what God and Dwight Eisenhower intended, and it's what I use today.
When thrown up against a browser window that is (gasp!) narrow, most three-column CSS layouts fail in some catastrophic way, either by overlapping content or shifting blocks above or below each other. After wasting way too much time trying to get various CSS schemes to work, I went back to tables. I'm much happier, and apparently the layout works. I've received many compliments on the site and have even had requests from people to copy the layout for their site.
In short, I think modern web designers have an irrational phobia of tables.
Gerald Combs wrote:
In short, I think modern web designers have an irrational phobia of tables.
Irrational, perhaps. But well motivated. I realize that the larger question that you, as the page author, are concerned with is 'who will be using my site?' For the most part, that undoubtably is going to be people browsing visually with a full screen computer. Arguably, since Ethereal doesn't run on PDA's or cell phones; it will be the only audience that matters. And that's fine.
Some pages (like the LUG's), however, have a general information conveyance purpose -- again, for the most part, the primary audience will be the above mentioned PC browsers. However, if a little extra effort could be thrown in to allow the page to /gracefully/ degrade to render with sematic meaning on a PDA, cell phone, braile reading, screen reader, and spiders then there's a possibility that the time investment is worth it; personally, I have become so familiar with CSS that I just always do it -- I try to make no assumptions about the viewing audience.
With regard to your troubles with CSS, perhaps I could offer some assistance. You are right in your assessment of the myriad of CSS 'solutions' that exist. Though, it's not a fundamental design flaw in semantic design -- those myriad of options have been motivated by a fundamental design flaw in IE's box model and IE's 'interpretation' of the standard.
For the most part, to accomplish the three collumn layout you described with a definitive aspect ratio, you merely use absolute positioning with doubly nested <div>'s to work around IE's problems. To accomplish a version that adjusts to the browser width is definetly more complicated but not unattainable. Again, the cost-benefit ratio has to be considered.
Check out the source of http://www.mozilla.org/ for a moderate complexity example of CSS design with an absolute width.
Jason Clinton wrote:
Irrational, perhaps. But well motivated. I realize that the larger question that you, as the page author, are concerned with is 'who will be using my site?' For the most part, that undoubtably is going to be people browsing visually with a full screen computer. Arguably, since Ethereal doesn't run on PDA's or cell phones; it will be the only audience that matters. And that's fine.
What is it about tables that causes browsing in PDAs and cell phones to fail? Why would this cause more trouble for blind users?
For the most part, to accomplish the three collumn layout you described with a definitive aspect ratio, you merely use absolute positioning with doubly nested <div>'s to work around IE's problems. To accomplish a version that adjusts to the browser width is definetly more complicated but not unattainable. Again, the cost-benefit ratio has to be considered.
...but I don't want absolute positioning. Here's my abbreviated RFC:
1. The page MUST contain a header across the top. The header MUST fill the width of the page.
2. The page body MUST have three columns below the header.
3. When viewed in a typical browser window, the columns MUST expand to fill the width if the window accordingly.
4. When viewed in my unnaturally narrow window, the page MUST degrade gracefully. The content blocks MUST NOT overlap. They MUST retain their right-to-left layout.
To meet these requirements using CSS, I can spend an inordinate amount of time tweaking the layout, only to find that some combination of {Mozilla|Firefox|IE|Konqueror|Safari|Opera} doesn't work. Once I get it to work, I can watch it break when a new version of <browser /> comes out.
With tables, I get to lay out the page in 10 minutes and move on to something important.
Check out the source of http://www.mozilla.org/ for a moderate complexity example of CSS design with an absolute width.
Check out http://www.plone.org/. First, read the content. You'll find that they're all about the semantic web, standards compliance, and accessibility. Now, look at the source. They're using tables.
Gerald Combs wrote:
What is it about tables that causes browsing in PDAs and cell phones to fail? Why would this cause more trouble for blind users?
Not fail. Presented as a useless stream of text and fields with no context or headings giving meaning or structure to the document.
...but I don't want absolute positioning. Here's my abbreviated RFC:
I'll do a Mozilla compatible mock-up this weekend. It should only take me about an hour or two to have the box model you want completed. The trick is to use 'min-width: ' on your page body. Again, IE not-with-standing.
Check out http://www.plone.org/. First, read the content. You'll find that they're all about the semantic web, standards compliance, and accessibility. Now, look at the source. They're using tables.
Yes, this supports your argument. However, their pages do not pass Bobby and while they might have been able to hide the semantic meaning with 'display: hidden;' from visual browsers, I think that this is asking for trouble. The other benefit to CSS is that it acts as a template seperating style from content -- they've lost that benefit by resorting to tables. CSS -- once it's been designed -- can really save you time on your maintenance.
On Fri, 2004-11-12 at 12:12, Jason Clinton wrote:
Gerald Combs wrote:
What is it about tables that causes browsing in PDAs and cell phones to fail? Why would this cause more trouble for blind users?
Not fail. Presented as a useless stream of text and fields with no context or headings giving meaning or structure to the document.
And thats different from css how? If the client can't render it can't render.
...but I don't want absolute positioning. Here's my abbreviated RFC:
I'll do a Mozilla compatible mock-up this weekend. It should only take me about an hour or two to have the box model you want completed. The trick is to use 'min-width: ' on your page body. Again, IE not-with-standing.
Thats an hour or 2 too long. Quick table and your done.
Check out http://www.plone.org/. First, read the content. You'll find that they're all about the semantic web, standards compliance, and accessibility. Now, look at the source. They're using tables.
Yes, this supports your argument. However, their pages do not pass Bobby and while they might have been able to hide the semantic meaning with 'display: hidden;' from visual browsers, I think that this is asking for trouble. The other benefit to CSS is that it acts as a template seperating style from content -- they've lost that benefit by resorting to tables. CSS -- once it's been designed -- can really save you time on your maintenance.
You can make pages Bobby compliant with tables, as tables and Bobby were around before css layout was even capable widespread. Just like how you can make css not Bobby compliant.
Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
Bill Cavalieri wrote:
Not fail. Presented as a useless stream of text and fields with no context or headings giving meaning or structure to the document.
And thats different from css how? If the client can't render it can't render.
When using CSS, you (are supposed to) make your content in outline form (the semantic part we've been talking about) and then arrange the outline using boxes. That cannot be done (easily) when your content spans table cells.
Thats an hour or 2 too long. Quick table and your done.
... unless you want graceful degredation and then you should have spent the hour or two.
You can make pages Bobby compliant with tables, as tables and Bobby were around before css layout was even capable widespread. Just like how you can make css not Bobby compliant.
You can't get a AAA rating. Besides, that has nothing to do with my argument here. We're talking about Plone, specifically, not CSS in general.
Jason Clinton wrote:
I'll do a Mozilla compatible mock-up this weekend. It should only take me about an hour or two to have the box model you want completed. The trick is to use 'min-width: ' on your page body. Again, IE not-with-standing.
Okay. I have the semantic base-line up at http://jasonclinton.com/css_example/index.xhtml. As of this writting, it has only 1 style rule applied hiding the audible jump links (see source code). I'll be working on it the rest of the afternoon; you can follow my progress if you'd like.
Jason Clinton wrote:
Okay. I have the semantic base-line up at http://jasonclinton.com/css_example/index.xhtml. As of this writting, it has only 1 style rule applied hiding the audible jump links (see source code). I'll be working on it the rest of the afternoon; you can follow my progress if you'd like.
It's more or less done. The colors are butt-ugly to allow you to easily see where containing boxes occur. I have some stylistic things to play with to make it look a bit more like you would expect it to on a standards site (nav links don't have bullets, for instance.) The most important thing is that when you go to View > Page Style > No Style you get to see what it would look like on a cell phone. Shrink the window down to only 100px wide to get a better idea.
Jason Clinton wrote:
It's more or less done.
Thanks to Hal for pointing out that lynx and links don't like the application/xml MIME type. This URL should work for everyone:
http://jasonclinton.com/css_example/index.html
I've confirmed that it works in Firefox, Opera, Konqueror, Links2 and Lynx and my Samsung cell phone -- again IE not-with-standing. Some reported that some older versions of the above have a floating point calculation error that occasionally causes the collumn to jump. That could be worked-around, though, by allow for a 1% margin of error.
On Fri, 2004-11-12 at 11:13, Jason Clinton wrote:
Gerald Combs wrote:
In short, I think modern web designers have an irrational phobia of tables.
I agree with Gerald here 100%.
Irrational, perhaps. But well motivated. I realize that the larger question that you, as the page author, are concerned with is 'who will be using my site?' For the most part, that undoubtably is going to be people browsing visually with a full screen computer. Arguably, since Ethereal doesn't run on PDA's or cell phones; it will be the only audience that matters. And that's fine.
The browser on my pda renders tables just fine. When I had inet on my phone, it wouldn't render css any better than tables (which was not at all).
Some pages (like the LUG's), however, have a general information conveyance purpose -- again, for the most part, the primary audience will be the above mentioned PC browsers. However, if a little extra effort could be thrown in to allow the page to /gracefully/ degrade to render with sematic meaning on a PDA, cell phone, braile reading, screen reader, and spiders then there's a possibility that the time investment is worth it; personally, I have become so familiar with CSS that I just always do it -- I try to make no assumptions about the viewing audience.
Same problem from above, css only renders in small browswers that support it, just like tables. Having worked with people using screen readers in the past, images not being labeled, and colums without proper tags were the bane of their existence, not page layout or css.
For the most part, to accomplish the three collumn layout you described with a definitive aspect ratio, you merely use absolute positioning with doubly nested <div>'s to work around IE's problems. To accomplish a version that adjusts to the browser width is definetly more complicated but not unattainable. Again, the cost-benefit ratio has to be considered.
Or create a simple table. Why everything have to be so hard.
Check out the source of http://www.mozilla.org/ for a moderate complexity example of CSS design with an absolute width.
Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
-
Bill Cavalieri -
Gerald Combs -
Jason Clinton -
mike＠handuma.com