www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - style sheets

reply Walter Bright <newshound digitalmars.com> writes:
I took out the:

	height=0;

lines in www.digitalmars.com/d/style.css, so it works in mozilla, but 
now it doesn't look right in Explorer (excessive vertical spacing).
Also, the tabs on the upper right are one pixel too low in mozilla.

Anyone know how to write a style sheet that will work in both?
Jun 04 2006
next sibling parent reply Johan Granberg <lijat.meREM OVEgmail.com> writes:
Walter Bright wrote:
 I took out the:
 
     height=0;
 
 lines in www.digitalmars.com/d/style.css, so it works in mozilla, but 
 now it doesn't look right in Explorer (excessive vertical spacing).
 Also, the tabs on the upper right are one pixel too low in mozilla.
 
 Anyone know how to write a style sheet that will work in both?
still broken in safari
Jun 04 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Johan Granberg wrote:
 Walter Bright wrote:
 Anyone know how to write a style sheet that will work in both?
still broken in safari
Can you suggest a fix? I don't have safari.
Jun 04 2006
parent reply Johan Granberg <lijat.meREM OVEgmail.com> writes:
Walter Bright wrote:
 Johan Granberg wrote:
 Walter Bright wrote:
 Anyone know how to write a style sheet that will work in both?
still broken in safari
Can you suggest a fix? I don't have safari.
adding a float:right; like this seemed to help div#content { margin-left:13em; /*border-left: 1px solid black;*/ padding-top: 1em; padding-left: 0em; float:right; }
Jun 04 2006
parent Johan Granberg <lijat.meREM OVEgmail.com> writes:
Johan Granberg wrote:
 Walter Bright wrote:
 Johan Granberg wrote:
 Walter Bright wrote:
 Anyone know how to write a style sheet that will work in both?
still broken in safari
Can you suggest a fix? I don't have safari.
adding a float:right; like this seemed to help div#content { margin-left:13em; /*border-left: 1px solid black;*/ padding-top: 1em; padding-left: 0em; float:right; }
forget what i said it was a bad browser cache
Jun 04 2006
prev sibling next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <e5vgbg$2efc$1 digitaldaemon.com>, Walter Bright says...
I took out the:

	height=0;

lines in www.digitalmars.com/d/style.css, so it works in mozilla, but 
now it doesn't look right in Explorer (excessive vertical spacing).
Also, the tabs on the upper right are one pixel too low in mozilla.

