Re: Generate XHTML (HTML compatible) Code using DOMDocument

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks for the feedback.

I too like xhtml but I think I like the option of serving both. My only concern is that a proxy server might cache an xhtml page and then serve it to a non-xhtml browser.

Do you think it's possible that a proxy might serve the xhtml source to the wrong browser?

__
Raymond Irving


--- On Tue, 4/14/09, Michael Shadle <mike503@xxxxxxxxx> wrote:

From: Michael Shadle <mike503@xxxxxxxxx>
Subject: Re:  Generate XHTML (HTML compatible) Code using DOMDocument
To: "Raymond Irving" <xwisdom@xxxxxxxxx>
Cc: "php-general@xxxxxxxxxxxxx" <php-general@xxxxxxxxxxxxx>
Date: Tuesday, April 14, 2009, 8:26 PM

As michael said my main reason is strictness. It's much easier to parse a document when an XML parser can read it. I like the idea of closing tags etc.

On Apr 14, 2009, at 4:38 PM, Raymond Irving <xwisdom@xxxxxxxxx> wrote:

> 
> Hi,
> 
> I'm thinking about using the html5 doctype for all html documents since it's supported by all the popular browsers available today.
> 
> Two Quick questions...
> 
> Why do we need to send XHTML code to a web browser when standard html code (with html 5 doctype) will do just fine?
> 
> Is there any advantage of using xhtml in the web browser over html for normal web application development?
> 
> 
> __
> Raymond Irving
> 
> --- On Tue, 4/14/09, Peter Ford <pete@xxxxxxxxxxxxx> wrote:
> 
>> From: Peter Ford <pete@xxxxxxxxxxxxx>
>> Subject: Re:  Generate XHTML (HTML compatible) Code using DOMDocument
>> To: php-general@xxxxxxxxxxxxx
>> Date: Tuesday, April 14, 2009, 5:05 AM
>> Michael Shadle wrote:
>>> On Mon, Apr 13, 2009 at 2:19 AM, Michael A. Peters
>> <mpeters@xxxxxxx>
>> wrote:
>>> 
>>>> The problem is that validating xhtml does not
>> necessarily render properly in
>>>> some browsers *cough*IE*cough*
>>> 
>>> I've never had problems and my work is primarily
>> around IE6 / our
>>> corporate standards. Hell, even without a script type
>> it still works
>>> :)
>>> 
>>>> Would this function work for sending html and
>> solve the utf8 problem?
>>>> 
>>>> function makeHTML($document) {
>>>>    $buffer =
>> $document->saveHTML();
>>>>    $output =
>> html_entity_decode($buffer,ENT_QUOTES,"UTF-8");
>>>>    return $output;
>>>>    }
>>>> 
>>>> I'll try it and see what it does.
>>> 
>>> this was the only workaround I received for the
>> moment, and I was a
>>> bit afraid it would not process the full range of
>> utf-8; it appeared
>>> on a quick check to work but I wanted to run it on our
>> entire database
>>> and then ask the native geo folks to examine it for
>> correctness.
>> 
>> I find that IE7 (at least) is pretty reliable as long as I
>> use strict XHTML and
>> send a DOCTYPE header to that effect at the top - that
>> seems to trigger a
>> standard-compliant mode in IE7.
>> At least then I only have to worry about the JavaScript
>> incompatibilities, and
>> the table model, and the event model, and ....
>> 
>> --Peter Ford
>> 
>> phone: 01580 893333
>> Developer
>> 
>>    fax:   01580 893399
>> Justcroft International Ltd., Staplehurst, Kent
>> 
>> --PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
>> 
> 
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux