CSS Safari Problem (Mac)

I'm trying to fix a CSS problem in Safari on Mac.

The following page displays fine on Firefox and IE on Windows and
Linux:
http://tinyurl.com/2w9nl3

The page has the following errors on Safari/Mac:
http://tinyurl.com/3yoj83
http://tinyurl.com/3xsdc2

The problem is in the footer section (marked in the code with
comments).

The CSS for that footer section is found at the bottom of this CSS
file:
http://tinyurl.com/32yk7p

Why isn't it displaying correctly in Safari/Mac?

Re: CSS Safari Problem (Mac)

In article
<1184363923.169851.19290@d55g2000hsg.googlegroups.com>,
0dev wrote:

> I'm trying to fix a CSS problem in Safari on Mac.
>
> The following page displays fine on Firefox and IE on Windows and
> Linux:
> http://tinyurl.com/2w9nl3
>
> The page has the following errors on Safari/Mac:
> http://tinyurl.com/3yoj83
> http://tinyurl.com/3xsdc2
>
> The problem is in the footer section (marked in the code with
> comments).
>
> The CSS for that footer section is found at the bottom of this CSS
> file:
> http://tinyurl.com/32yk7p
>
> Why isn't it displaying correctly in Safari/Mac?

In a sense, it does not display properly on any browser. Forget
the countless reported validation errors, you have managed to
somehow "fix" the font size of everything but "latest jazz news"
and the calendar. And then they do break at bigger text sizes.

--
dorayme

Re: CSS Safari Problem (Mac)

On Jul 13, 7:27 pm, dorayme wrote:
> In article

> > Why isn't it displaying correctly in Safari/Mac?
>
> In a sense, it does not display properly on any browser. Forget
> the countless reported validation errors, you have managed to
> somehow "fix" the font size of everything but "latest jazz news"
> and the calendar. And then they do break at bigger text sizes.

I didn't write the code except the footer links. I'm just trying to
get a footer that will display on Safari/Mac as well as FF and IE.

Re: CSS Safari Problem (Mac)

0dev wrote:
> On Jul 13, 7:27 pm, dorayme wrote:
>> In article
>
>>> Why isn't it displaying correctly in Safari/Mac?
>> In a sense, it does not display properly on any browser. Forget
>> the countless reported validation errors, you have managed to
>> somehow "fix" the font size of everything but "latest jazz news"
>> and the calendar. And then they do break at bigger text sizes.
>
> I didn't write the code except the footer links. I'm just trying to
> get a footer that will display on Safari/Mac as well as FF and IE.
>

Think about this for one moment, even though you did not write the other
code, if it is so malformed what are the chances that something you
*add* would display properly without repairing what precedes it?

Put this another way, no matter how well you construct a roof it will
not hold up if the building and foundation are poorly constructed.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

Re: CSS Safari Problem (Mac)

On Jul 13, 4:58 pm, 0dev wrote:
> I'm trying to fix a CSS problem in Safari on Mac.

> The following page displays fine on Firefox and IE on Windows and
> Linux:http://tinyurl.com/2w9nl3

Using the new Safari 3 for Windows on the XP OS, I see the problem
also. I do not see the problem on Opera. This sort of problem
sometimes can take a lot of time to solve. I would first get the page
to validate as html 4.01 at the w3c validator. This may not solve the
problem, buy at least you will have fewer potential problems to worry
about. I sometimes find it more easy to write a new page than modify
one someone else wrote. Everyone has their own style, and good
documentation of what someone else had in mind often is missing.



> The page has the following errors on Safari/Mac:http://tinyurl.com/3yoj83http://tinyurl.com/3xsdc 2
>
> The problem is in the footer section (marked in the code with
> comments).
>
> The CSS for that footer section is found at the bottom of this CSS
> file:http://tinyurl.com/32yk7p
>
> Why isn't it displaying correctly in Safari/Mac?

Re: CSS Safari Problem (Mac)

In article
<1184393542.459642.223940@57g2000hsv.googlegroups.com>,
cwdjrxyz wrote:

> On Jul 13, 4:58 pm, 0dev wrote:
> > I'm trying to fix a CSS problem in Safari on Mac.
>
> > The following page displays fine on Firefox and IE on Windows and
> > Linux:http://tinyurl.com/2w9nl3
>
> Using the new Safari 3 for Windows on the XP OS, I see the problem
> also. I do not see the problem on Opera. This sort of problem
> sometimes can take a lot of time to solve.

Yes, you can say that again.

