T
Trans
still no.
T.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
still no.
T.
S
Stefan Schmiedl
can anyone who is having this problem see if it is fixed now? i
updated the theme, but i since i'm not seeing this problem, i am not
sure if i fixed it or not? thanks again to everyone who helped me
resolve this. -dan
Your HTML states:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type"/>
<title>Ruby Waves: Home</title>
<link type="text/css" rel="stylesheet" href="/css/site.css"/>
But according to
http://validator.w3.org/check?verbose=1&uri=http://www.rubywaves.com/
you should avoid /> in HTML 4.01 strict.
HTH
s.
D
Dan Yoder
But according to
are there any browsers that actually interpret /> per the spec? i've
always just ignored that.
it appears the underlying problem is related to the way some versions
of firefox calculate the offset dimensions of block elements. the way
it is laying out the page suggests that it doesn't think it has
enough room to put the main content and the sidebar side-by-side.
although ie6, opera, safari, and mac / windows ff2 don't agree.
anyway. i will take this off-line since it has nothing to do with ruby.
thanks again for everyone's help and suggestions.
dan
http://validator.w3.org/check?verbose=1&uri=http:/%
2Fwww.rubywaves.com%2F
you should avoid /> in HTML 4.01 strict.
are there any browsers that actually interpret /> per the spec? i've
always just ignored that.
it appears the underlying problem is related to the way some versions
of firefox calculate the offset dimensions of block elements. the way
it is laying out the page suggests that it doesn't think it has
enough room to put the main content and the sidebar side-by-side.
although ie6, opera, safari, and mac / windows ff2 don't agree.
anyway. i will take this off-line since it has nothing to do with ruby.
thanks again for everyone's help and suggestions.
dan
T
Trans
are there any browsers that actually interpret /> per the spec? i've
always just ignored that.
it appears the underlying problem is related to the way some versions
of firefox calculate the offset dimensions of block elements. the way
it is laying out the page suggests that it doesn't think it has
enough room to put the main content and the sidebar side-by-side.
although ie6, opera, safari, and mac / windows ff2 don't agree.
anyway. i will take this off-line since it has nothing to do with ruby.
thanks again for everyone's help and suggestions.
one suggestion... use tables and forget about it. all the drivel about
the superiority of divs mean squat in the face of practical realities.
T.
J
John Joyce
Well, I'd like to add to that. The argument against tables is oftenone suggestion... use tables and forget about it. all the drivel about
the superiority of divs mean squat in the face of practical realities.
T.
an irrational one, but not completely.
The idea, is that using semantic divs for layouts is more flexible
and more accessible (for screen readers and such)
Tables are more brittle and make the code itself harder to read.
Tables on the other hand, are certainly easier to do layouts with,
but there are plenty of raw recipes out there using CSS to create div
based layouts.
Tables are appropriate when the CDATA (character data) makes sense as
a table.
All of that is just suggestions anyway. Ultimately you can do
whatever you like that works.
You could use spans and make them display:block; in CSS.
You can avoid CSS altogether and just use HTML containing all of the
presentational markup, but it's tougher to maintain.
The biggest problem with tables for layout is that people are often
trying to approximate print document layouts that are fixed and
controlled, but the reality with html is that you must be flexible
and accept the fact that different user-agents (browsers) will render
things differently and that users can resize text in most browsers
and that they all have different possible screen sizes/window sizes.
The main philosophy of div based layouts is that you should give up
trying to exercise complete control of the presentation of the
document in html.
Tables will do hideous things when designed for one platform in pixel-
based sizes...
In the end though, it all comes down to doing what suits you and your
target audience.
The argument is similar to frameset problems. You can avoid framesets
and just use the overflow CSS item to make scrollable sections.
T
Trans
Well, I'd like to add to that. The argument against tables is often
an irrational one, but not completely.
The idea, is that using semantic divs for layouts is more flexible
and more accessible (for screen readers and such)
Tables are more brittle and make the code itself harder to read.
No way are they are more brittle --it's divs that are more brittle.
I've seen many a site screwed-up because of messed up divs. To me divs
are beneficial in some of the ways you mention, but they were designed
rather poorly I think. It boggles my mind that it effectively pushes
us back to using absolute sizes all over the place --and then we end
up with things like Blueprint --one monstrosity on top of another. Do
developers like torture or what?
Tables on the other hand, are certainly easier to do layouts with,
but there are plenty of raw recipes out there using CSS to create div
based layouts.
Tables are appropriate when the CDATA (character data) makes sense as
a table.
All of that is just suggestions anyway. Ultimately you can do
whatever you like that works.
You could use spans and make them display:block; in CSS.
You have to measure ROI. You can spend a whole day getting divs
working the way you want. Just spend 10 minutes making it a table. And
it can be worse. Case in point, Waves' site has been broken for a week
now. Just use tables and get it fixed --you can always come back and
redo it with divs when you have the time.
You can avoid CSS altogether and just use HTML containing all of the
presentational markup, but it's tougher to maintain.
Well that's silly. Declarative stylization is hugely beneficial
regardless of whether you use divs or tables for layout.
The biggest problem with tables for layout is that people are often
trying to approximate print document layouts that are fixed and
controlled, but the reality with html is that you must be flexible
and accept the fact that different user-agents (browsers) will render
things differently and that users can resize text in most browsers
and that they all have different possible screen sizes/window sizes.
The main philosophy of div based layouts is that you should give up
trying to exercise complete control of the presentation of the
document in html.
Tables will do hideous things when designed for one platform in pixel-
based sizes...
Why would you do that? You can size your table in % not px.
T.
M
Marc Heiler
Tables are more brittle and make the code itself harder to read.
This is incorrect if anyone asks me.
I am generating tables programmatically from ruby, and on the layout
question, it is simply a lot easier to have a table arranged nicely with
columns rather than messing with multiple divs. You can use CSS in both
cases anyway.
The "harder to read" argument is really a no argument as far as I see
it, and I will even go as far as to suggest to compare a specific table
with 8 rows and 18 columns with the equivalent div solution.
I would be curious to see the solution so I can compare but until I have
seen it I will claim, based on my own experience, that the table
solution is the better one.
This is incorrect if anyone asks me.
I am generating tables programmatically from ruby, and on the layout
question, it is simply a lot easier to have a table arranged nicely with
columns rather than messing with multiple divs. You can use CSS in both
cases anyway.
The "harder to read" argument is really a no argument as far as I see
it, and I will even go as far as to suggest to compare a specific table
with 8 rows and 18 columns with the equivalent div solution.
I would be curious to see the solution so I can compare but until I have
seen it I will claim, based on my own experience, that the table
solution is the better one.
J
Jeremy McAnally
From a designer's perspective, tables are not accessible since they
don't retain the semantic structure of the document. I don't really
know a whole lot about accessibility and what have you, but I would
imagine that a screen reader treats tabular structured markup
differently than layout structured markup (and would, presumably,
treat a page laid out with tables incorrectly).
--Jeremy
--
http://www.jeremymcanally.com/
My books:
Ruby in Practice
http://www.manning.com/mcanally/
My free Ruby e-book
http://www.humblelittlerubybook.com/
My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/
don't retain the semantic structure of the document. I don't really
know a whole lot about accessibility and what have you, but I would
imagine that a screen reader treats tabular structured markup
differently than layout structured markup (and would, presumably,
treat a page laid out with tables incorrectly).
--Jeremy
This is incorrect if anyone asks me.
I am generating tables programmatically from ruby, and on the layout
question, it is simply a lot easier to have a table arranged nicely with
columns rather than messing with multiple divs. You can use CSS in both
cases anyway.
The "harder to read" argument is really a no argument as far as I see
it, and I will even go as far as to suggest to compare a specific table
with 8 rows and 18 columns with the equivalent div solution.
I would be curious to see the solution so I can compare but until I have
seen it I will claim, based on my own experience, that the table
solution is the better one.
--
http://www.jeremymcanally.com/
My books:
Ruby in Practice
http://www.manning.com/mcanally/
My free Ruby e-book
http://www.humblelittlerubybook.com/
My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/
D
Daniel DeLorme
Jeremy said:don't retain the semantic structure of the document. I don't really
know a whole lot about accessibility and what have you, but I would
imagine that a screen reader treats tabular structured markup
differently than layout structured markup (and would, presumably,
treat a page laid out with tables incorrectly).
Theoretically tables are less accessible, but the fact is that a large
portion of the web is made of table layouts, so screen readers have
adapted and learned how to make sense of table layouts. So in practice
there is no accessibility problem. Of course it might become problematic
if you have 25 levels of nested tables, but as in everything moderation
is key.
IMHO making a column layout with a table is a small HTML hack; making a
column layout with divs is a monstrous CSS hack. I think that, as a
community, web/graphical designers have not yet realized that monstrous
hacks are a bad thing rather than a sign of technical prowess.
D
Day
... continued XHTML/CSS debate
I'm sorry, but I keep looking at this thread expecting to hear more
about waves and have forgotten it was hijacked. I believe this
discussion has very little to do with Ruby and very little to do with
Waves. Would you folks (I don't mean to target Daniel specifically,
here) who want to argue this point (which is often argued and never
settled all over the internet) at least please change the subject
line? I would consider it a personal favor. Thank you.
Ben
C
Collins Richey
I'm sorry, but I keep looking at this thread expecting to hear more
about waves and have forgotten it was hijacked. I
AAgreed. :let's hear more about Waves.
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.
Similar Threads
Forum statistics
Latest Threads
-
Why does my SDL3 C++ app display very low fps but my frame count is very high
- Started by inno vation
-
RegExp pattern / replace function
- Started by FResher
-
How do I Convert VCF to Excel xls/xslx file format? - Easily & Quickly
- Started by evelynmoore
-
How to add PST file to Office 365 for email migration?
- Started by Regain@123
-
Linux ipc multiprocess program
- Started by H_coding
-
Hello folks
- Started by H_coding
-
Chainalysis -..... !?
- Started by john0er
-
Mistakes
- Started by jakey
-
How to interrupt the <Input type="submit> button in a form
- Started by jPaulB