Different behavior between HTML and XHTML intended?

A difference in behavior of Tag::tagHtml() bugged me:

$this->tag->setDocType(Phalcon\Tag::XHTML5);
echo $this->tag->tagHtml('div'); // yields <div>
$this->tag->setDocType(Phalcon\Tag::HTML5);
echo $this->tag->tagHtml('div'); // yields <div></div>

then I spotted what I thought to be the problem:

    public static function tagHtml(string tagName, var parameters = null, boolean selfClose = false,
        boolean onlyStart = false, boolean useEol = false) -> string
    {
        // [...]

        /**
         * Check if Doctype is XHTML
         */
        if self::_documentType > self::HTML5 {
            if selfClose {
                let localCode .= " />";
            } else {
                let localCode .= ">";
            }
        } else {
            if onlyStart {
                let localCode .= ">";
            } else {
                let localCode .= "></" . tagName . ">";
            }
        }

So I patched it:

        /**
         * Check if Doctype is XHTML
         */
        if self::_documentType > self::HTML5 {
            if selfClose {
                let localCode .= " />";
            } elseif onlyStart {
                let localCode .= ">";
            } else {
                let localCode .= "></" . tagName . ">";
            }
        } else {
            if onlyStart {
                let localCode .= ">";
            } else {
                let localCode .= "></" . tagName . ">";
            }
        }

recompiled the whole thing, ran ./run-tests.sh and then:

There were 3 failures:

---------
1) Phalcon\Tests\unit\Phalcon\Tag\TagTagHtmlTest::testTagHtmlName | tagHtml with name parameter returns invalid HTML Strict
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'<aside>'
+'<aside></aside>'

#1  /vagrant/webroot/vendor/phalcon/cphalcon/tests/_support/Verify.php:25
#2  /vagrant/webroot/vendor/phalcon/cphalcon/tests/unit/Phalcon/Tag/TagTagHtmlTest.php:48
#3  /vagrant/webroot/vendor/phalcon/cphalcon/tests/unit/Phalcon/Tag/TagTagHtmlTest.php:50
#4  /vagrant/webroot/vendor/phalcon/cphalcon/codecept.phar:7

---------
2) Phalcon\Tests\unit\Phalcon\Tag\TagTagHtmlTest::testTagHtmlNameEol | tagHtml with name parameter and EOL returns invalid HTML Strict
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'<aside>
+'<aside></aside>
 '

#1  /vagrant/webroot/vendor/phalcon/cphalcon/tests/_support/Verify.php:25
#2  /vagrant/webroot/vendor/phalcon/cphalcon/tests/unit/Phalcon/Tag/TagTagHtmlTest.php:165
#3  /vagrant/webroot/vendor/phalcon/cphalcon/tests/unit/Phalcon/Tag/TagTagHtmlTest.php:167
#4  /vagrant/webroot/vendor/phalcon/cphalcon/codecept.phar:7

---------
3) Phalcon\Tests\unit\Phalcon\Tag\TagTagHtmlTest::testTagHtmlWithArray | tagHtml with array parameter returns invalid HTML Strict
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'<canvas id="canvas1" width="300" height="300">'
+'<canvas id="canvas1" width="300" height="300"></canvas>'

#1  /vagrant/webroot/vendor/phalcon/cphalcon/tests/_support/Verify.php:25
#2  /vagrant/webroot/vendor/phalcon/cphalcon/tests/unit/Phalcon/Tag/TagTagHtmlTest.php:209
#3  /vagrant/webroot/vendor/phalcon/cphalcon/tests/unit/Phalcon/Tag/TagTagHtmlTest.php:211
#4  /vagrant/webroot/vendor/phalcon/cphalcon/codecept.phar:7

so, is this difference in behavior intended? If so, why?



9.8k

Another reason why I don't let PHP build my UI. Separation of concerns. I know I didn't answer your question, but it's been a gripe of mine for years.

edited Sep '15

I like to use optionnal automated rendering to keep my views simple as possible. For example to render a form:

/* @var $this \Phalcon\Mvc\View\Engine\Php */
$formDecorator = new \SomeProjectName\Core\Forms\Decorator\Bootstrap();
$formDecorator->render($this, $form);

If I need somewhere something more specific, I won't use automated rendering. When thing are done the right way (understand: my way, not saying that everyone should do as I do) I can for example easily switch Doctype with really few hassles.

What I really need to know is if this is really a bug that I can patch locally and future versions of Phalcon will behave the same way as my local patch, or is this behavior really intended, if so I must do it anotherway.