Mozilla clear not working

I assume that you've solved the problem with the "clearfix" method then ?

Hugo.

Sorry, I'm not quite sure what you mean, Hugo. The layout works in IE, Opera, and FF, but not in Mozilla. I am using the .frame:after { content: "." etc } method to get FF to work, but Mozilla seems not to toe the line.

Cheers

Tom

Sorry, looking at the wrong thing :roll:
I'm confused as Mozilla and FF should render much the same and interestingly when initially loaded the page in FF does demonstrate the image overlap (missed it first time round) that is until one resizes the window or pulls up a sidebar, after which it behaves itself- not sure why .
The clearing that you have shouldn't be needed on the image as it's a float nested within a float .
At this time my only rather vague suggestion would be to start commenting out rules one by one until you can isolate the effect hopefully, I thought initially that it might be collapsing margins but can't see any?
I'll try and have a more detailed look a bit later , one thing that I did notice was that there is no character encoding which is giving you only a tentative pass on validation.

Hugo.

Hi Hugo

Thanks for the feedback. The intermittent nature of the FF rendering is caused by the fact that the image has no declared dimensions. If FF knows the dimensions of the image, either via the code, or because it has cached it, it renders correctly. I'm not worried about that, and am trying to sort my code in order to include the image dimensions (not a CSS problem).

The character encoding one is a different issue. I was specifying it, but had to remove the META tag because it was declaring the document as text/html to all browsers. I now set the MIME type from the server side, but you are right that I have not set the character encoding. Is there a way to do that without also having to set the MIME type? If not, I'll have to set that conditionally as well.

Thanks again

Tom

Ah, missed the lack of image dimensions in the html .
If your your using the xhtml 1.0 trans doc type can you just not use the
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

It's what I generally use and seems fine although the subject is a slightly confused one and I'll probably be shot down for it!

Hugo.

I'm using XHTML 1.0 Strict, and the issue is that I want to send it to application/xhtml+xml enabled browsers using that MIME type, whereas IE has a hissy fit if you use that type, so I have to send it as text/html to IE. Not to worry. I'll just put a conditional META tag in there.

Any ideas on the original problem in Mozilla?

Thanks

Tom

Tom, sorry I don't have a Mozilla browser to hand so can't be much help, but I'll keep thinking on it .

Your probably fed up with the discussion but do you 'want' to serve up the doc as xml or 'have' to serve it up this way as I'm sure you are aware that xhtml 1.0 can be served up as either text/html or app/xhtml+xml

You may not need this but here is quite a good article on the subject

http://www.w3.org/International/articles/serving-xhtml/

Hugo.

If I don't server it as application/xhtml+xml rather a lot of the point of XHTML is lost. The XML parsers in FF, Moz, and so on will not parse it, and it will merely be parsed by the old tag-soup processors.

Thanks for the help. Wish I could nail the Moz rendering problem, though.

Tom

Tom are you saying in other words that you think that the document will render in "Quirks Mode" when you mention "Tag Soup" if so with all due respect you may have got the wrong end of the stick or been fed incorrect info are you not serving up an xhtml document you won't loose the "point" of the xml extensibility .

Hugo.

No, I don't mean that "Quirks Mode" rendering will be triggered. The specs say that XHTML 1.0 Strict SHOULD be served as application/xhtml+xml, so I want to do so in any browser which will support it (not IE/PC, naturally).

If anyone else looks in on this discussion, please concentrate on the Mozilla rendering issue.

Cheers

Tom

Apologies Tom as a mod I have taken your post right off topic :oops:
I hold my head in shame.

But read that link as I think it clears matters up, as xhtml 1.1 MUST be served as xhtml+xml and it does explain well the types of encoding required .

I shall butt out now, again sorry for taking things off topic.

Hugo.

Hi Hugo

No problem. But I'm afraid that w3.org explicitly states that "Best practice is for XHTML to be served as xml" in one of its valid MIME types, and goes on to say that application/xhtml+xml is the only really valid one in this context. See the following W3 summary:

http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/#summary

For discussion and clarification, try the following:

http://juicystudio.com/all-in-the-mime.asp
http://www.greytower.net/archive/articles/xhtmlcontent.html
http://www.hut.fi/u/hsivonen/doctype
http://keystonewebsites.com/articles/mime_type.php

So... Mozilla rendering bugs, anyone?

Cheers

Tom[url][/url]

Hugo: I worked with this a bit in the original devshed thread. I narrowed Mozilla's misbehavior to the use of a negative margin on the float which seems necessary for pulling the float into the parent's margin area. Due to cms issues, the float may not be a sibling to the content, but must be a child.

As the content area is the parent of the float, it should apply the clearing hack. With a negative margin on float, it doesn't work in Mozilla 1.7. It does work int FF, etc.

Even the presence of the clearing hack on the content's ancestor (and thus float's) will not cause the float to be cleared.

I haven't a clue, but maybe someone here has seen the negative margined float issue before.

