 |
 |
A CSS Question...
|
 |
|
 |
|
Clinically Insane
Join Date: Nov 1999
Status:
Offline
|
|
I'm trying to get a certain structure of my layout to work, and I'm having a lot of toruble doing it in CSS.
Basically, the idea is that there are two boxes, side by side. Their colors and background colors are different. There's a border drawn around them both, but not the boxes themselves. The kicker is: [i]the boxes must be the same height, no matter what they contain. To give an ASCII-fied example...
<BLOCKQUOTE><font size="1"face="Geneva, Verdana, Arial">code:</font><HR><pre><font size=1 face=courier>
=============================================
| This is the first box. | This is the |
| The line between the two | other box. |
| boxes should be invisible,| |
| but is put here to show | |
| the two-box thing. | |
=============================================
</font>[/code]
The background colors of both boxes should stretch to the border they share.
My HTML for this is fairly simple stuff, just one big DIV containing two smaller DIV's. The CSS, though, is tougher; I can get them to line up properly, but I can't force them both to the same height. Is there a way to do this that's not dependent on the text I put in them, or am I hosed?
One final note: I know you can do this with tables. It's quite easy, in fact; I've done it myself. But I'm not going to be using a table-based layout.
|
|
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
|
| |
|
|
|
 |
|
 |
|
Fresh-Faced Recruit
Join Date: Sep 2000
Location: niceFire
Status:
Offline
|
|
1) Why not use tables? Tables are designed specifically for this type of thing.
2) You may be able to do it in CSS by putting height: 100%; into the class definitions of each div, similar to this:
<BLOCKQUOTE><font size="1"face="Geneva, Verdana, Arial">code:</font><HR><pre><font size=1 face=courier><html>
<head>
<style>
<!--
div.container{
border-style: solid;
border-width: 1px;
border-color: navy;
width: <font color = blue>100</font>%;
}
div.left{
height: <font color = blue>100</font>%;
background-color: #EEEEEE;
<font color = green>float</font>: left;
margin: 0px;
}
div.right{
height: <font color = blue>100</font>%;
background-color: #EFEFFF;
margin: 0px;
}
-->
</style>
</head>
<body>
<div class=<font color = red>"container"</font>>
<div class=<font color = red>"left"</font>>
Left side text goes right about here.
</div>
<div class=<font color = red>"right"</font>>
Duh.
</div>
</div>
</body>
</html></font>[/code]
|
|
|
| |
|
|
|
 |
|
 |
|
Clinically Insane
Join Date: Nov 1999
Status:
Offline
|
|
1) Why not use tables? Tables are designed specifically for this type of thing.
No, tables are designed specifically for tabular data. This stuff doesn't fit in a table, so I won't use them for it in my final design. Currently I have a table version of this working, so I have an idea of how I want it to look. I'm not an anti-table zealot, mind you; I use them when they're appropriate. But in this case, they aren't.
2) You may be able to do it in CSS by putting height: 100%; into the class definitions of each div, similar to this:
Your code works in IE5/Windows, but that's due to a CSS bug. Mind you, the bug is, frankly, how CSS should work, but the W3C bade a braindead mistake in their specification of the float command (possibly their only such mistake, but it's a bad one). The problem is, floated objects are taken out of the normal flow, and thus aren't considered to be "inside" their containers. This not only throws the border off (because if the object is the largest or widest one in the container, the container's size will have to change to accommodate it), but also kills the height: 100% rule.
It's braindead, I know. the W3C shouldn't have designed it that way. But because of that, I need a different solution.
|
|
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
|
| |
|
|
|
 |
|
 |
|
Fresh-Faced Recruit
Join Date: Sep 2000
Location: niceFire
Status:
Offline
|
|
How fixed are the sizes? I think you're stuck with using positioning of some sort and fixed sizes. Then again, that's a good way to make netscape unhappy.
I still say go for tables.
|
|
|
| |
|
|
|
 |
|
 |
|
Grizzled Veteran
Join Date: Sep 2000
Location: Springfield, MA
Status:
Offline
|
|
I don't quite follow your philosophy on tables millennium. Tables are used all the time for formating. They are great for that kind of thing, and are widly supported (does lynx even show stuff that's in CSS, I have no idea).
Go ahead and use them for your none tabular data, it won't make you a bad person (at least not in my eyes).
|
|
We hope your rules and wisdom choke you / Now we are one in everlasting peace
-- Radiohead, Exit Music (for a film)
|
| |
|
|
|
 |
