grid structures: TABLE/TR/TD vs. DIV
phil-new...@ipal.net
properies, vs. the old method of TABLE and TR and TD?
I'm finding that by using DIV, it still involves the same number of
elements in the HTML to get everything just right. When you consider
the class attribute on the DIV elements, there's not much size savings
anymore for using DIV.
There are other disadvantages to not using TABLE/TR/TD, such as the
lack of ability to merge cells, and keeping rows and columns aligned
with each other under varying content.
Content should be in HTML and style in CSS. So how is that affected
by whether the HTML markup has TABLE/TR/TD or just DIV.
Note that I am not talking about the use of additional tables and cells
to create stylistic effects in the grid, such as spacing between cells.
This can be done in CSS regardless of whether the elemnts involved are
TABLE/TR/TD or just DIV.
I bet someone has already written "Tables considered harmful". But is
it really justified?
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Barbara de Zoete
> Is there really any advantage to using DIV elements with float style
> properies, vs. the old method of TABLE and TR and TD?
[ snip ]
> I bet someone has already written "Tables considered harmful". But is
> it really justified?
This discussion has been done over and over again, in this group and other
www.authoring groups. Go through the archives first and then make up your
mind.
<URL:http://www.google.com/search?q=tableless+design>
<ULR:http://groups.google.com/groups/search?q=no+tables++css+group:comp.infosystems.www.authoring.*+group:alt.html.*>
In short:
- Try to understand what markup is for: it 'tells' browsers and bots and
the like what your content is. So a div is only needed if no other
appropriate element is available (likewise with <span>).
- Tables are for tabular data. Using them for layout purposes is just the
same thing as using blockquote for the left margin, <br> for whitespace
between paragraphs, for padding on inline elements, <h4> for
creating a block of text with a slightly larger, bold font. Just a few
examples. It shows the author doesn't understand markup. It is all about
abusing elements because of there appearance in graphical browsers.
If done properly, in a html page the content is structured and marked up
using meaningful elements. This should give the author already a lot of
'handles' to create the appearance of the page, for every element s/he
uses in the body of the page, including the body element itself, can be
used as a selector in a style sheet.
If some content needs to be treated differently than the standard looks
the author created for the element, it gets a class or maybe an id. If
some content is to be 'physically separated' from the rest of the page,
the author can put it in a containing div and asign a class or id to that
div.
Once an author understands the concept of markup, why it came about in the
first place, how to use it properly, s/he will no longer feel the need for
tables for layout any longer.
--
______PretLetters:
| weblog | http://www.pretletters.net/weblog/weblog.html |
| webontwerp | http://www.pretletters.net/html/webontwerp.html |
|zweefvliegen | http://www.pretletters.net/html/vliegen.html |
phil-new...@ipal.net
| On Sun, 30 Apr 2006 08:41:16 +0200, <phil-new...@ipal.net> wrote:
|
|> Is there really any advantage to using DIV elements with float style
|> properies, vs. the old method of TABLE and TR and TD?
|
| [ snip ]
|
|> I bet someone has already written "Tables considered harmful". But is
|> it really justified?
|
| This discussion has been done over and over again, in this group and other
| www.authoring groups. Go through the archives first and then make up your
| mind.
| <URL:http://www.google.com/search?q=tableless+design>
| <ULR:http://groups.google.com/groups/search?q=no+tables++css+group:comp.infosystems.www.authoring.*+group:alt.html.*>
|
| In short:
| - Try to understand what markup is for: it 'tells' browsers and bots and
| the like what your content is. So a div is only needed if no other
| appropriate element is available (likewise with <span>).
Stop with the "try to understand" religion. I'm getting tired of it.
| - Tables are for tabular data. Using them for layout purposes is just the
| same thing as using blockquote for the left margin, <br> for whitespace
| between paragraphs, for padding on inline elements, <h4> for
| creating a block of text with a slightly larger, bold font. Just a few
| examples. It shows the author doesn't understand markup. It is all about
| abusing elements because of there appearance in graphical browsers.
That's all fine, but ...
| If done properly, in a html page the content is structured and marked up
| using meaningful elements. This should give the author already a lot of
| 'handles' to create the appearance of the page, for every element s/he
| uses in the body of the page, including the body element itself, can be
| used as a selector in a style sheet.
While CSS can do quite a lot, and can even do a lot of things that cannot
be done in just HTML, there remains a few things CSS cannot do. So it is
NOT yet time to say that HTML must be pure content.
Just accept the fact that, as good as it is, CSS still needs work!
| If some content needs to be treated differently than the standard looks
| the author created for the element, it gets a class or maybe an id. If
| some content is to be 'physically separated' from the rest of the page,
| the author can put it in a containing div and asign a class or id to that
| div.
I understand the principle. I've understood this for years, even before
CSS was practical enough to even try to use. The issue is NOT about the
understanding of the principle; the issue is that CSS has been growing
up from a state of being totally unusable (e.g. Netscape 3) to being a
royal PiTA (e.g. Netscape 4) to being now quite viable for _most_ things
(Firefox 1.5). But even still, it's not at 100%.
In many cases CSS forces the HTML (which should just be content and nothing
more) to have extra markup just to support style. For example, styling a
page to have some appearance of a grid structure through the use of float
requires _additional_ DIV elements to be added to the content. That
violates the principle of separation of content and style right there. If
CSS "had it right" then I could put some content in _just_ _one_ DIV element
and then you can put ANY style on it that you want, including hover raised
drop shadow effect that so far requires at least 3 layers of DIV elements in
the content to achieve. And that can confuse someone trying to restyle it
to something else.
| Once an author understands the concept of markup, why it came about in the
| first place, how to use it properly, s/he will no longer feel the need for
| tables for layout any longer.
Once you guys understand that CSS does NOT yet do all the things that people
_want_ to do, and _can_ be done with HTML hacks, then we won't see threads
like this and won't have repeated conversations like this.
The drop shadow effect is _better_ done in CSS than with HTML because it
requires lots of "wedges" in the form of extra table cells and transparent
GIF images to accomplish with just HTML. BUT ... it is still NOT RIGHT in
CSS because it _should_ be doable with exactly _one_ DIV element (which can
then be styled as anyone would want).
So ... I'm moving to use CSS for drop shadow effects.
The table grid is NOT _better_ in CSS, yet. There are _two_ reasons for
this. Reason 1 is that the way being promoted now (e.g. float:left) does
not work the same way. That is, not all the same effects are accomplished
with float:left as would be using TABLE/TR/TD. These effects include
syncronized alignment and rigid arrangement. Reason 2 is that, like the
case above for shadows though for different reasons, it still requires the
insertion of extra DIV elements in the content markup (beyond the two layers
that would obviously be needed in any method to distinguish what is to be in
a row and what is to be in a column). And I forgot to count some of the
column and row span features, which float:left can do only in limited ways.
So ... I'm going to stick with certain uses of tables for grid structure.
Please stop with the f*****g annoying "markup and style" religious promotion
and either work towards making CSS better (like maybe a CSS3 that fixes the
issues mentioned), or showing new creative ways to accomplish things that
people have been using HTML hacks for years to do, or just be quiet and take
a seat and watch the events unfold without your influence.
But just STOP ... NOW ... with all the "once authors understand ..." BS.
Get your OWN understanding that CSS just isn't at the 100% level, yet.
Barbara de Zoete
> But just STOP ... NOW ... with all the "once authors understand ..." BS.
> Get your OWN understanding that CSS just isn't at the 100% level, yet.
If you know all the answers to your own questions, why the heck do you ask.
phil-new...@ipal.net
| On Sun, 30 Apr 2006 18:01:46 +0200, <phil-new...@ipal.net> wrote:
|
|> But just STOP ... NOW ... with all the "once authors understand ..." BS.
|> Get your OWN understanding that CSS just isn't at the 100% level, yet.
|
| If you know all the answers to your own questions, why the heck do you ask.
The issue of TABLE/TR/TD vs. DIV is not a question of "how do I". Instead,
it is a question of "what should we do". And yes, I do know what I believe
is the correct answer: "fix CSS". Of course that takes a long time. One of
the steps necessary to get the end result is to break through all the denial
the community has.
Understanding the _principles_ of content, markup, style, etc., does _not_
automatically make one know all the methods and means to properly use it,
either. So questions I or anyone else asks of the "how do I" variety do
need to be considered without jumping to the religious answer of "if you
just understand ...". Both CSS and HTML, as well as programming languages,
are made up of a number of discrete pieces of syntax and semantics. They
alone give you nothing. Combining things together gives you something that
if well chosen and well combined can be something great.
Maybe the way _I_ understand things is different than the way _you_ understand
them. But that's common; people are different ... people think in different
ways. You and I both have to live with it. For example, I see certain things
as "definitely" content which you might see as style. I presume we would
agree that background colors are style. But for me that isn't a hard and fast
rule. In some cases background colors are _content_. One example is the red
and black colors of a Chess board. Sure, someone could decide to make a Chess
board of another color and such things exist. But these are the traditional
colors people recognize as such. So if I am going to lay out a grid structure
as a Chess board, you can bet I'm going to set the colors in the HTML tags.
And I'm not going to use "float:left" to layout a Chess board, either.
There are other cases where TABLE/TR/TD still beats DIV (and float) to make
a grid structure as desired. I'd rather do it with DIV, but it just isn't
capable, yet, for all that needs to be done. TABLE/TR/TD still works better
for certain things. It seems most everyone agrees tabular data is to be
done that way. But a lot of other things that wouldn't really be called
tabular data still need the same grid structure semantics/effects, which is
not possible with DIV and float (again I say "yet" because I see the potential
to fix this).
Johannes Koch
> While CSS can do quite a lot, and can even do a lot of things that cannot
> be done in just HTML, there remains a few things CSS cannot do. So it is
> NOT yet time to say that HTML must be pure content.
>
> Just accept the fact that, as good as it is, CSS still needs work!
Are you sure, you mean "CSS still needs work"? Not "CSS implementations
need work"? WRT presentation of HTML tables (what I suspect you call
grid), there is really a little stuff (rowspan/colspan) which cannot be
done with CSS.
--
Johannes Koch
Spem in alium nunquam habui praeter in te, Deus Israel.
(Thomas Tallis, 40-part motet)
Chris Morris
> rule. In some cases background colors are _content_. One example
> is the red and black colors of a Chess board. Sure, someone could
> decide to make a Chess board of another color and such things exist.
> But these are the traditional colors people recognize as such. So
Odd, most of the (real) chessboards I've seen are yellow and
black. Maybe it varies from place to place.
> if I am going to lay out a grid structure as a Chess board, you can
> bet I'm going to set the colors in the HTML tags.
I can't imagine a situation where HTML-based colour setting would be
more reliable than CSS-based colour setting in such a situation, with
modern browsers at least - every graphical browser I know with an
"ignore CSS" option also has some form of "ignore colours" option. If
the colour is truly part of the content then perhaps an image (with
suitable text alternative) is the better way to provide the
information?
> And I'm not going to use "float:left" to layout a Chess board, either.
I'd have thought a chess board was certainly tabular data.
> There are other cases where TABLE/TR/TD still beats DIV (and float)
> to make a grid structure as desired. I'd rather do it with DIV, but
> it just isn't capable, yet, for all that needs to be done.
> TABLE/TR/TD still works better for certain things. It seems most
> everyone agrees tabular data is to be done that way. But a lot of
> other things that wouldn't really be called tabular data still need
> the same grid structure semantics/effects, which is not possible
> with DIV and float (again I say "yet" because I see the potential to
> fix this).
Does IE7 support 'position: table-*'? That gives much the same layout
options but doesn't interfere with table-reading mode so much. (Of
course, even if it does, it'll be a couple of years before it's
generally usable)
--
Chris
phil-new...@ipal.net
| phil-new...@ipal.net writes:
|> rule. In some cases background colors are _content_. One example
|> is the red and black colors of a Chess board. Sure, someone could
|> decide to make a Chess board of another color and such things exist.
|> But these are the traditional colors people recognize as such. So
|
| Odd, most of the (real) chessboards I've seen are yellow and
| black. Maybe it varies from place to place.
I've seen a couple like that. But virtually all are red and black.
|> if I am going to lay out a grid structure as a Chess board, you can
|> bet I'm going to set the colors in the HTML tags.
|
| I can't imagine a situation where HTML-based colour setting would be
| more reliable than CSS-based colour setting in such a situation, with
| modern browsers at least - every graphical browser I know with an
| "ignore CSS" option also has some form of "ignore colours" option. If
| the colour is truly part of the content then perhaps an image (with
| suitable text alternative) is the better way to provide the
| information?
So how should the image be done? Don't forget it will be background.
There may be an image and/or text placed over it.
|> And I'm not going to use "float:left" to layout a Chess board, either.
|
| I'd have thought a chess board was certainly tabular data.
It probably comes down to what people see as tabular and not tabular.
When I want to align a set of boxes to hold blocks of text, such as
news items, I tend to want the behaviour TABLE/TR/TD bring, rather
than the behaviour I get with DIV+float.
|> There are other cases where TABLE/TR/TD still beats DIV (and float)
|> to make a grid structure as desired. I'd rather do it with DIV, but
|> it just isn't capable, yet, for all that needs to be done.
|> TABLE/TR/TD still works better for certain things. It seems most
|> everyone agrees tabular data is to be done that way. But a lot of
|> other things that wouldn't really be called tabular data still need
|> the same grid structure semantics/effects, which is not possible
|> with DIV and float (again I say "yet" because I see the potential to
|> fix this).
|
| Does IE7 support 'position: table-*'? That gives much the same layout
| options but doesn't interfere with table-reading mode so much. (Of
| course, even if it does, it'll be a couple of years before it's
| generally usable)
I have no idea. No IE running here of any version right now.
phil-new...@ipal.net
| phil-new...@ipal.net wrote:
|> While CSS can do quite a lot, and can even do a lot of things that cannot
|> be done in just HTML, there remains a few things CSS cannot do. So it is
|> NOT yet time to say that HTML must be pure content.
|>
|> Just accept the fact that, as good as it is, CSS still needs work!
|
| Are you sure, you mean "CSS still needs work"? Not "CSS implementations
| need work"? WRT presentation of HTML tables (what I suspect you call
| grid), there is really a little stuff (rowspan/colspan) which cannot be
| done with CSS.
Show me CSS2 coding that will produce tables with the same semantics that
TABLE/TR/TD has, and maybe I could believe it's an implementatuon issue.
For another issue with CSS, take a block of text in a _single_ DIV element
and using CSS only, style that block so it appears with a drop shadow effect
without changing the HTML at all. I had to add extra DIV elements to get it
to work, and found that a couple other people doing the same thing did it
the same way (though I went a step further and added yet another DIV to make
an effect that raised and lowered the shadow effect based on hover). Better
CSS would allow doing anything like that wihtout changing HTML at all. If
the style needs more container context, then CSS should be able to logically
include that.
Here's one of the pages I was experimenting with:
http://phil.ipal.org/usenet/ciwas/2006-04-30/shadow-boxes-in-tables.html
Be careful with the top right and bottom left corners as they can result in
the raising/lowering effect oscillating if you position the pointer on the
pixels that move away.
W˙rm
<phil-new...@ipal.net> kirjoitti
viestissä:e33or...@news1.newsguy.com...
<snip>
> For another issue with CSS, take a block of text in a _single_ DIV element
> and using CSS only, style that block so it appears with a drop shadow
> effect
> without changing the HTML at all.
http://www.kolumbus.fi/ace/ng/box.html
Div with heading and paragraph of text inside. If you add more paragraphs it
needs tweaking though.
phil-new...@ipal.net
|
| <phil-new...@ipal.net> kirjoitti
| viestiss?:e33or...@news1.newsguy.com...
|
| <snip>
|
|> For another issue with CSS, take a block of text in a _single_ DIV element
|> and using CSS only, style that block so it appears with a drop shadow
|> effect
|> without changing the HTML at all.
|
| http://www.kolumbus.fi/ace/ng/box.html
|
| Div with heading and paragraph of text inside. If you add more paragraphs it
| needs tweaking though.
OK, different elements. Usable in the case of just needing those two.
Or maybe just any two. But my point is it's still two elements being
selected for in CSS. One should be able to do it all for one single
element since many other styles can be done that way.
Here's how I think it could be done in CSS. Some purists might whine
that it is, in effect, adding markup in CSS. First, you'd have a property
that specifies a number of virtual containers:
/* WARNING to stray readers - the following is NOT valid CSS */
.mybox {
virtual-containers: 2;
}
/* Then you'd configure them separately as needed: */
.mybox [0] {
background-color: #cccccc;
color: #000000;
margin-bottom: 10px;
}
.mybox [1] {
background-color: #ffffff;
color: inherit;
border: 0;
position: relative;
top: -4px;
left: -4px;
margin: 0;
padding: 0;
}
Then what's inside could be configured any way desired without even any
concern for the fact that it's in something that is being styled with a
drop shadow. The border could be added by the interior elements, if one
is desired, or this can be changed to add one here.
The idea is the markup does not need to be changed just to make a more
complex style. An implemention _may_ actually accomplish it my adding
extra markup in its DOM structure (whatever they prefer as programmers).
Johannes Koch
> Show me CSS2 coding that will produce tables with the same semantics that
> TABLE/TR/TD has, and maybe I could believe it's an implementatuon issue.
_Semantics_ are defined by HTML, not CSS: If you have tabular data and
so table semantics are appropriate, use the table element and its
companions. CSS however defines table-like _presentation_
characteristics. See the chapter about tables in the CSS 2(.1) spec.
Alan J. Flavell
> Show me CSS2 coding that will produce tables with the same semantics
> that TABLE/TR/TD has, and maybe I could believe it's an
> implementatuon issue.
You're not making any kind of sense. The defined semantics of HTML
are what the HTML specification (for all its faults and weaknesses)
defines them to be. They don't change merely by fiddling around with
implementations of CSS.
Chris Morris
> On 30 Apr 2006 19:26:38 +0100 Chris Morris <c.i.m...@durham.ac.uk> wrote:
> | Odd, most of the (real) chessboards I've seen are yellow and
> | black. Maybe it varies from place to place.
>
> I've seen a couple like that. But virtually all are red and black.
Maybe you should use CSS and let people select their own preferred
chess-board colours with alternative stylesheets. ;)
> |> if I am going to lay out a grid structure as a Chess board, you can
> |> bet I'm going to set the colors in the HTML tags.
> |
> | I can't imagine a situation where HTML-based colour setting would be
> | more reliable than CSS-based colour setting in such a situation, with
> | modern browsers at least - every graphical browser I know with an
> | "ignore CSS" option also has some form of "ignore colours" option. If
> | the colour is truly part of the content then perhaps an image (with
> | suitable text alternative) is the better way to provide the
> | information?
>
> So how should the image be done? Don't forget it will be background.
> There may be an image and/or text placed over it.
Well, again, CSS is not going to be more or less 'reliable' than HTML
at positioning and providing the image (though CSS has more options).
I'm having trouble thinking of a situation where you'd want a
background image of a chessboard (or a background grid in checkerboard
colours with the exact colour crucial) with text and images
superimposed. Could you give a bit more detailed example (with a URL
if you can) of the sort of thing you mean?
> |> And I'm not going to use "float:left" to layout a Chess board, either.
> |
> | I'd have thought a chess board was certainly tabular data.
>
> It probably comes down to what people see as tabular and not tabular.
Well, when I sketch chessboards out on paper, they end up as a grid
rather than linearised, which suggests a table. The 2-D relationship
of the squares and pieces is crucial to understanding the position.
> When I want to align a set of boxes to hold blocks of text, such as
> news items, I tend to want the behaviour TABLE/TR/TD bring, rather
> than the behaviour I get with DIV+float.
Whereas if I was writing a news item with a pencil (or for an email) I
probably wouldn't be so concerned with the layout as long as it was in
the right 1-D order.
That's not to say a set of news items can't be expressed sensibly in a
table - it depends how the data for each news item is divided.
> | Does IE7 support 'position: table-*'? That gives much the same layout
> | options but doesn't interfere with table-reading mode so much. (Of
> | course, even if it does, it'll be a couple of years before it's
> | generally usable)
>
> I have no idea. No IE running here of any version right now.
Well, if IE is out of the equation, and you only want the grid for
visual presentation, you might as well use position: table-*
--
Chris
Charles Allen
>|> is the red and black colors of a Chess board. Sure, someone could
>| Odd, most of the (real) chessboards I've seen are yellow and
>| black. Maybe it varies from place to place.
> I've seen a couple like that. But virtually all are red and black.
Standard colors are off-white and green and off-white and brown.
Having "black" as the dark color is allowed, but many players feel
that gives too little contrast between the dark pieces and the dark
squares.
From <http://www.fide.com/> in the Info section you can find the FIDE
recommendations for boards:
3. Chess boards
Wood, plastic, cardboard or cloth are recommended as material for
chessboards. The board may also be of stone or marble with
appropriate light and dark colours, provided the Chief Arbiter
finds it acceptable. Natural wood with sufficient contrast, such
as birch, maple or European ash against walnut, teak, beech,
etc., may also be used for boards, which must have a dull or
neutral finish, never shiny.
Combination of colours such as brown, green, or very light tan
and white, cream, off-white ivory, buff, etc., may be used for
the chess squares in addition to natural colours.
Now back to our actual newsgroup topic.
--
NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth
phil-new...@ipal.net
| phil-new...@ipal.net wrote:
|> Show me CSS2 coding that will produce tables with the same semantics that
|> TABLE/TR/TD has, and maybe I could believe it's an implementatuon issue.
|
| _Semantics_ are defined by HTML, not CSS: If you have tabular data and
| so table semantics are appropriate, use the table element and its
| companions. CSS however defines table-like _presentation_
| characteristics. See the chapter about tables in the CSS 2(.1) spec.
It probably comes down to the fact that my intentions in a grid structure
do match the semantics of a table and tabular data, despite that it may
not appear that way to people that tell me to not use the table element.
phil-new...@ipal.net
| phil-new...@ipal.net writes:
|> On 30 Apr 2006 19:26:38 +0100 Chris Morris <c.i.m...@durham.ac.uk> wrote:
|> | Odd, most of the (real) chessboards I've seen are yellow and
|> | black. Maybe it varies from place to place.
|>
|> I've seen a couple like that. But virtually all are red and black.
|
| I'm not sure I've seen any red and black ones.
|
| Maybe you should use CSS and let people select their own preferred
| chess-board colours with alternative stylesheets. ;)
Fine. Show how.
|> |> if I am going to lay out a grid structure as a Chess board, you can
|> |> bet I'm going to set the colors in the HTML tags.
|> |
|> | I can't imagine a situation where HTML-based colour setting would be
|> | more reliable than CSS-based colour setting in such a situation, with
|> | modern browsers at least - every graphical browser I know with an
|> | "ignore CSS" option also has some form of "ignore colours" option. If
|> | the colour is truly part of the content then perhaps an image (with
|> | suitable text alternative) is the better way to provide the
|> | information?
|>
|> So how should the image be done? Don't forget it will be background.
|> There may be an image and/or text placed over it.
|
| Well, again, CSS is not going to be more or less 'reliable' than HTML
| at positioning and providing the image (though CSS has more options).
But how well can CSS choose which squares to color? If the browser
supports :first-child then you can color the top and left ones different.
| I'm having trouble thinking of a situation where you'd want a
| background image of a chessboard (or a background grid in checkerboard
| colours with the exact colour crucial) with text and images
| superimposed. Could you give a bit more detailed example (with a URL
| if you can) of the sort of thing you mean?
You want to color in CSS. Be my guest. Show how. But show CSS that
can be used with any chess board in tables where only the table element
has a class on it.
|> |> And I'm not going to use "float:left" to layout a Chess board, either.
|> |
|> | I'd have thought a chess board was certainly tabular data.
|>
|> It probably comes down to what people see as tabular and not tabular.
|
| Well, when I sketch chessboards out on paper, they end up as a grid
| rather than linearised, which suggests a table. The 2-D relationship
| of the squares and pieces is crucial to understanding the position.
However, the "CSS people" still often whine about the use of tables
for stuff that needs to be 2-D.
|> When I want to align a set of boxes to hold blocks of text, such as
|> news items, I tend to want the behaviour TABLE/TR/TD bring, rather
|> than the behaviour I get with DIV+float.
|
| Whereas if I was writing a news item with a pencil (or for an email) I
| probably wouldn't be so concerned with the layout as long as it was in
| the right 1-D order.
|
| That's not to say a set of news items can't be expressed sensibly in a
| table - it depends how the data for each news item is divided.
Within an item, sure, it would basically be 1-D. But when categorizing
items, and ordering them by some priority or date, then you may want a
grid structure. And tables seems nature for it.
|> | Does IE7 support 'position: table-*'? That gives much the same layout
|> | options but doesn't interfere with table-reading mode so much. (Of
|> | course, even if it does, it'll be a couple of years before it's
|> | generally usable)
|>
|> I have no idea. No IE running here of any version right now.
|
| Well, if IE is out of the equation, and you only want the grid for
| visual presentation, you might as well use position: table-*
The table/tr/td elements are still needed to markup what content goes in
which cell. At that point, it works fine so I don't see the need for a
position property.
phil-new...@ipal.net
Of course it doesn't make sense. It was to get people to think about
the fact that it actually cannot be done (the same way) in CSS2.
Steve Pugh
>On 01 May 2006 12:41:20 +0100 Chris Morris <c.i.m...@durham.ac.uk> wrote:
>
>| I'm having trouble thinking of a situation where you'd want a
>| background image of a chessboard (or a background grid in checkerboard
>| colours with the exact colour crucial) with text and images
>| superimposed. Could you give a bit more detailed example (with a URL
>| if you can) of the sort of thing you mean?
>
>You want to color in CSS. Be my guest. Show how. But show CSS that
>can be used with any chess board in tables where only the table element
>has a class on it.
A somewhat artificial restriction but here you go:
http://steve.pugh.net/test/chessboard.html
Works in Opera and FireFox and IE7, I presume it will work in Safari.
As in many situations, IE6 and lower are the problem, not the CSS
spec.
The amount of code can be reduce consideranly if you would allow
classes to be set on the <tr> elements.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st...@pugh.net> <http://steve.pugh.net/>
Neredbojias
vouchsafed:
>>You want to color in CSS. Be my guest. Show how. But show CSS that
>>can be used with any chess board in tables where only the table
>>element has a class on it.
>
> A somewhat artificial restriction but here you go:
>
> http://steve.pugh.net/test/chessboard.html
>
> Works in Opera and FireFox and IE7, I presume it will work in Safari.
>
> As in many situations, IE6 and lower are the problem, not the CSS
> spec.
Very clever! Simple but sound. I like it.
--
Neredbojias
Infinity has its limits.
Chris Morris
> On 01 May 2006 12:41:20 +0100 Chris Morris <c.i.m...@durham.ac.uk> wrote:
> | Maybe you should use CSS and let people select their own preferred
> | chess-board colours with alternative stylesheets. ;)
>
> Fine. Show how.
type="text/css">
(where cbcolours.css is a script that parses the colours and returns a
stylesheet, and the above <link> is also generated via scripting)
Use of rel="alternate stylesheet" could let you do it without any
scripting if you used only a few possible colour schemes.
> | Well, again, CSS is not going to be more or less 'reliable' than HTML
> | at positioning and providing the image (though CSS has more options).
>
> But how well can CSS choose which squares to color? If the browser
> supports :first-child then you can color the top and left ones different.
Well, if you were doing it with HTML you'd have to colour each cell
individually anyway, so you don't lose anything by using CSS and you
gain only having to change two values instead of 64 if you decide to
use different colours.
(and of course there is a solution in another post even given the
restriction of not individually classing table cells)
> | Well, when I sketch chessboards out on paper, they end up as a grid
> | rather than linearised, which suggests a table. The 2-D relationship
> | of the squares and pieces is crucial to understanding the position.
>
> However, the "CSS people" still often whine about the use of tables
> for stuff that needs to be 2-D.
People have different views on what is best expressed 2-D and what is
best expressed 1-D. There's a grey area in which it would work either
way, definitely.
It doesn't help that the occasional person (as seen in the group
archives) interprets "don't use tables for layout" as "don't use
tables" or "don't use tables to lay out data with a relationship
between the rows and columns"
> | Whereas if I was writing a news item with a pencil (or for an email) I
> | probably wouldn't be so concerned with the layout as long as it was in
> | the right 1-D order.
> |
> | That's not to say a set of news items can't be expressed sensibly in a
> | table - it depends how the data for each news item is divided.
>
> Within an item, sure, it would basically be 1-D. But when categorizing
> items, and ordering them by some priority or date, then you may want a
> grid structure. And tables seems nature for it.
I assume you mean something like
<table>
<thead><tr><th>Date</th><th>Title</th><th>Article<th></tr></thead>
<tbody>...<!-- 1 news article per row -->...</tbody>
</table>
(exact column headings and even if the <thead> block needs to be
explicitly displayed varying depending on exactly what you're doing,
of course)
I don't think there's anything wrong with that (although if the full
text of the news articles was being included in the table, I'd
probably do it differently unless the full text was very short)
--
Chris
W˙rm
<phil-new...@ipal.net> kirjoitti
viestissä:e35fi...@news2.newsguy.com...
<snip>
> It probably comes down to the fact that my intentions in a grid structure
> do match the semantics of a table and tabular data.
If it's tabular data, use table. It's that simple.
If table is just there to do layout certain way when data is _NOT tabular_,
don't, there are almost certainly better ways to do that layout.
<snip>
phil-new...@ipal.net
| phil-new...@ipal.net wrote:
|>On 01 May 2006 12:41:20 +0100 Chris Morris <c.i.m...@durham.ac.uk> wrote:
|>
|>| I'm having trouble thinking of a situation where you'd want a
|>| background image of a chessboard (or a background grid in checkerboard
|>| colours with the exact colour crucial) with text and images
|>| superimposed. Could you give a bit more detailed example (with a URL
|>| if you can) of the sort of thing you mean?
|>
|>You want to color in CSS. Be my guest. Show how. But show CSS that
|>can be used with any chess board in tables where only the table element
|>has a class on it.
|
| A somewhat artificial restriction but here you go:
|
| http://steve.pugh.net/test/chessboard.html
That's gross!
| Works in Opera and FireFox and IE7, I presume it will work in Safari.
|
| As in many situations, IE6 and lower are the problem, not the CSS
| spec.
|
| The amount of code can be reduce consideranly if you would allow
| classes to be set on the <tr> elements.
Well, I wanted it to be able to handle whatever size chess board that
happens to be in the HTML. I should have said it in such a way.
I think it comes down to whether identifying that specific positions
have specific colors is a matter of content or style or ... layout.
I just don't accept that the dividing line between CSS and HTML is
really at where the theoretical dividing line between style and content
would be.
Steve Pugh
>On Mon, 01 May 2006 19:29:26 +0100 Steve Pugh <st...@pugh.net> wrote:
>| phil-new...@ipal.net wrote:
>|>On 01 May 2006 12:41:20 +0100 Chris Morris <c.i.m...@durham.ac.uk> wrote:
>|>
>|>| I'm having trouble thinking of a situation where you'd want a
>|>| background image of a chessboard (or a background grid in checkerboard
>|>| colours with the exact colour crucial) with text and images
>|>| superimposed. Could you give a bit more detailed example (with a URL
>|>| if you can) of the sort of thing you mean?
>|>
>|>You want to color in CSS. Be my guest. Show how. But show CSS that
>|>can be used with any chess board in tables where only the table element
>|>has a class on it.
>|
>| A somewhat artificial restriction but here you go:
>|
>| http://steve.pugh.net/test/chessboard.html
>
>That's gross!
I aim to please.
The HTML is as elegant a representation of a chessboard as you'll get.
The CSS is overly verbose because of your desire to avoid classes on
everything except the table element.
However, that one "gross" piece of CSS can provide the colouring for
all the chess boards on your site. If you have a chess site that will
be a large number and the saving in filesize over putting the colours
inline in every cell (as HTML or inline CSS) will be noticeable. Ditto
the ease of changing the colours ('cos everyone loves green and white
chessboards on St Patrrick's Day...) or allowing users to choose their
own colour scheme from alternate stylesheets.
With CSS 3 :nth-child selectors the CSS would be much tidier.
http://www.w3.org/TR/css3-selectors/#nth-child-pseudo
Browser support doesn't exist at the moment but you can see how much
more compact the code would be:
http://steve.pugh.net/test/chessboard2.html
>| Works in Opera and FireFox and IE7, I presume it will work in Safari.
>|
>| As in many situations, IE6 and lower are the problem, not the CSS
>| spec.
>|
>| The amount of code can be reduce consideranly if you would allow
>| classes to be set on the <tr> elements.
>
>Well, I wanted it to be able to handle whatever size chess board that
>happens to be in the HTML. I should have said it in such a way.
Oh well, just move the sizing out of the
table.board th, table.border td {width: 5em; height: 5em; text-align:
center; vertical-align: middle;}
style and into one that uses a different class name. Then you table
can have two class names
e.g. <table class="board thumbnail"> or <table class="board detailed">
with the sizes specified in these second classes.
>I think it comes down to whether identifying that specific positions
>have specific colors is a matter of content or style or ... layout.
The exact colour values are style - as demonstrated elsewhere in this
thread boards come in different colour combinations and hence there's
the colours used are not intrinsic to the fact that it is a chees
board. So they belong in the CSS.
I've also seen chess boards that do not use two colours - just a grid
pattern. The colours are merely a convenient visual aid and a game of
chess can be played without reference to the colours at all.
But if you are willing to put classes on each table cell then you can
assign colours (and easily reassign them) via a stylesheet without
needing to work with those gross (and IE6 unsupported) adjacent
selectors.
>I just don't accept that the dividing line between CSS and HTML is
>really at where the theoretical dividing line between style and content
>would be.
The fact that a chessboard is an 8x8 grid is structure.
The fact that alternating squares are in some way different could be
considered borderline between structure and style.
The fact that these alternating squares happen to be white and black,
or red and black, or whatever is style.
So use HTML tables; class names; CSS. for those three levels.
phil-new...@ipal.net
| phil-new...@ipal.net writes:
|> On 01 May 2006 12:41:20 +0100 Chris Morris <c.i.m...@durham.ac.uk> wrote:
|> | Maybe you should use CSS and let people select their own preferred
|> | chess-board colours with alternative stylesheets. ;)
|>
|> Fine. Show how.
|
| <link rel="stylesheet" href="cbcolours.css?c1=ff0000;c2=000000"
| type="text/css">
| (where cbcolours.css is a script that parses the colours and returns a
| stylesheet, and the above <link> is also generated via scripting)
|
| Use of rel="alternate stylesheet" could let you do it without any
| scripting if you used only a few possible colour schemes.
|
|> | Well, again, CSS is not going to be more or less 'reliable' than HTML
|> | at positioning and providing the image (though CSS has more options).
|>
|> But how well can CSS choose which squares to color? If the browser
|> supports :first-child then you can color the top and left ones different.
|
| Well, if you were doing it with HTML you'd have to colour each cell
| individually anyway, so you don't lose anything by using CSS and you
| gain only having to change two values instead of 64 if you decide to
| use different colours.
You can be sure that changing the colors in HTML is easy and simple.
It's called substitution in an editor. And if that's not enough, one
can use a variable in PHP.
But that's all beyond the point.
CSS has to know more about the layout than simply a classified set of
elements. It has to know the nesting relationship in so many cases.
That's layout. Why should it be cross mixed in both style and content?
In all likelihood I would color a chessboard with CSS, but not because
it is theoretically the right way, but because it's a practical way.
> However, the "CSS people" still often whine about the use of tables
|> for stuff that needs to be 2-D.
|
| People have different views on what is best expressed 2-D and what is
| best expressed 1-D. There's a grey area in which it would work either
| way, definitely.
|
| It doesn't help that the occasional person (as seen in the group
| archives) interprets "don't use tables for layout" as "don't use
| tables" or "don't use tables to lay out data with a relationship
| between the rows and columns"
How about something as simple as having a web page divided up into
3 major columns, and NOT wanting the rightmost column to fall down
underneath if the browser width is squeezed?
Tables do work when what is desired is some degree of rigidity.
Floats work great for other things in ways tables could never do.
|> Within an item, sure, it would basically be 1-D. But when categorizing
|> items, and ordering them by some priority or date, then you may want a
|> grid structure. And tables seems nature for it.
|
| I assume you mean something like
| <table>
| <thead><tr><th>Date</th><th>Title</th><th>Article<th></tr></thead>
| <tbody>...<!-- 1 news article per row -->...</tbody>
| </table>
| (exact column headings and even if the <thead> block needs to be
| explicitly displayed varying depending on exactly what you're doing,
| of course)
I was thinking more along the lines of:
<table>
<thead><tr>
<th>Category 1</th>
<th>Category 2</th>
<th>Category 3</th>
<th>Category 4</th>
</tr></thead>
<tbody><tr>
<td>
Article 1 in Category 1<hr>
Article 2 in Category 1<hr>
Article 3 in Category 1
</td>
<td>
Article 1 in Category 2<hr>
Article 2 in Category 2<hr>
Article 3 in Category 2
</td>
<td>
Article 1 in Category 3<hr>
Article 2 in Category 3<hr>
Article 3 in Category 3<hr>
Article 4 in Category 3
</td>
<td>
Article 1 in Category 4<hr>
Article 2 in Category 4<hr>
Article 3 in Category 4
</td>
</tr></tbody>
</table>
The <hr> between articles in an arbitrary example. In this case I want
the columns all lined up prefectly. But the Nth article in one column
does not need to be exactly beside the Nth article in another column.
| I don't think there's anything wrong with that (although if the full
| text of the news articles was being included in the table, I'd
| probably do it differently unless the full text was very short)
The text can vary since the flow is the full length of the columns.
phil-new...@ipal.net
|
| <phil-new...@ipal.net> kirjoitti
|
| <snip>
|
|> It probably comes down to the fact that my intentions in a grid structure
|> do match the semantics of a table and tabular data.
|
| If it's tabular data, use table. It's that simple.
I cannot say that it _is_ tabular data. I can say that it needs the
same _behaviour_ as tabular data.
| If table is just there to do layout certain way when data is _NOT tabular_,
| don't, there are almost certainly better ways to do that layout.
But until I find what better way there is, I'll leave it in a table.
Anyone wanting to urge me to not use a table must not only suggest what
alternative to use, but needs to also verify that the alternative fits
all the needs I have that make the table element a practical choice.
I do know that what a lot of people _think_ a lot of other people intend
with tables can be done with float. For many things it can (examples I
see on pages urging not to use tables show cases where float works fine).
But for many things (they didn't show these ... wonder why) it cannot.
One example is a smaller browser window or large font that pushes cells
off to the next row, thus mangling the grid structure. The examples in
http://www.realworldstyle.com/thumb_float.html
show cells that fall down to the next row. That's not a grid structure.
Johannes Koch
> On Tue, 2 May 2006 00:49:04 +0300 "W?rm" <nomails...@north.invalid> wrote:
> | If it's tabular data, use table. It's that simple.
>
> I cannot say that it _is_ tabular data. I can say that it needs the
> same _behaviour_ as tabular data.
Then the HTML table elements would not be appropriate. But you could use
the CSS table stuff. Don't blame CSS for not offering presentation
characteristics you need, when in fact it's some user agent(s) that
lack(s) implementation.
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
W˙rm
<phil-new...@ipal.net> kirjoitti
viestissä:e370m...@news3.newsguy.com...
<snip>
> I cannot say that it _is_ tabular data. I can say that it needs the
> same _behaviour_ as tabular data.
If it's that your linux site (or do I think other person?, it might be very
possible, been up too long and too many beers)...
LIST of links... In one way tabular data, but more closer to list of
links...
So DIV with heading and list of links, three columns split in 3 divs
floated, and in each column those div boxes with heading + list of links...
If I assumed / thought site wrong, well, not up and running at the moment,
more like near requiring resurrection...
<snip>
Chris Sharman
> phil-new...@ipal.net wrote:
>> On 01 May 2006 12:41:20 +0100 Chris Morris <c.i.m...@durham.ac.uk> wrote:
>>
>> | I'm having trouble thinking of a situation where you'd want a
>> | background image of a chessboard (or a background grid in checkerboard
>> | colours with the exact colour crucial) with text and images
>> | superimposed. Could you give a bit more detailed example (with a URL
>> | if you can) of the sort of thing you mean?
>>
>> You want to color in CSS. Be my guest. Show how. But show CSS that
>> can be used with any chess board in tables where only the table element
>> has a class on it.
>
> A somewhat artificial restriction but here you go:
>
> http://steve.pugh.net/test/chessboard.html
>
> Works in Opera and FireFox and IE7, I presume it will work in Safari.
>
> As in many situations, IE6 and lower are the problem, not the CSS
> spec.
I agree, it's gross.
And anything that doesn't work in ie5/6 is sadly not a viable solution
for www. Commercial reality dictates that pages must work on ie6, and
preferably ie5 too.
What's wrong with classes light & dark (or similar) on the td tags ?
This is a fairly pathological example in any case. It's more common in
my experience to want to colour rows or columns, enabling the classes to
be moved out to tr or col, for more concise html.
Chris
Alan J. Flavell
> I agree, it's gross.
Yes, but I found it quite entertaining. I suspect that it's possible
to halve the quantity of CSS without having to work too hard, but
it's still gross..
> And anything that doesn't work in ie5/6 is sadly not a viable
> solution for www.
In the sense that CSS is optional by design, it "works" to
specification in IE. It's just that IE chooses not to take the
option. No more would the presentation effect be distinguishable on a
speaking browser, after all, nor on any browser with stylesheets
disabled.
However, it's arguable (and has indeed been argued both ways already
on this thread, and I'm not going to say that either standpoint was
wrong) that in this case the cell colour is part of the content,
rather than being merely presentational.
> This is a fairly pathological example in any case. It's more common
> in my experience to want to colour rows or columns, enabling the
> classes to be moved out to tr or col, for more concise html.
Well, it is - but have you found a way *according to specification*
to get your class to propagate from a <col> element to its column
cells?
Cells are not descendants of a col/colgroup element. You can't
usefully write selectors of the form
*WRONG* col.odd row.odd, col.even row.even { something }
*WRONG* col.even row.odd, col.odd row.even { somethingelse }
(Aside - Some browsers propagate more properties from a col/colgroup
element than the specification says they should, but it would be wrong
to rely on that behaviour.)
http://www.w3.org/TR/CSS21/tables.html#q4
Your column colour can only be effective if the rows *and* the cells
specify (or imply) transparent backgrounds. That's fine if all the
rows in a given column are to be the same colour; but it's a bit of a
non-event if you want to make checkerboard patterns.
cheers
Steve Pugh
>
>> I agree, it's gross.
>
>Yes, but I found it quite entertaining. I suspect that it's possible
>to halve the quantity of CSS without having to work too hard, but
>it's still gross..
Hmm, how insulted should I be by everyone calling it gross? :-o
It was a quickly thrown together demo to show that even with the
highly artificial constraint of only setting a class on the table
element CSS could do what was being asked. In reality I would use more
classes and dream about the days when CSS3 :nth-child selectors are
supported.
As for halving the amount of CSS. What did you have in mind? I
considered setting a default cell colour and the over riding that for
particular cells. But as td+td matches the second and subsequent cells
that seemed to be a dead end.
The two sets of colour styles can be combined into one, but that
hardly saves anything as it's the selectors that make the bulk, not
the properties. This would be the way to go if you wanted to make it
so that each of the colours could be changed in just one place.
>http://www.w3.org/TR/CSS21/tables.html#q4
>
>Your column colour can only be effective if the rows *and* the cells
>specify (or imply) transparent backgrounds. That's fine if all the
>rows in a given column are to be the same colour; but it's a bit of a
>non-event if you want to make checkerboard patterns.
There's also the fact that background is supported but color is not
which means that any colouring done via columns will break the best
practice rule of setting colour and background together.
Alan J. Flavell
> As for halving the amount of CSS. What did you have in mind? I
> considered setting a default cell colour and the over riding that for
> particular cells.
Something along those lines, indeed.
> But as td+td matches the second and subsequent cells
> that seemed to be a dead end.
The trick, as far as the rows is concerned, is to note that they all
start with a th.
So th+td matches precisely the first data cell,
th+td+td matches the second, and so on.
You get similar effects with the rows, however, so you need
some way to anchor the sectors which currently say tr+tr and so on.
> >http://www.w3.org/TR/CSS21/tables.html#q4
> >
> >Your column colour can only be effective if the rows *and* the
> >cells specify (or imply) transparent backgrounds. That's fine if
> >all the rows in a given column are to be the same colour; but it's
> >a bit of a non-event if you want to make checkerboard patterns.
>
> There's also the fact that background is supported but color is not
> which means that any colouring done via columns will break the best
> practice rule of setting colour and background together.
True.
Now, here's something odd that I pondered on:
Unicode has two sets of chess pieces, called "white" and "black".
See the set at e.g
http://ppewww.ph.gla.ac.uk/~flavell/unicode/unidata26.html#x2654
(assuming you have a capable font).
If you exhibit them on a black background, they disappear (not
surprisingly).
If you style a "black" one white, on a black background, then it
looks like a white piece.
Which leaves only the "white" one, styled white, to represent the
black piece on a black background.
http://ppewww.ph.gla.ac.uk/~flavell/tests/chessfun.html
This would surely be confusing content with presentation ;-)
din...@codesmiths.com
phil-new...@ipal.net wrote:
> Is there really any advantage to using DIV elements with float style
> properies, vs. the old method of TABLE and TR and TD?
No, of course not. You might not even need float, as CSS has
table-specific formatting properties too.
The real question is "Is an inflexible rectilinear grid mechanism the
right way to do layout, and particularly fluid layout?". If you
rigidly replicate <table> behaviour with <div>+CSS, then you're still
no better than HTML 2.0 pure-tables.
Steve Pugh
>
>> As for halving the amount of CSS. What did you have in mind? I
>> considered setting a default cell colour and the over riding that for
>> particular cells.
>
>Something along those lines, indeed.
>
>> But as td+td matches the second and subsequent cells
>> that seemed to be a dead end.
>
>The trick, as far as the rows is concerned, is to note that they all
>start with a th.
>
>So th+td matches precisely the first data cell,
> th+td+td matches the second, and so on.
Cunning.
>You get similar effects with the rows, however, so you need
>some way to anchor the sectors which currently say tr+tr and so on.
tr:first-child+tr perhaps?
Steve Pugh
>"Alan J. Flavell" <fla...@physics.gla.ac.uk> wrote:
>>On Tue, 2 May 2006, Steve Pugh wrote:
>>
>>> As for halving the amount of CSS. What did you have in mind? I
>>> considered setting a default cell colour and the over riding that for
>>> particular cells.
>>
>>Something along those lines, indeed.
>>
>>> But as td+td matches the second and subsequent cells
>>> that seemed to be a dead end.
>>
>>The trick, as far as the rows is concerned, is to note that they all
>>start with a th.
>>
>>So th+td matches precisely the first data cell,
>> th+td+td matches the second, and so on.
>
>Cunning.
>
>>You get similar effects with the rows, however, so you need
>>some way to anchor the sectors which currently say tr+tr and so on.
>
>tr:first-child+tr perhaps?
Yep. http://steve.pugh.net/test/chessboard3.html
Still 'gross' though.
Martin Eyles
news:e33tje$r7n$1...@phys-news4.kolumbus.fi...
>
> <phil-new...@ipal.net> kirjoitti
> viestissä:e33or...@news1.newsguy.com...
>
> <snip>
>
>> For another issue with CSS, take a block of text in a _single_ DIV
>> element
>> and using CSS only, style that block so it appears with a drop shadow
>> effect
>> without changing the HTML at all.
>
> http://www.kolumbus.fi/ace/ng/box.html
>
> Div with heading and paragraph of text inside. If you add more paragraphs
> it needs tweaking though.
There are two ways of doing this.
The first is the ideal way - but doesn't work in anything due to the use of
:first-child
.mybox
{
width: 200px;
background-color: #c0c0c0;
color: #000000;
margin-bottom: 10px;
}
.mybox > *
{
background-color: #ffffff;
color: inherit;
border: 1px solid #000000;
border-top: none;
position: relative;
top: -4px;
left: -4px;
margin: 0;
padding: 0;
}
.mybox:first-child
{
background-color: #e0e0ff;
border-top: 1px solid #000000;
color: inherit;
}
The second version will work in firefox fine (certainly 1.5, not sure about
1.0), but still not in IE6 (not sure about IE7)
.mybox
{
width: 200px;
background-color: #c0c0c0;
color: #000000;
margin-bottom: 10px;
}
.mybox > *
{
background-color: #e0e0ff;
color: inherit;
border: 1px solid #000000;
position: relative;
top: -4px;
left: -4px;
margin: 0;
padding: 0;
}
.mybox > * + *
{
border-top: none;
background-color: #ffffff;
color: inherit;
}
Still, I think the original link is the best cross browser method available
at the moment, but I just wanted to show how things might be in the brighter
future. :-)
ME
Martin Eyles
news:Pine.LNX.4.64.06...@ppepc87.ph.gla.ac.uk...
> Now, here's something odd that I pondered on:
>
> Unicode has two sets of chess pieces, called "white" and "black".
> See the set at e.g
> http://ppewww.ph.gla.ac.uk/~flavell/unicode/unidata26.html#x2654
> (assuming you have a capable font).
>
> If you exhibit them on a black background, they disappear (not
> surprisingly).
>
> If you style a "black" one white, on a black background, then it
> looks like a white piece.
>
> Which leaves only the "white" one, styled white, to represent the
> black piece on a black background.
>
> http://ppewww.ph.gla.ac.uk/~flavell/tests/chessfun.html
>
> This would surely be confusing content with presentation ;-)
I can't see those characters in my browser (firefox 1.5 on windows server
2003). I just get question marks instead. Is there a way to fix that - eg.
changing fonts?
Anyway, one way round this problem I would think would be to use spans or
divs to contain the chess pieces, and use css content. I would expect it to
work in firefox. I you were able to turn than into an example page showing
all the chess pieces on the chess board in starting places I'd be pretty
impressed.
eg.
_html_
<td><div class="black king"></div></td>
_style (I am only using round brackets () to denote shorthand)_
black king {content: '♚'}
(css for a black square) > black king {content: '♔'; colour: white}
Alan J. Flavell
[...]
> > http://ppewww.ph.gla.ac.uk/~flavell/tests/chessfun.html
> >
> > This would surely be confusing content with presentation ;-)
>
> I can't see those characters in my browser (firefox 1.5 on windows
> server 2003). I just get question marks instead. Is there a way to
> fix that - eg. changing fonts?
If you have MS Office, or other eligible application, then it's worth
installing Arial Unicode MS from it. SIL Viewglyph, at any rate,
tells me that the glyphs are present there. AFAIK this font still does
not come free with any bare OS, but many MS products have it included.
The glyphs are also present in the shareware unicode font "Code2000"
which a web search should easily find.
Unfortunately I don't really know how to ask the Windows font system
the question "which of my installed fonts contain this specific
Unicode character?". I only know how to browse a given font (e.g with
SIL Viewglyph) and see whether it does or not. At any rate, "Lucida
Sans Unicode", which has a fair character repertoire, and comes as
standard with current Windows OSes, does not contain the chess pieces
(though it does contain the four card suits, in black - U+2660, 3, 5
and 6).
I found, incidentally, that installing Japanese language support (even
though I can't read it) had the side effect of considerably improving
my coverage of mathematical operators and various other symbols.
See e.g http://www.alanwood.net/unicode/fontsbyrange.html#u2600
which may explain it - Windows is presumably installing extra fonts
which just /happen/ also to have improved symbol repertoires.
> Anyway, one way round this problem I would think would be to use
> spans or divs to contain the chess pieces, and use css content. I
> would expect it to work in firefox. I you were able to turn than
> into an example page showing all the chess pieces on the chess board
> in starting places I'd be pretty impressed.
So would I - but it would be an even *worse* example of confuddling
content with presentation!
cheers
--
The only problem I had with MSN messenger was finding out how to turn it
off. Once that was accomplished, I was a lot happier. - Chris Tolley
phil-new...@ipal.net
| This is a fairly pathological example in any case. It's more common in
| my experience to want to colour rows or columns, enabling the classes to
| be moved out to tr or col, for more concise html.
The more common problem I see is in so many examples available online,
the CSS must be coded for a specific number of rows or columns. What
I want is CSS that works just fine regardless of how many rows and/or
columns there are.
And I want CSS that lets me do hover bouncing drop shadows without having
to change the markup to accomodate it. The problem is, all examples I
have seen show extra DIV or other elements added to prove a mechanism to
implement the visual effect style. IMHO, whatever style I want to do
should be appliable to exactly a single element in the markup (for each
such element to which it applies, of course).
I was just looking at online examples of rounded corners. Ewww, more
horrors with large images and size limitations. But I need to spend some
time on trying to better innovate that myself, first, before I say it is
a CSS problem.
phil-new...@ipal.net
| "Alan J. Flavell" <fla...@physics.gla.ac.uk> wrote:
|>On Tue, 2 May 2006, Chris Sharman wrote:
|>
|>> I agree, it's gross.
|>
|>Yes, but I found it quite entertaining. I suspect that it's possible
|>to halve the quantity of CSS without having to work too hard, but
|>it's still gross..
|
| Hmm, how insulted should I be by everyone calling it gross? :-o
It's not an insult. Lots of my (developed long ago) HTML is certainly
quite gross, and recognized as such even back then. I'm looking for
CSS methods to do what I've done in the past in purely HTML, with the
requirement that the end results be at least just as good. I'm not
willing to take even one tiny step backwards to achieve results since
I know I can step back to the (ugly and gross) HTML and still have it.
If your example is gross, but turns out to be the only way to make it
work, then it's a go, anyway. But if there's a better way, we ought
try to find it.
| It was a quickly thrown together demo to show that even with the
| highly artificial constraint of only setting a class on the table
| element CSS could do what was being asked. In reality I would use more
| classes and dream about the days when CSS3 :nth-child selectors are
| supported.
Turns out the chess board example was a bad example to begin with.
I should try to think up something else.
But today, I'm playing with rounded corners and seeing what I can do to
get them working in CSS as well as I had them working in just HTML.
Google found me plenty of online examples, but so far all of them seem
to be using elongated images ... e.g. images that include a stretch of
the sides as well, for at least some of them. Some strategies differ,
but it all seems to be yet another case of the stylesheets having to
specify some of the mechanics of layout to achieve a style result.
In other words, I still have to add extra elements to the markup as
the hooks CSS needs.
I think maybe tables will work (in a simpler way, of course) to do this
with CSS as well.
phil-new...@ipal.net
| phil-new...@ipal.net wrote:
|> On Tue, 2 May 2006 00:49:04 +0300 "W?rm" <nomails...@north.invalid> wrote:
|> | If it's tabular data, use table. It's that simple.
|>
|> I cannot say that it _is_ tabular data. I can say that it needs the
|> same _behaviour_ as tabular data.
|
| Then the HTML table elements would not be appropriate. But you could use
| the CSS table stuff. Don't blame CSS for not offering presentation
| characteristics you need, when in fact it's some user agent(s) that
| lack(s) implementation.
Why would there be 2 different non-depricated mechanisms in the standards
that accomplish exactly the same thing?
"A table of numbers from a spread sheet"
"A table of images" (note, NOT use of tables to mosaic the images together)
"A table of whatever stuff you want to have a table of"
I don't see why different mechanisms have to be used when the concept of
how it is organized is the same regardless of the contents.
I'll use what works. When I want to get a web site done, I'm not going
to be a standards purist when the implementations aren't keeping up.
The "web standards" community for years did little or nothing to help
get browsers usable so the new standards could even be widely used.
Netscape went all to hell in version 4 and until Firefox 1.5, there was
plenty of reason to stay behind in browsers (and for plenty of reasons
beyond the scope of compliance with standards). I asked certain people
who were prominant in the "web standards" community to help by pushing
hard (in a public way) to get browsers fixed. But instead, all they
would do is stress how important web standards were. And that turned
a lot of people off.
Blaming CSS would not be right if the standards provide for a way to do
regardless of what implementations may or may not. Of course it would
be nice to have a list of what features don't work (or work wrong) in
which browsers.
Firefox is available for the major platforms. IE is not. If I have to
tell someone to use another browser, it's going to be Firefox. At least
I now have that option. So the big question is, how well does Firefox
implement CSS? It seems to be working fairly well. Who has IE7 to show
and tell?
phil-new...@ipal.net
| So DIV with heading and list of links, three columns split in 3 divs
| floated, and in each column those div boxes with heading + list of links...
How to keep the columns from floating down to the bottom when the window
is narrower?
Johannes Koch
> On Tue, 02 May 2006 09:54:54 +0200 Johannes Koch <ko...@w3development.de> wrote:
> | Then the HTML table elements would not be appropriate. But you could use
> | the CSS table stuff. Don't blame CSS for not offering presentation
> | characteristics you need, when in fact it's some user agent(s) that
> | lack(s) implementation.
>
> Why would there be 2 different non-depricated mechanisms in the standards
> that accomplish exactly the same thing?
Because they are two different things: One (HTML tables) is markup for
tabular data. E.g. it includes the "Table rendering by non-visual user
agents" (HTML 4.01, section 11.4). The other (CSS table presentation
model) is just for presenting content in a certain way (a grid).
--
Johannes Koch
Spem in alium nunquam habui praeter in te, Deus Israel.
(Thomas Tallis, 40-part motet)
phil-new...@ipal.net
| phil-new...@ipal.net wrote:
|> On Tue, 02 May 2006 09:54:54 +0200 Johannes Koch <ko...@w3development.de> wrote:
|> | Then the HTML table elements would not be appropriate. But you could use
|> | the CSS table stuff. Don't blame CSS for not offering presentation
|> | characteristics you need, when in fact it's some user agent(s) that
|> | lack(s) implementation.
|>
|> Why would there be 2 different non-depricated mechanisms in the standards
|> that accomplish exactly the same thing?
|
| Because they are two different things: One (HTML tables) is markup for
| tabular data. E.g. it includes the "Table rendering by non-visual user
| agents" (HTML 4.01, section 11.4). The other (CSS table presentation
| model) is just for presenting content in a certain way (a grid).
So why not use the CSS table presentation model for the tubular data?
Or is there some difference in the exact semantics of these methods?
Why have two mechanisms that work the same way?
W˙rm
<phil-new...@ipal.net> kirjoitti
viestissä:e38c3...@news4.newsguy.com...
<snip>
> How to keep the columns from floating down to the bottom when the window
> is narrower?
Let them float down instead of trying to prevent it, don't make issue from
something that is not. There are ways to prevent it though, but I'd rather
see stuff to adjust to viewport so...
axlq
>specification in IE. It's just that IE chooses not to take the
>option.
Not really... It would be nice if IE actually did consider CSS
optional and choose not to take the option. Instead, it chooses to
implement the option incorrectly. That's a totally different thing.
-A
Johannes Koch
> On Tue, 02 May 2006 22:25:17 +0200 Johannes Koch <ko...@w3development.de> wrote:
> | Because they are two different things: One (HTML tables) is markup for
> | tabular data. E.g. it includes the "Table rendering by non-visual user
> | agents" (HTML 4.01, section 11.4). The other (CSS table presentation
> | model) is just for presenting content in a certain way (a grid).
>
> So why not use the CSS table presentation model for the tubular data?
In many browsers the CSS table presentation model _is_ used for
presenting table/tr/td etc. That's the default rendering.
Johannes Koch
> Why have two mechanisms that work the same way?
Why is there a strong element in HTML, when CSS offers 'font-weight:
bold'? Same answer.
Neredbojias
<nomails...@north.invalid> vouchsafed:
>
> <phil-new...@ipal.net> kirjoitti
> viestissä:e35fi...@news2.newsguy.com...
>
> <snip>
>
>> It probably comes down to the fact that my intentions in a grid
>> structure do match the semantics of a table and tabular data.
>
> If it's tabular data, use table. It's that simple.
>
> If table is just there to do layout certain way when data is _NOT
> tabular_, don't, there are almost certainly better ways to do that
> layout.
A chessboard grid is not tabular data, it's structured data. There is a
difference.
Here's a mock-up I made using someone's visual example from above. Putting
all the ridiculous artificial restrictions aside, it uses no tables, is
fluid, and works in IE. It, unfortunately, doesn't work in Opera because
of Opera's flawed graphic technology.
http://www.neredbojias.com/zyxix/chess/chss2.html
As I intimated, it's just a prototype, but I think it could be a decent
base for a dynamic chess page.
--
Neredbojias
Infinity has its limits.
W˙rm
"Neredbojias" <http://www.neredbojias.com/fliam.php?cat=alt.html> kirjoitti
viestissä:Xns97B8DD4DC1D6ht...@208.49.80.251...
<snip>
>> If it's tabular data, use table. It's that simple.
>>
>> If table is just there to do layout certain way when data is _NOT
>> tabular_, don't, there are almost certainly better ways to do that
>> layout.
>
> A chessboard grid is not tabular data, it's structured data. There is a
> difference.
And where did I say it is? Incase it escaped you what I meant above.
Translation: (spell it word by word if meaning still happily escapes from
you)
If
it's
tabular
data,
use
table.
It's
that
simple.
And data in it meaning _ANY_ data, not just some silly chess stuff.
Neredbojias
<nomails...@north.invalid> vouchsafed:
>>> If it's tabular data, use table. It's that simple.
>>>
>>> If table is just there to do layout certain way when data is _NOT
>>> tabular_, don't, there are almost certainly better ways to do that
>>> layout.
>>
>> A chessboard grid is not tabular data, it's structured data. There
>> is a difference.
>
> And where did I say it is? Incase it escaped you what I meant above.
And where did I say you said it? I was modifying your information, not
contradicting it.
> Translation: (spell it word by word if meaning still happily escapes
> from you)
>
> If
> it's
> tabular
> data,
> use
> table.
> It's
> that
> simple.
You're being childishly gratuitous. Of course, that rather fits this whole
thread.
> And data in it meaning _ANY_ data, not just some silly chess stuff.
I'm glad you clarified that in case anyone out there believes they could
use tables only for chess boards...
W˙rm
"Neredbojias" <http://www.neredbojias.com/fliam.php?cat=alt.html> kirjoitti
viestissä:Xns97B82EFA235Eht...@208.49.80.251...
> And where did I say you said it? I was modifying your information, not
> contradicting it.
If one would been talking about bananas and you'd go on telling pretty
accusatorily "but pink bananas are no bananas they're grapes!" one might
like EXPECT it has relation to talk about bananas you know.
<snip>
> You're being childishly gratuitous. Of course, that rather fits this
> whole
> thread.
ofcoz :)
<snip>
phil-new...@ipal.net
| phil-new...@ipal.net wrote:
|
|> On Tue, 02 May 2006 22:25:17 +0200 Johannes Koch <ko...@w3development.de> wrote:
|> | Because they are two different things: One (HTML tables) is markup for
|> | tabular data. E.g. it includes the "Table rendering by non-visual user
|> | agents" (HTML 4.01, section 11.4). The other (CSS table presentation
|> | model) is just for presenting content in a certain way (a grid).
|>
|> So why not use the CSS table presentation model for the tubular data?
|
| In many browsers the CSS table presentation model _is_ used for
| presenting table/tr/td etc. That's the default rendering.
A new feature that does the same thing as the old feature? Why?
The relationship of data to each other when in a table is fixed. Is CSS
tables trying to change that? I still see no point in having this in CSS
unless there is something different (and hopefully better).
phil-new...@ipal.net
| phil-new...@ipal.net wrote:
|
|> Why have two mechanisms that work the same way?
|
| Why is there a strong element in HTML, when CSS offers 'font-weight:
| bold'? Same answer.
No.
There still has to be something in HTML for the content to say "this is
strong", whether that is <b>foo</b> or <div class="strong">foo</div>.
CSS cannot just select unmarked text and make it bold or strong. There
has to be content markup to give CSS a handle on it.
In some cases making something bold/strong is content. But in other cases
it is style, such as making headings bold, or not, as a choice of style.
Putting tabular data (or data that might not look tabular to some but
needs to be treated as tabular) into relationships of rows and columns
is content markup, not style. Once in a relationship like that, then
it is a table. Then it's fine for CSS to stylize it in some way (maybe
controlling the borders, for example).
CSS cannot, for example, know how many columns the table might have.
One table might have 4 columns and another table might have 6 columns.
But if the stylemaster wants all tables to have a black border around
the whole table, gray lines separating all cells, a pink background
color, and blue text, then he would use CSS and have _one_ stylesheet
without regard to the number of columns.
So tell me again why CSS needs to define the tabular relationships in
the data, and how it can do that without knowing anything about the
data, in any way _more_ than what can be done with the tags we already
have in HTML? I can see a need perhaps to do this for XML which is
devoid of such tags.
phil-new...@ipal.net
|
| <phil-new...@ipal.net> kirjoitti
| viestiss?:e38c3...@news4.newsguy.com...
|
| <snip>
|
|> How to keep the columns from floating down to the bottom when the window
|> is narrower?
|
| Let them float down instead of trying to prevent it, don't make issue from
| something that is not. There are ways to prevent it though, but I'd rather
| see stuff to adjust to viewport so...
I'd rather see stuff that maintains its data relationship and does not
alter the semantics of the content by moving data into a different column.
Poor baby, has to use the horizontal scroll bar to see everything on his
puny little screen.
phil-new...@ipal.net
| To further the education of mankind, "W?rm"
| <nomails...@north.invalid> vouchsafed:
|
|>
|> <phil-new...@ipal.net> kirjoitti
|> viestiss?:e35fi...@news2.newsguy.com...
|>
|> <snip>
|>
|>> It probably comes down to the fact that my intentions in a grid
|>> structure do match the semantics of a table and tabular data.
|>
|> If it's tabular data, use table. It's that simple.
|>
|> If table is just there to do layout certain way when data is _NOT
|> tabular_, don't, there are almost certainly better ways to do that
|> layout.
|
| A chessboard grid is not tabular data, it's structured data. There is a
| difference.
|
| Here's a mock-up I made using someone's visual example from above. Putting
| all the ridiculous artificial restrictions aside, it uses no tables, is
| fluid, and works in IE. It, unfortunately, doesn't work in Opera because
| of Opera's flawed graphic technology.
|
| http://www.neredbojias.com/zyxix/chess/chss2.html
|
| As I intimated, it's just a prototype, but I think it could be a decent
| base for a dynamic chess page.
Now put some content on that cheesboard, such as pieces, or text that
represents pieces, in various positions that present a position of play.
Given that there are not 64 discrete items in the markup where this could
be done, it is not obvious how your design would accomplish that. I do
know I could accomplish it with a table that has 64 TD elements. Or try
putting the letter/number code in each square.
phil-new...@ipal.net
|
| "Neredbojias" <http://www.neredbojias.com/fliam.php?cat=alt.html> kirjoitti
| viestiss?:Xns97B8DD4DC1D6ht...@208.49.80.251...
|
| <snip>
|
|>> If it's tabular data, use table. It's that simple.
|>>
|>> If table is just there to do layout certain way when data is _NOT
|>> tabular_, don't, there are almost certainly better ways to do that
|>> layout.
|>
|> A chessboard grid is not tabular data, it's structured data. There is a
|> difference.
|
| And where did I say it is? Incase it escaped you what I meant above.
|
| Translation: (spell it word by word if meaning still happily escapes from
| you)
|
| If
| it's
| tabular
| data,
| use
| table.
| It's
| that
| simple.
|
| And data in it meaning _ANY_ data, not just some silly chess stuff.
This still leaves open all the arguments about whether some data is, or
is not, tabular data. You're saying if it is tabular data, put it in a
table ... that's fine. You didn't say if it's not tabular data, what to
do or not do. But then you say "_ANY_ data", so I guess that leaves it
open to use a table for anything when the semantics effects of a table
is what is desired.
Johannes Koch
> So tell me again why CSS needs to define the tabular relationships in
> the data,
CSS _does not_ define tabluar relationships. It just defines
presentation characteristics. E.g. adjacent blocks with "display:
table-cell" have the same height.
Johannes Koch
> On Wed, 03 May 2006 10:05:44 +0200 Johannes Koch <ko...@w3development.de> wrote:
> | In many browsers the CSS table presentation model _is_ used for
> | presenting table/tr/td etc. That's the default rendering.
>
> A new feature that does the same thing as the old feature?
HTML does not the same as CSS. HTML defines structure, CSS suggests
presentation.
> The relationship of data to each other when in a table is fixed. Is CSS
> tables trying to change that?
No, you can change the appearance with CSS.
> I still see no point in having this in CSS
> unless there is something different (and hopefully better).
CSS defines the presentation characteristics used in the default
rendering of table/tr/td elements. Just like CSS defines a font-weight
property that is used (value bold) in the default rendering of HTML's
strong element.
phil-new...@ipal.net
| phil-new...@ipal.net wrote:
|
|> On Wed, 03 May 2006 10:05:44 +0200 Johannes Koch <ko...@w3development.de> wrote:
|> | In many browsers the CSS table presentation model _is_ used for
|> | presenting table/tr/td etc. That's the default rendering.
|>
|> A new feature that does the same thing as the old feature?
|
| HTML does not the same as CSS. HTML defines structure, CSS suggests
| presentation.
And a table is a structure. Of course its presentation can be styled, too.
|> The relationship of data to each other when in a table is fixed. Is CSS
|> tables trying to change that?
|
| No, you can change the appearance with CSS.
That's what I thought. So for the structure, I should use HTML. Then
for the appearance use CSS. That's what I thought all along.
|> I still see no point in having this in CSS
|> unless there is something different (and hopefully better).
|
| CSS defines the presentation characteristics used in the default
| rendering of table/tr/td elements. Just like CSS defines a font-weight
| property that is used (value bold) in the default rendering of HTML's
| strong element.
And I can change how table/tr/td presented, too.
But I still use table/tr/td to define the structure.
phil-new...@ipal.net
| phil-new...@ipal.net wrote:
|
|> So tell me again why CSS needs to define the tabular relationships in
|> the data,
|
| CSS _does not_ define tabluar relationships. It just defines
| presentation characteristics. E.g. adjacent blocks with "display:
| table-cell" have the same height.
But how is it that the CSS capability is having certain people tell me
to not use TABLE/TR/TD/etc in HTML?
W˙rm
<phil-new...@ipal.net> kirjoitti
viestissä:e3aeq...@news2.newsguy.com...
And I bet you also use hammer to drive in screws, instead of using
screwdriver. After all, IT can be done.
You are making issues from anything just because you wanna argue and not use
elements that have proper semantical meaning. Like in your linux page, those
links, they are LISTS of links so use <ul><li><a href="">..</a></li>...</ul>
structure for those. Those lists had image in top if I recall right, like a
heading, so maybe use heading for those, etc. Just because you try to twist
something to be tabular data when it obviously is not, it don't make it
"proper use of tables".
Use elements that have proper _SEMANTICAL_ meaning. If you got tabular data
it's table, for a LIST it is a list etc. When you do not have any element
that has proper semantical meaning for something, go for DIV or SPAN. Just
keep it simple.
Do not make issues just because you wanna argue.
Johannes Koch
> On Wed, 03 May 2006 17:23:47 +0200 Johannes Koch <ko...@w3development.de> wrote:
> | phil-new...@ipal.net wrote:
> |
> |> On Wed, 03 May 2006 10:05:44 +0200 Johannes Koch <ko...@w3development.de> wrote:
> |> | In many browsers the CSS table presentation model _is_ used for
> |> | presenting table/tr/td etc. That's the default rendering.
> |>
> |> A new feature that does the same thing as the old feature?
> |
> | HTML does not the same as CSS. HTML defines structure, CSS suggests
> | presentation.
>
> And a table is a structure. Of course its presentation can be styled, too.
Yes.
> |> The relationship of data to each other when in a table is fixed. Is CSS
> |> tables trying to change that?
> |
> | No, you can change the appearance with CSS.
>
> That's what I thought. So for the structure, I should use HTML. Then
> for the appearance use CSS. That's what I thought all along.
Yes.
> |> I still see no point in having this in CSS
> |> unless there is something different (and hopefully better).
> |
> | CSS defines the presentation characteristics used in the default
> | rendering of table/tr/td elements. Just like CSS defines a font-weight
> | property that is used (value bold) in the default rendering of HTML's
> | strong element.
>
> And I can change how table/tr/td presented, too.
>
> But I still use table/tr/td to define the structure.
Yes.
Johannes Koch
> But how is it that the CSS capability is having certain people tell me
> to not use TABLE/TR/TD/etc in HTML?
If you have tabular data, use table, caption, col, colgroup, thead,
tfoot, tbody, tr, th, td. If you don't have tabular data, use
appropriate markup. Additionally, if you want the non-tabular data to be
styled like a grid (equal height etc.), then use the CSS table model.
E.g. DocBook defines an element called 'simplelist'
(<http://www.docbook.org/tdg/en/html/simplelist.html>), which may be
presented as a grid:
apple banana bread cherry
hazelnut mango orange pear
potato tomato
This is not really tabular. What is it that mango has in common with
banana and tomato that differs from hazelnut, orange and pear? What OTOH
does mango have in common with hazelnut, orange and pear that differs
from banana and tomato? There are no row and column relations. It's just
a 2-dimensional presentation of a 1-dimensional list.
Neredbojias
<nomails...@north.invalid> vouchsafed:
>
> "Neredbojias" <http://www.neredbojias.com/fliam.php?cat=alt.html>
> kirjoitti
> viestissä:Xns97B82EFA235Eht...@208.49.80.251...
>
>> And where did I say you said it? I was modifying your information,
>> not contradicting it.
>
> If one would been talking about bananas and you'd go on telling pretty
> accusatorily "but pink bananas are no bananas they're grapes!" one
> might like EXPECT it has relation to talk about bananas you know.
Perhaps, but are we all just a troupe of gibbering monkeys? (-Okay,
present scope excluded.)
>> You're being childishly gratuitous. Of course, that rather fits this
>> whole
>> thread.
>
> ofcoz :)
The whole point of my original post was to gleen feedback about what you
(et al) thought of my version of the grid. Instead I get nonsense. It
certainly seems as if ciwas has become much more like alt.2600 and its ilk
than it used to be.
W˙rm
"Neredbojias" <http://www.neredbojias.com/fliam.php?cat=alt.html> kirjoitti
viestissä:Xns97B899C2D514Fht...@208.49.80.251...
<snip>
> The whole point of my original post was to gleen feedback about what you
> (et al) thought of my version of the grid. Instead I get nonsense.
Whoa!! Now hold on your horses and do some rechecking about WHO might have
said something. I haven't said __ANYTHING__ about your version of grid.
<snip>
phil-new...@ipal.net
| phil-new...@ipal.net wrote:
|> But how is it that the CSS capability is having certain people tell me
|> to not use TABLE/TR/TD/etc in HTML?
|
| If you have tabular data, use table, caption, col, colgroup, thead,
| tfoot, tbody, tr, th, td. If you don't have tabular data, use
| appropriate markup. Additionally, if you want the non-tabular data to be
| styled like a grid (equal height etc.), then use the CSS table model.
In another followup you weren't saying this. Now you are. I don't get
what this flip flop is.
What do you think the "appropriate markup" is for non-tabular data that
needs to have the same rigid structure as a table?
| E.g. DocBook defines an element called 'simplelist'
| (<http://www.docbook.org/tdg/en/html/simplelist.html>), which may be
| presented as a grid:
|
| apple banana bread cherry
| hazelnut mango orange pear
| potato tomato
|
| This is not really tabular. What is it that mango has in common with
| banana and tomato that differs from hazelnut, orange and pear? What OTOH
| does mango have in common with hazelnut, orange and pear that differs
| from banana and tomato? There are no row and column relations. It's just
| a 2-dimensional presentation of a 1-dimensional list.
That data could just as easily come out as:
apple banana bread cherry hazelnut
mango orange pear potato tomato
or as:
apple banana bread
cherry hazelnut mango
orange pear potato
tomato
This example is not what I have been talking about.
But I'll talking about it briefly, anyway. I'd like to have a COLUMN
orientation version of that, which would come out like this:
apple bread hazelnut orange potato
banana cherry mango pear tomato
or in a narrower window like:
apple cherry orange tomato
banana hazelnut pear
bread mango potato
or even:
apple hazelnut potato
banana mango tomato
bread orange
cherry pear
There are some things where this would work better, such as a list of
files in a folder/directory. But it would be style ... something to
decide how to present. Does CSS have a way to say to list stuff this
way? In case someone doesn't see what I'm showing, just look at the
alphabetical sequence of these "food items".
But if I have 2-dimentional data, then this is not the thing to be doing.
So I'm still back to using TABLE/TR/TD, etc., for the 2-D stuff.
Mark Parnell
<phil-new...@ipal.net> declared in
comp.infosystems.www.authoring.stylesheets:
> But I'll talking about it briefly, anyway. I'd like to have a COLUMN
> orientation version of that, which would come out like this:
<snip>
> There are some things where this would work better, such as a list of
> files in a folder/directory. But it would be style ... something to
> decide how to present. Does CSS have a way to say to list stuff this
> way?
CSS3 does/will.
http://www.w3.org/TR/2005/WD-css3-multicol-20051215/
--
Mark Parnell
My Usenet is improved; yours could be too:
http://blinkynet.net/comp/uip5.html
phil-new...@ipal.net
| And I bet you also use hammer to drive in screws, instead of using
| screwdriver. After all, IT can be done.
I make my decisions based on what is practical. YES! I do use a hammer
on a screw ... to pound in just enough of a dent in the wood to keep the
screw stable as the screwdriver turns it into the wood. In extreme cases
I'll even use a drill to drill a hole a bit smaller than the screw core
to avoid causing the wood to split.
But it is NOT practical to use a hammer to drive the screw in all the way
unless you're objective it to just gouge a hole in the wood (someone might
want to do that). On a smaller scale, your dentist may well be doing
something akin to that with the tiny tools used for root canals.
I use TABLE/TR/TD for what those are the most practical solution I can
see at the time.
| You are making issues from anything just because you wanna argue and not use
| elements that have proper semantical meaning.
No.
I use what works most practical. I simply have not seen anything that
is any more practical than using TABLE/TR/TD for 2-D data. If you want
to every show how it is done some other way, maybe I can show you where
your solution doesn't match my problem.
| Like in your linux page, those
| links, they are LISTS of links so use <ul><li><a href="">..</a></li>...</ul>
| structure for those. Those lists had image in top if I recall right, like a
| heading, so maybe use heading for those, etc. Just because you try to twist
| something to be tabular data when it obviously is not, it don't make it
| "proper use of tables".
If you look more closely at the source you'll see that the list of links
is NOT structured in a table. The entire list for a given site, inside
a box for that site, is in ONE cell. There are BR elements to force each
link to a new line ... not TR elements.
An early version DID use UL/LI, but that never came out right. That MAY
be tweakable today, but some things like the bullet size don't seem to
be adjustable. So for now, they are just a list formed in lines with BR.
The page does have two basic levels of tables (with additional levels used
to wedge things into place). The outer level is to organize things into
3 columns ... in a way that stays as 3 columns. The inner level is the big
mess used to create the drop shadow effect. This inner layer is what will
go away soon. I already have it's general replacement done in CSS, and am
working on reorganizing the PHP code before it all goes online.
| Use elements that have proper _SEMANTICAL_ meaning. If you got tabular data
| it's table, for a LIST it is a list etc. When you do not have any element
| that has proper semantical meaning for something, go for DIV or SPAN. Just
| keep it simple.
Show me where a list (there are many separate lists on linuxhomepage.com)
is being formatted using a table.
| Do not make issues just because you wanna argue.
Why not show what you think is the solution, so you can either prove
someone wrong ... or perhaps have your solution knocked down because
maybe you didn't understand the original problem. There are LAYERS
going on in LHP. The list of links is the 3rd layer. The shadows are
the 2nd layer (though in a correct markup, this shouldn't be a layer).
And the columnization is the 1st layer.
Mark Parnell
<phil-new...@ipal.net> declared in
comp.infosystems.www.authoring.stylesheets:
> If you look more closely at the source you'll see that the list of links
> is NOT structured in a table.
He never said it was. He was simply using it as another example of you
using non-semantic markup, similar to your use of tables.
> An early version DID use UL/LI, but that never came out right. That MAY
> be tweakable today, but some things like the bullet size don't seem to
> be adjustable.
Not AFAIK (they tend to adjust with the font size but can't be resized
independently), but you can certainly remove the bullets altogether and
e.g. use an image instead.
> So for now, they are just a list formed in lines with BR.
Which isn't really a list at all.
Johannes Koch
> On Wed, 03 May 2006 23:50:16 +0200 Johannes Koch <ko...@w3development.de> wrote:
> | If you have tabular data, use table, caption, col, colgroup, thead,
> | tfoot, tbody, tr, th, td. If you don't have tabular data, use
> | appropriate markup. Additionally, if you want the non-tabular data to be
> | styled like a grid (equal height etc.), then use the CSS table model.
>
> In another followup you weren't saying this. Now you are. I don't get
> what this flip flop is.
Where can you quote me?
> What do you think the "appropriate markup" is for non-tabular data that
> needs to have the same rigid structure as a table?
I'm not talking about "rigid structure as a table". I try to explain to
you what the CSS table presentation model is about in contrast to the
HTML table model. CSS is not about structure. It's about presentation.
> | E.g. DocBook defines an element called 'simplelist'
> | (<http://www.docbook.org/tdg/en/html/simplelist.html>), which may be
> | presented as a grid:
> |
> | apple banana bread cherry
> | hazelnut mango orange pear
> | potato tomato
> |
> | This is not really tabular. What is it that mango has in common with
> | banana and tomato that differs from hazelnut, orange and pear? What OTOH
> | does mango have in common with hazelnut, orange and pear that differs
> | from banana and tomato? There are no row and column relations. It's just
> | a 2-dimensional presentation of a 1-dimensional list.
>
> That data could just as easily come out as:
>
> apple banana bread cherry hazelnut
> mango orange pear potato tomato
>
> or as:
>
> apple banana bread
> cherry hazelnut mango
> orange pear potato
> tomato
Of course, it can.
> This example is not what I have been talking about.
I chose this example to explain to you the difference between tabular
data and non-tabular data that someone wants to present in a grid way.
> But I'll talking about it briefly, anyway. I'd like to have a COLUMN
> orientation version of that, which would come out like this:
[...]
> apple hazelnut potato
> banana mango tomato
> bread orange
> cherry pear
>
> There are some things where this would work better, such as a list of
> files in a folder/directory. But it would be style ... something to
> decide how to present. Does CSS have a way to say to list stuff this
> way? In case someone doesn't see what I'm showing, just look at the
> alphabetical sequence of these "food items".
I don't think, CSS currently has a way to do this. Neither has HTML. The
HTML table model is row-oriented. So the table's serialization would not
represent the alphabetical order.
phil-new...@ipal.net
| Deciding to do something for the good of humanity,
| <phil-new...@ipal.net> declared in
| comp.infosystems.www.authoring.stylesheets:
|
|> But I'll talking about it briefly, anyway. I'd like to have a COLUMN
|> orientation version of that, which would come out like this:
| <snip>
|> There are some things where this would work better, such as a list of
|> files in a folder/directory. But it would be style ... something to
|> decide how to present. Does CSS have a way to say to list stuff this
|> way?
|
| CSS3 does/will.
| http://www.w3.org/TR/2005/WD-css3-multicol-20051215/
Sounds good. I look forward to it. Any chance Firefox has advance
support to try it out?
phil-new...@ipal.net
| Deciding to do something for the good of humanity,
| <phil-new...@ipal.net> declared in
| comp.infosystems.www.authoring.stylesheets:
|
|> If you look more closely at the source you'll see that the list of links
|> is NOT structured in a table.
|
| He never said it was. He was simply using it as another example of you
| using non-semantic markup, similar to your use of tables.
So he's shifting off topic and trying to address the person instead of
the issue. That's not the first time he's done so. Well, at least he
isn't doing so in an insulting/attack manner (as some people I've seen
are want to do). But I think he needs to stay _on_ topic for 2 reasons.
One is that it can get confusing when the deviation is made. And two,
he hasn't really addressed the TABLE/TR/TD issue adequately. Merely
saying that I'm not using the semantics means he expects me to use some
other means, but only makes vague references to what those are, without
being specific. I think he needs to be specific because that's the only
way I can pin point _his_ misunderstanding of what _I_ am trying to do.
|> An early version DID use UL/LI, but that never came out right. That MAY
|> be tweakable today, but some things like the bullet size don't seem to
|> be adjustable.
|
| Not AFAIK (they tend to adjust with the font size but can't be resized
| independently), but you can certainly remove the bullets altogether and
| e.g. use an image instead.
I don't want to use an image there. I want something very tiny. The dash
did the job just fine.
|> So for now, they are just a list formed in lines with BR.
|
| Which isn't really a list at all.
My "semantics of a list" does not require a bullet. I would call such a
thing a "bulleted list". That's not so much of a departure from an ordered
list that gets numbered. I see the choice of bullet, or numbers, or nothing
at all, a presentation issue, anyway. But I can't see where CSS gives me
those choices just yet. Maybe in CSS3?
OK, for semantics purposes, I'll call the list of links "not a list".
Then I won't use UL/LI. Or would it be better to just accept that the
semantics really is a list, but that available stylings are inadequate
for now?
phil-new...@ipal.net
| phil-new...@ipal.net wrote:
|
|> On Wed, 03 May 2006 23:50:16 +0200 Johannes Koch <ko...@w3development.de> wrote:
|> | If you have tabular data, use table, caption, col, colgroup, thead,
|> | tfoot, tbody, tr, th, td. If you don't have tabular data, use
|> | appropriate markup. Additionally, if you want the non-tabular data to be
|> | styled like a grid (equal height etc.), then use the CSS table model.
|>
|> In another followup you weren't saying this. Now you are. I don't get
|> what this flip flop is.
|
| Where can you quote me?
In Message-ID: <4459273d$0$11086$892e...@authen.yellow.readfreenews.net>
All those short answers.
|> What do you think the "appropriate markup" is for non-tabular data that
|> needs to have the same rigid structure as a table?
|
| I'm not talking about "rigid structure as a table". I try to explain to
| you what the CSS table presentation model is about in contrast to the
| HTML table model. CSS is not about structure. It's about presentation.
But I want the rigid structure. If CSS is not about structure, then that
goal should not attempt to use CSS.
|> | E.g. DocBook defines an element called 'simplelist'
|> | (<http://www.docbook.org/tdg/en/html/simplelist.html>), which may be
|> | presented as a grid:
|> |
|> | apple banana bread cherry
|> | hazelnut mango orange pear
|> | potato tomato
|> |
|> | This is not really tabular. What is it that mango has in common with
|> | banana and tomato that differs from hazelnut, orange and pear? What OTOH
|> | does mango have in common with hazelnut, orange and pear that differs
|> | from banana and tomato? There are no row and column relations. It's just
|> | a 2-dimensional presentation of a 1-dimensional list.
|>
|> That data could just as easily come out as:
|>
|> apple banana bread cherry hazelnut
|> mango orange pear potato tomato
|>
|> or as:
|>
|> apple banana bread
|> cherry hazelnut mango
|> orange pear potato
|> tomato
|
| Of course, it can.
Though that is not what I want in my 2-D structures.
|> This example is not what I have been talking about.
|
| I chose this example to explain to you the difference between tabular
| data and non-tabular data that someone wants to present in a grid way.
|
|> But I'll talking about it briefly, anyway. I'd like to have a COLUMN
|> orientation version of that, which would come out like this:
| [...]
|> apple hazelnut potato
|> banana mango tomato
|> bread orange
|> cherry pear
|>
|> There are some things where this would work better, such as a list of
|> files in a folder/directory. But it would be style ... something to
|> decide how to present. Does CSS have a way to say to list stuff this
|> way? In case someone doesn't see what I'm showing, just look at the
|> alphabetical sequence of these "food items".
|
| I don't think, CSS currently has a way to do this. Neither has HTML. The
| HTML table model is row-oriented. So the table's serialization would not
| represent the alphabetical order.
So for 1-D lists I want presented in that form, I'll have to wait for CSS3.
In the mean time, there is no way to really get it.
But for 2-D structures, I can put it together with TABLE/TR/TD since the
position of everything would be known by the content producer/generator.
Johannes Koch
> On Thu, 04 May 2006 10:08:09 +0200 Johannes Koch <ko...@w3development.de> wrote:
> | phil-new...@ipal.net wrote:
> |
> |> On Wed, 03 May 2006 23:50:16 +0200 Johannes Koch <ko...@w3development.de> wrote:
> |> | If you have tabular data, use table, caption, col, colgroup, thead,
> |> | tfoot, tbody, tr, th, td. If you don't have tabular data, use
> |> | appropriate markup. Additionally, if you want the non-tabular data to be
> |> | styled like a grid (equal height etc.), then use the CSS table model.
> |>
> |> In another followup you weren't saying this. Now you are. I don't get
> |> what this flip flop is.
> |
> | Where can you quote me?
>
> In Message-ID: <4459273d$0$11086$892e...@authen.yellow.readfreenews.net>
> All those short answers.
You said:
And a table is a structure. Of course its presentation can be styled,
too.
I responded:
Yes.
You said:
So for the structure, I should use HTML. Then for the appearance use
CSS. That's what I thought all along.
I responded:
Yes
You said:
And I can change how table/tr/td presented, too.
But I still use table/tr/td to define the structure.
I responded:
Yes
Now, why is that flip flop?
W˙rm
<phil-new...@ipal.net> kirjoitti
viestissä:e3cgq...@news3.newsguy.com...
<snip>
> So he's shifting off topic and trying to address the person instead of
> the issue. That's not the first time he's done so.
Not true. My point is that most of the time in _your examples_ you are NOT
using semantically meaningful elements for the things you do. That's all. I
don't see point of you trying to stick using table to define LAYOUT. Because
that's what you keep doing. It might be hard to unlearn thinking in table
way, but it's worth it.
Even in latest drop shadow thing you keep using table to create layout
structure.
<snip>
> But I think he needs to stay _on_ topic for 2 reasons.
> One is that it can get confusing when the deviation is made. And two,
> he hasn't really addressed the TABLE/TR/TD issue adequately.
I am saying you use table to position things, like your columns.
http://www.kolumbus.fi/ace/ng/boxes.html is quick mock up without tables. I
have no idea where it works because I didn't really test it that much
though...
> Merely
> saying that I'm not using the semantics means he expects me to use some
> other means, but only makes vague references to what those are, without
> being specific. I think he needs to be specific because that's the only
> way I can pin point _his_ misunderstanding of what _I_ am trying to do.
How does your ROWS and colums relate in tables, what relation that data in
there has?
For example first thing in your page, you are using TABLE to position
elements. Meaning you use TABLE to position a heading of your page and
google ads (that I have turned off, only saw those when looked in IE).
On main part of page you use again TABLE to create three columns. Again to
make a LAYOUT. And when you look inside those three tables cells, well,
what you know. More tables.. etc. You are not using elements that have
semantical purpose for things. Like lists (of those links) are inside tables
and just text you use <BR> to split in lines. Etc.
And yes, I know you have said this page is not new, so, as I look things,
now is yout chance to "fix" things like not anymore using tables for
position things or create layout structures.
> |> An early version DID use UL/LI, but that never came out right. That
> MAY
> |> be tweakable today, but some things like the bullet size don't seem to
> |> be adjustable.
> |
> | Not AFAIK (they tend to adjust with the font size but can't be resized
> | independently), but you can certainly remove the bullets altogether and
> | e.g. use an image instead.
>
> I don't want to use an image there. I want something very tiny. The dash
> did the job just fine.
then use that in either text or
li:before
{
content: "-";
}
That don't work IE6 or earlier though. Though if you'd use TINY image on LI
background positioned left, it would suit too.
> |> So for now, they are just a list formed in lines with BR.
> |
> | Which isn't really a list at all.
>
> My "semantics of a list" does not require a bullet.
then use list-style-type: none;
> I would call such a
> thing a "bulleted list". That's not so much of a departure from an
> ordered
> list that gets numbered. I see the choice of bullet, or numbers, or
> nothing
> at all, a presentation issue, anyway. But I can't see where CSS gives me
> those choices just yet. Maybe in CSS3?
li
{
list-style-type: none;
}
etc?
<snip>
phil-new...@ipal.net
You said in a previous post:
If you have tabular data, use table, caption, col, colgroup, thead,
tfoot, tbody, tr, th, td. If you don't have tabular data, use
appropriate markup. Additionally, if you want the non-tabular data to be
styled like a grid (equal height etc.), then use the CSS table model.
I don't know about equal height bit, though that would be expected in a
grid structure. The "data" I have is blocks of text. It's not what people
refer to as "tabular data" (like you might find in a spreadsheat as one
person described it). Instead, it is a grid organization of sections of
data, pretty forcing a specific set of columns. But all the semantics are
still the same as what TABLE/TR/TD and friends provide, and not what any
other method provides (certainly not float:left). So unless your definition
of "tabular data" doesn't follow the norm, this does come across as a
flip-flop. But looking over all your postings, it certain does seem you
may have a different definition of things like "tabular data".
Mark Parnell
<phil-new...@ipal.net> declared in
comp.infosystems.www.authoring.stylesheets:
> I don't want to use an image there. I want something very tiny.
So use a tiny image. ;-)
> The dash
> did the job just fine.
As Wyrm said, just put the dash in the text as you are now, or add it
with CSS (with the caveat that IE doesn't support it).
> My "semantics of a list" does not require a bullet.
Well, really you want a bullet that looks like a dash instead of a disc.
> That's not so much of a departure from an ordered
> list that gets numbered. I see the choice of bullet, or numbers, or nothing
> at all, a presentation issue, anyway.
The actual style of the bullet or number is certainly a presentation
issue, yes.
However there is a semantic difference between bullets and numbers, i.e.
an unordered list and an ordered list - in the former, the order of the
list items is irrelevant, in the latter, the order does matter. A recipe
is a prime example - the list of ingredients can be in any order, but
the steps in the method need to be in the correct order.
Though you could style an unordered list with numbers (or an ordered
list with glyphs) if you really wanted to.
> But I can't see where CSS gives me
> those choices just yet.
The bullet style can be set with list-style-type, though a dash is not
one of the options.
> Maybe in CSS3?
Looks like it - according to the current draft, list-style-type will
include "hyphen".
http://www.w3.org/TR/2002/WD-css3-lists-20021107/#glyphs
phil-new...@ipal.net
|
| <phil-new...@ipal.net> kirjoitti
|
| <snip>
|
|> So he's shifting off topic and trying to address the person instead of
|> the issue. That's not the first time he's done so.
|
| Not true. My point is that most of the time in _your examples_ you are NOT
| using semantically meaningful elements for the things you do. That's all. I
| don't see point of you trying to stick using table to define LAYOUT. Because
| that's what you keep doing. It might be hard to unlearn thinking in table
| way, but it's worth it.
I don't see _anyone_ doing any layout that gets what I want to have
who uses anything but tables. People have suggested things before and
it did not work (not same semantics ... stuff like rightmost column
falls down to left side, which is unacceptable).
| Even in latest drop shadow thing you keep using table to create layout
| structure.
And so far, it takes that to ensure it works.
|> But I think he needs to stay _on_ topic for 2 reasons.
|> One is that it can get confusing when the deviation is made. And two,
|> he hasn't really addressed the TABLE/TR/TD issue adequately.
|
| I am saying you use table to position things, like your columns.
|
| http://www.kolumbus.fi/ace/ng/boxes.html is quick mock up without tables. I
| have no idea where it works because I didn't really test it that much
| though...
Some issues exist:
1. Text falls outside of these boxes, but does not with tables.
Maybe that's another property that table/tr/td defaults to
that you could add.
2. The content producer (that does not produce the CSS) decides how
many columns of data there are (it's the content the user selects).
3. There's no savings here. That's been touted as _one_ reason to
use CSS. But I don't see it. You have as many elements as I would
just named different, and with classes.
I've been doing styles now with selectors like:
.foo
.foo>*
.foo>*>*
.foo>*>*>*
to handle each level of element to select. I suppose that could work
whether the elements involved are TABLE/TR/TD or DIV/DIV/DIV and only
need a class on the outmost one. Seems to work.
|> Merely
|> saying that I'm not using the semantics means he expects me to use some
|> other means, but only makes vague references to what those are, without
|> being specific. I think he needs to be specific because that's the only
|> way I can pin point _his_ misunderstanding of what _I_ am trying to do.
|
| How does your ROWS and colums relate in tables, what relation that data in
| there has?
That depends one which things I'm doing. Where there are multiple rows,
each item (cell) needs to be under the others of the same column. Where
there are not, it's basically just one row of N columns to stop flow of
blocks onto the row below.
| For example first thing in your page, you are using TABLE to position
| elements. Meaning you use TABLE to position a heading of your page and
| google ads (that I have turned off, only saw those when looked in IE).
|
| On main part of page you use again TABLE to create three columns. Again to
| make a LAYOUT. And when you look inside those three tables cells, well,
| what you know. More tables.. etc. You are not using elements that have
| semantical purpose for things. Like lists (of those links) are inside tables
| and just text you use <BR> to split in lines. Etc.
Don't count the tables used to structure the drop shadow. That I know is
not what tables is for. Semantically, the drop shadows are not content,
just style, so ideally I should be able to do that in CSS. Unfortunately,
even this can't be done just in CSS. CSS needs more element laters to be
in the content to accomplish it.
| And yes, I know you have said this page is not new, so, as I look things,
| now is yout chance to "fix" things like not anymore using tables for
| position things or create layout structures.
Which is what I am working on. The drop shadows I'm going to do in CSS as
much as I can (but I still have to put 2 extra layers of DIVs in to do
stationary drop shadows, and 4 extra layers to do saluting drop shadoows
where the page rises up ... one of those layers to prevent a situation
where the salute can oscillate when the point is positioned where the
movement pulls the object out from under the pointer, then it no longer
is hovering and it comes back, then it is hovering again, over and over.
But As I said earlier, I don't see the gain in using 3 different elements
for 3 elements I already use. But the real point here is, if you can do
exactly what TABLE/TR/TD does with DIV/DIV/DIV then you've also shown that
having TABLE/TR/TD in HTML is unnecessary (and I would expect to see you
urge that they be depricated from the standard).
|> |> An early version DID use UL/LI, but that never came out right. That
|> MAY
|> |> be tweakable today, but some things like the bullet size don't seem to
|> |> be adjustable.
|> |
|> | Not AFAIK (they tend to adjust with the font size but can't be resized
|> | independently), but you can certainly remove the bullets altogether and
|> | e.g. use an image instead.
|>
|> I don't want to use an image there. I want something very tiny. The dash
|> did the job just fine.
|
| then use that in either text or
|
| li:before
| {
| content: "-";
| }
|
| That don't work IE6 or earlier though. Though if you'd use TINY image on LI
| background positioned left, it would suit too.
|
|
|> |> So for now, they are just a list formed in lines with BR.
|> |
|> | Which isn't really a list at all.
|>
|> My "semantics of a list" does not require a bullet.
|
| then use list-style-type: none;
OK.
|> I would call such a
|> thing a "bulleted list". That's not so much of a departure from an
|> ordered
|> list that gets numbered. I see the choice of bullet, or numbers, or
|> nothing
|> at all, a presentation issue, anyway. But I can't see where CSS gives me
|> those choices just yet. Maybe in CSS3?
|
| li
| {
| list-style-type: none;
| }
I missed that one. But I'm still focusing my work on other aspect of the
design right now. This is generated HTML, so I've got to get all aspects
of the coding just right on the context of the coming variations in content.
W˙rm
<phil-new...@ipal.net> kirjoitti
viestissä:e3e5s...@news1.newsguy.com...
<snip>
> I don't see _anyone_ doing any layout that gets what I want to have
> who uses anything but tables. People have suggested things before and
> it did not work (not same semantics ... stuff like rightmost column
> falls down to left side, which is unacceptable).
And you can prevent it if you actually wan't, because I prefer layout to be
fluid wien it comes to colums which only "relation" is that you want them
presented (no relation in data of the columns itself) side by side instead
being fluid so that's why I don't do that in example. I don't see it to be
unacceptable in this case because there is not any relation for the data you
have in columns, atleast not currently.
Too bad internet explorer do not support min-width: but there are other
ways to prevent it too. Use width for the body, or h1, or add maybe one more
container with width set so wide things dont mess up, or use one line gif
(with "minumum" acceptable width for all columns combined (for IE to get by
the missing min-width:) etc. there are different ways. Now what is best,
that is not something I will say a thing, because I like content to be fluid
unless design itself is "fixed width" and I try avoid such designs when ever
I can.
<snip>
> Some issues exist:
>
> 1. Text falls outside of these boxes, but does not with tables.
> Maybe that's another property that table/tr/td defaults to
> that you could add.
one way is min-width: to sent minimum acceptable width for those things. But
don't work for IE. Again there are work arounds for that, but what's good or
proper, that's entirely different matter...
> 2. The content producer (that does not produce the CSS) decides how
> many columns of data there are (it's the content the user selects).
>
> 3. There's no savings here. That's been touted as _one_ reason to
> use CSS. But I don't see it. You have as many elements as I would
> just named different, and with classes.
Yes there are actually less when you remove tables, depends how complex use
of tables there is, your tables are simple so there's not that much
difference. But that is not the point.
Point is to use structures that have semantical meaning.
Like those unordered lists, headings etc. Then use CSS to tweak their
presentation in way you want to show em.
It's like when you write Document, you should use elements that have
semantical meaning, like Headings for Headings (in html H1 as whole document
heading, H2 as headings under it, H3 for headings that are under H3 etc.),
not just use paragraph for heading and style it to look like heading.
See, idea is to use elements that have certain semantical meaning for the
content. Headings are headings, lists are, well lists, paragraphs of text
are paragraphs etc. And when there's no proper thing to use, then there's
DIV and SPAN...
<snip>
> | How does your ROWS and colums relate in tables, what relation that data
> in
> | there has?
>
> That depends one which things I'm doing. Where there are multiple rows,
> each item (cell) needs to be under the others of the same column. Where
> there are not, it's basically just one row of N columns to stop flow of
> blocks onto the row below.
So data itself has no relation, you only use table for layout.
<snip>
> But As I said earlier, I don't see the gain in using 3 different elements
> for 3 elements I already use. But the real point here is, if you can do
> exactly what TABLE/TR/TD does with DIV/DIV/DIV then you've also shown that
> having TABLE/TR/TD in HTML is unnecessary (and I would expect to see you
> urge that they be depricated from the standard).
No, I say that you should use _elements_ that are _semantical_ for the
purpose. Like those mentioned headings for headings, lists for lists etc.
Table will not be unnecessary, it has it's semantical meaning too, not to
use it for layout, but for tabular data. Table represent relationships
between data.
<snip>
> I missed that one.
Easy to miss things sometimes, been doing whole night C# coding and was
refactoring some earlier code. Plenty of lines that I had done some point
earlier, happily reinventing some wheels when there were already stuff on
.NET for that purpose. I was feeling like kicking my self plenty of times
just because I had originally missed those things, heh. Just gotta try
remember next time and keep on trying to learn more. Sad part is that more
one learn, more one feel like knowing nothing. Always find more new things
to learn than manage to learn.
> But I'm still focusing my work on other aspect of the
> design right now. This is generated HTML, so I've got to get all aspects
> of the coding just right on the context of the coming variations in
> content.
Well, you'll get there some point :) Maybe kicking and screaming about
HTML/CSS and them having no "use" ;)
Anyway, I hope you get what I am trying to say, about using semantically
meaningful stuff. It's 6am and haven't yet got any sleep (but plan to have
some now) so might be rather rambling state...
phil-new...@ipal.net
| Deciding to do something for the good of humanity,
| <phil-new...@ipal.net> declared in
| comp.infosystems.www.authoring.stylesheets:
|
|> I don't want to use an image there. I want something very tiny.
|
| So use a tiny image. ;-)
I'm wanting to avoid the extra server hit.
|> The dash
|> did the job just fine.
|
| As Wyrm said, just put the dash in the text as you are now, or add it
| with CSS (with the caveat that IE doesn't support it).
|
|> My "semantics of a list" does not require a bullet.
|
| Well, really you want a bullet that looks like a dash instead of a disc.
I guess you could say it that way.
|> That's not so much of a departure from an ordered
|> list that gets numbered. I see the choice of bullet, or numbers, or nothing
|> at all, a presentation issue, anyway.
|
| The actual style of the bullet or number is certainly a presentation
| issue, yes.
|
| However there is a semantic difference between bullets and numbers, i.e.
| an unordered list and an ordered list - in the former, the order of the
| list items is irrelevant, in the latter, the order does matter. A recipe
| is a prime example - the list of ingredients can be in any order, but
| the steps in the method need to be in the correct order.
So if an implementation were to re-arrange the order of items given in
a list with UL/LI, that would be OK?
phil-new...@ipal.net
|
| <phil-new...@ipal.net> kirjoitti
|
| <snip>
|
|> I don't see _anyone_ doing any layout that gets what I want to have
|> who uses anything but tables. People have suggested things before and
|> it did not work (not same semantics ... stuff like rightmost column
|> falls down to left side, which is unacceptable).
|
| And you can prevent it if you actually wan't, because I prefer layout to be
| fluid wien it comes to colums which only "relation" is that you want them
| presented (no relation in data of the columns itself) side by side instead
| being fluid so that's why I don't do that in example. I don't see it to be
| unacceptable in this case because there is not any relation for the data you
| have in columns, atleast not currently.
We each have our own different desires of ways to do things, and/or different
projects with different requirements.
| Too bad internet explorer do not support min-width: but there are other
| ways to prevent it too. Use width for the body, or h1, or add maybe one more
| container with width set so wide things dont mess up, or use one line gif
| (with "minumum" acceptable width for all columns combined (for IE to get by
| the missing min-width:) etc. there are different ways. Now what is best,
| that is not something I will say a thing, because I like content to be fluid
| unless design itself is "fixed width" and I try avoid such designs when ever
| I can.
On the TABLE element I can specify width=100% and get the whole table to go
to at least the width of the viewing area. Then however many columns I have
can be made to fit with width= some percentage that the content generator
will have knowledge of. I suppose I could do style= on DIV elements their
place instead of the separate CSS file.
|> Some issues exist:
|>
|> 1. Text falls outside of these boxes, but does not with tables.
|> Maybe that's another property that table/tr/td defaults to
|> that you could add.
|
| one way is min-width: to sent minimum acceptable width for those things. But
| don't work for IE. Again there are work arounds for that, but what's good or
| proper, that's entirely different matter...
Apparently width= works on TH/TD in IE.
|> 2. The content producer (that does not produce the CSS) decides how
|> many columns of data there are (it's the content the user selects).
|>
|> 3. There's no savings here. That's been touted as _one_ reason to
|> use CSS. But I don't see it. You have as many elements as I would
|> just named different, and with classes.
|
| Yes there are actually less when you remove tables, depends how complex use
| of tables there is, your tables are simple so there's not that much
| difference. But that is not the point.
|
| Point is to use structures that have semantical meaning.
I'd like to. But details of the layout come with the content, not with the
style, based one what the content generator produces (e.g. data selections
the user may supply on a form).
| Like those unordered lists, headings etc. Then use CSS to tweak their
| presentation in way you want to show em.
I guess I need to get used to using things that by default have some kind
of presentation style already which I have to then turn off, as opposed to
the previous method (basically just using <BR> to force a new line) which
was simple and did exactly what I wanted.
| It's like when you write Document, you should use elements that have
| semantical meaning, like Headings for Headings (in html H1 as whole document
| heading, H2 as headings under it, H3 for headings that are under H3 etc.),
| not just use paragraph for heading and style it to look like heading.
|
| See, idea is to use elements that have certain semantical meaning for the
| content. Headings are headings, lists are, well lists, paragraphs of text
| are paragraphs etc. And when there's no proper thing to use, then there's
| DIV and SPAN...
Now to find the CSS properties that make DIV behave like each of the elements
of a table.
|> That depends one which things I'm doing. Where there are multiple rows,
|> each item (cell) needs to be under the others of the same column. Where
|> there are not, it's basically just one row of N columns to stop flow of
|> blocks onto the row below.
|
| So data itself has no relation, you only use table for layout.
There is relation, though relatively simple. It just has to all be in the
same row. You did accomplish that, but there were other issues which I
don't yet know the answers to.
|> But As I said earlier, I don't see the gain in using 3 different elements
|> for 3 elements I already use. But the real point here is, if you can do
|> exactly what TABLE/TR/TD does with DIV/DIV/DIV then you've also shown that
|> having TABLE/TR/TD in HTML is unnecessary (and I would expect to see you
|> urge that they be depricated from the standard).
|
| No, I say that you should use _elements_ that are _semantical_ for the
| purpose. Like those mentioned headings for headings, lists for lists etc.
| Table will not be unnecessary, it has it's semantical meaning too, not to
| use it for layout, but for tabular data. Table represent relationships
| between data.
And I often see (where others often don't) a relationship that is like what
a table creates. So it's just natural to use a table there for that.
|> I missed that one.
|
| Easy to miss things sometimes, been doing whole night C# coding and was
| refactoring some earlier code. Plenty of lines that I had done some point
| earlier, happily reinventing some wheels when there were already stuff on
| .NET for that purpose. I was feeling like kicking my self plenty of times
| just because I had originally missed those things, heh. Just gotta try
| remember next time and keep on trying to learn more. Sad part is that more
| one learn, more one feel like knowing nothing. Always find more new things
| to learn than manage to learn.
Sometimes one reinvents things that would have worked. And sometimes one
one tries to use things that exist that end up not working or being a big
pain to use. In my programming I started collecting all my tools and even
made them available online as a library. Some people see some of the things
I've done as duplication of what others have done. But looking closer one
could see there's more to it, or it's simpler, etc. Not everything that
appears to be a re-invention really is.
|> But I'm still focusing my work on other aspect of the
|> design right now. This is generated HTML, so I've got to get all aspects
|> of the coding just right on the context of the coming variations in
|> content.
|
| Well, you'll get there some point :) Maybe kicking and screaming about
| HTML/CSS and them having no "use" ;)
|
| Anyway, I hope you get what I am trying to say, about using semantically
| meaningful stuff. It's 6am and haven't yet got any sleep (but plan to have
| some now) so might be rather rambling state...
My understanding is the content should have markup to say what it is, and
the stylesheet should say how to present it. But there's a gap of layout
that straddles the two. Maybe a third language for that is needed. But
in some cases, the relationships of data are known with the content and
can be different such that a single style can't be used to do a layout.
Mark Parnell
<phil-new...@ipal.net> declared in
comp.infosystems.www.authoring.stylesheets:
> So if an implementation were to re-arrange the order of items given in
> a list with UL/LI, that would be OK?
It shouldn't matter, no. For example a UA could (theoretically) provide
the ability to automatically sort list items in alphabetical order. For
an unordered list that would be fine. For an ordered list it wouldn't.
phil-new...@ipal.net
| Anyway, I hope you get what I am trying to say, about using semantically
| meaningful stuff. It's 6am and haven't yet got any sleep (but plan to have
| some now) so might be rather rambling state...
So how would you do the following? You have a list of stuff, maybe a lot.
The list is to be presented where each row alternates between white and
light green. But the list is being produced by some database program you
cannot change. So whatever HTML element it uses, it's identical for every
row generated. I saw the + used on selectors to accomplish that effect
for a chessboard (I had replied to that with "gross"). But you could not
really use that here because this list might have thousands of rows. Of
course, it would be nicer to have the rows generated with some kind of
even/odd class names so it can be done with 2 selectors.
Steve Pugh
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_?
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.
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.
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?
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.
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.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st...@pugh.net> <http://steve.pugh.net/>
Steve Pugh
>So how would you do the following? You have a list of stuff, maybe a lot.
>The list is to be presented where each row alternates between white and
>light green. But the list is being produced by some database program you
>cannot change. So whatever HTML element it uses, it's identical for every
>row generated. I saw the + used on selectors to accomplish that effect
>for a chessboard (I had replied to that with "gross"). But you could not
>really use that here because this list might have thousands of rows. Of
>course, it would be nicer to have the rows generated with some kind of
>even/odd class names so it can be done with 2 selectors.
Either wait for support for CSS3.
Or use some JavaScript to apply the styling dynamically (see the
thread 'Style based on tag content' for examples using both plain
JavaScript and bindings/behaviours).
Or take the ouput HTML and feed it through another level or processing
on the server to add the classes for odd/even.
I guess I'm lucky that on my current job that the back end programs
grabbing stuff out of the database spit everything out as XML and so
the production of the HTML via XSLT is entirely in my hands. I can
write the XSLT and CSS at the same time and never need to bother the
back end programmers or database guys to get an extra class attribute
included.
Johannes Koch
Well summarized.
> 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.
Or ignore IE :-)
phil-new...@ipal.net
| 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.
| 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?
| 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. 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.
| 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").
| 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. I've seen some examples that correct the flow problem
(e.g. they made the right column stay at the right) 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).
| 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).
The site design of http://linuxhomepage.com/ was made for Netscape 3 because
Netscape 4 that was already out at the time I created that design (which was
before that site itself) was horrendously bloated and terribly slow when
compared to Netscape 3. So I could not recommend Netscape 4 to anyone. The
design (based entirely on tables) was tweaked to work in NS 3, NS 4, IE 3,
IE 4, and Opera (forgot the version). It is the emergence of Firefox 1.5
that has changed the landscape for me because it is universally recommendable
and apparently is very compliant. That is why I am doing CSS now.
phil-new...@ipal.net
| Deciding to do something for the good of humanity,
| <phil-new...@ipal.net> declared in
| comp.infosystems.www.authoring.stylesheets:
|
|> So if an implementation were to re-arrange the order of items given in
|> a list with UL/LI, that would be OK?
|
| It shouldn't matter, no. For example a UA could (theoretically) provide
| the ability to automatically sort list items in alphabetical order. For
| an unordered list that would be fine. For an ordered list it wouldn't.
I usually want my lists to be in order, but generally do not want the
numbers. So I'll have to see if CSS can do that.
Keep in mind that I only raised the TABLE/TR/TD issue, and I did that since
that is the level of what I am working on right now. I was not concerned
with the list issue at this time because I could fall back to doing it the
way I have been doing it all along, and I would eventually get to that part
of CSS. I'm doing one thing at a time, and someone else raised the list
issue and I simply addressed it the best I can.
Here's a little unordered list:
It would help if:
* Answers given would include actual exact CSS code and not just say
"you need to understand ..."
* Online example pages would be the utmost minimum to illustrate just one
feature so people don't have to figure out what parts of the HTML and
CSS are really needed.
Steve Pugh
>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?
That's almost certaibly not a data table and hence should not be
marked up with HTML table elements.
>| 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".
>| 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.
> 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.
>| 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 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.
>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.
>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?
>| 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.
niels.f...@seies.de
> TABLE/TR/TD has, and maybe I could believe it's an implementatuon issue.
>
> For another issue with CSS, take a block of text in a _single_ DIV element
> and using CSS only, style that block so it appears with a drop shadow effect
> without changing the HTML at all. I had to add extra DIV elements to get it
> to work, and found that a couple other people doing the same thing did it
> the same way (though I went a step further and added yet another DIV to make
> an effect that raised and lowered the shadow effect based on hover). Better
> CSS would allow doing anything like that wihtout changing HTML at all. If
> the style needs more container context, then CSS should be able to logically
> include that.
>
> Here's one of the pages I was experimenting with:
> http://phil.ipal.org/usenet/ciwas/2006-04-30/shadow-boxes-in-tables.html
> Be careful with the top right and bottom left corners as they can result in
> the raising/lowering effect oscillating if you position the pointer on the
> pixels that move away.
I think you underestimate what's possible with CSS:
http://www.paradice-insight.us/tests/drop-shadow.html
It has it's problems, but shows that you _can_ adress complex (HTML)
tasks 'successfull' in CSS, also it shows that CSS develops into the
right direction anyway.
Regarding your 'table-problem' there is the grid-supporting
'display'-attribute in CSS3 which is better suited for grid than tables
are (try to make floating L- or U-forms with tables).
Ciao
Niels
niels.f...@seies.de
You're changing language-semantics here, this is
direction: ltb (gravity left, order top-to-bottom)
float: top
whereas western style is 'tlr'.
Also it goes into the direction of:
http://www.quirksmode.org/css/multicolumn.html
Both have the same 'problem', the restrictor is _height_
not _width_, but that's only natural behaviour (consistent
with the definition of direction in both cases).
> But if I have 2-dimentional data, then this is not the thing to be doing.
> So I'm still back to using TABLE/TR/TD, etc., for the 2-D stuff.
Ciao
Niels
phil-new...@ipal.net
| phil-new...@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-new...@ipal.net
That's not something I've ever heard of.
| Also it goes into the direction of:
|
| http://www.quirksmode.org/css/multicolumn.html
|
| Both have the same 'problem', the restrictor is _height_
| not _width_, but that's only natural behaviour (consistent
| with the definition of direction in both cases).
I don't really see any "problem" there. The multi-column stuff looks good.
I've curious why this wasn't in earlier versions of CSS. I'll bet that
when it is widely available, it will get used a lot.
phil-new...@ipal.net
|> Show me CSS2 coding that will produce tables with the same semantics that
|> TABLE/TR/TD has, and maybe I could believe it's an implementatuon issue.
|>
|> For another issue with CSS, take a block of text in a _single_ DIV element
|> and using CSS only, style that block so it appears with a drop shadow effect
|> without changing the HTML at all. I had to add extra DIV elements to get it
|> to work, and found that a couple other people doing the same thing did it
|> the same way (though I went a step further and added yet another DIV to make
|> an effect that raised and lowered the shadow effect based on hover). Better
|> CSS would allow doing anything like that wihtout changing HTML at all. If
|> the style needs more container context, then CSS should be able to logically
|> include that.
|>
|> Here's one of the pages I was experimenting with:
|> http://phil.ipal.org/usenet/ciwas/2006-04-30/shadow-boxes-in-tables.html
|> Be careful with the top right and bottom left corners as they can result in
|> the raising/lowering effect oscillating if you position the pointer on the
|> pixels that move away.
|
| I think you underestimate what's possible with CSS:
|
| http://www.paradice-insight.us/tests/drop-shadow.html
That middle one oscillates when you move the pointer just into the bottom
of it. I fixed the effect in my drop shadow boxes by enclosing everything
in an invisible outer box (DIV) that had the :hover on it's selector.
| It has it's problems, but shows that you _can_ adress complex (HTML)
| tasks 'successfull' in CSS, also it shows that CSS develops into the
| right direction anyway.
| Regarding your 'table-problem' there is the grid-supporting
| 'display'-attribute in CSS3 which is better suited for grid than tables
| are (try to make floating L- or U-forms with tables).
When will CSS3 be widely usable?
niels.f...@seies.de
> | You're changing language-semantics here, this is
> | direction: ltb (gravity left, order top-to-bottom)
> | float: top
> | whereas western style is 'tlr'.
>
> That's not something I've ever heard of.
It isn't reality, sadly. You may find an in depth discussion
about vertical text-flow here:
http://fantasai.inkedblade.net/style/discuss/vertical-text/
Pardon for not using the appropriate acronym, I wrote out of
my memory, it's "rtl" (left + top-down) and "ltr" (top + left-right).
Because all of this it quiet a mess, "float: top;" in "rtl" should
be the correct floating-equivalent of "float: left;" in "ltr", but as
you may see in:
http://www.w3.org/TR/css3-roadmap/
3.6 Box model / vertical -> Floating boxes to top/bottom of page
has no description, so I'm assuming that it will be named 'top'.
Ciao
Niels
niels.f...@seies.de
> | 'display'-attribute in CSS3 which is better suited for grid than tables
> | are (try to make floating L- or U-forms with tables).
>
> When will CSS3 be widely usable?
When something called 'consensus' will become widely
accepted ... :)
If I remember right CSS3 is not even a draft of concept.
Anyway, for me it's strange that 'text/css' is the only styling-
form available. I guess for some sites 'text/gamess' is more
appropriate (no offense! I really think different concepts need
different realizations, for ex. games are not really using qt3
for controling). An explanation can be that the CSS-idea is
so much manifest that you can't even _plug-in_ other styling-
languages into a browser (not to speak of scripting-languages,
I would love to have Rexx in FireFox).
Ciao
Niels
phil-new...@ipal.net
| languages into a browser (not to speak of scripting-languages,
| I would love to have Rexx in FireFox).
<offtopic topic="comp.programming">
It would be nice to have a universal programming API in various languages
for access to libraries of code to implement various scripting languages
so that a browser, or any other program, could make use of scripting tools.
A few languages do have some interfaces. But there is no universal one
that I've ever heard of that would allow an application like a browser to
access each different scripting language library with the same common API.
OTOH, given some of the APIs I've seen out there, it would probably end up
becoming another mess. Many of those APIs use methods (callbacks, longjmp)
that inhibit layering another library around it.
</offtopic>
Steve Pugh
>On Fri, 05 May 2006 19:37:07 +0100 Steve Pugh <st...@pugh.net> wrote:
>| phil-new...@ipal.net wrote:
>|>On Fri, 05 May 2006 08:10:01 +0100 Steve Pugh <st...@pugh.net> wrote:
>|>| 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.
The semantics of a table are "This is a table, there are relationships
between the items in the rows and columns as specified by the row and
column headers". Those semantics remain the same regardless of whether
the table is presented as a 2d grid on a screen/piece of paper, read
out in some way by a speech browser, linearised by a braile device,
stripped to its component pieces by a script and inserted into a
database, etc.
A grid does not have those semantics. A grid just has presentation, it
says nothing about what the dat _is_ but everything about how the data
_looks_.
I strongly suspect that you are not using the word semantics in the
same way as the rest of us. Which lets me make a terrible
meta-something joke and ask you "what do you mean by semantics?" ;-)
>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".
Probably for the best.
Steve Pugh
>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.
That becomes tricky if you want the table columns to have equal widths
(I'm assuming that the table should be 100% wide and not some fixed
pixel width). If the column widths are in the CSS then some
assimputions need to be made about the number of columns. If the
column widths are inline in the HTML then you start to bloat your
code.
The example I'm using gets around this by setting two classes on the
parent div. One sets up all the basic table presentation, and the
other sets up the column widths.
>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.
These come as standard with CSS tables just as they do with HTML
tables. Whatever examples you saw were probably using floats rather
than CSS tables.
Both can be worked around to a certain extent when using floats by use
of min-width styles (so that includes IE 7 but not Ie 6) but will
still break down in extreme cases.
>There may be other issues. In all, the way TABLE/TR/TD elements work in
>HTML must be retained.
Even the things that make tables a poor choice for web page layout
(the very rigidity you desire, oo er missus).
http://steve.pugh.net/test/css-table-demo.html
Note that all the cells in each row have the same height regardless of
the height of their contents. That each row stays together no matter
how narrow the window becomes and that the content always stays inside
the cells. The HTML is minimal, the CSS likewise.
My choice of ul for the rows and li for the cells was arbitrary but
ensures that thre's some measure of presentation even in IE which
doesn't support display: table.
Works as desired in FireFox and Opera and I hope it works in
Safari/Konqueror as well. IE, even IE 7, is a lost cause. Maybe in IE
8.
I've included a short block of code inside an IE conditional comment
that gives IE a basic floated layout instead. This demonstrates quite
clearly some of the shortcomings with floats for this sort of layout
and why MS really need to pull their finger out and implement CSS
tables (only eight years and counting since the spec was published).