Problems with display in Opera
Jeremy Clulow
looks fine in IE5+ and Netscape 6, but there are some real problems with
Opera (we're using 5.12). CSS experts will probably recognise them. Perhaps
I could be pointed to the possible solutions. Thanks.
ps We'll be tweeking the @import stuff a little later for Netscape 4 users,
so apologies for the problems there.
--
------------------------------------------------------------
Jeremy Clulow, Webs Wonder Design
jer...@webswonder.net
http://www.webswonder.net
Tel: 01239 698488
------------------------------------------------------------
Jan Roland Eriksson
<jer...@webswonder.net> wrote:
>Our new site at
>
>www.cambrianorganics.com
>
>looks fine in IE5+ and Netscape 6, but there are some real problems with
>Opera (we're using 5.12).
You may want to start with that invalid "comment" declaration you have
at approx lines 14-16 in the source.
<!-- Hide from old browsers
<!--
- - ^^ [1]
function breakOut() {
if (self != top)
window.open("my URL","_top","");
}
// -->
[1] Your initial "comment" ends at those ^^ and the rest of it
becomes "something else".
Really you should not use XHTML in the first place. It gives nothing
of advantage over HTML4.01 especially not at the transitional level
where the target is to really tweak popular wowsers.
--
Rex .. <r...@css.nu> .. <http://css.nu/>
Jeremy Clulow
|| On Sun, 21 Oct 2001 13:24:15 +0100, Jeremy Clulow
|| <jer...@webswonder.net> wrote:
||
|| >Our new site at
|| >
|| >www.cambrianorganics.com
|| >
|| >looks fine in IE5+ and Netscape 6, but there are some real problems with
|| >Opera (we're using 5.12).
||
|| You may want to start with that invalid "comment" declaration you have
|| at approx lines 14-16 in the source.
||
Oops!....now removed.
|| Really you should not use XHTML in the first place. It gives nothing
|| of advantage over HTML4.01 especially not at the transitional level
|| where the target is to really tweak popular wowsers.
I'm trying to adhere to XHTML because:
a. I'm trying to look forward not backwards.
b I'm hoping to make my code a bit more "future proof"
c I use "HTML Tidy" within Homesite which seems to do a god job of
improving and formatting code and "converting to XHTML is one of the
options
Are you saying that I am misguided in my aspirations?
ps. Changing the DTD made no difference to the Opera layout problem ;-(
Cheers,
Jeremy
Alan J. Flavell
> I'm trying to adhere to XHTML because:
>
> a. I'm trying to look forward not backwards.
>
> b I'm hoping to make my code a bit more "future proof"
You might want to re-examine your reasons. I can certainly see the
argument for using an XML-based structural markup, which for practical
reasons you would then "render" into XHTML for delivery to today's
wowsers.
I can't see any argument based on feelgoods like "forward looking" and
"future proof" that supports actually authoring in XHTML1.* as
opposed to HTML4.01. I can see some _other_ arguments for doing that,
as we see in a moment...
But I'd say there's a justifiable worry that XHTML is the thin end of
a wedge, that rates to be used to turn XML into the same mess as
HTML-du-jour became. XML was meant to be an antidote to tag soup and
HTML-du-jour. Remember the original requirement of XML, that an
invalid document must result in termination of parsing? That was
mandatory, and for good reason; but just you try telling a browser
designer that in the face of an invalid document they are required to
give up, and should not try to display a rendering, and I reckon I
know what kind of answer you're going to get.
There's just far too much invested (well, I shouldn't say "invested",
I probably should say "diverted") into recovering from defective
markup and attempts at DWIM-ery. In turn there are far too many
document authors who (knowingly or not) are relying on that error
recovery, and get quite stroppy when another browser recovers in a
different way than the one they "designed for".
> c I use "HTML Tidy" within Homesite which seems to do a god job of
> improving and formatting code and "converting to XHTML is one of the
> options
Indeed, the ability to use XML-based tools is an entirely reasonable
argument for moving to an XML-based markup. If you have definite aims
to do that with HTML, then OK.
But don't go for XHTML just because it's sexier than HTML4.01.
> Are you saying that I am misguided in my aspirations?
We actually don't know what your _aspirations_ are. We only know
what you said your justification was.
And the current sig seems apt ;-)
cheers
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
- Bjoern Hoehrmann
Jeremy Clulow
<fla...@mail.cern.ch> wrote:
|| I can't see any argument based on feelgoods like "forward looking" and
|| "future proof" that supports actually authoring in XHTML1.* as
|| opposed to HTML4.01. I can see some _other_ arguments for doing that,
|| as we see in a moment...
My reasons are more than just "feelgood". If a W3C standard has been
agreed, and that standard is the goal for web authors, then I can't see any
good reason for not trying to move in that direction. That's what I meant
by "aspiration". Unless of course browsers just can't recognise or display
the code or the format (perhaps PNG and SVG are examples of this).
3 years ago when few web authors were incorporating CSS into their sites, I
took the bull by the horns and found ways of making more use of them,
although browser support was then poor. By taking XHTML seriously now, I'm
hopefully improving my skills at separating structure from formatting.
||
|| But I'd say there's a justifiable worry that XHTML is the thin end of
|| a wedge, that rates to be used to turn XML into the same mess as
|| HTML-du-jour became. XML was meant to be an antidote to tag soup and
|| HTML-du-jour. Remember the original requirement of XML, that an
|| invalid document must result in termination of parsing? That was
|| mandatory, and for good reason; but just you try telling a browser
|| designer that in the face of an invalid document they are required to
|| give up, and should not try to display a rendering, and I reckon I
|| know what kind of answer you're going to get.
I've no problems with parsing stopping at the first error - my skills would
improve very rapidly, even though I'd have an empty portfolio for the first
month or two ;-)
|| > c I use "HTML Tidy" within Homesite which seems to do a god job of
|| > improving and formatting code and "converting to XHTML is one of the
|| > options
||
|| Indeed, the ability to use XML-based tools is an entirely reasonable
|| argument for moving to an XML-based markup. If you have definite aims
|| to do that with HTML, then OK.
Without TIDY I probably wouldn't be attempting XHTML at this stage, becasue
at the end of the day, I need to work to commercial deadlines
|| But don't go for XHTML just because it's sexier than HTML4.01.
I can't imagine what "sexier" could mean in this context - if I started
finding markup sexy, my wife would definitely think I'd lost it ;-) My
approach is simply one of trying to keep moving forward as fast as the
browsers will allow, in the direction of the next W3C standard, rather than
the last one.
Rijk van Geijtenbeek
<jer...@webswonder.net> wrote:
>www.cambrianorganics.com
>
>looks fine in IE5+ and Netscape 6, but there are some real problems with
>Opera (we're using 5.12). CSS experts will probably recognise them. Perhaps
>I could be pointed to the possible solutions. Thanks.
>
>ps We'll be tweeking the @import stuff a little later for Netscape 4 users,
>so apologies for the problems there.
Removing the height line from:
#toptable{
width:100%;
height:78px;
}
in your stylesheet solves the problem. Why fix a height anyway when you
are not using absolute or fixed positioning? Anyway, the table contains
two rows, the first of which is already filled with a 78 pixel high
image. Maybe you meant that height to go with the #banner style?
--
If you don't like having choices | Rijk van Geijtenbeek
made for you, you should start | mailto:ri...@iname.com
making your own. - Neal Stephenson | http://rijk.op.het.net
Alan J. Flavell
> By taking XHTML seriously now, I'm
> hopefully improving my skills at separating structure from formatting.
But if that's what you're aiming at, then it's arguable that
HTML4 Strict or ISO-HTML are good targets, whereas XHTML Transitional
would be a poor target.
Let me say that a mere rote conversion (not that I'm accusing you of
any such thing, but just discussing the options) of HTML into XHTML
brings no particular benefits for the markup; the only proven
advantage seems to be the possibility of using XML-based tools.
Separation of structure from presentation can be done just as well in
HTML as in XHTML, it's not a clincher for the choice of one rather
than the other.
Your other points were of course well taken.
cheers
Bertilo Wennergren
> Without TIDY I probably wouldn't be attempting XHTML at this stage,
> becasue at the end of the day, I need to work to commercial
> deadlines
You should be aware that Tidy has a few puzzling bugs that makes
it analyze XHTML pages incorrectly sometimes. For that reason I've
haven't used Tidy for quite a while now. E.g. "div" elements
sometimes make Tidy insist that a Strict XHTML page is Transitional.
Furthermore all work on Tidy seems to have stopped more that a
year ago.
(Yes, I have reported all bugs I've found in Tidy.)
--
#################################################################
Bertilo Wennergren
<http://purl.oclc.org/net/bertilo>
<bert...@gmx.net>
#################################################################
Jeremy Clulow
wrote:
|| #toptable{
|| width:100%;
|| height:78px;
|| }
||
|| in your stylesheet solves the problem.
Thanks Rijk!Just the kind of obvious (except to me of course) solution I
was hoping for.
(Now I just need to figure out why those pesky links at the top change size
in Opera when mousing over - hopefully I can solve that one myself..)
Jeremy
Jeremy Clulow
wrote:
||
|| Furthermore all work on Tidy seems to have stopped more that a
|| year ago.
Drat! Are there other tools you could recommend?
Bjoern Hoehrmann
>Jeremy Clulow wrote:
>
>> Without TIDY I probably wouldn't be attempting XHTML at this stage,
>> becasue at the end of the day, I need to work to commercial
>> deadlines
>
>You should be aware that Tidy has a few puzzling bugs that makes
>it analyze XHTML pages incorrectly sometimes. For that reason I've
>haven't used Tidy for quite a while now. E.g. "div" elements
>sometimes make Tidy insist that a Strict XHTML page is Transitional.
Yes...
>Furthermore all work on Tidy seems to have stopped more that a
>year ago.
No, but Dave is no longer maintainer of HTML Tidy, Charlie Reitzel,
Terry Teague and me are, please have a look at <http://tidy.sf.net/>.
We should have fixed quadrazillions of bugs and added dozens of new
features and we are heading for a release, but days have unfortunately
only 24 hours. Feel free to help us!
--
Björn Höhrmann { mailto:bjo...@hoehrmann.de } http://www.bjoernsworld.de
am Badedeich 7 } Telefon: +49(0)4667/981028 { http://bjoern.hoehrmann.de
25899 Dagebüll { PGP Pub. KeyID: 0xA4357E78 } http://www.learn.to/quote/
Rijk van Geijtenbeek
<jer...@webswonder.net> wrote:
>On Sun, 21 Oct 2001 21:49:35 +0200, Rijk van Geijtenbeek <ri...@iname.com>
>wrote:
>
>|| #toptable{
>|| width:100%;
>|| height:78px;
>|| }
>||
>|| in your stylesheet solves the problem.
>
>Thanks Rijk!Just the kind of obvious (except to me of course) solution I
>was hoping for.
>
>(Now I just need to figure out why those pesky links at the top change size
>in Opera when mousing over - hopefully I can solve that one myself..)
Maybe I can beat you to that...
You have declared
font-size: 0.8em;
for all pseudo classes of links in this navmenu. Opera applies this
twice on hovering. Not without reason, as a link can have the state
:link and :hover at the same time. However, it should not use the
calculated :link font-size as base for calculating the :hover font-size,
as :link can hardly be thought of as the parent of :hver in this case..
Once you actually click a link, you'll note that even :visited get
applied on top of (instead of 'instead of') :link. Fortunately, it stops
there: a hovered visited link doesn't become even smaller...
Seth Parker
body {
...
font-size: 1.0em;
}
a.navmenu:link
...
font-size: 0.8em;
}
a.navmenu:active
{
...
font-size: 0.8em;
}
a.navmenu:visited
{
font-size: 0.8em;
}
a.navmenu:hover {
...
font-size: 0.8em;
}
That to me would mean that any of those states would cause the font-size to
decrease. Why it doesn't do it in IE6 and it does in Opera 5.12 is beyond
me. But try changing the 0.8em values to 1.0em values and see if that makes
a difference in opera. Other than that is seems to look fine when I view it
in opera 5.12. I'm by no means an expert but compairing it to IE6 it looks
just the same except for those links size changing
"Jeremy Clulow" <jer...@webswonder.net> wrote in message
news:pnc6ttok2an7v24d9...@4ax.com...
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
Jeremy Clulow
wrote:
|| Yes...
||
|| >Furthermore all work on Tidy seems to have stopped more that a
|| >year ago.
||
|| No, but Dave is no longer maintainer of HTML Tidy, Charlie Reitzel,
|| Terry Teague and me are, please have a look at <http://tidy.sf.net/>.
|| We should have fixed quadrazillions of bugs and added dozens of new
|| features and we are heading for a release, but days have unfortunately
|| only 24 hours. Feel free to help us!
Thanks!. I will certainly help to the limit of my skills.
Cheers,
Jeremy
Jeremy Clulow
wrote:
|| >(Now I just need to figure out why those pesky links at the top change size
|| >in Opera when mousing over - hopefully I can solve that one myself..)
||
|| Maybe I can beat you to that...
||
|| You have declared
|| font-size: 0.8em;
|| for all pseudo classes of links in this navmenu. Opera applies this
|| twice on hovering. Not without reason, as a link can have the state
|| :link and :hover at the same time. However, it should not use the
|| calculated :link font-size as base for calculating the :hover font-size,
|| as :link can hardly be thought of as the parent of :hver in this case..
||
|| Once you actually click a link, you'll note that even :visited get
|| applied on top of (instead of 'instead of') :link. Fortunately, it stops
|| there: a hovered visited link doesn't become even smaller...
Errr., yes you beat me ;-)
Thanks.
Bertilo Wennergren
>>Furthermore all work on Tidy seems to have stopped more that a
>>year ago.
> No, but Dave is no longer maintainer of HTML Tidy, Charlie Reitzel,
> Terry Teague and me are, please have a look at <http://tidy.sf.net/>.
> We should have fixed quadrazillions of bugs and added dozens of new
> features and we are heading for a release, but days have unfortunately
> only 24 hours. Feel free to help us!
Great! It would be very useful if there was a link on the original
Tidy page to the open source version. You are on speaking terms
with Dave, I hope...
ValerieGSharp
>
> Our new site at
>
> www.cambrianorganics.com
>
> looks fine in IE5+ and Netscape 6, but there are some real problems
> with Opera (we're using 5.12). CSS experts will probably recognise
> them. Perhaps I could be pointed to the possible solutions. Thanks.
[...]
As others have observed:
#toptable has the property 'height:78px'. However, your logo is already
78px, not to mention the navtable cell that follows.
According to CSS2 "17.5.3 Table height algorithms":
"... CSS2 does not specify rendering when the specified table height
differs from the content height, in particular whether content height
should override specified height; if it doesn't, how extra space should
be distributed among rows that add up to less than the specified table
height; or, if the content height exceeds the specified table height,
whether the UA should provide a scrolling mechanism. Note. Future
versions of CSS may specify this further."
<http://www.w3.org/TR/REC-CSS2/tables.html#height-layout>
It seems that, where some other browsers allow content height to
override specified height, Opera chooses instead to fix the TABLE to the
specified height and let content overflow.
Hence, in Opera, contenttab overwrites part of toptable.
----------------------------------------------------------------------
Problem with width of middle table cell appears to be due to a
combination of 'font-variant: small-caps' in .parabold, and those
character references i.e.   - is just as bad, but an
ordinary space is fine.
Opera is significantly increasing the width of the cell with each
character reference - try adding another one or two and you'll see what
I mean.
This is definitely a bug - and a rather strange one at that.
----------------------------------------------------------------------
Note re. Strict DTD (HTML4.01 & XHTML1.0): The BODY element can contain
only block level elements. You start with an A element, which is inline.
----------------------------------------------------------------------
Hint: It's less efficient (effort, bandwidth, etc) to add
class="navmenu" to every link in the navtable.
Using the style
#navtable a:link {...}
etc ...
would avoid this. But there's no right or wrong here.
--
Regards,
Val Sharp - Edinburgh