|
 |
|
Dedicated MacNNer
Join Date: Sep 1999
Location: Grand Forks, ND, USA
Status:
Offline
|
|
Originally posted by Mactoid:
<STRONG>Go ahead and use them for your none tabular data, it won't make you a bad person (at least not in my eyes).</STRONG>
Nope—it's not valid markup under anything beyond HTML 4.01 strict. Valid markup good, non-valid markup bad.
Anyway, to answer the original question, no I don't think it can be done. I was (am) stuck in the same boat as you are. The only halfway workable solution is to do it with DHTML (ornery) or misuse CSS a bit:
<BLOCKQUOTE><font size="1"face="Geneva, Verdana, Arial">code:</font><HR><pre><font size=1 face=courier>
body {color: #F00}
div.leftColumn {width: 400px; color: #FFF; border-right: 100px solid #<font color = blue>000</font>; z-index: <font color = blue>-1</font>}
div.rightColumn {width: 100px; color: #<font color = blue>000</font>; z-index: <font color = blue>1</font>}</font>[/code]
If you make two divs (<div class=leftColumn"> and <div class=rightColumn"> ) you should have two columns of equal height where the visual height of the right column is dependent on the height of the left column. Basically you're putting a border on the right side of the left column that is as wide as and the same color as your right column.
[ 06-16-2001: Message edited by: Herr Newton ]
|
|
|
| |
|
|
|
 |
|
 |
|
Clinically Insane
Join Date: Nov 1999
Status:
Offline
|
|
I don't quite follow your philosophy on tables millennium. Tables are used all the time for formating.
That doesn't make it right. When you do that, you're embedding presentation into a document that should only be describing the document's structure, and that's not what the Web is supposed to be all about. The Web isn't like paper; people use a huge array of devices to get and read (or otherwise use) data. None of these are going to be able to deal with documents in the same way, and in many cases this isn't even appropriate. Classic example: aural browsers which speak text rather than displaying it. This is often used as an example of catering to blind users, but that's rather cliched by now (though it's true), so I'll use another possibility: in-car Web browsers. These obviously couldn't display the data visually; it wouldn't be safe to do so. But with Web "designers" still stuck in this idea that the Web is only a visual medium to be viewed on computers with high-resolution monitors, and then assuming this to be the case, such browsers wouldn't be anywhere approaching usable today. It's only when we separate sturcture from presentation, thus allowing us to present the same document in many different ways, that this becomes a possibility. And it can be done, without stifling any creative possibility at all.
They are great for that kind of thing, and are widly supported (does lynx even show stuff that's in CSS, I have no idea).
Actually, you've got it backwards. Lynx can't support tables at all, and this can really mess up sites which rely on them. Lynx doesn't yet support CSS either. But because the document is structurally-defined, the page will still be completely usable. It may not look as 1337, but the information will get across.
By the way, I eventually found what I was looking for. It looks like what I want to do actually can be done only in tables. However, it's actually possible to define a table in CSS! What you have to do us use CSS2's display property. In addition to the block, inline, hidden, and none values we saw in CSS1, CSS2 adds many others, including: - table : makes matching tags act like the TABLE tag.
- table-row : makes matching tags act like the TR tag.
- table-cell : makes matching tags act like the TD tag.
These are actually just three of the many possibilities. It's possible to completely recreate the full capability of HTML's tables using only CSS.
This feature of CSS was actually meant to be used in XML documents. However, it's easy to use it for HTML too, though you'd need to use class selectors instead of tag selectors. But in any case, it lets you excise inappropriate tables from your HTML, without sacrificing the capabilities of the table construct. Very cool stuff, and if done properly it still degrades gracefully.
|
|
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
|
| |
|
|
|
 |
|
 |
|
Occasionally Quoted
Join Date: Apr 2001
Location: San Francisco
Status:
Offline
|
|
|
(Last edited by daimoni; Apr 21, 2004 at 12:02 PM.
)
|
|
.
|
| |
|
|
|
 |
|
 |
|
Clinically Insane
Join Date: Nov 1999
Status:
Offline
|
|
I'm still testing out the tag to see what works and what doesn't. I haven't done much testing yet, since I only discovered this trick yesterday. But I'm working on it.
Gecko-based browsers are known to work. IE5/Mac might work, but I don't know for certain just yet (I would say it probably does; I'll test it out soon). IE5/Windows is also uncertain, but it's at least a possibility (then again, it took them until Version 6 to even fully support CSS1). OmniWeb probably doesn't work yet, nor does iCab, because neither of them even have full CSS1 support, and these are CSS2 values.
In any case, since you use standard DIV and SPAN tags to do this trick, the layout should still degrade pretty gracefully. However, the tag set isn't too likely to work in the alternative browser community just yet. Hopefully we can make it popular enough that it becomes a priority.
|
|
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
|
| |
|
|
|
 |
|
 |
|
Clinically Insane
Join Date: Nov 1999
Status:
Offline
|
|
Well, I've been doing some testing. I'm going to try and refine the technique, but the news thus far is rather disheartening.
Mozilla: Works perfectly.
IE5/Carbon: Does not work; page is unusable (only the first div is drawn).
OmniWeb: Does not work; page is unusable (only the first div is drawn).
iCab/Carbon: Does not work, but degrades gracefully (the divs are drawn one above the next, and all are readable; they just aren't positioned right).
I'm going to test with more browsers, and I'm also going to work on refining this technique more. I think it could really be useful for designers that want to stop embedding tables in HTML for layout, but need some capability or other that only tables can currently provide (such as my need for two DIV's that are always the same height regardless of what they contain). I'll keep everyone posted with my findings. If I can get it working well on Mac browsers, I'll post some HTML/CSS source so that it can be tested on other stuff too.
|
|
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
|
| |
|
|
|
 |
|
 |
|
Forum Regular
Join Date: May 2000
Location: new york
Status:
Offline
|
|
Mozilla: Works perfectly.
IE5/Carbon: Does not work; page is unusable (only the first div is drawn).
OmniWeb: Does not work; page is unusable (only the first div is drawn).
iCab/Carbon: Does not work, but degrades gracefully (the divs are drawn one above the next, and all are readable; they just aren't positioned right)
I'm not sure what the objection to tables is... I've build some MASSIVE sites with tables... and unlike CSS you're guaranteed compatibility cross platform and browsers...all the way back to 3.0
|
|
|
| |
|
|
|
 |
|
 |
|
Clinically Insane
Join Date: Nov 1999
Status:
Offline
|
|
Simply put, because hacks like table-based layouts are breaking the Web.
To elaborate, it's "designers" like you who treat the Web as a piece of paper, when it's not. The Web is a way to deliver content across many different kinds of media, from an Apple Cinema Display to a Nokia cell phone to printed paper to spoken output, even to Braille terminals or things even more exotic than that. And it's not just about human-readability; computers can and do use the data found in the Web, when it's coded in a proper format so that they can find meaning in the text.
Content has to be presented differently for these different media; no one layout is appropriate for all of them. Because of this, the content of a site, as defined in HTML, must be defined in a purely structural manner; otherwise you've killed true interoperability. You think you've made some great achievement by making a site look identical in Netscape 3, 4, and 6, and IE 3, 4, 5, and 6. I say you have done nothing; in your misuse of the Web, you've narrowed the focus to a very limited set of browsers on only one medium.
In short, Netscape broke the Web when they introduced tables. Not so much because of the table tag itself, but because spoiled-brat kiddies calling themselves "designers" have abused it to no end, not understanding anything about what they're designing as long as it looks 31337. They've set the Web back by at least five years, in terms of the technological advancements that could have been made. And now, we're stuck trying to fix it all.
That is why I object to table-based layouts. They run contrary to the very essence, the entire point of the World Wide Web. It pisses me off to see "MacNN Mobile Edition"; there should be no need for it. If only they'd used a proper stylesheet layout, they could have served to both media from the same HTML in a completely user-transparent fashion. And even more media than that, actually; add a third stylesheet, again noting that the HTML doesn't ever have to be rewritten, and they could get a printer-friendly version of all their pages, even dynamically-generated ones, with zero extra work. Plug in a fourth, and the text could be read out to a user in a linear, sensible fashion, with different voices or voice positioning; heck, with a little work we could get this forum to read out all of the replies in different voices that sound like they're coming from different poin ts in the room; just like a real conversation. This is the power of stylesheets. And it's the kind of power that you're holding back, without even realizing you're doing it, by insisting on keeping with antiquated table-based layout methods. Satisfied?
|
|
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
|
| |
|
|
|
 |
|
 |
|
Forum Regular
Join Date: May 2000
Location: new york
Status:
Offline
|
|
server response time is killing me
[ 06-21-2001: Message edited by: pcp_ip ]
|
|
|
| |
|
|
|
 |
|
 |
|
Forum Regular
Join Date: May 2000
Location: new york
Status:
Offline
|
|
server response time is killing me
[ 06-21-2001: Message edited by: pcp_ip ]
|
|
|
| |
|
|
|
 |
|
 |
|
Forum Regular
Join Date: May 2000
Location: new york
Status:
Offline
|
|
server response time is killing me
[ 06-21-2001: Message edited by: pcp_ip ]
|
|
|
| |
|
|
|
 |
|
 |
|
Forum Regular
Join Date: May 2000
Location: new york
Status:
Offline
|
|
server response time is killing me
[ 06-21-2001: Message edited by: pcp_ip ]
|
|
|
| |
|
|
|
 |
|
 |
|
Forum Regular
Join Date: May 2000
Location: new york
Status:
Offline
|
|
I'm hardly a hack or paper designer.
Your argument about tables is just pure wrong. Until CSS is a uniform standard you need to build sites that can be viewed by EVERYONE. Until that's a reality I'm not willing to build a site that cuts X% of the viewers out.
Build your friggen site in XML and publish any way you like, poll the browser type and serve CSS, tables, WML cards, whatever.
At the moment- over HTTP- the best way to keep a layout together is tables. period. good luck getting your css to look the same- or at least good - on settop boxes and across multiple platforms and multiple browser flavors...
lets see some of your pure CSS site designs... I'm interested to see how "universal" they are. I hope you're not another WYSIWYG web designer building layer after layer of dreamweaver nonsense.
|
|
|
| |
|
|
|
 |
|
 |
|
Senior User
Join Date: Apr 1999
Location: Bow, NH USA
Status:
Offline
|
|
Man, a little anger there, is your name Davide by any chance?
Look, I can see where this going. I recieved an email this morning from an angry viewer because I use PNG images and GoLive javascript which is not supported on all browsers..
Well, so what? If we were designing sites in 2001 for 100% compatibility then we would all be using BBEdit 4 and gif images. Personally, it is how I learned to code in 1993, by hand, but GoLive and Dreamweaver offer way to much to blow them off because the standards of the browsers are so out of whack.
Nobody wanted IE to win the war against Netscape, but they did and Netscape just gave up. Netscape 6 sucks, Netscape 4.x has never worked right.
OmniWeb is fine for OS X but it admits it's standards aren't up to snuff, Opera has potential..but here's a fact for you:
As much as you hate it (and I join you) IE sets the standards and alwasy will, so live with it as I have. Microsoft built the best browser as much as we all hate to say it.
MacNETv2 is designed for IE but we'll do our best by July 1st to make it viewable by more browsers..but give up PNG images...never!
Why is anyone using Netscape anyway? Habit? It sucks...Now if Omniweb and make their browser as compliant as IE than OmniWeb will gain share because it renders text better than any browser, but then IE will adopt it and OmniWeb will lose...
|
http://www.macnet2.com
|
| |
|
|
|
 |
|
 |
|
Clinically Insane
Join Date: Nov 1999
Status:
Offline
|
|
Your argument about tables is just pure wrong. Until CSS is a uniform standard you need to build sites that can be viewed by EVERYONE. Until that's a reality I'm not willing to build a site that cuts X% of the viewers out.
And CSS is a uniform standard. Some browser makers don't seem to want to implement that standard; this is their problem. And frankly, it's the one thing I have against OmniWeb; even NS4's CSS support was better than OmniWeb's is now, and if you know NS4's CSS support then you know what an insult I just threw at their feet.
At the moment- over HTTP- the best way to keep a layout together is tables. period. good luck getting your css to look the same- or at least good - on settop boxes and across multiple platforms and multiple browser flavors...
Like I said, a spoiled hack. The Web is about content. As long as the content is provided in a format that's usable, how the site looks should be of little importance. What's important is that it works, not that it looks identical on everything you throw at it (which, by the way, is impossible, because of the many different media through which a Web page could be presented).
lets see some of your pure CSS site designs... I'm interested to see how "universal" they are. I hope you're not another WYSIWYG web designer building layer after layer of dreamweaver nonsense.
Um, no. I don't even use WYSIWYG editors at all; while I have nothing against those who do (as long as they tweak the code to make it standards-compliant afterwards), they're just not my style. And how universal are they? Well, I can get my sites usable from Netscape6/IE6 all the way back to Lynx, and everything in between. Sure, it doesn't have the 1337 d3$1gN 7r1c|<$ in all of those browsers, but who cares? The content gets across in a usable format, and that is what matters.
|
|
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
|
| |
|
|
|
 |
|
 |
|
Forum Regular
Join Date: May 2000
Location: new york
Status:
Offline
|
|
It's true the "promise" of the web is write-once-read-anywhere. It's unfortunate it's not that way at the moment. When you get out of school- and have paying clients one day- you'll realize you're going to have to build for the lowest common denominator.
What you're doing is the same thing the bank of montreal is doing... designing sites for specific browsers- and cutting a large part of their customers out. That's fine for your little personal "homepage", but when it comes to commercial deployment of massive sites, I’m afraid tables is the way to go, whether you’re an anti-tablite or not.
You'd never produce a TV commercial that can only be viewed on Sony TVs. Why would you create a high traffic website that can only be seen by IE5? Until DHTML/CSS standards become synced in the most popular browsers, the rest of us- that you call hacks- are thinking strategically for our clients. ROI does not come from building sites with the coolest new tag.
Back in the early days of tables I was building IBM sites that HAD to be viewed by WebExplorer for OS/2. It was the same battle. Like CSS, tables just couldn’t be used for layouts. Soon CSS will have the penetration and compatibility it needs to be a design tool... Then probably we’ll have a new tags to play with and people will be bitching “why use CSS when you can use the new .NET tags!"
Evolution.
As I. M. Pei put it- "don't design novelty for novelty’s sake."
[ 06-22-2001: Message edited by: pcp_ip ]
|
|
|
| |
|
|
|
 |
|
 |
|
Clinically Insane
Join Date: Nov 1999
Status:
Offline
|
|
It's true the "promise" of the web is write-once-read-anywhere. It's unfortunate it's not that way at the moment.
Yes. And people like you ae part of the problem, by not pushing evolution along.
When you get out of school- and have paying clients one day- you'll realize you're going to have to build for the lowest common denominator.
While it's true that no one ever got fired by underestimating the American public, that doesn't make it right. And you seem to think I'm cutting off a portion of my users; I'm not.
And don't assume I'm still in school and have no paying customers. Guess what: I do.
What you're doing is the same thing the bank of montreal is doing... designing sites for specific browsers- and cutting a large part of their customers out.
I am doing no such thing. My site can be viewed in every single browser I have ever thrown in it: Netscape back to 0.9, IE back to 1, Lynx, Links, Amaya, MacWeb, Arena, Konqueror... heck, even the Apple Help Viewer can use everything but forms.
How could I do this? Because I realized something: it's not important that a page looks exactly as I conceived it, as long as everything is accessible and usable. And I still test it in everything I can find, which is, in the end, much lower than the "common denominator" you pander to.
That's fine for your little personal "homepage", but when it comes to commercial deployment of massive sites, I’m afraid tables is the way to go, whether you’re an anti-tablite or not.
No it isn't. Making the site usable is the way to go, and if the layout isn't quite fitting my Sublime Artistic Vision in some browser or other, who cares as long as they can get to the content and use the forms (assuming their browser even supports forms; I do have to draw the line somewhere after all)?
You'd never produce a TV commercial that can only be viewed on Sony TVs.
Of course not; that would be absurd.
Why would you create a high traffic website that can only be seen by IE5?
That would be equally absurd. Which is why I don't do it. You're confusing me with the zealots over at the Web Standards Project, who insist that you force people to upgrade before entering. I don't do that. I do notify them that they should upgrade, of course, but I also point out that my site is still perfectly usable otherwise. Because it is.
Until DHTML/CSS standards become synced in the most popular browsers, the rest of us- that you call hacks- are thinking strategically for our clients. ROI does not come from building sites with the coolest new tag.
No, it comes from sites that are usable to the largest possible audience. Which table-based sites, by and large, are not.
Back in the early days of tables I was building IBM sites that HAD to be viewed by WebExplorer for OS/2. It was the same battle. Like CSS, tables just couldn’t be used for layouts.
There you go again, "don't take my precious layout away!" Utter bull. If you can't make a site look 31337 in a given browser with the standards, then don't even try; just ensure that the site still works. The Web is not a piece of paper; it will look different, depending on how it is being viewed. Accept this, or even embrace it.
Soon CSS will have the penetration and compatibility it needs to be a design tool...
It has it already.
Then probably we’ll have a new tags to play with and people will be bitching “why use CSS when you can use the new .NET tags!"
Actually, the next standard will probably be XSL; .NET won't be there for several years yet. But even so, CSS was made to be interoperable; it's a completely different beast from table-based layouts. This is the whole point of separating structure from presentation; the two can evolve separately, but always remain interoperable.
Pretty words. Now go practice what you preach.
|
|
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
|
| |
|
|
|
 |
|
 |
|
Forum Regular
Join Date: May 2000
Location: new york
Status:
Offline
|
|
No it isn't. Making the site usable is the way to go, and if the layout isn't quite fitting my Sublime Artistic Vision in some browser or other, who cares as long as they can get to the content and use the forms (assuming their browser even supports forms; I do have to draw the line somewhere after all)?
so your the guy that builds all those ugly sites?
beecher - you still have yet to produce links to sites you have designed, and you're clearly a student. Built your sites anyway you like.
[ 06-22-2001: Message edited by: pcp_ip ]
|
|
|
| |
|
|
|
 |
|
 |
|
Clinically Insane
Join Date: Nov 1999
Status:
Offline
|
|
so your the guy that builds all those ugly sites?
Not according to my clients and users.
beecher - you still have yet to produce links to sites you have designed, and you're clearly a student. Built your sites anyway you like.
I'm impressed; you looked up my e-mail address and did a directory lookup. You're so 31337.
Unfortunately, that's my old e-mail address. Thanks for bringing the fact that I'd forgotten to change it to my attention, though.
|
|
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
|
| |
|
|
|
 |
|
 |
|
Forum Regular
Join Date: May 2000
Location: new york
Status:
Offline
|
|
well you did graduate from high school in '97- so you haven't been in the industry that long.
|
|
|
| |
|
|
|
 |
|
 |
|
Clinically Insane
Join Date: Nov 1999
Status:
Offline
|
|
Who are you, anyway?
And for that matter, what makes you think I had no paying customers back then? I think you're forgetting a few things about the Web design industry as it currently stands.
And don't speak of evolution when you're helping to hold it back, by the way. It really hurts your credibility.
|
|
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
|
| |
|
|
|
 |
|
 |
|
Forum Regular
Join Date: May 2000
Location: new york
Status:
Offline
|
|
[white flag]
I have no reason to have a flame war with you. Keep advancing the web.
|
|
|
| |
|
|
|
 |
|
 |
|
Mac Elite
Join Date: Mar 2001
Status:
Offline
|
|
Geez. what a bunch of babies! Cmon' millenium - you want your site to be compatible with everything.
We use tables because browsers support them..
Since you get paid for it, i'm assuming you know a little about the intended audience. What is your intended audience? Is it people that use browsers that are 100% compliant with w3c standards? I didn't think so.
Most browsers implement tables a little better than the latest w3c standards. That's a hard fact. Just because tables were made up by people to store tabular data doesnt mean you cant and shouldn't use it do store non-tabular data.
Are you against using 1 pixel transparent gif's for shims, too?
Use what works.
|
|
|
| |
|
|
|
 |
|
 |
|
Fresh-Faced Recruit
Join Date: Sep 2000
Location: niceFire
Status:
Offline
|
|
You're making too big of distinction between rigid tabular data with defined headings and practical tabular data with implied headings.
For instance, if I laid a website out like this:
<BLOCKQUOTE><font size="1"face="Geneva, Verdana, Arial">code:</font><HR><pre><font size=1 face=courier>
---------------------
| | |
| | |
| | |
| | |
| | |
---------------------
</font>[/code]
Using the left side as a menu and the right, larger cell, as content, is that not tabular data? I have relevant navigation data in the left column, and relevant content data in the right column. The headings are implied, but it's still tabular data. Now, how is structuring a table like this any different than writing something similar in XML?
<BLOCKQUOTE><font size="1"face="Geneva, Verdana, Arial">code:</font><HR><pre><font size=1 face=courier>
<page>
<main>
<menu>
<choice>
</choice>
<choice>
</choice>
</menu>
<content>
</content>
</main>
</page>
</font>[/code]
Now, let's look at the HTML:
<BLOCKQUOTE><font size="1"face="Geneva, Verdana, Arial">code:</font><HR><pre><font size=1 face=courier>
<table>
<tr>
<td <font color = purple>id</font>=<font color = red>"menu"</font>>
<choice>
</choice>
<choice>
</choice>
</td>
<td <font color = purple>id</font>=<font color = red>"content"</font>>
</td>
</tr>
</table>
</font>[/code]
In the XML method you're simply telling the user agent that your <page> object contains both menu (with several menu choice nodes) and content nodes. In the table version, you're telling the agent that you've defined a table with two cells... menu and content. You haven't specifically defined a presentation, you've just defined the structure of the data, much as you would in XML.
Take this quote from the W3 for instance:
From the purist's point of view, the alignment of text within table cells and the borders between cells is a rendering issue, not one of structure. In practice, though, it is useful to group these with the structural information, as these features are highly portable from one application to the next.
That seems pretty clear to me. Tables are useful, highly portable, and widely accepted. Limiting their usage to exact situations (like strictly tabular data) is being different for the sake of being different.
Nope—it's not valid markup under anything beyond HTML 4.01 strict. Valid markup good, non-valid markup bad.
Erm... XHTML 1.0 is simply the HTML 4.01 made to be valid XML. XHTML 1.1 isn't the spec yet, and I still can't find anything addressing the valid use of tables within the proposal. Would you like to point me to links?
|
|
|
| |
|
|
|
 |
|
 |
|
Registered User
Join Date: Jul 2000
Location: Newcastle, Australia
Status:
Offline
|
|
Honestly, what's the point?
There's no way you're ever going to be able to write a page that looks identical on all platforms and browsers, and there are different ways of doing things that work in exactly the same way.
I tend to lean toward tables for dynamic layout, simply because they are supported better than layers right now. I use CSS for my text formatting, and nothing else.
Take a look at: http://homepage.mac.com/tonyarnold/
This was ALL designed in DreamWeaver (no, you don't have to use a text editor to produce something that displays correctly across multiple browsers). I'm a bit worried about introducing it to this argument, because I haven't thoroughly checked it, but I used tables to produce an effect that would have been otherwise fairly impossible.
I could have done it using layers, but then it wouldn't have looked the same between NS4/6 and IE5/6.
Do what is technically correct up until the point that you absolutely need to break a rule. Yes, the web is all about content, but presentation of the content is just as important as what is actually in the content.
|
|
|
| |
|
|
|
 |
|
 |
|
Professional Poster
Join Date: Dec 2000
Location: Staffs, UK
Status:
Offline
|
|
If you are woried about separating content from design then write all your content as XML and parse that into whatever HTML is appropriate for the target browser.
...meantime, back in the real world, write your HTML so that it supports the greatest number of browser platforms - and that means using tables in this case. You may feel like you're betraying your web design ethics, but really, your audience will thank you.
FWIW - I'm a strong proponent of separating content from design. But I'm also a strong proponent of 'if it aint broke - dont fix it', and 'the simplest solution is best'.
|
|
|
| |
|
|
|
 |
|
 |
|
Grizzled Veteran
Join Date: Sep 1999
Location: Boston, MA USA
Status:
Offline
|
|
Here's my take -
The web was intended to be a medium that transferred across different output devices. That doesn't mean that's what it *is*. What it currently *is* is a visual medium. It may eventually become something different, but I've yet to see someone give out figures on how many aural browsers there currently are, or how many users surf the web by audio. I realize it's currently in style to badmouth "weenie visual web designers", but the truth is most of this comes from a quick read of Jakob Nielsen's book/articles, and Jakob Nielsen doesn't even practice what he preaches.
Standards-compliance is a wonderful thing. But being a standards-compliancy fascist (and incidentally, denigrating other people as "designers like you") is a great way to turn off everyone to your message. This is an old story, and the reality is that some people use a broad palette and design for current technology, other people use a narrower palette and design for the ages. One approach is not appropriate for all content or websites. This, btw, is the same argument that raged in the print industry concerning acid-free paper, so frankly, been there done that, and I'm twice as bored by it this time around.
Design your site as you see fit, and keep your opinions about other's design approaches to yourself unless asked.
|
|
|
| |
|
|
|
 |
|
 |
|
Grizzled Veteran
Join Date: Sep 1999
Location: Boston, MA USA
Status:
Offline
|
|
GeeForce - you hit the nail on the head.
|
|
|
| |
|
|
|
 |
 |
|
 |
|
|
|
|
|

|
|
 |
Forum Rules
|
 |
 |
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is Off
|
|
|
|
|
|
 |
 |
 |
 |
|
 |
|