I suggest using the response object for outputting headers instead of doing
that in index.php. You might run into issues later when you try to set
cookies or start the session if headers have already been sent.
To use the response object, you can use a front controller plugin to
manipulate the response. Since the response is not procedural, it doesn't
really matter when you set the headers as long as its before the response is
sent (which I believe happens after dispatchLoopShutdown).
Also, you if you specify the view's doctype early (like perhaps in your
bootstrap), then most (if not all) ZF view helpers will honor the doctype
and correctly self-close their tags and such. This should include Zend_Form,
but I don't know if it will affect (which I thought was valid
XHTML).
You can specify the doctype by calling $view->doctype('XHTML1_STRICT').
I hope this helps!
--
Hector
On Fri, May 14, 2010 at 11:04 AM, Andrew Ballard <aball...@gmail.com> wrote:
> DISCLAIMER: OK, I know that browser support for serving XHTML pages as
> application/xhtml+xml is not very good yet.
>
> That said, since most of the sites I develop using ZF use the XHTML
> strict doctype, I was experimenting with conditionally serving the
> pages with the correct mime-type to browsers that claim to support it.
> To test, I added this block to the top of index.php:
>
> <?php
>
> header("Vary: Accept");
> if (stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml"))
> header("Content-Type: application/xhtml+xml; charset=utf-8");
> else
> header("Content-Type: text/html; charset=utf-8");
>
>
> // rest of index.php ...
>
> ?>
>
> I encountered a couple issues that convinced me rather quickly to
> revert to the default (serving all requests as text/html):
>
> 1) The contents of the HeadStyle view helper are not "properly"
> escaped for XHTML. I'm not sure it can be, though, as this could
> create compatibility issues with other browsers that can otherwise
> display the pages OK. Simplest solution - move the style declarations
> to an external document and link it with HeadLink instead. Still, I
> wonder if it would be possible to have the HeadStyle view helper check
> HTTP_ACCEPT as above and, if supported by the browser, change the way
> it marks up the <style> tag. (I believe the markup used for inline
> Javascript worked OK.)
>
> 2) Zend_Form (and perhaps other helpers or decorators) sometimes
> insert the HTML entity ' ' for non-breaking spaces (such as
> between <dt>...</dt> tags in the DtDdWrapper decorator), but that
> entity is not valid in XHTML. Because of this, the page doesn't even
> validate in Firefox and is therefore rendered as a yellow page with an
> XML Parsing Error. There may also be similar issues that result from
> character escaping in Zend_View since characters like 'é' could be
> escaped as 'é' rather than '&#E9;'.
>
> I know this isn't much of a priority until browser support improves,
> but in the interest of being forward-thinking and moving toward
> "correctness" is it possible to serve valid pages with the correct
> XHTML mime-type using ZF or is this still too much of a mine field?
>
> Andrew
>