in re OT comments: I'm with you, Hugo. The page has no compelling reason (I haven't seen any extensions to html4*) to exist as xhtml1.1, and is best served as xhtml1.0 strict text/html. The specs say xhtml1.1 must be served as application/xhtml+xml, while xhtml1.0 should be application/xhtml+xml and may be text/html.

*As an exercise, I created an xhtml1.1 document that has new elements defined. It is served as application/xhtml+xml.

cheers,

gary

HI Gary

Thanks for clarifying the issue: your grasp of concept-level CSS far outstrips mine.

Re: OT
I believe in serving XHTML by way of future-proofing. You brought it to my attention, Gary, that XHTML1.1 can only be served as application/xhtml+xml, so I reverted to XHTML 1.0 Strict. My understanding is that this SHOULD be served as application/xhtml+xml, so I am doing so if the UA accepts it.

I have read many articles evangelizing HTML4.01 Transitional, but remain unconvinced. Given my choice to serve XHTML, which flavour, and which MIME type, is most appropriate?

Cheers

Tom

Hmm, if you're looking up to me, you must be pretty far down. Have you considered seeking help for your low self-esteem?

Considering the state of the art (read IE), I think we're stuck with text/html unless you're willing to write pure xml, which IE sz it groks. I write and validate to xhtml1.0 strict standards. That way I know everything is up to date and there are no deprecated elements or attributes. In the end, it's still html.

cheers,

gary

I'd up my self-esteem, but I don't think I'm worth it etc etc.

OK, so my approach of delivering xhtml1.0 Strict, and serving it as text/html to IE (and anything else which cannot handle application/xhtml+xml) and as application/xhtml+xml to FF, Mozilla (and anything else which can handle application/xhtml+xml) is sound?

So [claps hands and rubs them together]... Mozilla rendering issues, anyone?

Cheers

Tom

I see, I can't recall any specific mozilla problems with negative margins, a difficult problem then! I should get a copy of mozilla really, I tend to usually assume that if it's ok in FF it will be ok in Mozi


This was what I was trying to say but being rather unclear in my ramblings(my fault)
As far as I can gather unlike some peoples belief that you shouldn't ever use 1.1 it's more a case of you can do so quite happily but must serve it up as xhtml+xml and really the advantage being the ability to create (extend) the dtd with custom tags but you also must declare the prolog with utf-8 set with attendant problems thus it's recommended to serve up 1.0 with text/html for basic xhtml pages and also recommends not relying on the http header for the sole character declaration but always include the metatag as well , which to my mind cleared this page to use the metatag and serve up as text/html
The most important thing is really that we serve up xhtml whether it's as text/html or xhtml+xml .If it's for html then we still get standards compliant rendering but if you want full custom tag creation and namespace functions you will have to work round IE



and I guess looks fine in browsers that will read that content type ,would be nice to have the ability but does lead to a whole different world ! have to start understanding xslt.

Sorry Tom rambled on again.

Hugo.

Sighing, and going with the XHTML discussion, can I ask the status of the xml prolog? I know it triggers quirks mode in IE, and I seem to remember that it is officially optional in some flavours of XHTML. Two things, then:

- is the xml prolog completely optional in XHTML 1.0 Strict, or SHOULD it be used, or SHOULD it NOT be used? (using W3's definitions of should etc)

- given that I am sniffing the UA's to find out which MIME type they accept, would it be a good idea to serve out the xml prolog to UAs which accept application/xhtml+xml, while leaving it out from UAs which do not (including IE, and therefore avoiding triggering quirks mode rendering)?

Now, Hugo. Go get a copy of Mozilla. You know you are simply DYING_ to see the Mozilla negative margin rendering bug. Aren't you.

Cheers

Tom

Given that it is optional whether you serve up 1.0 as text/html or xhtml+xml and that the W3C reccomend that the metatag character encoding be used as well as the http header declaration for text/html it seems better to drop the prolog and save on unnecesary work as the gains are really only the extensibility of the xml language.
The prolog is not so much optional as prefered, but the W3C recognize the problems associated with it and accept the dropping of it in the case of text/html , the main thing is that we render to "Standards compliance" so all things considered I think that you are better of serving up 1.0 text/html with a metatag and no prolog unless you are actualy going to be customizing tags ? but whatever you do it would be a mistake to serve the prolog to IE and loose compliance.

EDIT:

There is a fad of serving text/html to IE but serving the same markup with no added value as application/xhtml+xml to Mozilla. This is usually done without a mechanism that would ensure the well-formedness of the served documents. Mechanisms that ensure well-formed output include serializing from a document tree object model (eg. DOM) and XSLT transformations that do not disable output escaping. When XHTML output has been retrofited to a content management system that was not designed for XML from the ground up, the system usually ends up discriminating Mozilla users by serving tag soup labeled as XML to Mozilla (leading to a parse error) and serving the same soup labeled as tag soup to IE (not leading to a parse error).

Hm, I find myself becoming further confused the more I try to understand fully

yep I'm intrigued by this one, have to see what's occurring for myself
as I still labour under the belief that Mozilla/FF should render near identically :? time to focus on your actual problem and get of this xhtml lark.

Hugo.

I bet you didn't have a look at this problem in Mozilla, did you Hugo?

Tom