# Is this HTML Helper good or bad?

I have written this HTML static class which may categorize as a helper (not really sure what the definition of helper is). Anyways, I was just wondering if it was a smart idea to call a bunch of PHP functions instead of using raw markup because it just doesn't seem right to me.

One of the things that I'm positive about is that as output it creates a long string instead of many lines with tabs and line breaks (i.e. it is automatically minified). However, there's still this thing inside that's bugging me about these function calls because each element is a product of a function call, and this means that there will be a lot of calls, as opposed to a simple string output in ordinary case of raw markup.

This is an example usage:

echo \HTML::html(
\HTML::head(
\HTML::title('Hello')
)
.
\HTML::body(
\HTML::h1('Hello world').
\HTML::p('example')
)
);


And the result:

<html><head><title>Hello</title></head><body><h1>Hello world</h1><p>example</p></body></html>


In the actual usage I will not have concatenating strings like between head and body. I use a template engine and that's it's job, however now for the sake of simplicity I just use a concatenation.

The actual class itself:

/**
*
* Author php_nub_qq at stackoverflow.com
*
**/

final class HTML {
private function __construct() {

}

public static function __callStatic($name,$arguments) {
$content = isset($arguments[0]) ? $arguments[0] : null;$attributes = isset($arguments[1]) ?$arguments[1] : array();

return '<'.$name.self::parseAttributes($attributes).'>'.$content.'</'.$name.'>';
}

public static function script($src, array$attributes = array(), $defer = true){$attributes['type'] = 'text/javascript';
$attributes['src'] = strstr($src, '://') ? $src : SITE_URL .$src;
if($defer){$attributes['defer'] = 'defer';
}

return '<script'.self::parseAttributes($attributes).'></script>'; } public static function stylesheet($src, array $attributes = array()){$attributes['type'] = 'text/css';
$attributes['href'] = strstr($src, '://') ? $src : SITE_URL .$src;
$attributes['rel'] = 'stylesheet'; return '<link'.self::parseAttributes($attributes).'/>';
}

public static function a($url,$text = null, $target = '_self', array$attributes = array()){
$attributes['href'] = strpos($url, '://') === false ? SITE_URL.$url :$url;
$attributes['target'] =$target;

if($text === null){$text = $attributes['href']; } return '<a'.self::parseAttributes($attributes).'>'.$text.'</a>'; } public static function form($method = 'GET', $action = '', array$attributes = array(), $csrfToken = null,$content = null){
if($csrfToken === null){$csrfToken = \Input::generateCSRFtoken();
}

$attributes['method'] =$method;
$attributes['action'] =$action;

return '<form'.self::parseAttributes($attributes).'>'. '<input type="hidden" name="csrf-token" value="'.$csrfToken.'"/>'.
$content. '</form>'; } public static function input($name, $type,$value = null, array $attributes = array(),$div = true){
$attributes['name'] =$name;

if($name === null){$div = '';
}else{
if($value === null &&$type != 'password'){
$value = \Input::data($name);
}

if($div){$div = '<div class="'.$name.' Field-Error">'.\Input::getValidationErrors($name).'</div>';
}
}

switch($type){ case 'textarea':$input = '<textarea'.self::parseAttributes($attributes).'>'.$value.'</textarea>';
break;

case 'select':
if(is_array($value)){$options = '';
foreach($value as$key => $option){$options .= '<option value="'.$key.'">'.$option.'</option>';
}
$input = '<select'.self::parseAttributes($attributes).'><option>'.$options.'</option></select>'; } break; default:$attributes['type'] = $type;$attributes['value'] = $value;$input = '<input'.self::parseAttributes($attributes).'/>'; } return$div.$input; } private static function parseAttributes($attributes){
foreach($attributes as$attribute => $value){$attributes[$attribute] = ' '.$attribute . '="'.$value.'"'; } return join('',$attributes);
}

public static function sanitize($string,$flag = ENT_QUOTES, $encoding = 'UTF-8'){ return htmlspecialchars($string, $flag,$encoding);
}
}


A few details - the __callStatic function handles the majority of tags, and currently does not support self-closing tags. The whole class is currently a work in progress and I'd be really thankful if you share any bugs or improvements you see. I would like to also mention that if anyone finds this class useful they can use it freely (not that I can actually put any restrictions on that but just thought it's good to know).

Also about the sanitize function, I know it's not good to create function wrappers that do nothing else than call another function with the same parameters, but that's just something I foresaw. Maybe in the future I will need to put some custom sanitizing technique or something, then I'll have all of my projects automatically updated, as opposed to having to start implementing it everywhere.

• Forgive me but: What's the point? PHP can be embedded in HTML easily (simply close ?>, write the markup and reopen <?php). Why add the overhead of static method calls and a pure evil magic __callStatic? Your api doesn't allow me to turn back to a node, change some attributes or add children to it. In the end, I'm still stuck writing rather old-school procedural styled code (with an OO front) – Elias Van Ootegem Oct 10 '14 at 15:02
• Just for the record it already exists out there github.com/naomik/htmlgen and you should remember the DRY concept – elibyy Oct 10 '14 at 15:09
• @elibyy DRY concept? And IMHO that object you referenced is extremely ugly and closures, really? – php_nub_qq Oct 10 '14 at 17:19
• @EliasVanOotegem the point is that you need to write very less, as well as you can use php variables in elements' content without having to open and close php tags every time which I find to be a great pain for coding and reading, literally. Also I have automated error reporting on form submission and auto field refill in case of such, to do that with markup it is a bit more complicated and certainly not good looking. – php_nub_qq Oct 10 '14 at 17:22
• Just saying DRY = don't repeat yourself. I'm just saying also. That you should do something more general then tag specific. Also that what I've found by quick googling – elibyy Oct 10 '14 at 17:22

