In article <e5vn9o$2n16$1@digitaldaemon.com>, Unknown W. Brackets says...
>
>Eric,
>
>My day job is web development.  I write HTML/CSS, and I do dynamic pages as well in various languages (primarily Flash or JavaScript client side, or PHP server side.)  I'm not strong in Flash, but I'm pretty strong in HTML, CSS, JavaScript, and PHP.
>
>I work with this every day, and I never use CSS hacks.  I'm consistently able to write CSS and HTML that works in Mozilla 1.0, Internet Explorer 5.0, and Safari 1.3 (and usually Opera, but we don't officially support that one.)  It isn't hard, people just jump to wanting to use hacks too quickly.
>
>In fact, I used to support Opera and Internet Explorer 4.0 officially when I worked freelance.
>
>Anyway, as far as I remember, the CSS spec does not include // as a comment, only /* */ multiline comments.  If I am correct, this means that Mozilla is doing the wrong thing here.
>
>Please see for reference: http://www.w3.org/TR/REC-CSS2/syndata.html#comments
>
>Thus, if Mozilla were correctly patched to better follow the spec in this case, it would break again.  Better to fix it the right way.
>
>Please do not take what I've said as condescending or snooty; I'll admit it flares me up a tiny bit when people start using CSS hacks since it's so easy not to, but understand that I wouldn't bother to say this if I thought it was falling on deaf ears or if I had no respect for your opinion.

Well, we're two of a kind then: my day job is also web-development. Thank you for taking the time to clarify where you're coming from on all this.  :)

I just hope that I didn't come off as arrogant or pushy in my last post; if I have, then I apologize.  Such was not my intention.

I respect your opinion, and you're right about the use of comments in the CSS spec.  And no, I take nothing but wisdom and position from your post - it was obvious from word one that you were speaking from solid experience.

Anyway, in light of all this, can you suggest a more compliant way to patch the site CSS?  In light of the non-compliant "//" comments being gracefully accepted (or just flat-out ignored as a malformatted line) by Mozilla, perhaps its best such that future browsers can still render the site correctly.

- EricAnderton at yahoo

WB, ignore that last paragraph of my last post.  It appears that the stylesheet has been patched according to the specficiation.

- EricAnderton at yahoo

I have; but I'm actually (as I said or meant to say) not sure whether Mozilla is doing the right thing or not.  I haven't read the part of the spec that deals with errors too thoroughly, and expect it's probably rather terse.

It may be that Mozilla is parsing it as a "//height" property, which may be the correct (or simply undefined by the spec) behavior.

Anyway, the main problem was that IE was rendering the whitespace outside the li tags (but inside the ul), and this seemed to be because the a elements had padding.

Weird.  I don't remember seeing that before.

-[Unknown]



> Anyway, in light of all this, can you suggest a more compliant way to patch the
> site CSS?  In light of the non-compliant "//" comments being gracefully accepted
> (or just flat-out ignored as a malformatted line) by Mozilla, perhaps its best
> such that future browsers can still render the site correctly.

Unknown W. Brackets wrote:
> My suggestions:
> 
> This won't affect anything, but you are using HTML 4, but your head element's children are all closed in the XHTML manner.  Just search and replace " />" with ">".
> 

Yes, there is also this one Walter. Always remember to validate the webpages:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.digitalmars.com%2Fd%2F


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

pragma wrote:
> Anyway, in light of all this, can you suggest a more compliant way to patch the site CSS?  In light of the non-compliant "//" comments being gracefully accepted (or just flat-out ignored as a malformatted line) by Mozilla, perhaps its best such that future browsers can still render the site correctly.

Some sites use server side scripting to serve different css-files to different browsers. That's one "more compliant" way to do that, but of course there are several alternatives. One common approach is to make style sheets as simple as possible to avoid more advanced features or to use simple inline css and do all the fancy things with Macromedia Flash. IMHO these pages look quite lame :-\

-- 
Jari-Matti

This is a bit cheeky but I was wondering if either of you have a solution to a problem I am having... (Feel free to ignore this post if you don't have the time or inclination, I won't mind, any help I get is a bonus)

The problem is this. We have an old set of pages, using html, using tables. The objective is to remove the html formatting and produce CSS that causes the pages to display exactly as they currently do. Thus far I have removed all the border="0" etc from the tables and other elements and added class="x" where I need to add formatting etc.

