CSS Safari Problem (Mac)

0

0dev

D

dorayme

0dev said:
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.
 
0

0dev

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.[/QUOTE]

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.
 
J

Jonathan N. Little

0dev said:
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.
[/QUOTE]

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.
 
C

cwdjrxyz

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.
 
D

dorayme

cwdjrxyz said:
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. <g>

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...
 
S

Sherm Pendley

dorayme said:
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--
 
D

dorayme

Sherm Pendley said:
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...
 
B

Ben C

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.
 
0

0dev

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?
 
B

Ben C

On 2007-07-16 said:
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.
 
0

0dev

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...
 
B

Ben C

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.
 
B

Bergamot

0dev said:
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
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.
 
J

Jukka K. Korpela

Scripsit Bergamot:
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. <meta ... /> 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.
 
0

0dev

These days, such document errors typically reflect the common cluelessness
of mixing HTML and XHTML. Using e.g. <meta ... /> 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 </p> is optional).
 
C

cwdjrxyz

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 </p> is optional).

In html(notxhtml) closing of several tags such as <p></p> is optional.
However in xml based languages, everything must be closed. This is one
of the most important things to do, especially for many small devices,
some of which do not even understand html and which often will not
work if everything is not closed.. In the case of xhtml, many tags are
carried over from html as well as some pure xml ones are used. When a
tag has an optional closing tag such as <p> then the optional(in html)
closing tag such as </p> must be used. When a tag such as <img blah>
has no closing tag in html, the tag must be self closed in xhtml such
as <img blah />. Actually the space between blah and / is there for
practical reasons, since some older browsers, and a few not so old
ones, will not understand the tag properly without the space. In many
pure xml languages, such as SMIL, no space is required. Most PC
browsers do not understand W3C SMIL 2 properly, although reader or
viewer programs for it, including recent Real players do. IE6 does
support a very watered down version of SMIL that works on IE browsers
only. The W3C validator often will fault you if you use a self closing
tag in an html program. This is correct, because it is not part of
html. However, many, if not most, recent browsers in wide use will
still work properly if you slip a self closed xhtml tag into a html
4.01 document. I am in the habit of closing <p> 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.
 
N

Neredbojias

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.
 
J

Jukka K. Korpela

Scripsit cwdjrxyz:
In html(notxhtml) closing of several tags such as <p></p> is optional.

It seems that you don't know what "tag" means. Besides, you are not using
any paragraph structure in your Usenet message.
However in xml based languages, everything must be closed. This is one
of the most important things to do, especially for many small devices,
some of which do not even understand html and which often will not
work if everything is not closed..

People using such devices won't have a great experience on the Web anyway,
since the vast majority of web pages are nowhere near valid XHTML, or even
"well-formed XML".

Yet the point is what I wrote in my message that you responded to, and
indirectly quoted (as a quote inside a quote), though without having
anything to say on my point: mixing HTML 4.01 and XHTML 1.0 is clueless. And
as exemplified in this thread, it often results from copying markup without
understanding it or the bigger context.
 
C

cwdjrxyz

Scripsit cwdjrxyz:


It seems that you don't know what "tag" means. Besides, you are not using
any paragraph structure in your Usenet message.


People using such devices won't have a great experience on the Web anyway,
since the vast majority of web pages are nowhere near valid XHTML, or even
"well-formed XML".

This may be so where you live, but where I live very many people use
small devices. Many of these people have used a PC for a long time. A
few have used top main frame computers such as a Cray, such as
installed in the computing building of a major petroleum company a few
blocks from where I live.
Yet the point is what I wrote in my message that you responded to, and
indirectly quoted (as a quote inside a quote), though without having
anything to say on my point: mixing HTML 4.01 and XHTML 1.0 is clueless. And
as exemplified in this thread, it often results from copying markup without
understanding it or the bigger context.

In an answer to your comments, Odev gave information that you do not
quote here. It is:

_______________________________________________________________________________

These days, such document errors typically reflect the common cluelessness
of mixing HTML and XHTML. Using e.g. <meta ... /> 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 </p> is optional)

__________________________________________________________________________

Some others than Odev might consider your response to this and some
other posts from you rude. However, one might ask why your responses
should be considered very important. Surely someone with such an
attitude should write nearly perfect web pages. See below.
The main page to the site that you quote above has no errors. I assume
the site belongs to you, or perhaps a relative, because jkorpela is in
the url. If one looks at the many pages in the above site using the
W3C html validator, one finds quite a few errors. Surely someone
offering minute details and opinions on writing web pages should use
completely valid html in the many pages describing this, regardless of
who owns the pages. Below is a listing of the number of errors, if
any, found in the mentioned site.

http://www.cs.tut.fi/~jkorpela/www.html - 6 errors
http://www.cs.tut.fi/~jkorpela/internet/index.html - 1 error
http://www.cs.tut.fi/~jkorpela/comm/index.html - 1 error
http://www.cs.tut.fi/~jkorpela/chars/index.html - 3 errors
http://www.cs.tut.fi/~jkorpela/chars/index.html - 3 errors
http://www.cs.tut.fi/~jkorpela/lang/index.html - 1 error
http://www.cs.tut.fi/~jkorpela/mathem/index.html - 1 error
http://www.cs.tut.fi/~jkorpela/soft/index.html - 2 errors
http://www.cs.tut.fi/~jkorpela/prog/index.html - 3 errors
http://www.cs.tut.fi/~jkorpela/legal/index.html - 1 error
http://www.cs.tut.fi/~jkorpela/misc/index.html - 3 errors

http://www.cs.tut.fi/~jkorpela/wwwfi.html - no errors
http://www.cs.tut.fi/~jkorpela/internetfi/index.html - 1 error
http://www.cs.tut.fi/~jkorpela/viest/index.html - no errors
http://www.cs.tut.fi/~jkorpela/merkit/index.html - 1 error
http://www.cs.tut.fi/~jkorpela/normit/index.html - no errors
http://www.cs.tut.fi/~jkorpela/kielet/index.html - no errors
http://www.cs.tut.fi/~jkorpela/matikka/index.html - no errors
http://www.cs.tut.fi/~jkorpela/softa/index.html - 2 errors
http://www.cs.tut.fi/~jkorpela/ohjelmointi/index.html - no errors
http://www.cs.tut.fi/~jkorpela/lait/index.html - no errors
http://www.cs.tut.fi/~jkorpela/muut/index.html - no errors

The pages in Finnish have fewer errors than those in English. However,
I would guess that far more people read the English pages than the
Finnish ones. Actually there are few errors compared to much of what
you find on the web. I recently looked at a page on MySpace.com that
had well over 200 validation errors, and most of these were made in
the MySpace code, not extra code added by the member of MySpace.

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".
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,537
Members
45,020
Latest member
GenesisGai

Latest Threads

Top