On Fri, 05 May 2006 19:37:07 +0100 Steve Pugh <st***@pugh.net > wrote:
|
ph************* *@ipal.net wrote:
|
|>On Fri, 05 May 2006 08:10:01 +0100 Steve Pugh <st***@pugh.net > wrote:
|>
|>| Consider your blocks of text that you want to arrange in a grid. Now
|>| take the block of text that's at the intersection of the third row and
|>| the second column. What does that fact that it's at that intersection
|>| _mean_?
|>
|>That can depend. It might be more important that it is in the second
|>column.
|
| So you can swap the items in the third row, second column and fifth
| rowm second column, without changing the meaning of the page?
In some such cases, sure. Maybe not in others. It depends on which site
and the nature of that content.
| That's almost certaibly not a data table and hence should not be
| marked up with HTML table elements.
But until I see a way to make it work correctly in CSS, I fall back to
what does work, and will still use TABLE elements, regardless of any
debate over whether the meaning is appropriate.
|>| In a table it means something. e.g. it means that it's the printer
|>| sales figure for France (row) in May 2005 (column); or that the black
|>| queen is on square C6 (which is why I think the chessboard is a valid
|>| table).
|>|
|>| But it just means that this block of text is in the third row and the
|>| second column, then there are no table semantics. And hence HTML
|>| tables should not be used, but CSS display: table-* can be used to
|>| give the appearance a table like grid effect.
|>
|>I saw a demonstration of display: table-* that did not do the job.
|>Maybe that demonstration was defective and you can provide a better
|>one?
|
| I'd need to know in which way it "did not do the job".
I've seen several different examples over the past few days and cannot
say which is which anymore. I don't bother to try to remember all the
details of things where the other party isn't trying to follow through
on those issues. I just dismiss it and remember that some greater number
of examples still don't work.
Of course, if you are wanting make something work, and follow through
to get it working in all ways, I'm certainly willing to give feedback.
But here are some of the issues I have seen:
1. It must be a separate CSS file that works regardless of how many
different columns the HTML marked up content has.
2. It must not "float" any items down to following "rows" (what appears
to be a row).
3. Text (and everything else) must not bleed out from the bounds of the
cell. If the font size is too large, it must keep either whole words,
or at least whole character glyphs, within the cell, even if that means
the total width forces horizontal scrolling.
There may be other issues. In all, the way TABLE/TR/TD elements work in
HTML must be retained.
|>| It's all about the semantics. A table has semantics whereby any piece
|>| of content belongs to a row and column and that belonging has a set
|>| meaning. A 'grid' just has the same appearance but none of the
|>| semantics.
|>
|>I've found more than one kind of semantics for a grid.
|
| A grid has no semantics.
Sure it does. But there's no real value in debating words. What I want
is what a grid is with the semantics that I see with TABLE/TR/TD elements.
To me, it's a grid if it meets certain criteria. I call those criteria
the semantics of a grid. But maybe it might be clearer to shift the
usage over to something like "rigid grid".
|> One demo page
|>I was showed an invisible grid with thumbnail pictures. When the size
|>of the displayable area was shrunk, the object on the right moved to
|>the next lower row and on the left. For some kinds of semantics this
|>would be fine (and I've done stuff like that, too). But for others it
|>is not.
|
| If it's just an image gallery then in terms of semantics that's not a
| problem. In terms of layout it might not match the designer's vision
| and then it becomes an issue of usability v. design fidelity in the
| edge case or users with narrow browser windows.
To me, the image gallery in such a case is a list (of images that may be
captioned individually and may be hyperlinekd) which is presented in a
convenient form (but could also be presented in an inconvenient form).
I have seen image galleries entirely vertical, and that way annoying.
But it's really not any different than a list, other than what happens to
be in the elements of the list. Choosing to let the list flow horizontally
is usually a good idea. The good image galleries do that.
But I wasn't talking about an image gallery when I was bringing up the
overall table issue.
|>| One way to decide whether your data belongs in a table or not is to
|>| consider whether every row and column could be given a heading, i.e.
|>| could you include a <th> for each row and column?
|>
|>In some cases they could be. Or it could be implied and not actually
|>shown (which I think you intended to include by your choice of the word
|>"could").
|
| Or by the bit a little later where I say "It's not always necessary to
| then go and put these headings in the page (though it's usually a very
| good idea to do so)"
|
| The important thing is that if it's a table then at least one, and
| often both, of rows or columns must have some sort of easily labelled
| relationship.
One thing I have found is that there is some variation among people who
have written in this and other threads about what is a table. Most will
agree that the kind of data found in a spreadsheet is appropriate. But
I can tell you that I've seen some really bizarre spreadsheet files in
some places. Some other people seem to be more accepting of just about
anything in each of the cells, and still call it a table as long as there
simply is the row/column relationship (with the implication that the table
elements in HTML would be OK).
|>| One that will be meaningful, so that if an aural browser read out
|>| [heading for row 3, heading for column 2, content of cell at
|>| intersection of row 3 and column 2] it would make sense.
|>|
|>| It's not always necessary to then go and put these headings in the
|>| page (though it's usually a very good idea to do so) but if you don't
|>| have any headings for your rows or columns then there's a good chance
|>| that semantically you don't have a data table and hence you should be
|>| looking at CSS tables not HTML tables.
|>
|>However, what I ahve in mind right now needs to have the layout semantics
|>of TABLE/TR/TD.
|
| "Layout semantics". That doesn't really make sense. Some semantics
| demand a particular layout (though for most data tables you can rotate
| by 90 degrees - i.e. swap rows and columns - and maintain the
| semantics) and in general the layout may give visual hints towards the
| underlying semantics (unless the author has done something stupid like
| make all of H1 - H6 appear the same) but the semantics and the
| presentation are different things.
Actually, the rotation would retain the relationship; it would just be
in a less convenient form.
|>I've seen some examples that correct the flow problem
|>(e.g. they made the right column stay at the right)
|
| For a table, where the data in a row must stay in a row otherwise the
| meaning is distorted, that is essential. For a layout where the
| meaning is the same but the presntation is different that is totally
| optional.
In a table, the data must also stay in the column. In some cases swapping
whole columns across all rows is OK. In some cases (not necessarily the
same set of cases just mentioned) swapping whole rows across all columns
is OK. In other cases, any swapping is not OK.
|>but they had other
|>issues which I don't know can be corrected (in part because I have seen
|>that problem in a _lot_ of web pages, so I worry that it could be an issue
|>of CSS).
|
| What is this other problem?
See the list I gave above. The biggest one I was thinking about while
writing that was the bleeding of text out of the cell.
|>| Of course this is somewhat academic as IE6 doesn't support CSS tables,
|>| so if your design really demands a grid then you must either abuse
|>| HTML tables or change the design.
|>
|>For a long time I avoided CSS altogether because of the browser upgrade
|>barrier. Firefox has managed to break that barrier because:
|>1. It seems to be a very compliant implementation
|>2. It's portable (Linux, BSD, Unix, Mac, and Windows)
|>3. It didn't bloat too much in relation to machine capability of the day
|>Basically, it means I feel good about recommending to everyone that they
|>use Firefox. Had IE also met all these requirements for just Windows, and
|>Firefox not been ported to Windows, I could have accepted recommending IE
|>for Windows users and Firefox for everyone else. But at least there is a
|>browser I can recommend (and it happens to be the same one for all).
|
| I would largely agree (I use Opera myself and the same points can be
| said about that browser). However, IE is still at least 80% of the
| population, so it can not be ignored. Otherwise CSS tables would be a
| semantics neutral layout grid solution.
.... once I see a CSS table that works just like an HTML table for all the
aspects that are important to me (there might be some aspect of HTML tables
I'm not aware of or don't remember because it wasn't important to me, and
such an aspect could be left out of a CSS table and it would not bother me).
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN |
http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net |
http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