Actually I came on back here to see if anyone has an answer to
something that I have wanted but could not figure: in FF
developer tools, you can outline elements and their css paths are
are displayed in a field at top. How to be able to copy paste the
text in the field?

I was going to make a point to the OP about the line .... I force
myself to type it from a screenshot I kept, something like:

html > body > div#wrapper > div#MainRed > table > tbody > tr >td
> table.footer-box> tbody > tr > td > table.footer-box > tbody> tr > td.listhostels > a

No point in making a rude point about it now. But does anyone
know a way of telling the field to stay still while the mouse
gets there to copy it? Happily the Mac screenshot controls of
Shift + Command + 4 "fixes" the mouse pointer while a snap is
taken...

--
dorayme

Re: CSS Safari Problem (Mac)

dorayme writes:

> Actually I came on back here to see if anyone has an answer to
> something that I have wanted but could not figure: in FF
> developer tools, you can outline elements and their css paths are
> are displayed in a field at top. How to be able to copy paste the
> text in the field?

Mouse over an element, then *without moving the mouse* use cmd-tab to
switch to another app. Then select the FF window's title bar to switch
back; because all of the "mouse moved" events were sent to another app,
and the mouse pointer is now outside the document area, the CSS path
field hasn't changed.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

Re: CSS Safari Problem (Mac)

In article ,
Sherm Pendley wrote:

> dorayme writes:
>
> > Actually I came on back here to see if anyone has an answer to
> > something that I have wanted but could not figure: in FF
> > developer tools, you can outline elements and their css paths are
> > are displayed in a field at top. How to be able to copy paste the
> > text in the field?
>
> Mouse over an element, then *without moving the mouse* use cmd-tab to
> switch to another app. Then select the FF window's title bar to switch
> back; because all of the "mouse moved" events were sent to another app,
> and the mouse pointer is now outside the document area, the CSS path
> field hasn't changed.
>
> sherm--

Sherm, you are a genius! There is no doubt about it. This is a
nice bit of knowledge indeed. Thank you.

You can say anything at all to me from now on and nothing will
ever take you off the special list I keep that excludes folk from
my attempts at withering criticisms, carping childish accusations
and fantastic posings...

--
dorayme

Re: CSS Safari Problem (Mac)

On 2007-07-13, 0dev wrote:
> I'm trying to fix a CSS problem in Safari on Mac.
>
> The following page displays fine on Firefox and IE on Windows and
> Linux:
> http://tinyurl.com/2w9nl3
>
> The page has the following errors on Safari/Mac:
> http://tinyurl.com/3yoj83
> http://tinyurl.com/3xsdc2
>
> The problem is in the footer section (marked in the code with
> comments).
>
> The CSS for that footer section is found at the bottom of this CSS
> file:
> http://tinyurl.com/32yk7p
>
> Why isn't it displaying correctly in Safari/Mac?

The footer is a table, whose width is set to 760px.

Inside its second row are three cells, with widths 316px, 225px, and one
with a div whose outer margin width is 215px. You've also got 15px of
padding on the first cell.

That lot adds up to 771px. So the browser asks itself, well which do you
want? 760px or 771px? Firefox picks 760px, Safari 771px. As it happens,
you wanted 760px so Safari guessed wrong on this occasion.

Easier to let the computer do what it's good at and add the numbers up
for you, so just delete "width=225" from the middle cell in that row. The
browser will give it whatever it can get away with to try to make the
whole thing 760px wide.

Re: CSS Safari Problem (Mac)

On Jul 13, 8:19 pm, "Jonathan N. Little"
wrote:
> 0dev wrote:
> > I didn't write the code except the footer links. I'm just trying to
> > get a footer that will display on Safari/Mac as well as FF and IE.
>
> Think about this for one moment, even though you did not write the other
> code, if it is so malformed what are the chances that something you
> *add* would display properly without repairing what precedes it?

I ran the page through two validators and most of the errors would not
affect layout, or they were errors with the validators. For example,
the W3C Validator says "end tag for element "HEAD" which is not
open." But if you look at the HEAD element it opens and closes
normally. Missing alt attributes and using "language" instead of
"type" for scripts shouldn't affect the layout. The ampersands in the
URLs shouldn't affect the layout.

Can Safari/Mac handle proprietary attributes like "TOPMARGIN"?

These are the main CSS rules for the footer:

