[MacPorts] #14062: Website does not render properly in IE7
William Siegrist
wsiegrist at apple.com
Fri Dec 19 22:59:08 PST 2008
On Dec 19, 2008, at 10:39 PM, Ryan Schmidt wrote:
> On Dec 20, 2008, at 00:06, William Siegrist wrote:
>
>> On Dec 19, 2008, at 9:46 PM, Ryan Schmidt wrote:
>>
>>> On Dec 19, 2008, at 09:32, Marco Battistella wrote:
>>>
>>>> http://www.macports.com repose is correct, when "application/xhtml
>>>> +xml" is accepted the header response is application/xhtml+xml
>>>> and when it is not the header response is text/html
>>>> for some reason when requesting http://www.macports.com/ports.php
>>>> the response is always application/xhtml+xml
>>>>
>>>> I re-adapted a small php script i had written some time ago to
>>>> allow to test the pages behavior with or without the Accept:
>>>> application/xhtml+xml header.
>>>>
>>>> The little script works from the command line like this:
>>>> $ php testGet.php -uri http://www.macports.org -accept ie7
>>>> or
>>>> $ php testGet.php -uri http://www.macports.org -accept safari
>>>> or
>>>> $ php testGet.php -uri http://www.macports.org/ports.php -accept
>>>> ie7
>>>>
>>>> you get the point.
>>>> It is a "works in my machine" type of script but i don't see why
>>>> it should not work in yours as well ;-)
>>>> It will return the header and then the content.
>>>>
>>>> I am part of this thread because i had originally sent a
>>>> modification suggestion for this issue, i'm not a macports
>>>> developer or a macports website maintainer but I could have a
>>>> look at the code if you guys think it would help.
>>>> If so what path should i use to do a checkout with subversion
>>>> (without downloading the whole macport project, just the relevant
>>>> part of the site, please)....
>>>
>>> You can get the web site code here:
>>>
>>> http://trac.macports.org/browser/trunk/www
>>>
>>> I haven't yet understood why I seem to be getting different
>>> behavior out of the different pages (and even different behavior
>>> of http://www.macports.org/ vs. http://www.macports.org/
>>> index.php ) when they're all including the same common code to
>>> handle the headers.
>>
>> Getting consistent rendering with XHTML 1.1 is probably not worth
>> the effort. I doubt the site does anything requiring XHTML 1.1
>> anyway, so why not just serve an HTML 4.01 page? There's a good
>> WebKit blog post [1] about this issue too.
>>
>> -Bill
>>
>> [1] http://webkit.org/blog/68/understanding-html-xml-and-xhtml/
>
> That article, written in September 2006, basically says forget XHTML
> and use HTML 4. Is that still the best advice today, over 2 years
> later? If so, I am given to wonder why we have the XHTML standard in
> the first place, if browser vendors recommend not using it.
>
>
Yes, its still valid due to browsers not behaving correctly with the
xml tags and the application/xhtml+xml content type. The following
pages are served as HTML 4.01:
http://webkit.org/
http://mozilla.org/
These are served as XHTML 1.0, which doesnt have the leading xml tag,
and they use an html content type, which is technically wrong but it
makes browsers handle it better:
http://microsoft.com/
http://opera.com/
So if the browser vendors are not using XHTML 1.1, why are we going
through all this trouble?
-Bill
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2421 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20081219/6401578a/attachment.bin>
More information about the macports-dev
mailing list