Anyone know how to write a style sheet that will work in both?
Rather convinently, IE will still process any rule that begins with '//'. As all browsers will follow the last declared instance of a rule, you can exploit both behaviors like so: foobar{ height: 1px; //height: 0px; } .. where Mozilla will obey the comment and use 1px, and IE will follow both and use 0px due to the ordering. While I don't advocate using stylesheet hacks like that, sometimes, its the fastest workaround available. - EricAnderton at yahoo
Jun 04 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
pragma wrote:
 Rather convinently, IE will still process any rule that begins with '//'.  As
 all browsers will follow the last declared instance of a rule, you can exploit
 both behaviors like so:
 
 foobar{
 height: 1px;
 //height: 0px;
 }
 
 .. where Mozilla will obey the comment and use 1px, and IE will follow both and
 use 0px due to the ordering.
Ok, that does seem to work. But in Mozilla, there is still excessive spacing above the "Community" and "Archives" thing, that isn't in Explorer.
Jun 04 2006
parent Brad Anderson <brad dsource.org> writes:
Walter Bright wrote:
 But in Mozilla, there is still excessive spacing above the "Community"
 and "Archives" thing, that isn't in Explorer.
to .navblock h2, add: margin-top: 0px;
Jun 04 2006
prev sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
CSS hacks are evil.  They are worse than the C++ preprocessor because 
they are undocumented.

In fact, they are bugs that should and most often are fixed in later 
versions.  For example, IE7 fixes many CSS bugs resulting in many of 
these sorts of hacks no longer working.

Please do not use CSS hacks.

-[Unknown]


 In article <e5vgbg$2efc$1 digitaldaemon.com>, Walter Bright says...
 I took out the:

 	height=0;

 lines in www.digitalmars.com/d/style.css, so it works in mozilla, but 
 now it doesn't look right in Explorer (excessive vertical spacing).
 Also, the tabs on the upper right are one pixel too low in mozilla.

 Anyone know how to write a style sheet that will work in both?
Rather convinently, IE will still process any rule that begins with '//'. As all browsers will follow the last declared instance of a rule, you can exploit both behaviors like so: foobar{ height: 1px; //height: 0px; } .. where Mozilla will obey the comment and use 1px, and IE will follow both and use 0px due to the ordering. While I don't advocate using stylesheet hacks like that, sometimes, its the fastest workaround available. - EricAnderton at yahoo
Jun 04 2006
parent reply pragma <pragma_member pathlink.com> writes:
In article <e5vkpt$2kf2$1 digitaldaemon.com>, Unknown W. Brackets says...
CSS hacks are evil.  They are worse than the C++ preprocessor because 
they are undocumented.
The problem you cite is due to the *exact* same phenomenon that web developers have to cope with. The more compilers/browsers you support, the more you have to dance around all the quirks and deviations from the specification. Unfortunately, the code that adheres to the strictest interpretation of any such supported standard will have the hardest time as they will have to bend over backwards avoiding all of these compatibility problems. Its possible, but not always practical. I agree that CSS hacks are a technique that should be avoided if possible. But a smart coder can always stack the rules such that they degrade *twoards* compliance. The hack I outlines does just this: if IE were patched to do the right thing, the page would still render correctly. :) - EricAnderton at yahoo
Jun 04 2006
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
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.

-[Unknown]


 In article <e5vkpt$2kf2$1 digitaldaemon.com>, Unknown W. Brackets says...
 CSS hacks are evil.  They are worse than the C++ preprocessor because 
 they are undocumented.
The problem you cite is due to the *exact* same phenomenon that web developers have to cope with. The more compilers/browsers you support, the more you have to dance around all the quirks and deviations from the specification. Unfortunately, the code that adheres to the strictest interpretation of any such supported standard will have the hardest time as they will have to bend over backwards avoiding all of these compatibility problems. Its possible, but not always practical. I agree that CSS hacks are a technique that should be avoided if possible. But a smart coder can always stack the rules such that they degrade *twoards* compliance. The hack I outlines does just this: if IE were patched to do the right thing, the page would still render correctly. :) - EricAnderton at yahoo
Jun 04 2006
next sibling parent reply pragma <pragma_member pathlink.com> writes:
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
Jun 05 2006
next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
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.
Jun 05 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
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
Jun 06 2006
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
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
Jun 06 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
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
Jun 06 2006
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
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?
Jun 07 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
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.
Jun 07 2006
parent reply Unknown W. Brackets <Unknown_member pathlink.com> writes:
Oh, sorry.  I didn't realize you meant you were nesting them four levels, etc.

In that case, I might have to recommend IE7, if you can't move to divs.  That
should definitely handle it, even if for the penalty (which will go away once
MSIE 7 is released.)

You could put classes on the tds themselves, which would fix this issue...

Sorry, there isn't a good solution to this problem for your usage after all,
that I know of.  Forgive me for misunderstanding.

-[Unknown]

In article <optasqjczv23k2f5 nrage.netwin.co.nz>, Regan Heath says...
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.
Jun 07 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 8 Jun 2006 02:02:16 +0000 (UTC), Unknown W. Brackets  
<Unknown_member pathlink.com> wrote:
 Oh, sorry.  I didn't realize you meant you were nesting them four  
 levels, etc.
Well.. I kinda implied only 2 levels initially. Don't you get the same problem with 2 levels as you do with 4? Both rules will be applied and the latter will override the former? (I haven't actually tested it..)
 In that case, I might have to recommend IE7, if you can't move to divs.  
 That
 should definitely handle it, even if for the penalty (which will go away  
 once MSIE 7 is released.)
