bug? COL element very poor support in O7b1
Marek Mänd
<col style="width:200px;color:blue;font:60px Arial;">
<col style="width:500px;color:red;background:red;">
<tr>
<td>1-Igaunja =P</td><td>2-Latvia</td>
</tr><tr>
<td>1-Igaunja =P</td><td>2-Latvia</td>
</tr><tr>
<td>1-Igaunja =P</td><td>2-Latvia</td>
</tr>
</table>
the HTML above sets nicely font sizes and colors and
background color for the cells in the column in IEs.
However in Opera7b1 this COL element (about 4 year old HTML construct)
is still very poorly supported. Please note, the
COL(group) element is often the key to massive HTML code
size reduction - it is very unrational to specify
individually the attributes for EACH CELL,
even having each cell the CLASS attribute would be obvious
overkill in tables having 1000 rows...
That is - smbd file this bug in proper manner ;)
Rijk van Geijtenbeek
> <table border="1">
> <col style="width:200px;color:blue;font:60px Arial;">
> <col style="width:500px;color:red;background:red;">
> <tr>
> <td>1-Igaunja =P</td><td>2-Latvia</td>
> </tr><tr>
> <td>1-Igaunja =P</td><td>2-Latvia</td>
> </tr><tr>
> <td>1-Igaunja =P</td><td>2-Latvia</td>
> </tr>
> </table>
> the HTML above sets nicely font sizes and colors and
> background color for the cells in the column in IEs.
>
> However in Opera7b1 this COL element (about 4 year old HTML construct)
> is still very poorly supported.
See http://www.w3.org/TR/REC-CSS2/tables.html#q4
The browser is onyl supposed to apply a very limited numberof style
properties to column and columngroup elements.
So background and width is OK, and font isn't. I don't care that much about
font (in a column setting), but weirdly enough also 'text-align' isn't
allowed on columns.
--
Rijk van Geijtenbeek
nospam
(Microsoft Brain Damage) you should certainly expect the
proliferation of this deviations on the web pages out there.
I think that your goal should be a browser that works well
in most conditions than a perfectly compliant with every
detail of the standard.
Rijk van Geijtenbeek
> And is it that hard to add support? With so wide-spread MBD (Microsoft
> Brain Damage) you should certainly expect the proliferation of this
> deviations on the web pages out there.
>
> I think that your goal should be a browser that works well in most
> conditions than a perfectly compliant with every detail of the standard.
That is our goal in most cases. But I'd prefer to get the CSS 2 spec
changed.
--
Rijk van Geijtenbeek
Marek Mänd
> And is it that hard to add support?
I dont think it is hard. Its plain HTML. It is the core concept of the browser.
But as seen, Opera7b even supports far more load of IE proprietary JScript
features than Opera6. It is reasonable to ask - why waste developers time on that?
And indeed why to add proprietary scripting support, if javascript is simply a tool
to make pages more attractive - but it is not the basic thing.
The IE will add for sure even more proprietary scripting, does that mean Opera will
go for the iterations and add in years those new one to ? Why ??
The basic thing is adequately render HTML.
That is - better add IE-specific HTML rendering
(which in CSS4 might become the standard, as with many good things,
that are initially despised happen - they become widely accepted
and thus in te and also standard)
than IE-specific scripting
(most of the time scripting is turned off anyway by all browsers, so no use of that IE scripting support =) )
>With so wide-spread MBD (Microsoft Brain Damage) you should certainly
>expect the proliferation of this deviations on the web pages out there.
> I think that your goal should be a browser that works well
> in most conditions than a perfectly compliant with every
> detail of the standard.
Imagine you want in your 6 column * 1000 row table have each row have different font color/ font weight.
How do you achieve it now in Opera? By adding 6000 CSS class names ? Thats insane!
What if the table (procuct catalog would be even lenghtier?)
I feel, that IE model is just the thing that stands for HTML massive code reduction and
content and presentation segregation. It is so easy to have 6 COL elements with classnames
instead of ending up with 6000 classnames determening classname for each cell, which
are far more hard to maintain, change,manage... And when it comes to emulating IE specific
JScript in Opera you still cant hide then a column using CSS-display which is a simple thing in IE ;)
I THINK the whole issue about
http://www.w3.org/TR/REC-CSS2/tables.html#q4
is, that the spec doenst want to use plain peasant logic, which says
"similar kind of data is put in tables into same column".
"Same kind of data" also means for me, that most of the times it is presented visually
with the same style. That is most of the times you want apply style by columns
and special cases (sepcial prize offers) you may want to emphasize by giving style(class)
to the row (TR). And the peasant logic says - applied class to the TR has
higher specifity than the one applied to COL.
The whole thing I guess here in spec is abut CSS (selector) SPECIFITY
and browser vendors unwilligness to adapt-implement more complex rendering schema-principles
as this would be little bit more work to programmers, thus resulting in more
possible present rendering errors and varos implementations among different browsers.
That is the spec states intentionally so few, in order to avoid problems.
I think this thinking model is false.
Dont come to say, rthat Opera hast it proprieary CSS selectors... Just implementing
one column selector to do little more it is told is no crime.
Its all about specifity, and the time the spec was written so, was due to people beeing unwanting to
implement more complex algorithms. IE does it fine. And the HTML code is far more mainainable
so than by Opera. And the specs change. The change is caused by idea, that smth has to change
due to it can be done in better fashion. Good ideas are simple and trivial, yet so trivial hard to find,
as a mind trained to solve complex problems is not operable good amongs very simple tasks.
That is. I hope you will implement this as you see the difference in HTML having 6*1000 table ;)
Marek Mänd
And theres no room for innovation ? A slight more implementatiuon of the spec?
We could like in ten years review this thread and I am pretty sure, that sopmeday
some CSS version covers that, as this peasant locic is so intuitive.
Rijk van Geijtenbeek
> "nospam" <nos...@nospam.com> wrote in message
> news:1103_10...@news.opera.no...
>> And is it that hard to add support?
>
> I dont think it is hard. Its plain HTML.
No, we were talking about CSS. I agree it would be nice to support a little
more than than the spec says, but that is not the first thing to do. After
implementing the specs to the letter, Opera developers are implementing
things that are actually being used on pages our used visit. If you can
give some examples of 'normal' (non-test) sites that use font properties on
the COL selector in CSS, I could try to push for supporting this in Opera.
--
Rijk van Geijtenbeek
Marek Mänd
> more than than the spec says, but that is not the first thing to do. After
> implementing the specs to the letter, Opera developers are implementing
> things that are actually being used on pages our used visit. If you can
> give some examples of 'normal' (non-test) sites that use font properties on
> the COL selector in CSS, I could try to push for supporting this in Opera.
0) people usually dont know what they really want
1) people are too ignorant/careless to demand a thing that doesnt exist, yet is useful
2) you ought to make first a product to create a "artificial" need for that product.
Thus, it is currently not widely used due to it been supported "only" in IE.
Therefore people are due to non-peasant W3C CSS spec logic
in no position to require that feature to be implemented.
But hey, even having COL paddings,font applied would be nice....
Its all about CSS specifity and willigness to understand that the CSS2 spec was written
in year 1998 - that is 4 years and soon already 5 years ago, but the browsers are
developed much in that timeframe, and if one takes all by word it will be becoem stagnation ;)
One has to be innovative to create new proposals for standards...
I still thik it would make much more sense to support peasant logic -" IE specific CSS"
than IE specific useless prprietary scripting.
John Lewis
> But hey, even having COL paddings,font applied would be nice....
> Its all about CSS specifity and willigness to understand that the CSS2
> spec was written
> in year 1998 - that is 4 years and soon already 5 years ago, but the
> browsers are
> developed much in that timeframe, and if one takes all by word it will be
> becoem stagnation ;)
> One has to be innovative to create new proposals for standards...
Indeed, that's why CSS 2.1 and CSS 3 have been written and will eventually
become standards. (And you can't look at CSS 3 and tell me it's not
powerful or innovative enough. If anything, it's so complex that it won't
be implemented for years--sort of like CSS 2.) If any browser implements
whatever they want, that's no standard at all. IE has terrible standards
support and yet Microsoft adds proprietary extentions and implement
standards that are still working drafts. Yet they haven't even *attempted*
to fully support the *existing* standards. Opera, on the other hand, sticks
much better to the stardards, and when they do implement extensions they do
so correctly (well, they do now). Opera's small screen rendering is a good
example. It's not written in a W3C standard somewhere, but it's not harmful
and it is innovative. If IE can't implement a standard written, as you say,
a long time ago in 1998, what business to they have implementing an
unfinished standard still being rewritten today?
--
John Lewis
Marek Mänd
> become standards. (And you can't look at CSS 3 and tell me it's not
> powerful or innovative enough. If anything, it's so complex that it won't
> be implemented for years--sort of like CSS 2.) If any browser implements
> whatever they want, that's no standard at all. IE has terrible standards
> support and yet Microsoft adds proprietary extentions and implement
> standards that are still working drafts. Yet they haven't even *attempted*
> to fully support the *existing* standards. Opera, on the other hand, sticks
> much better to the stardards, and when they do implement extensions they do
> so correctly (well, they do now). Opera's small screen rendering is a good
> example. It's not written in a W3C standard somewhere, but it's not harmful
> and it is innovative. If IE can't implement a standard written, as you say,
> a long time ago in 1998, what business to they have implementing an
> unfinished standard still being rewritten today?
About to rant ;)
Yet I personally find Opera adding a lot more IE specific client side j(ava)scripting
stuff for a very bad concept. It for sure took time and resources a lot.
And the emulated support will NEVER be adequate with the functionality
offered by real IE. And what if IE will add even more components in its scripting
language, does that mean Opera is going along with those changes to come for sure?
Proprietary scripting is I guess far more complex thing than having all CSS attributes
inherited (which currently in Operas program code are just artificially restricted
with some array of names and few if-clauses in C++ code to some to meet the spec)
Coming back to scripting, then now Opera7 presumably supports the W3C methods on
dynamic content creation. As Mozilla, Netscape7 (6) been developed and becoming more widespread
and on websites teaching how to do javascripting the W3C model has been intensively
targeted at least 2 years for now, which results in scripts targeted and aware
of IE and W3C DOM both, and as Opera supports now W3C DOM Level 1
most common methods, then
allow me to astonish and ask - what use of that supporting IE model
(btw ancient IE5.0+ supports a good part of DOM Level1 ) in Opera is?
The time it took to implement this could have been yet spent for even more
fuller and stable W3C DOM ECMAScript binding implementation supporting,
or have had freed up resources to test the product in much more depth.
I sincerely hoped that Opera7 will throw away that IE-specific scripting,
but I guess it was the marketing people and not designers or programmes,
who pushed the support in as it lokked initially attractive and "nice sales argument"
Marek Mänd
Tallinn
Rijk van Geijtenbeek
..
> I still thik it would make much more sense to support peasant logic -" IE
> specific CSS"
> than IE specific useless prprietary scripting.
I'm already uncomfortable with all the effort our developers are putting
into supporting proprietary MSIE stuff that is actually being used a lot
onthe web. I don't want to encourage them to work on supporting proprietary
MSIE stuff that is not widely used. CSS filter-effects anyone?
--
Rijk van Geijtenbeek
Rijk van Geijtenbeek
..
> I sincerely hoped that Opera7 will throw away that IE-specific scripting,
> but I guess it was the marketing people and not designers or programmes,
> who pushed the support in as it lokked initially attractive and "nice
> sales argument"
Opera's goal is not to please webdesigners (whatever their feelings are
about MSIE-specific coding), but to deliver a great experience to
websurfers. Sometimes those two things aren't contradictory, but sometimes
they are.
--
Rijk van Geijtenbeek
Jernej Simončič
> CSS filter-effects anyone?
Here, here! (but only to get the PNG translucency to render properly in IE :)
--
Jernej Simončič, jernej....@guest.arnes.si
http://www2.arnes.si/~sopjsimo/
Panos Stokas
wrote:
>> I sincerely hoped that Opera7 will throw away that IE-specific
>> scripting,
> Opera's goal is not to please webdesigners (whatever their feelings are about
> MSIE-specific coding), but to deliver a great experience to websurfers.
That's a very important statement and in my opinion is the only way to go.
I like W3C's specifications but for a browser to restrict its visual
rendering on their validity is catastrophic. Opera must not be a
developer's tool, a visual validator, if it is to succeed. It must be a
browser that people use without being afraid of falling into sites they
won't be able to read, whether valid or not!
Marjolein Katsma
> See http://www.w3.org/TR/REC-CSS2/tables.html#q4
> The browser is onyl supposed to apply a very limited numberof style
> properties to column and columngroup elements.
>
> So background and width is OK, and font isn't. I don't care that much
> about font (in a column setting), but weirdly enough also 'text-align'
> isn't allowed on columns.
It _is_ allowed to specify col properties in a stylesheet - which is what
I do. NO effect in opera which apparently doesn't support it at all. About
time!
--
Marjolein Katsma - from Amsterdam, NL
* Help with HomeSite/Studio: http://hshelp.com/
* HomeSite Help Blogs: http://blogs.hshelp.com/
Samuli Lintula
news:Xns92EC5BA6314...@193.69.113.75:
> Rijk van Geijtenbeek wrote in
> news:oprg1kws...@news.opera.com:
>
>> See http://www.w3.org/TR/REC-CSS2/tables.html#q4
>> The browser is onyl supposed to apply a very limited numberof
>> style properties to column and columngroup elements.
>>
>> So background and width is OK, and font isn't. I don't care
>> that much about font (in a column setting), but weirdly
>> enough also 'text-align' isn't allowed on columns.
>
> It _is_ allowed to specify col properties in a stylesheet -
Yes, but only some properties, see See http://www.w3.org/TR/REC-
CSS2/tables.html#q4 :
"The following properties apply to column and column-group
elements:"
"'border'"
"'background'"
"'width'"
"'visibility'"
--
Opera 7 Known Bugs: http://www.gjk.dk/~krn/bugs/o7buglist.html
Mail/News: http://www.opera.com/support/helpfiles/m2tutorial.html
Reporting crashes:
http://www.opera.com/support/search/supsearch.dml?index=432
Reporting bugs: http://www.opera.com/support/bugs/
Jonny Axelsson
> Marjolein Katsma <nob...@spamcop.net> wrote in
> news:Xns92EC5BA6314...@193.69.113.75:
>>> So background and width is OK, and font isn't. I don't care
>>> that much about font (in a column setting), but weirdly
>>> enough also 'text-align' isn't allowed on columns.
>>
>> It _is_ allowed to specify col properties in a stylesheet -
>
> Yes, but only some properties, see See http://www.w3.org/TR/REC-
> CSS2/tables.html#q4 :
>
> "The following properties apply to column and column-group elements:"
>
> "'border'"
> "'background'"
> "'width'"
> "'visibility'"
HTML cols have no support for background and visibily (though some support
for border through the rules attribute), but they do have the align and
valign attributes. If you try this code, you'll find that Opera indeed
supports them.
<table border="1" cellspacing="0" cellpadding="5" width="50%">
<col align="right" valign="top"/>
<col align="center" valign="middle"/>
<col align="left" valign="bottom"/>
<col/>
<tr>
<td>Top-right</td>
<td>Center-middle</td>
<td>Bottom-left</td>
<td>This table cell contains a long sentence that should even wrap over
multiple lines, this is to make it clear where the other cells align
horizontally and vertically. </td>
</tr>
</table>
I don't think it makes much sense to have to hard-code the alignment in
HTML, and not use the corresponding CSS properties. I wouldn't find it
unreasonable to let elements with display table-column or table-column-
group 'influence' the text-align and vertical-align properties, even though
the specification says otherwise.
--
Jonny Axelsson,
Web Standards,
Opera Software
Marek Mänd
> Marjolein Katsma <nob...@spamcop.net> wrote in
> news:Xns92EC5BA6314...@193.69.113.75:
> > Rijk van Geijtenbeek wrote in
> > news:oprg1kws...@news.opera.com:
> >> See http://www.w3.org/TR/REC-CSS2/tables.html#q4
> >> The browser is onyl supposed to apply a very limited numberof
> >> style properties to column and columngroup elements.
> >> So background and width is OK, and font isn't. I don't care
> >> that much about font (in a column setting), but weirdly
> >> enough also 'text-align' isn't allowed on columns.
> > It _is_ allowed to specify col properties in a stylesheet -
> Yes, but only some properties, see See http://www.w3.org/TR/REC-
> CSS2/tables.html#q4 :
> "The following properties apply to column and column-group
> elements:"
> "'border'"
> "'background'"
> "'width'"
> "'visibility'"
Does it read "following properties x,y,z, ONLY AND ONLY"?
Does it forbid other properties to also be supported whereas
the UA still remains to support adequately the least what
is required by spec:
> "'border'"
> "'background'"
> "'width'"
> "'visibility'"
It only says: those MUST be implemented in order to
claim yourself CSS2 compliant UA, no others are *required* for that here.
Please DO not laconically cite that spec. If you do everything by
spec then you cant live - your main life content would be - asking
yourself - do I do it like they want to, thus resulting having
no life your own.
What if I have a product catalog with standard entry as
(sizes amounts models car colors, engine types,prizes etc)
a huge table and I want different colums have a little diferent
color of shades of gray - DO I REALLY HAVE TO SPELL THAT OUT FOR
EACH CELL - DO I ?? For Gds sakes - THIS IS TRULY HORRIBLE
ESPECIALLY IN THE TIME WHERE mobile computing devices-handhelds etc
are spreading and people are sittig behind slow data links and may
even pay for data transfer amount (per Megabyte)!
Such tables would be horrible then! I only want logicial -
have a piece of CSS, that defines colors, font-decoration,
and alignment per column. If anybody knows howto do that, please
post Operacompliant CSS here!
TABLES ARE ABOUT COLUMNAR DATA!! Why else would I put
things then into a table and anna organize and stylize them?
Or amd I wrong here? The question is - why cant I in reasonalbe fashion?!
Gee, this is a design true horrible flaw in HTML and Opera7b2
still doesnt support column colouring nor
text-align's (very vital feature!!) !
Using javascript I cant do collapsible columns (which IE can)...
THere goes usability and interactivity on web site... byebye... ;(
Rijk van Geijtenbeek
> Samuli Lintula <samuli....@utu.fi> wrote in message
> news:<Xns92EC6E0C33DDAs...@193.69.113.75>...
>> Marjolein Katsma <nob...@spamcop.net> wrote in
>> > It _is_ allowed to specify col properties in a stylesheet -
>> Yes, but only some properties, see See http://www.w3.org/TR/REC-
>> CSS2/tables.html#q4 :
>> "The following properties apply to column and column-group elements:"
>> "'border'" "'background'" "'width'" "'visibility'"
> Does it read "following properties x,y,z, ONLY AND ONLY"?
This is what it says:
"17.3 Column selectors
Table cells may belong to two contexts: rows and columns. However, in the
source document cells are descendants of rows, never of columns.
Nevertheless, some aspects of cells can be influenced by setting properties
on columns. The following properties apply to column and column-group
elements: "
This wording doesn't tell us that all properties are inherited. Note that
the link between column and cell is indirect, and normal inheritance is not
possible. So if the spec says that a limited number of properties can be
used on columns, it is reasonable to conclude that they didn't make that
list for nothing.
[..]
> What if I have a product catalog with standard entry as
> (sizes amounts models car colors, engine types,prizes etc)
> a huge table and I want different colums have a little diferent
> color of shades of gray - DO I REALLY HAVE TO SPELL THAT OUT FOR
> EACH CELL - DO I ?? For Gds sakes - THIS IS TRULY HORRIBLE
> ESPECIALLY IN THE TIME WHERE mobile computing devices-handhelds etc
> are spreading and people are sittig behind slow data links and may
> even pay for data transfer amount (per Megabyte)!
> Such tables would be horrible then! I only want logicial - have a piece
> of CSS, that defines colors, font-decoration, and alignment per column.
> If anybody knows howto do that, please
> post Operacompliant CSS here!
td {color: gray;}
td+td {color: lime;}
td+td+td {color: blue;}
td+td+td+td {color: yellow;}
td+td+td+td+td {color: red;}
> TABLES ARE ABOUT COLUMNAR DATA!! Why else would I put
> things then into a table and anna organize and stylize them? Or amd I
> wrong here? The question is - why cant I in reasonalbe fashion?!
>
> Gee, this is a design true horrible flaw in HTML
Not really - in HTML you can at least use align on columns. It's is CSS
that is limiting your options.
> and Opera7b2 still doesnt support column colouring nor text-align's (very
> vital feature!!) !
For the record: Mozilla also doesn't support these properties on columns.
While it makes perfect sense that not all properties can be used on columns
(positioning, margin and padding, for example), the absence of color and
text-align is hard to swallow. Go lobby the CSS Working Group, there's
still time to influence the decisions for CSS 2.1.
--
If you don't like having choices | Rijk van Geijtenbeek
made for you, you should start | Documentation & QA
making your own. - Neal Stephenson | mailto:ri...@opera.com
Marerk Mänd
>> Does it read "following properties x,y,z, ONLY AND ONLY"?
> This is what it says:
> This wording doesn't tell us that all properties are inherited. Note
> that the link between column and cell is indirect, and normal
> inheritance is not possible. So if the spec says that a limited number
> of properties can be used on columns, it is reasonable to conclude that
> they didn't make that list for nothing.
This letter is gonna be long, but please read it,
I have some valid points about element selectors.
Based on logic "the css group cant err on concepts"
(they are only humans ;)) ) I must agree
with You here, although I think, that that list is so short
because the CSS group wanted to avoid
unnecessary headache caused by wrong and incomplete CSS
implementations thus went along therefore
the easy way and simply specified very few and quite useless
(with exception of width) properties that are inherited.
More than any "border" the padding-left, padding-right is
vital in colums.
Do I really have to use spacer gifs in every cell or do I really
have to STILL make extra columns in table to fake spacing
right before column starts (that is add some extra "air" before
text in column) ?? That truly is horrible by design and even by
functionality - when you take in count the users with screen-
readers, which then must work on empty cells in that
"padding-faking-columns"
<table><tr>
<td width="5"><img src="spacer.gif" width="5" height="1" alt=""></td>
<td>THE ACTUAL CONTENT HAVING html-FAKED "padding-left"
...
</tr><tr>
<td width="5"><img src="spacer.gif" width="5" height="1" alt=""></td>
<td>THE ACTUAL CONTENT HAVING html-FAKED "padding-left"
...
...
> [..]
>> What if I have a product catalog with standard entry as
>> (sizes amounts models car colors, engine types,prizes etc)
>> a huge table and I want different colums have a little diferent
>> color of shades of gray - DO I REALLY HAVE TO SPELL THAT OUT FOR
>> EACH CELL - DO I ?? For Gds sakes - THIS IS TRULY HORRIBLE
>> ESPECIALLY IN THE TIME WHERE mobile computing devices-handhelds etc
>> are spreading and people are sittig behind slow data links and may
>> even pay for data transfer amount (per Megabyte)!
>> Such tables would be horrible then! I only want logicial - have a
>> piece of CSS, that defines colors, font-decoration, and alignment per
>> column. If anybody knows howto do that, please
>> post Operacompliant CSS here!
> td {color: gray;}
> td+td {color: lime;}
> td+td+td {color: blue;}
> td+td+td+td {color: yellow;}
> td+td+td+td+td {color: red;}
Lets take this for example
<html><head>
<title>ma(rek|nd) versus Rijk's advocating valid CSS support</title>
<style type="text/css">
td {color: gray;}
td+td {color: lime;}
td+td+td {color: blue;}
td+td+td+td {color: yellow;}
td+td+td+td+td {color: red;}
</style></head><body>
<table border="1">
<caption> THIS TABLE IS FINE </caption>
<tr>
<td>Row #1 Col #1</td>
<td>Row #1 Col #2</td>
<td>Row #1 Col #3</td>
<td>Row #1 Col #4</td>
<td>Row #1 Col #5</td>
</tr>
<tr>
<td>Row #2 Col #1</td>
<td>Row #2 Col #2</td>
<td>Row #2 Col #3</td>
<td>Row #2 Col #4</td>
<td>Row #2 Col #5</td>
</tr>
</table>
<hr />
<table border="1">
<caption> THIS TABLE IS N O T FINE </caption>
<tr>
<td>Row #1 Col #1</td>
<td>Row #1 Col #2</td>
<th>Row #1 Col #3</th>
<td>Row #1 Col #4</td>
<td>Row #1 Col #5</td>
</tr>
<tr>
<td>Row #2 Col #1</td>
<td>Row #2 Col #2</td>
<td>Row #2 Col #3</td>
<td>Row #2 Col #4</td>
<td>Row #2 Col #5</td>
</tr>
</table></body></html>
Although this works in Mozilla and Opera7b2(even in Opera6.05)
You see, in second table the "Row #1 Col #3" is not having
the same color as in the first one as due to Your proposed
selectors fail. And *all cells* in row that come after
TH are having
not the right "column color"
The practical problem is, the adjacent tag-selectors
WILL NEVER PROVIDE THE FLEXIBILITY, EASE OF USE AND
FAST MODIFICATIONS TO THE PRESENTATION. The only things
THAT DO GREAT DEAL ON CONTENT AND PRESENTATION LOGIC
SEGGREGATION are class selectors. To the last one adds power
the fact we can define multiple classes for an element
<element class="c1 c2 ..."
And in tables in conjuction with COL(GROUP) elements this
multiple CSS-classes really becomes VERY POWERFUL tool
to separate content from presentation attributes, resulting
also in drastical source code reduction as in the past
described by me (800 !times! shrinked by 126KB example)
Furthermore as I now demonstrated how Your CSS will fail
(which would not be the case with <COL class="...")
I demonstarte now it would be quite unimaginable to handle
that css:
td {color: gray;}
td+td {color: lime;}
td+td+td {color: blue;}
td+td+td+td {color: yellow;}
td+td+td+td+td {color: red;}
becomes in order "to be flexible" and compete with
"<col class=..."-solution into:
mycoll.td {color: gray; MOREATTRIBUTES.......}
mycoll.th {color: gray;}
mycoll.td+td {color: lime;}
mycoll.td+th {color: lime;}
mycoll.th+td {color: lime;}
mycoll.th+th {color: lime;}
mycoll.td+td+td {color: blue;}
mycoll.td+td+th {color: blue;}
mycoll.td+th+td {color: blue;}
mycoll.td+th+th {color: blue;}
mycoll.th+td+td {color: blue;}
mycoll.th+td+th {color: blue;}
mycoll.th+th+td {color: blue;}
mycoll.th+th+th {color: blue;}
mycoll.td+td+td+td {color: yellow;}
mycoll.td+td+td+th {color: yellow;}
mycoll.td+td+th+td {color: yellow;}
mycoll.td+td+th+th {color: yellow;}
mycoll.td+th+td+td {color: yellow;}
mycoll.td+th+td+th {color: yellow;}
mycoll.td+th+th+td {color: yellow;}
mycoll.td+th+th+th {color: yellow;}
mycoll.th+td+td+td {color: yellow;}
mycoll.th+td+td+th {color: yellow;}
mycoll.th+td+th+td {color: yellow;}
mycoll.th+td+th+th {color: yellow;}
mycoll.th+th+td+td {color: yellow;}
mycoll.th+th+td+th {color: yellow;}
mycoll.th+th+th+td {color: yellow;}
mycoll.th+th+th+th {color: yellow;}
mycoll.td+td+td+td+td {color: red;}
mycoll.td+td+td+td+th {color: red;}
mycoll.td+td+td+th+td {color: red;}
mycoll.td+td+td+th+th {color: red;}
mycoll.td+td+th+td+td {color: red;}
mycoll.td+td+th+td+th {color: red;}
mycoll.td+td+th+th+td {color: red;}
mycoll.td+td+th+th+th {color: red;}
mycoll.td+th+td+td+td {color: red;}
mycoll.td+th+td+td+th {color: red;}
mycoll.td+th+td+th+td {color: red;}
mycoll.td+th+td+th+th {color: red;}
mycoll.td+th+th+td+td {color: red;}
mycoll.td+th+th+td+th {color: red;}
mycoll.td+th+th+th+td {color: red;}
mycoll.td+th+th+th+th {color: red;}
mycoll.th+td+td+td+td {color: red;}
mycoll.th+td+td+td+th {color: red;}
mycoll.th+td+td+th+th {color: red;}
mycoll.th+td+th+td+td {color: red;}
mycoll.th+td+th+td+th {color: red;}
mycoll.th+td+th+th+td {color: red;}
mycoll.th+td+th+th+th {color: red;}
mycoll.th+th+td+td+td {color: red;}
mycoll.th+th+td+td+th {color: red;}
mycoll.th+th+td+th+th {color: red;}
mycoll.th+th+th+td+td {color: red;}
mycoll.th+th+th+td+th {color: red;}
mycoll.th+th+th+th+td {color: red;}
mycoll.th+th+th+th+th {color: red;}
Gee! How would one manage to handle this horrible stylesheet,
that ONLY does specify 5 colors accordingy for earch column!!
That CSS is truly horrible ! Editing it by hand is in
practice impossible.
What if I have some two tables more even with more columns
and attributes such as padding and margin.
WHAT A REDUNTANCY!
Rijk, as a human please aknowlege at least, taht although
my ideas arent valid & conform with W3C, You as a human
perfectly understand the absurdity, based on my examples,
of CSS when it comes to tables.
>> TABLES ARE ABOUT COLUMNAR DATA!! Why else would I put
>> things then into a table and anna organize and stylize them? Or amd I
>> wrong here? The question is - why cant I in reasonalbe fashion?!
>> Gee, this is a design true horrible flaw in HTML
> Not really - in HTML you can at least use align on columns. It's is CSS
> that is limiting your options.
My mistake, apologize, but I want to use as few HTML attributes
as possible due to content and layout seggregation thus
I dont want use <col align=""> but want use css equivalent -
BUT THERE ISNT ANY - this is insane and looks like the
power of css is a myth and hype!
>> and Opera7b2 still doesnt support column colouring nor text-align's
>> (very vital feature!!) !
> For the record: Mozilla also doesn't support these properties on columns.
so it is, but Mozilla isnt alfa and omega.
> While it makes perfect sense that not all properties can be used on
> columns (positioning, margin and padding, for example), the absence of
> color and text-align is hard to swallow. Go lobby the CSS Working Group,
> there's still time to influence the decisions for CSS 2.1.
Wanting to please you I would claim that all properties make
sense. The only property that could be under discussion
would be vertical-align as column cannot be vertically aligned,
but that vertical-align would following my dreams apply
to every cell in that column then and turn those cells like
HTML equivalent: <td valign="top"> or so.
What concerns CSS2.1 working group then my English is so poor,
that I am even happy You understand me and can reply to me =)
I have no influence and power on whatsoever company that
has a proprietary browser as a product, so there's no point
for me even to try with "standardization working group" as I
dont know the rules how to behave.
As You are on Operas payroll, at least You could do is
bring my examples out and introduce the issue to the people,
so they become active and motivated themselves to participate
on CSS-working group to overcome this issue.
And yes, I really belive my posting here is historical and
prophetical, in CSS4 you will find COL(GROUP)s inheriting
a lot more properties and everyb =))
Thanks for reading!
Rijk van Geijtenbeek
> Rijk van Geijtenbeek wrote:
>>> Does it read "following properties x,y,z, ONLY AND ONLY"?
>> This is what it says:
>> [..]
>> This wording doesn't tell us that all properties are inherited. Note
>> that the link between column and cell is indirect, and normal
>> inheritance is not possible. So if the spec says that a limited number
>> of properties can be used on columns, it is reasonable to conclude that
>> they didn't make that list for nothing.
> This letter is gonna be long, but please read it,
> I have some valid points about element selectors.
Excuse me for a lot of snippage!
>> [..]
>>> What if I have a product catalog with standard entry as
>>> (sizes amounts models car colors, engine types,prizes etc)
>>> a huge table and I want different colums have a little diferent
>>> color of shades of gray - DO I REALLY HAVE TO SPELL THAT OUT FOR
>>> EACH CELL - DO I ?? For Gds sakes - THIS IS TRULY HORRIBLE
>>> ESPECIALLY IN THE TIME WHERE mobile computing devices-handhelds etc
>>> are spreading and people are sittig behind slow data links and may
>>> even pay for data transfer amount (per Megabyte)!
>>> Such tables would be horrible then! I only want logicial - have a
>>> piece of CSS, that defines colors, font-decoration, and alignment per
>>> column. If anybody knows howto do that, please
>>> post Operacompliant CSS here!
>> td {color: gray;}
>> td+td {color: lime;}
>> td+td+td {color: blue;}
>> td+td+td+td {color: yellow;}
>> td+td+td+td+td {color: red;}
>
> Lets take this for example
>
> <table border="1">
> <caption> THIS TABLE IS N O T FINE </caption>
> <tr>
> <td>Row #1 Col #1</td>
> <td>Row #1 Col #2</td>
> <th>Row #1 Col #3</th>
> <td>Row #1 Col #4</td>
> <td>Row #1 Col #5</td>
> </tr>
> </table></body></html>
>
> Although this works in Mozilla and Opera7b2(even in Opera6.05)
> You see, in second table the "Row #1 Col #3" is not having
> the same color as in the first one as due to Your proposed
> selectors fail. And *all cells* in row that come after
> TH are having not the right "column color"
> The practical problem is, the adjacent tag-selectors
> WILL NEVER PROVIDE THE FLEXIBILITY, EASE OF USE AND
> FAST MODIFICATIONS TO THE PRESENTATION. The only things
> THAT DO GREAT DEAL ON CONTENT AND PRESENTATION LOGIC
> SEGGREGATION are class selectors. To the last one adds power
> the fact we can define multiple classes for an element
[..]
> What if I have some two tables more even with more columns
> and attributes such as padding and margin.
> WHAT A REDUNDANCY!
I have to say that tables normally are more structured than your example.
But I agree that using adjacent tag selectors is much less useful that the
new nth child selector introduced for CSS3.
td:nth-child(1), th:nth-child(1) { color: navy; }
td:nth-child(2), th:nth-child(2) { color: green; }
td:nth-child(3), th:nth-child(3) { color: maroon; }
td:nth-child(4), th:nth-child(4) { color: purple; }
td:nth-child(5), th:nth-child(5) { color: teal; }
A minor problem with this is, that no browser supports it right now.
[..]
> Rijk, as a human please aknowlege at least, that although
> my ideas arent valid & conform with W3C, You as a human
> perfectly understand the absurdity, based on my examples,
> of CSS when it comes to tables.
I think I've already said a few times that I agree with this :) And this
issue has been raised on the www-style mailing list some time ago.
Marek Mänd
> Excuse me for a lot of snippage!
No harm done, I am glad You read it =)
> I have to say that tables normally are more structured than your
> example. But I agree that using adjacent tag selectors is much less
> useful that the new nth child selector introduced for CSS3.
> td:nth-child(1), th:nth-child(1) { color: navy; }
> td:nth-child(2), th:nth-child(2) { color: green; }
> td:nth-child(3), th:nth-child(3) { color: maroon; }
> td:nth-child(4), th:nth-child(4) { color: purple; }
> td:nth-child(5), th:nth-child(5) { color: teal; }
> A minor problem with this is, that no browser supports it right now.
Sense of humour You have =)
Minor problem =)
Wouldnt it be easier now implement in Opera that COL thingie-
so that one could use it already now and not after 2 years ?
> [..]
>> Rijk, as a human please aknowlege at least, that although
>> my ideas arent valid & conform with W3C, You as a human
>> perfectly understand the absurdity, based on my examples,
>> of CSS when it comes to tables.
> I think I've already said a few times that I agree with this :)
> And this issue has been raised on the www-style mailing list some
> time ago.
well, I am a small brat and in order to behave I need
from time to time appreciation for my ideas =))
NRN