This all worked wonderfully except in one case:

//css file
table {
}

table.visible {
  background-color: ..etc..
  border: ..etc..
}

table.visible > tbody > tr > td {
  border: ..etc..
}

//html file
<table>
  <tr>
    <td><table class="visible">
      <tr>
        <td>A</td>
      </tr>
    </td>
  </tr>
</table>

As you probably know IE does not support the child selector ">", so, the rules to add borders to the internal table cells do not apply in IE, but do apply in opera, mozilla, etc. Further, if you use the descendant selector (a space) then they apply where they shouldn't in the reverse case (normal table inside table.visible) eg.

//CSS file
table.visible td {
  border: ..etc..
}

//HTML file
<table class="visible">
  <tr>
    <td><table>
      <tr>
        <td>A</td>
      </tr>
    </td>
  </tr>
</table>

I know the general consensus is that we shoudn't be using tables, and for new pages we don't. In this case we just want to be able to apply different styling to one old set of pages (without making too many changes to them) if coming to them from different locations.

Adding class="visible" to all the tr, td and th's seems heavy handed to me.

Any ideas?

Regan

Okay.  I would suggest putting a class on both tables, and then applying two rules at the same precedence:

table.visible td
table.notvisible td

Then they won't conflict.  Just don't use !important.  Or you could just do this with tables that are nested inside .visible tables.

Another option is to use IE7.  http://dean.edwards.name/IE7. Unfortunately, while it's amazing and great, your IE users will notice a slight increase in load time.  Some would say that's a good thing :P.

Also, I'm sorry, I have to say it - and here I disagree with most CSS zealots, but - tables are not evil.  If you're nesting tables, that's almost always wrong... but please for the love of goodness don't use divs for tabular data!

Does that help, or is that not really what you're looking for?

-[Unknown]


> This is a bit cheeky but I was wondering if either of you have a solution to a problem I am having... (Feel free to ignore this post if you don't have the time or inclination, I won't mind, any help I get is a bonus)
> 
> The problem is this. We have an old set of pages, using html, using tables. The objective is to remove the html formatting and produce CSS that causes the pages to display exactly as they currently do. Thus far I have removed all the border="0" etc from the tables and other elements and added class="x" where I need to add formatting etc.
> 
> This all worked wonderfully except in one case:
> 
> //css file
> table {
> }
> 
> table.visible {
>   background-color: ..etc..
>   border: ..etc..
> }
> 
> table.visible > tbody > tr > td {
>   border: ..etc..
> }
> 
> //html file
> <table>
>   <tr>
>     <td><table class="visible">
>       <tr>
>         <td>A</td>
>       </tr>
>     </td>
>   </tr>
> </table>
> 
> As you probably know IE does not support the child selector ">", so, the rules to add borders to the internal table cells do not apply in IE, but do apply in opera, mozilla, etc. Further, if you use the descendant selector (a space) then they apply where they shouldn't in the reverse case (normal table inside table.visible) eg.
> 
> //CSS file
> table.visible td {
>   border: ..etc..
> }
> 
> //HTML file
> <table class="visible">
>   <tr>
>     <td><table>
>       <tr>
>         <td>A</td>
>       </tr>
>     </td>
>   </tr>
> </table>
> 
> I know the general consensus is that we shoudn't be using tables, and for new pages we don't. In this case we just want to be able to apply different styling to one old set of pages (without making too many changes to them) if coming to them from different locations.
> 
> Adding class="visible" to all the tr, td and th's seems heavy handed to me.
> 
> Any ideas?
> 
> Regan

On Tue, 06 Jun 2006 21:25:03 -0700, Unknown W. Brackets <unknown@simplemachines.org> wrote:
> Okay.  I would suggest putting a class on both tables, and then applying two rules at the same precedence:
>
> table.visible td
> table.notvisible td
>
> Then they won't conflict.  Just don't use !important.  Or you could just do this with tables that are nested inside .visible tables.

Why didn't I think of that!? This sounds like it will suit me just fine, thanks!

> Another option is to use IE7.  http://dean.edwards.name/IE7. Unfortunately, while it's amazing and great, your IE users will notice a slight increase in load time.  Some would say that's a good thing :P.
>
> Also, I'm sorry, I have to say it - and here I disagree with most CSS zealots, but - tables are not evil.  If you're nesting tables, that's almost always wrong...

Why?