I'll have a look at it. I'd never heard of it before now.
 You could put classes on the tds themselves, which would fix this  
 issue...
Yeah, that still seems overly heavy handed to me.. but then again it may be the only solution which actually works :( We can conditionally output css data based on browser, except I'd like to avoid taking that step as some browsers (opera) often masquerade as others (like IE)..
 Sorry, there isn't a good solution to this problem for your usage after  
 all, that I know of.  Forgive me for misunderstanding.
No worries. I can't really complain about help freely given, can I. ;) Regan
 In article <optasqjczv23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 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.
Jun 07 2006
prev sibling parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
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
Jun 05 2006
prev sibling parent pragma <pragma_member pathlink.com> writes:
WB, ignore that last paragraph of my last post.  It appears that the stylesheet
has been patched according to the specficiation.

- EricAnderton at yahoo
Jun 05 2006
prev sibling next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter Bright wrote:
 I took out the:
 
     height=0;
 
 lines in www.digitalmars.com/d/style.css, so it works in mozilla, but 
 now it doesn't look right in Explorer (excessive vertical spacing).
 Also, the tabs on the upper right are one pixel too low in mozilla.
 
 Anyone know how to write a style sheet that will work in both?
It's broken in IE7 http://img390.imageshack.us/img390/8088/dmdsite8wq.png
Jun 04 2006
prev sibling next sibling parent reply Brad Anderson <brad dsource.org> writes:
Walter Bright wrote:
 I took out the:
 
     height=0;
 
 lines in www.digitalmars.com/d/style.css, so it works in mozilla, but
 now it doesn't look right in Explorer (excessive vertical spacing).
 Also, the tabs on the upper right are one pixel too low in mozilla.
 
 Anyone know how to write a style sheet that will work in both?
div#navigation ul { list-style-type: none; margin-top: 0px; margin-left: 1ex; margin-right: 1ex; margin-bottom: 1ex; padding: 0; } div#navigation li { padding-left: 0; padding-bottom: 3px; } div#navigation a { text-decoration: none; padding: 3px; background-color: #eeeeee; color: black; } div#navigation a:hover { background-color: #dddddd; }
Jun 04 2006
parent Brad Anderson <brad dsource.org> writes:
Brad Anderson wrote:
 Walter Bright wrote:
 I took out the:

     height=0;

 lines in www.digitalmars.com/d/style.css, so it works in mozilla, but
 now it doesn't look right in Explorer (excessive vertical spacing).
 Also, the tabs on the upper right are one pixel too low in mozilla.

 Anyone know how to write a style sheet that will work in both?
div#navigation ul { list-style-type: none; margin-top: 0px;
although I think it looks better with the above line being 1ex, like the rest. so, you could do margin: 1ex; and be done with it.
         margin-left: 1ex;
         margin-right: 1ex;
         margin-bottom: 1ex;
         padding: 0;
 }
 div#navigation li
 {
         padding-left: 0;
         padding-bottom: 3px;
 }
 div#navigation a
 {
         text-decoration: none;
         padding: 3px;
         background-color: #eeeeee;
         color: black;
 }
 div#navigation a:hover
 {
         background-color: #dddddd;
 }
 
Jun 04 2006
prev sibling next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
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 ">".

I've made a diff with suggested changes.  These make it look better, in 
my opinion, on Internet Explorer and Firefox.  I will check it on Safari 
shortly, and possibly offer additional suggestions.

Most important is setting the default margin back to 0 for the form tag, 
fixing your immediate concern, and placing padding and such styles in 
the right place for ditsy IE.

Hope that helps,
-[Unknown]


 I took out the:
 
     height=0;
 
 lines in www.digitalmars.com/d/style.css, so it works in mozilla, but 
 now it doesn't look right in Explorer (excessive vertical spacing).
 Also, the tabs on the upper right are one pixel too low in mozilla.
 
 Anyone know how to write a style sheet that will work in both?
