Is it possible that the library supports PHP5.0?

In raising this issue, I confirm the following (please check boxes):

• I have read and understood the contributors guide.
• I have checked the pull requests tab for existing solutions/implementations to my issue/suggestion.
• I have checked that the bug-fix I am reporting can be replicated.

Description of the problem

I'm aware that this library is under no active development, yet I wanted tp post a bug I have come across.

Creating <script> does not work as desired. I came across this by pure chance and first suspected that this library only allows certain attributes. Later I figured that creating even the simplest <script> does not work.

Steps to reproduce

Example script:

$attributes = [
	'src'   => 'https://url.to/script.js',
    'defer' => 'defer'
];

el('script', $attributes, null);

// => string(46) "<script>https://url.to/script.jsdefer</script>"

Expected result:

string(60) "<script src="https://url.to/script.js defer="defer"></script>"

I have noticed that the syntax for self-closing tags is working as expected, except that <script> isn't self-closing

el('script[src=https://url.to/script.js][defer="defer"]');

// => string(62) "<script src="https://url.to/script.js" defer="defer"></script>"

In raising this issue, I confirm the following (please check boxes):

• I have read and understood the contributors guide.
• I have checked the pull requests tab for existing solutions/implementations to my issue/suggestion.
• I have checked that the bug-fix I am reporting can be replicated.

Description of the problem

One of the important reasons for using hyperscript is that it handles escaping of characters which are reserved in html. Which prevents XSS.

spatie/html-element does not do this. Mainly because it uses strings as intermediate format instead of an object representation of the DOM.

I was wondering, to which extent does this way affect the performance and loading of the page in comparison to plain html. Although I suppose caching would level this out.

Hello,

In raising this issue, I confirm the following (please check boxes):

• I have read and understood the contributors guide.
• I have checked the pull requests tab for existing solutions/implementations to my issue/suggestion.
• I have checked that the bug-fix I am reporting can be replicated.

I am trying to render a HTML SELECT OPTION tag programmatically. As it turns out, the value "0" is ignored when used as an attribute value, as shown here:

$attr = ['name'=>'foo', 'value'=>'0', 'label'=>'Foo'];
echo el('option', $attr, $attr['label']);
// Observed output: <option name="foo" value label="Foo">Foo</option>
// Expected output: <option name="foo" value="0" label="Foo">Foo</option>

It most likely happens because the value "0" is treated as empty (both the string "0" and the number 0).

Here is also a working example:

$attr = ['name'=>'foo', 'value'=>'1', 'label'=>'Foo'];
echo el('option', $attr, $attr['label']);
// Works fine, the observed and expected output is: <option name="foo" value="1" label="Foo">Foo</option>

How do I get the expected output when using value=0?

Steps to reproduce

Full code to recreate:

<?php
require './html-element/html-element.php';

$attr = ['name'=>'foo', 'value'=>'0', 'label'=>'Foo'];
echo el('option', $attr, $attr['label']);
// Observed output: <option name="foo" value label="Foo">Foo</option>
// Expected output: <option name="foo" value="0" label="Foo">Foo</option>

el() is defined this way:

require 'src/HtmlElement.php';
require 'src/Attributes.php';
require 'src/AbbreviationParser.php';
require 'src/TagRenderer.php';
require 'src/Helpers/Arr.php';

function el(string $tag, $attributes = null, $content = null) : string {
	return \Spatie\HtmlElement\HtmlElement::render(...func_get_args());
}

latest release supports php7 only