On Nov 27, 11:59 pm, Thomas Fuchs <[EMAIL PROTECTED]> wrote:
> Again, this is just a bug in Safari's rendering engine... :)

It may well be, but only if you can support the notion that the HTML
body element *must* extend to the full extent of the window (a
reference to a W3C recommendation would do).  In any case, the
document being served by the OP isn't valid HTML, so all bets are off.


> Prototype doesn't "break" Safari, it's broken to start with... ;)

In the specific example provided by the OP, Safari behaves differently
depending on whether Prototype.js and a second script file are
included or not.  There would seem to be at least an incompatibility
relating to Safari and Prototype.js in this case.

If Prototype.js doesn't "break" Safari, then why doesn't the issue
occur with version 1.5 or 1.4?  Clearly there is something different
in 1.6 that causes the behaviour.


> I'd go with  
> the pragmatic fix and telling safari to give a background to the HTML  
> element, too.

That may "work" for the limited number of browsers that Prototype.js
supports, but not only is it invalid HTML (and XHTML), it doesn't
increase anyones understanding of why Safari does what it does.

As I pointed out, when the document is served as XHTML, neither
Firefox nor Safari extend the body element to the full extent of the
window - regardless of whether any script files are loaded or not.


> Btw, solves some rendering bugs in Firefox too, that can happen under  
> specific circumstances. OMG, BROWSERS!!! ;)

You are depending on pure coincidence of how browsers handle
transition doctypes and invalid markup to fix a problem that you don't
understand (not that I claim to either).


> As for the XHTML 1.0 strict issue -- I recommend using XHTML 1.0  
> Transitional as the "most compatible" doctype; and serving it as text/
> html. These days, that seems to be the way to go:

Which is a really confused recommendation.  If you are concerned about
web standards, then you should recommend HTML 4.01 strict.  It seems a
contradiction to use a transitional XHTML doctype served as HTML
(which will be treated as invalid HTML by any browser that it is
served to) to cause some kind of compatibility in the hope that
browsers will all treat the erroneous markup the same.  How can you
say one browser has a bug because it treats the invalid markup
differently to some other browser?

This subject is somewhat off topic for this news group, search the
archives at comp.infosystems.www.authoring.html to see what others
with far more knowledge than I say about the use of XHTML on the web,
particularly when served as text/HTML.


--
Rob
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Spinoffs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to