## The general idea

is it good or bad?

I would say it's bad. But let's look at the pros and cons.

Advantages:

1. Decoupling: your content is decoupled from the actual HTML. If HTML ever changes, you only have to change your HTML class, and all the code that uses it continues to be correct. You could also easily print your content in a different format than HTML (well, maybe not easily, but it would certainly be possible).
2. Fast to Use: it might be faster to use than writing HTML yourself.
3. Minify: it can produce already minified HTML.
4. Correctness: You can verify that all HTML is correct (no missing closing tags, etc).

But: Do you really need 1.? I would guess not. And with a decent IDE, is it really slower to write HTML yourself? I wouldn't think so, so 2. is out as well. And 3.: You can just use a minifier, which will probably be better at what it does. And allows you the option of turning it off for debug purposes. Point 4. is the only one I would consider to be a real advantage (but then you would have to make it a priority to produce valid HTML).

Disadvantages:

1. Speed: it will always be slower than native HTML.
2. Complexity: native HTML will always work (it might not validate, but it will display something). You have to extensively test your class, and still, you might overlook something.
3. Usability: People know how HTML works, but they don't know your class, so they have to invest time in it.

In the end, you have to decide for yourself, but I think that the disadvantages outweigh the advantages for general HTML (for some elements, such as forms, a class that can generate them is indeed very helpful).

## Your Code

HTML and Input

Your HTML class is quite coupled with your Input class. This makes re-using it a bit difficult, and it also leads to your HTML class doing more than just generating HTML. It now also contains program logic, such as displaying errors or inserting CSRF tokens).

Repeated Code

You have this code strstr($src, '://') ?$src : SITE_URL . $src; two times, and effectively three times if you count strpos($url, '://') === false ? SITE_URL.$url :$url;. You should extract this code to its own function.

input function

Your input function is too complex, try to think of a way to make it simpler. If you cannot think of a good way, extract code to its own function (the code at the beginning could go to createErrorDiv, and each of the cases could get its own function as well).

Misc

• I would prefer to surround . with whitespace, I think it makes the code more readable (same for { and }).
• Basically the class started as a form generator, then I renamed it to HTML and started creating these methods 1 by 1 in time. Up until today it hit me that I can use only php to create markup and the main idea that drove me was that I can use values from PHP variables without having to use the open and close php tags <?=\$var?> which may not seem like much but it really makes a difference for me. Thank you for the nice review, I guess I will benchmark it and decide if the slowdown is significant enough to make me use markup instead. – php_nub_qq Oct 10 '14 at 17:31
• @php_nub_qq I agree, PHP tags are quite distracting. If it's just about them, you might want to look at a template engine, such as twig, which I think looks a lot nicer than HTML with PHP mixed in. – tim Oct 10 '14 at 17:42
• One potential advantage I could see to using a wrapper class versus raw HTML is that a wrapper class can take care of escapes and sanitization in a way that might be more difficult using raw HTML. If everything has to go through the wrapper, then it's possible to ensure that no unescaped greater-than signs can be created except by the wrapper itself. That would seem more difficult if code is expected to build things from HTML tags that would of course include such characters. – supercat Oct 10 '14 at 18:01
• @php_nub_qq check my links. Generally, yes, htmlspecialchars prevents most cases of xss. But there are corner cases where it might not be enough (mainly when placing user input inside HTML attributes (as key or as value)). If you want to know more about it, this XSS Prevention Cheat Sheet is interesting. – tim Oct 10 '14 at 18:41
• @tim I just finished benchmarking and I thought I should let you know what the results are just in case you are curious. With unrealistically small markup, like the one in the example, markup appears to be 6% faster than nested functions, however with slightly larger ( but still small ) response - 1024 bytes in size - the times are almost identical and by increasing the response size markup starts getting a little slower. I suppose that is due to unminified content but anyway the php way doesn't seem to be much slower if at all. – php_nub_qq Oct 10 '14 at 21:30

Even though the answer was already accepted, I want to argue a bit differently.

So practically, with your current approach, I think the answer is no, not really, unless you can cut down the number of tokens. Though if you can find a way to have just html(body(...)), then yes.

First of all, this is known as an embedded DSL since you're using language constructs to mimic HTML.

Now I don't think correctness is an issue here (unless you're very dilligent), since you won't be able to encode all the rules of HTML (which version even), not to mention CSS and other standards. And even if you did, you'd have to follow new developments and also fix compatibility issues, which you also won't have enough resources to do.

However, you gain an advantage here, which is more than a bit muddled, because you're already in a templating language anyway: You can use the regular tools of the language to create new kinds of abstractions instead of passing around strings. And you've already done that with the form and input functions. IMO that is a win.

Depending on what you want you could also generate a DOM instead of outputting strings, but using the same syntax, so you gain flexibility for different kinds of usages.

Lastly, you are able to stay in the syntax of your (primary) language. For some that is already enough of a reason to do this kind of thing. Usability-wise this could also be an improvement, since other people already have to know the programming language anyway (except if they just do design I guess, which is probably one of the main arguments against that), so staying within that framework can be less of an overhead than switching between two different systems, including interpolation rules, quoting, etc.