Jun 04 2006
next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Just to note, it looks fine in Safari with these changes; and thus looks 
the same in all those (most popular) browsers.

Unfortunately, it doesn't look exactly the same in Opera 7 and above, 
but the difference is extremely minor.  The black line at the top and 
the buttons above it have no padding between them.

An additional change I suggest is the following:

  .navblock h2
  {
  	font-size: 120%;
  	padding-top: 0px;
+	margin-top: 0;
  	margin-bottom: 0px;
  }

But this is a cosmetic change to all browsers that is based solely on my 
personal preference.

I should also note that the comments on the front page overflow the 
600px containing box with my fonts.  You can solve this either by adding 
a scrollbar or by extending the size of the box in this case (which is a 
pain in IE, but possible.)  Or you can hide the overflow (not my 
favorite) or leave it hanging out there.

-[Unknown]


 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 ">".
 
 I've made a diff with suggested changes.  These make it look better, in 
 my opinion, on Internet Explorer and Firefox.  I will check it on Safari 
 shortly, and possibly offer additional suggestions.
 
 Most important is setting the default margin back to 0 for the form tag, 
 fixing your immediate concern, and placing padding and such styles in 
 the right place for ditsy IE.
 
 Hope that helps,
 -[Unknown]
Jun 04 2006
parent Walter Bright <newshound digitalmars.com> writes:
Thanks, I've folded in your suggestions.
Jun 04 2006
prev sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
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
Jun 05 2006
prev sibling next sibling parent reply Carlos Santander <csantander619 gmail.com> writes:
Walter Bright escribió:
 I took out the:
 
     height=0;
 
 lines in www.digitalmars.com/d/style.css, so it works in mozilla, but 
 now it doesn't look right in Explorer (excessive vertical spacing).
 Also, the tabs on the upper right are one pixel too low in mozilla.
 
 Anyone know how to write a style sheet that will work in both?
Not good with Camino. Ok with Safari, although the buttons look a bit weird. -- Carlos Santander Bernal
Jun 04 2006
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Make sure to clear your cache.  When I first looked at it, it looked 
horrible in Firefox.  I had to press Ctrl-F5 (probably different in 
Camino; possibly Apple-R.)

I may check it at some point with Camino.  In my experience, it's rare 
to have problems with that browser because it's basically just Gecko.

-[Unknown]


 Walter Bright escribió:
 I took out the:

     height=0;

 lines in www.digitalmars.com/d/style.css, so it works in mozilla, but 
 now it doesn't look right in Explorer (excessive vertical spacing).
 Also, the tabs on the upper right are one pixel too low in mozilla.

 Anyone know how to write a style sheet that will work in both?
Not good with Camino. Ok with Safari, although the buttons look a bit weird.
Jun 04 2006
parent Carlos Santander <csantander619 gmail.com> writes:
Unknown W. Brackets escribió:
 Make sure to clear your cache.  When I first looked at it, it looked 
 horrible in Firefox.  I had to press Ctrl-F5 (probably different in 
 Camino; possibly Apple-R.)
 
 I may check it at some point with Camino.  In my experience, it's rare 
 to have problems with that browser because it's basically just Gecko.
 
 -[Unknown]
 
 
 Walter Bright escribió:
 I took out the:

     height=0;

 lines in www.digitalmars.com/d/style.css, so it works in mozilla, but 
 now it doesn't look right in Explorer (excessive vertical spacing).
 Also, the tabs on the upper right are one pixel too low in mozilla.

 Anyone know how to write a style sheet that will work in both?
