Validating a page with W3.org

[dorayme]

dorayme, where are you now?

Generally buried in work with deadlines, specifically grappling
with a table whose rows will not even roughly be height evened.

(Know anything about getting a table to be this and nicely enough
cross browser? Have not a clue what I am talking about? Why not?
Are you refusing to imagine my problem? Is the call for a url
welling up in your brain? There is a ruddy great picture of an
item in a left column that spans 7 rows, and the 7 rows of
remaining columns are just very short text and number strings but
the last row of these latter takes up about 3/4 of the space.
Looks ugly while being semantically beautiful. You see what
happens to table skills when one needs them and has been
generally not practicing them for layout - an excellent form of
practice and now a dying art because of people at alt.html. I
blame you all.)

 

[Ben C]

Generally buried in work with deadlines, specifically grappling
with a table whose rows will not even roughly be height evened.

(Know anything about getting a table to be this and nicely enough
cross browser? Have not a clue what I am talking about? Why not?
Are you refusing to imagine my problem? Is the call for a url
welling up in your brain? There is a ruddy great picture of an
item in a left column that spans 7 rows, and the 7 rows of
remaining columns are just very short text and number strings but
the last row of these latter takes up about 3/4 of the space.
Looks ugly while being semantically beautiful.

I tried this and it comes out OK in most browsers, but not Konqueror,
aka Safari, in which the first few rows get their content height and the
last one gets the rest, which sounds like what you're describing.

If you don't know the height of the big item on the left then I don't
know what you can do about that.

Rowspan and colspan make table formatting much more complicated than it
would otherwise be, so it might be more predictable to use nested
tables, and there is an easy solution there if you know the height of
the left item.

Give the first table two cells in one row with the big item on the left
and another table inside the cell on the right with 7 rows. If you know
the height of the item on the left[1], then you can just set the height of
the nested table on the right to that value, and that should get
distributed evenly between the 7 rows.

As far as I know the only reliable way to stretch 7 rows evenly so they
add up to some target height is to put them all in a table and set the
desired total on the table, which is what this approach does.

[1] As a final resort, if you don't know that height, I suppose you could use
JavaScript to read it back and apply it to the nested table but I really don't
like using JS for layout.

 

[dorayme]

I tried this and it comes out OK in most browsers, but not Konqueror,
aka Safari, in which the first few rows get their content height and the
last one gets the rest, which sounds like what you're describing.

You are not wrong. I have been looking in Safari and when it
looks right there, I move on to other browsers. Even a martian

If you don't know the height of the big item on the left then I don't
know what you can do about that.

Rowspan and colspan make table formatting much more complicated than it
would otherwise be, so it might be more predictable to use nested
tables, and there is an easy solution there if you know the height of
the left item.

Funny you should mention this! I just finished roughly this
tactic (as you go on to describe) on one of the many tables I
have to do and it sort of solved the problem. (I don't quite know
the height of the cell with the pic as it has a tiny bit of html
text underneath. I tried for the inner table:

<table style="width:100%;height:100%">

And this took up the space fine in Safari.

But I have an uncomfortable feeling about it. The site I am
updating has been moving slowly for years in a certain simpler
and better direction and this takes it a step backwards into
complexity. But if it has to be, it has to be. I might have to
take the pics out of the table and float them left next to a then
easy to manage regular table (there is a small complication that
stops me rushing to this solution but I won't bore you with the
details)

Thanks, Ben, for the input.

 

[dorayme]

<table style="width:100%;height:100%">

And this took up the space fine in Safari.

But not in any other Mac browser I have! (a late discovery). I
will post a url and choose a new thread and topic if needs be.

 

[Dave Kelly]

Well bust mah britches and call me cheeky, on Mon, 23 Jul 2007 02:32:37
GMT Dave Kelly scribed:


Whaaaaaaaaaaaaaat??? According to your first post, you could have done
that by simply using the correct doctype.

TYPO TYPO not should be now.

 

[Neredbojias]

Well bust mah britches and call me cheeky, on Mon, 23 Jul 2007 10:16:45
GMT rf scribed:

A good confession, but for the wrong reasons. (I also find that I need
to confess: I agree with Korpela on this.)

You want to do something that you *know* will not validate, so you use
a construct that bypasses the validator and introduces a layer of
obfuscation as well. Sorry, head in sand approach IMHO. You know you
are "doing wrong" but if you hide in the javascript sandbox then
perhaps nobody will notice.

Well, I _know_ it's wrong! But I am not "playing ostrich" though. It's
just that the Neredbojias-Don't-Bee half of my conscience is overriding
the Neredbojias-Do-Bee half, leaving me a helpless victim in the fray.

Crikey, with this approach your page could

be one single JS call that commits all sorts if infractions, including
using <font> elements, and still "validate".

Yeah... Awesome to think about, ain't it? 'Course I would never be so
uncouth as to do anything like that.

Muses: what if the validator suddenly started to validate the
resultant DOM and not the source?

That, of course, would upset the proverbial apple cart. You do realize I
hardly recommend this technique, I was just sharing the ebullience of one
of my wilder moments.

Except when javascript is disabled and then you lose content for the
10% or so, for no other reason than the exhalted goal of validation.

Yep, ought only to be used in a non-critical situation. Actually, it
should _never_ be used, but if one has human failings...

dorayme, where are you now?

She's probably at the library looking up more cultural cuss words with
which to arm her schizoid psyche.

The validator exists to validate to the published standard. However
even strict languages like C++ allow one to turn off their
"validation" warnings if there is a need to do so. I personally treat
the HTML validator as a cleanup the typos tool.

If you have cause to go outside the standards, for whatever reason,
and mostly those reasons are to be able to survive in the *real*
world, then do so.

Perhaps include a comment in the source to the effect that you are
including an iframe for *this* reason. Perhaps you are writing a CMS
where an iframe is compulsory given the poor browser support for
editable content. Nobody will mind, except the "no tables" purists
(and yes, I do use tables for layout when nothing else will work).

Your client will never know, or even care, or even know that she might
need to care. Job done.

Yes, I quite agree with you. Nevertheless, sometimes it's fun to be
irreverent in the spirit of a sophist. I often find such
prestidigitation more entertaining than, say, tennis.

 

[Neredbojias]

Well bust mah britches and call me cheeky, on Mon, 23 Jul 2007 12:21:22
GMT Bergamot scribed:

That's icky, and generally a bad practice, as rf mentioned.


Right on both counts. You should take your own advice, though.

You're right. But I wasn't advocating such methods, I was simply sharing
one of my faults.

Validating is just a tool--validated code isn't an end to itself.
You don't do yourself any favors by this js trickery.

It made me chuckle. That was favor enough.

 

[Neredbojias]

Well bust mah britches and call me cheeky, on Tue, 24 Jul 2007 02:13:42 GMT
Dave Kelly scribed:

TYPO TYPO not should be now.

OOhhhhhhhhhhhhhhhhhhhhhh!

Do you know the trouble you caused, young man? Now half the group is out
for my blood, and it's all your fault! I hope you're happy in your
negligent carelessness.

 

[Ben C]

But not in any other Mac browser I have! (a late discovery). I
will post a url and choose a new thread and topic if needs be.

The problem is it's a percentage height of an auto height container.

You might get away with it if you also set style="height: 100%" on the
td containing the nested table. And sometimes Firefox makes more effort
with this kind of thing in quirks mode.

But you don't want to rely on that kind of thing. Nothing changes the
circularity that the space available to that nested table depends on the
height of the nested table itself (as well as on the stuff on the left,
which in your case in the limiting factor).

 

[dorayme]

The problem is it's a percentage height of an auto height container.

You might get away with it if you also set style="height: 100%" on the
td containing the nested table. And sometimes Firefox makes more effort
with this kind of thing in quirks mode.

But you don't want to rely on that kind of thing. Nothing changes the
circularity that the space available to that nested table depends on the
height of the nested table itself (as well as on the stuff on the left,
which in your case in the limiting factor).

Yes. I mean no, I won't rely on this sort of thing. It turns out
that the _biggest_ problem I have is when there are only two rows
of details and a pic in a col that spans them. In Safari only, it
looks absurd - the only saving grace being it is not
unintelligible. After I have done all the substantial details on
the section I am working on, I will return to this issue.