> but please for the love of goodness don't use divs for tabular data!

:)

> Does that help, or is that not really what you're looking for?

It looks to be perfect (I haven't actually tried it yet, I'm not at work today)

Regan

> -[Unknown]
>
>
>> This is a bit cheeky but I was wondering if either of you have a solution to a problem I am having... (Feel free to ignore this post if you don't have the time or inclination, I won't mind, any help I get is a bonus)
>>  The problem is this. We have an old set of pages, using html, using tables. The objective is to remove the html formatting and produce CSS that causes the pages to display exactly as they currently do. Thus far I have removed all the border="0" etc from the tables and other elements and added class="x" where I need to add formatting etc.
>>  This all worked wonderfully except in one case:
>>  //css file
>> table {
>> }
>>  table.visible {
>>   background-color: ..etc..
>>   border: ..etc..
>> }
>>  table.visible > tbody > tr > td {
>>   border: ..etc..
>> }
>>  //html file
>> <table>
>>   <tr>
>>     <td><table class="visible">
>>       <tr>
>>         <td>A</td>
>>       </tr>
>>     </td>
>>   </tr>
>> </table>
>>  As you probably know IE does not support the child selector ">", so, the rules to add borders to the internal table cells do not apply in IE, but do apply in opera, mozilla, etc. Further, if you use the descendant selector (a space) then they apply where they shouldn't in the reverse case (normal table inside table.visible) eg.
>>  //CSS file
>> table.visible td {
>>   border: ..etc..
>> }
>>  //HTML file
>> <table class="visible">
>>   <tr>
>>     <td><table>
>>       <tr>
>>         <td>A</td>
>>       </tr>
>>     </td>
>>   </tr>
>> </table>
>>  I know the general consensus is that we shoudn't be using tables, and for new pages we don't. In this case we just want to be able to apply different styling to one old set of pages (without making too many changes to them) if coming to them from different locations.
>>  Adding class="visible" to all the tr, td and th's seems heavy handed to me.
>>  Any ideas?
>>  Regan

Well, tables should generally be used for tabular data.  I'm a big advocate of semantic usage.

When I say "wrong", I just mean, "it makes your site not as semantic." Unfortunately, I sometimes end up using a table here or there to make a browser happy when there's no other way... but tables inside tables don't happen to often.

The practical reason is that tables are dynamically sized.  Browsers have to reflow the content, more than once, to draw a table.  It's much more involved than just a div.  This also often causes it to work better, though (depending on implementation.)

A lot of people who use CSS heavily or tell you to switch to CSS these days want, for some reason, to make sure "table" never appears on their entire page.  This freaks me out, because a table is the absolute best way to show... a table.

And the reflow problem isn't much of one unless it means recursively reflowing each nested table, so that's not a reason either.  Anyway, it's not long either.

Just my opinion.

Anyway, let me know if it works out :).

-[Unknown]


>> Also, I'm sorry, I have to say it - and here I disagree with most CSS zealots, but - tables are not evil.  If you're nesting tables, that's almost always wrong...
> 
> Why?

On Wed, 07 Jun 2006 07:25:54 -0700, Unknown W. Brackets <unknown@simplemachines.org> wrote:
> Anyway, let me know if it works out :).

It doesn't work. The page in particular on which it's a problem goes:

<table class="invisible">
<tr>
	<th>..etc..</th>
</tr>
<tr>
	<td><table class="invisible">
	<tr>
		<td><table class="visible">
		<tr>
			<td><table class="invisible">
			<tr>
				<td>..A..</td>
			</tr>
			<tr>
				<td>..B..</td>
			</tr>
			</table></td>
		</tr>
		<tr>
			<td>..C..</td>
		</tr>
		</table></td>
	</tr>
	<tr>
		<td>..etc..</td>
	</tr>
	</table>
	</td>
</tr>

The CSS is:

table.invisible {
  background-color: none;
  border: none;
}
table.invisible td {
  background-color: none;
  border: none;
}

table.visible {
  background-color: silver;
  border: 2px outset silver;
  border-spacing: 1px;
}
table.visible td {
  border: 1px inset silver;
  padding: 2px;
}

I want borders around the table enclosing A and B and around C, but not around A and B individually.

The above CSS puts borders around A and B individually, if I reverse the order, placing the ".visible" rules before the ".invisible" ones I get no borders at all.

:(

Regan.