Not good with Camino. Ok with Safari, although the buttons look a bit weird.
Wow, magic... lol... That did it. Thanks! -- Carlos Santander Bernal
Jun 04 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Ok, I pretty much dislike the new Digitals Mars D site layout. Am I the 
only one?
I don't like on-mouse-over highlighting of any kind for functional 
websites (pointless eyecandy?) Also, the highlighted area doesn't even 
seem to be well centered (or framed) around it's respective text.
And there are "empty link spaces" between (all) menu entries, that is, 
areas where there is no hyperlink/menu-selection (I've found that that 
bothers me, although this issue could be just change-nausea(unlikely 
though)).
Plus, I don't like the "button" look of the "Home | Downloads | Search | 
D | Comments" header, as the buttons look ugly.


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jun 12 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bruno Medeiros" <brunodomedeirosATgmail SPAM.com> wrote in message 
news:e6ke0t$30ub$1 digitaldaemon.com...

 I don't like on-mouse-over highlighting of any kind for functional 
 websites (pointless eyecandy?)
On the contrary, feedback like that often improves the experience for graphical interfaces. It's not "pointless eyecandy," it's letting you know what you can interact with by showing it in an interactive way. We get the same kind of feedback from things like keyboard keys; they kind of wiggle if you put your finger on them, and they make a nice "click" and have a good springiness when pushed. Feedback is an important part of graphical interface design as well.
 Also, the highlighted area doesn't even seem to be well centered (or 
 framed) around it's respective text.
Not sure what you mean. Maybe it's a browser display issue?
 And there are "empty link spaces" between (all) menu entries, that is, 
 areas where there is no hyperlink/menu-selection (I've found that that 
 bothers me
The alternative is cramming all the links together, which looks awful.
 Plus, I don't like the "button" look of the "Home | Downloads | Search | D 
 | Comments" header, as the buttons look ugly.
They do look a bit ugly.
Jun 12 2006
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Jarrett Billingsley wrote:
 "Bruno Medeiros" wrote:
 
I don't like on-mouse-over highlighting of any kind for functional 
websites (pointless eyecandy?)
On the contrary, feedback like that often improves the experience for graphical interfaces. It's not "pointless eyecandy," it's letting you know what you can interact with by showing it in an interactive way. We get the same kind of feedback from things like keyboard keys; they kind of wiggle if you put your finger on them, and they make a nice "click" and have a good springiness when pushed. Feedback is an important part of graphical interface design as well.
IMHO, too, on-mouse-over highliting is convenient. AS LONG AS the designer didn't make the links otherwise hard notice within text. O-m-o is also very good for the visually or motorically impaired. (Ever tried to surf badly decorated sites after a "night out" and with sore eyes?)
Jun 13 2006
prev sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Jarrett Billingsley wrote:
 "Bruno Medeiros" <brunodomedeirosATgmail SPAM.com> wrote in message 
 news:e6ke0t$30ub$1 digitaldaemon.com...
 
 I don't like on-mouse-over highlighting of any kind for functional 
 websites (pointless eyecandy?)
On the contrary, feedback like that often improves the experience for graphical interfaces. It's not "pointless eyecandy," it's letting you know what you can interact with by showing it in an interactive way. We get the same kind of feedback from things like keyboard keys; they kind of wiggle if you put your finger on them, and they make a nice "click" and have a good springiness when pushed. Feedback is an important part of graphical interface design as well.
The thing that "let's you know what you can interact with" is called the hyperlink text underline, a standard issue of HTML, and is a better feedback.
 Also, the highlighted area doesn't even seem to be well centered (or 
 framed) around it's respective text.
Not sure what you mean. Maybe it's a browser display issue?
No it's not a browser display issue. Hum, I didn't explain myself too clearly. The left side of the highlighted area starts just about where the text starts, which doesn't look good, In My UI Opinion. To see what I think should look better, see the page with the attached style.css (tested for IE and Firefox).
 And there are "empty link spaces" between (all) menu entries, that is, 
 areas where there is no hyperlink/menu-selection (I've found that that 
 bothers me
The alternative is cramming all the links together, which looks awful.
No it doesn't (look awful). Even if it did, it didn't matter for the point. I'm not asking that the links have little vertical interval, I just want the vertical interval to be all or mostly "link" space, that is, with no blank, non-link spaces.
 Plus, I don't like the "button" look of the "Home | Downloads | Search | D 
 | Comments" header, as the buttons look ugly.
They do look a bit ugly.
Indeed. -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jun 14 2006