/* For footer navigation */
..footer-box {
font-family: Arial, Helvetica, sans-serif;
color: #fff;
background-color: #830d12;
}
..listhostels a:link, .listhostels a:visited {
text-decoration: none;
color: #fff;
}
..listhostels a:hover {
text-decoration: underline;
color: #fff;
}
..footer-box h1, .footer-box h2 {
margin-top: 0;
padding-top: 0;
font-size: 12px;
font-family: Arial, Helvetica, sans-serif;
margin-bottom: 0;
padding-bottom: 0;
color: #fff;
}
..listhostels {
font-size: 9px;
margin-top: 0;
padding-top: 0;
}

Is there anything in there that Mac Safari handles differently than IE/
FF that would cause the problem shown in the images linked to in the
original post?

Re: CSS Safari Problem (Mac)

On 2007-07-16, 0dev wrote:
[...]
> These are the main CSS rules for the footer:
>
> /* For footer navigation */
> .footer-box {
> font-family: Arial, Helvetica, sans-serif;
> color: #fff;
> background-color: #830d12;
> }
> .listhostels a:link, .listhostels a:visited {
> text-decoration: none;
> color: #fff;
> }
> .listhostels a:hover {
> text-decoration: underline;
> color: #fff;
> }
> .footer-box h1, .footer-box h2 {
> margin-top: 0;
> padding-top: 0;
> font-size: 12px;
> font-family: Arial, Helvetica, sans-serif;
> margin-bottom: 0;
> padding-bottom: 0;
> color: #fff;
> }
> .listhostels {
> font-size: 9px;
> margin-top: 0;
> padding-top: 0;
> }
>
> Is there anything in there that Mac Safari handles differently than IE/
> FF that would cause the problem shown in the images linked to in the
> original post?

The difference between Safari and FF is not in those styles but in the
widths you've set on the table and on the cells in it. I explained this
in an earlier post.

Re: CSS Safari Problem (Mac)

On Jul 14, 6:36 am, Ben C wrote:
> On 2007-07-13, 0dev wrote:
> > Why isn't it displaying correctly in Safari/Mac?
>
> The footer is a table, whose width is set to 760px.
>
> Inside its second row are three cells, with widths 316px, 225px, and one
> with a div whose outer margin width is 215px. You've also got 15px of
> padding on the first cell.
>
> That lot adds up to 771px. So the browser asks itself, well which do you
> want? 760px or 771px? Firefox picks 760px, Safari 771px. As it happens,
> you wanted 760px so Safari guessed wrong on this occasion.
>
> Easier to let the computer do what it's good at and add the numbers up
> for you, so just delete "width=225" from the middle cell in that row. The
> browser will give it whatever it can get away with to try to make the
> whole thing 760px wide.

Thank you for your help. I've made the change and just need to find a
Mac to test it on.

Much appreciated...

Re: CSS Safari Problem (Mac)

On 2007-07-16, 0dev wrote:
> On Jul 14, 6:36 am, Ben C wrote:
>> On 2007-07-13, 0dev wrote:
>> > Why isn't it displaying correctly in Safari/Mac?
>>
>> The footer is a table, whose width is set to 760px.
>>
>> Inside its second row are three cells, with widths 316px, 225px, and one
>> with a div whose outer margin width is 215px. You've also got 15px of
>> padding on the first cell.
>>
>> That lot adds up to 771px. So the browser asks itself, well which do you
>> want? 760px or 771px? Firefox picks 760px, Safari 771px. As it happens,
>> you wanted 760px so Safari guessed wrong on this occasion.
>>
>> Easier to let the computer do what it's good at and add the numbers up
>> for you, so just delete "width=225" from the middle cell in that row. The
>> browser will give it whatever it can get away with to try to make the
>> whole thing 760px wide.
>
> Thank you for your help. I've made the change and just need to find a
> Mac to test it on.

I don't have a Mac either, but Konqueror (Linux) was doing the same
thing as your screenshot. Safari is based on Konqueror so it's probably
the same issue.

Re: CSS Safari Problem (Mac)

0dev wrote:
>
> errors with the validators. For example,
> the W3C Validator says "end tag for element "HEAD" which is not
> open." But if you look at the HEAD element it opens and closes
> normally.

FYI, that is not an error with the validator. It usually indicates an
error somewhere else that affects parsing. Fix the other error, and the
error goes away, too.

> Can Safari/Mac handle proprietary attributes like "TOPMARGIN"?

It's foolish to expect Safari, or any other browser, to "handle"
proprietary attributes in any way other than ignoring them altogether.

--
Berg

Re: CSS Safari Problem (Mac)

Scripsit Bergamot:

> 0dev wrote:
>>
>> errors with the validators. For example,
>> the W3C Validator says "end tag for element "HEAD" which is not
>> open." But if you look at the HEAD element it opens and closes
>> normally.
>
> FYI, that is not an error with the validator. It usually indicates an
> error somewhere else that affects parsing.

