On Sun, 07 May 2006 11:52:37 +0100 Steve Pugh <st***@pugh.net> wrote:
|
ph**************@ipal.net wrote:
|>On Sat, 06 May 2006 23:54:28 +0100 Steve Pugh <st***@pugh.net> wrote:
|>|
ph**************@ipal.net wrote:
|>|>On Sat, 06 May 2006 18:48:03 +0100 Steve Pugh <st***@pugh.net> wrote:
|>|>|
ph**************@ipal.net wrote:
|
|>|>|> What term would you use for data that
|>|>|>is not tabular in nature, but requires exactly the same presentation?
|>|>|
|>|>| Maybe I'd call it an image? On the WWW I'd almost certainly call it
|>|>| broken.
|>|>
|>|>Why would it be broken?
|>|
|>| Because the WWW is media independent and if a certain exact
|>| presentation is required then that is something that can not exist on
|>| the WWW. What does your grid look like in an aural browser?
|>
|>Not all content is suitable for all media. What does you voice look
|>like on a visual browser to a deaf person?
|
| My voice is presentation. But my words are content. Hence I would put
| my words into an HTML document and leave the details of my voice to a
| CSS stylesheet.
That's going to be some very complex presentation. And it would make it
quite easy for someone to just change the words in the content and have
your voice saying whatever they want.
Maybe we should just carry this concept one step further and have the
content be in no specific language, and leave the language up to the
presentation.
This whole separation of content and presentation I think is being carried
way too far, at least in the context of requiring that everything be in
such a form. I don't think it's a big problem for text. But for things
like images and sounds and smells, I believe it's going too far.
|>|>I see no reason to have a constraint on _what_ you can put in a table.
|>|>If it's a number, fine. If it's a block text, why should that matter?
|>|
|>| Anything can go into a table so long as it's tabular data. That can be
|>| text, images, anything. So long as it has a relationship with the
|>| other items of data in the same row and column then it's tabular data.
|>
|>And this rule applies whether it's a TABLE element in HTML or CSS tables?
|
| CSS doesn't have elements and doesn't have (document) semantics. The
| 'rule' above applies to HTML tables. CSS tables are purely for
| presentation and can be applied to anything.
What is the meaning of "table"? It sounds like HTML and CSS are trying to
have only partial implementations of what that means.
I don't see the point. I do see an advantage to using CSS because it lets
you specify one the properties of things appearing many times. By the
whole philosophy that is going on with it isn't somethin gI agree with.
|>| Who ever suggested that it can't be a block of text?
|>
|>Other respondents in this newsgroup.
|
| Care to post the messages IDs?
Why would I keep a record of that, for what seemed, at that time, something
with no great controversy? Do you keep a record of every message ID of
everything you discuss when it's about something you are not an expert in
just in case someone later on says "oh, that's not true, give me the message
ID of that"? That's just not a common, or practical practice, any more
than expecting you to police every thread (otherwise I could say "why were
you not there to refute it on the spot").
|>OK, so it's a block of text then. I'll try to remember who to send them
|>to if they try to say any different. You can set them straight.
|
| Feel free. But please point them towards an actual post of mine rather
| than just trying to paraphrase my words or quote part of them out of
| context. I suspect that the chances are that I and they will agree
| and that it is you who has yet again failed to grasp the distinction.
Or maybe they didn't phrase it well. That's common on Usenet.
|>|>It's like a table, with no required relationships.
|>|
|>| Bingo. That's the context I've been using it in this thread. Like a 2d
|>| representation of a table in presentation, but without the table
|>| semantics.
|>
|>Since you widened the scope of what is tabular data, then doesn't that
|>imply the semantics of tabular data, if I use that which is within the
|>scope of tabular data?
|
| No. The semantics of what is a table are as have been given several
| times. There must be a relationship along the rows and down the
| columns.
|
| <table>
| <thead>
| <tr>
| <th scope="col">Stock Number</th>
| <th scope="col">Item Name</th>
| <th scope="col">Item Description</th>
| <th scope="col">Picture</th>
| <th scope="col">Unit Cost</th>
| </tr>
| </thead>
| <tbody>
| <tr>
| <td>467657</td>
| <td>Clue Stick</td>
| <td><p>For beating people who seem incapable of getting a clue via
| any other means. 42.5cm with average radius of 2.1cm. Made of solid
| oak.</p></td>
| <td><a href="/pics/467657.jpg"><img src="/thumbs/467657.jpg"
| alt="Clue Stick"></a></td>
| <td>?15.80</td>
| </tr>
| ....
| </tbody>
| </table>
|
| See? There are still relationships between the cells even though they
| contain different types of data. The only real debate here is whether
| one should make the first cell of each row a th rather than td.
One should make a header be TH. If a header is applicable to a row,
then put one there. And I don't see how the first cell has anything
to do with it ... the semantics are the semantics even if you put it
in a different place. It might seem odd when it isn't the first, but
that doesn't mean someone else's content can't have what that kind of
markup implies.
Or headers can be omitted.
| If the paragraph in column 3 and the image in column 4 weren't related
| to the stock number in column 1 then it would not be a table.
|
|>| You're rapidly approaching Luigi levels of obliviousness.
|>
|>No meaning to me from that.
|
| Google for Luigi in alt.html. You remind me of him.
In what way?
FYI, I'm not actually going to look. I have no interest in following
some useless thread of conversation somewhere else. And I should not
have followed this one aside from the fact that doing so finally led
me to something that worked. The average person would probably have
given up before a working example was seen.
|>I don't think there is anything in HTML that can truly give me the
|>semantics of the document itself, the way I want.
|
| Which is why HTML gives you the semantically neutral div and span
| elements to as hooks to hang semantics-free presentation on.
But from a practical perspective, when presentation is what is trying to
be achieved, the implications of semantics in HTML don't really matter.
People will use what they want. Elements like TABLE are more about being
shortcuts to common default presentations than they are about semantics,
the exact details of which either are not agreed upon by all, or are not
explained the same way by all.
|>|>| That's how it works - HTML for semantics and CSS for presentation.
|>|>
|>|>There are, however, semantics for the things found in the CSS "language".
|>|>That's not semantics of the document, but rather, semantics of how those
|>|>things will cause the browser to render the document.
|>|
|>| The "semantics" of the CSS display: table-* properties are "make this
|>| look _like_ a typical 2d rendering of a table".
|>
|>Maybe they should have chosen a different term in place of "table".
|
| Would you also suggest that they should have avoided the word list in
| display: list-item and list-style-type?
I don't know. I haven't studied or worked with those, yet.
| Every element in HTML has a presentation that is more or less the same
| across graphical browsers. The writers of CSS 2 decided that thaat
| default presentation had to be expressable in CSS. For most elements
| standard properties like margin and display: block could be used, but
| for lists and even more so for tables a set of new properties had to
| be created to replicate the default presentation.
And even that wasn't 100% complete. A noble effort. A little more
work is needed. You can see that in some tweaks being used in the
default stylesheet for HTML in Firefox.
| Maybe a study of
http://www.w3.org/TR/CSS21/sample.html would be
| instructive as to why CSS exists in the form it does?
Same concept as the default one in Firefox, but this one from the
standards people, so no tweaks. I wonder how well it would work in
Firefox if I swap it.
|>But, neveretheless, it is there, and it can be made to work, though it
|>seems a few other people don't have the knack for it (but, you do).
|
| Other people were probably trying to make something that worked in the
| real world where IE dominates.
It could be. That's a big issue. Some stuff I have done and will be
doing is Linux oriented. Yet even there, IE is a big portion of the
user base. Some other stuff I will be doing is for a generic audience,
so not only must IE work, it must work about equally well.
|>|>So why is there "table" in HTML _and_ "table" in CSS? Is "table" a kind
|>|>of presentation? Someone thought so if they put it in CSS.
|>|
|>| The table in HTML is to markup data with table semantics.
|>| The table in CSS is to markup data with table like presentation.
|>
|>You left the door pretty wide for using HTML tables, though.
|
| I'm not opening or closing any doors. I've said all along that as IE
| doesn't support the relevant CSS you have to make a choice between
| using semantically false tables or changing your design (or living in
| a fantasy world where IE doesn't exist).
What I meant about the doors is that you allowed for anything to be
"tabular data" by it merely having the row and column relationships.
Layout _does_ have row and column relationships. Yet layout really is
presentation. But the relationship specifics (e.g. which block of
"stuff" is related in what way to what other block of stuff) can't be
in the presentation; so it has to be in the content markup. So I'm
still force to express at least part of the layout presentation in
the content (at a minimum as classified divisions).
|>| The built in style sheets in browsers give CSS table presentation to
|>| HTML tables, so you don't need to specify the CSS itself in your
|>| author stylesheet.
|>|
|>| But if you want to create something that looks like a table, but
|>| isn't, semantically speaking, a table you use the CSS to give the
|>| table presentation to some other HTML element - one who's semantics
|>| does match the data in question.
|>
|>I think that leaves things pretty well open to the wild to debate
|>whether some contents/document is a table.
|
| Yes, there is room for debate and even disagreement. Your chessboard
| is a good example. It doesn't really match my simplified descript of
| having relationships across the rows and dow the columns, but still
| has many table like qualities to it. A more common example is a form -
| placing all the labels in one column and all the inputs in another.
It ended up being an example of stuff different than what I had intended.
|> Some others would not
|>agree with you about anything being allowed if it had the row and
|>column relationships that you seemed to a few paragraphs above.
|>It might be presented as a table; but _is_ it a table? Who knows.
|
| I think you've missed the point again. The row and column
| relationships must say somthing about the data in cell X,Y so that by
| looking along row X and column Y we learn something more about that
| piece of data.
|
| Using a table to lay out a grid whereby each column contained news
| stories from different regions wouldn't be a table in my mind.
Why not? It has the row and column relationships. Of course, the
data could stand by itself and not _need_ those relationships. But in
the context of how presented, the relationships are a (small) part of
the meaning given. There can be added semantics provided by the editor
merely in _how_ the relationship is set up, without having to actually
change any of the text. So what seems like presentation is also a form
of semantics (that maybe many people just can't see as semantics).
| But if each row specified a time period (and hence each cell could
| contain multiple news stories,) then that would be a table. It
| wouldn't matter in which order a speech browser read out the stories
| so lng
I think the order should matter.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN |
http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net |
http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