These days, such document errors typically reflect the common cluelessness
of mixing HTML and XHTML. Using e.g. in an HTML 4.01 document
means, by specifications, that the "/" closes the meta tag and ">" is
character data, which thus implicitly closes the head element and opens the
body element. This goes, of course, far above the heads of authors who blame
a validator for their own errors.

> It's foolish to expect Safari, or any other browser, to "handle"
> proprietary attributes in any way other than ignoring them altogether.

Well, things _could_ be worse. A proprietary attribute might get interpreted
by a browser other than its inventor's, in some other meaning.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Re: CSS Safari Problem (Mac)

On Jul 16, 5:01 pm, "Jukka K. Korpela" wrote:

> These days, such document errors typically reflect the common cluelessness
> of mixing HTML and XHTML. Using e.g. in an HTML 4.01 document
> means, by specifications, that the "/" closes the meta tag and ">" is
> character data, which thus implicitly closes the head element and opens the
> body element. This goes, of course, far above the heads of authors who blame
> a validator for their own errors.


No need to be rude. Thanks for the tip though.

The closed meta tag was copied and pasted from Google's Webmaster
Control Panel. I assumed that closing all elements in HTML was
optional (e.g. closing tag of

Re: CSS Safari Problem (Mac)

On Jul 19, 12:39 pm, 0dev wrote:
> On Jul 16, 5:01 pm, "Jukka K. Korpela" wrote:
>
> > These days, such document errors typically reflect the common cluelessness
> > of mixing HTML and XHTML. Using e.g. in an HTML 4.01 document
> > means, by specifications, that the "/" closes the meta tag and ">" is
> > character data, which thus implicitly closes the head element and opens the
> > body element. This goes, of course, far above the heads of authors who blame
> > a validator for their own errors.
>
> No need to be rude. Thanks for the tip though.
>
> The closed meta tag was copied and pasted from Google's Webmaster
> Control Panel. I assumed that closing all elements in HTML was
> optional (e.g. closing tag of

then the optional(in html)
closing tag such as

etc even when optional
when writing an xhtml 4.01 page. This helps prevent forgetting to do
this when writing xml or xhtml. Also tags in xhtml must be in lower
case, while case does not matter in html(although case is important in
javascript.) Hence I write tags in lower case when writing xtml 4.01
to help prevent making mistakes in xhtml or other languages where case
is important. Errors such as wrong case or wrong closing tag can be
difficult to catch. Many people tend to read what they thought they
wrote rather than what they actually wrote. One big advantage of the
W3C validator is that it often will catch such errors.

Re: CSS Safari Problem (Mac)

Well bust mah britches and call me cheeky, on Fri, 20 Jul 2007 02:29:31
GMT cwdjrxyz scribed:

> Also tags in xhtml must be in lower
> case, while case does not matter in html(although case is important in
> javascript.) Hence I write tags in lower case when writing xtml 4.01
> to help prevent making mistakes in xhtml or other languages where case
> is important.

I've been doing that nigh-on 10 years since I first read somewhere for some
reason it was a good idea (-according to the author), and, yes, it did
help.

--
Neredbojias
A self-made man who worships his creator

Re: CSS Safari Problem (Mac)

Scripsit cwdjrxyz:

> In html(notxhtml) closing of several tags such as

Re: CSS Safari Problem (Mac)

On Jul 20, 3:10 am, "Jukka K. Korpela" wrote:
> Scripsit cwdjrxyz:
>
> > In html(notxhtml) closing of several tags such as

Re: CSS Safari Problem (Mac)

Scripsit cwdjrxyz:

[ Pointless babbling and personal accusations etc. ]

Please keep using the same fake identity as long as you have nothing useful
to say and you publicly accuse people for rudeness and whatever, while you
yourself are making those accusations hiding behind a fake identity like a
coward.

Thank you in advance. You will that way make the best you obviously can to
make Usenet a more useful medium. Thank you again for your cooperation.

Re: CSS Safari Problem (Mac)

Well bust mah britches and call me cheeky, on Fri, 20 Jul 2007 18:10:11
GMT cwdjrxyz scribed:

> Perhaps, in summary, let he who is without guilt cast the first stone.
> But since this is Usenet, many likely are aware that the theme song
> for Usenet is the old song "Anything Goes".

No, that's "Everybody Must Get Stoned". (Dylan, you know. But Welsh, not
Irish, I heard.)

--
Neredbojias
Half lies are worth twice as much as whole lies.