The self closing tags don't really work... I changed two lines of code and that seems to fix it:

Tag.php (#109)

$this->isOpened = !$this->isSelfClosing;

Tag.php (#118)

return '<'.$this->element.Helpers::parseAttributes($this->attributes) . ($this->isSelfClosing ? ' /' : ''). '>';

PS: Great library!

Is it possible to add raw values to data attributes? If I pass a JSON string to Former with Former::text('tags', 'Tags')->dataTags($tags);, the data get's encoded Maybe an extra parameter to specify raw output?

If you have a custom tag/custom element that needs different self-closing rules (or one that isn't already defined in the code, such as meta), this PR adds the ability to override that behavior to ensure a tag is or is not self-closing.

When tag attributes are parsed, any whose value isn't equivalent to "true" is discarded. However, as the value attribute can legitimately be zero or and empty string, it's white-listed.

However, it's not the only attribute that can legitimately have a zero value. Min and max for a number type input field may be required to impose a zero bound on the field's input. So these have been added to the white-list, along with some associated tests.

Please could we have a tag on this project?

Currently former can't be used in any project with minimum stability "stable" as it depends on this project which doesn't have a stable release.

When an attribute is dynamically set through the magic __call() method, but no parameter is supplied, the attribute is defaulted to the string 'true'. However, the Helpers::parseAttributes() method does a strict type comparison to the boolean true to determine boolean attributes. Due to this, when an attribute is set as $tag->required() or $tag->checked(), it is rendered as required="true" or checked="true", instead of as an actual boolean attribute.

This pull request changes the default value for dynamically set attributes to a boolean true instead of the string 'true'.

This also addresses issue formers/former#437.

When wrapWith() called by some tree child element, it is expected to return element itself; and also expected that element be actually moved into wrapper element, affecting parent tree.

It breaks BC in cases when Tag::wrapWith() return value used. But it seems to be more logical and intuitive, like in jQuery

When applying a checked state to a checkbox, it is convenient to set the checked attribute with a boolean like the jQuery prop() API.

$bool = false; // Perhaps the property of a model
$el = Input::checkbox('foo', 'bar', ['checked' => $bool]);

#14 / #15 broke this by making NULL be the only wait to pass an attribute value that tells html-object not to add the attribute. This PR makes it so setting an attribute value to FALSE will NOT create the attribute. And setting it to TRUE will add the attribute as a property (no value).

Consider the following snippet:

$formGroup = \HtmlObject\Element::div();
$formGroup->nest(\HtmlObject\Input::text('foo'));

echo htmlentities($formGroup);

What I expect to get printed is:

<div><input type="text" name="foo"></div>

But, what really gets printed is:

Input get printed correctly, if I use it alone htmlentities(\HtmlObject\Input::text('foo'))

<input type="text" name="foo">

The closing tag comes to haunt only when nesting it inside another tag.

After looking through the code, I think the issue can be solved by modifying the code for close function on the Tag class, as follows:

foreach ($this->children as $childName => $child) {
  if ($child->isOpened ) { // <-- change condition to if ($child->isOpened && !$child->isSelfClosing) {
    $openedOn = $childName;
    $element .= $child->close();
  } elseif ($openedOn and $child->isAfter($openedOn)) {
    $element .= $child;
  }
}

The problem is, I am not sure whether this fix will cause any side effects. :(

Hi @Anahkiasen,

Sorry for making more work for you today, thanks for releasing 1.4.3.

It ends up that 1.4.3 changes the behavior of ->addClass(null), which is causing headaches in 20+ Former tests.

This branch simply demonstrates the change -- feel free to merge a different fix if you like, or let me know if you don't consider this a regression and I will deal with it in former.

# html-object 1.4.2:
Element::p('foo')->addClass(null)->__toString(); # <p>foo</p>

# html-object 1.4.3:
Element::p('foo')->addClass(null)->__toString(); # <p class="">foo</p>

The issue stems from the new strict in_array check in Tag::addClass(). It ends up this call is:

# html-object 1.4.2:
in_array(null /* $class */, [""] /* $classes */); # true

# html-object 1.4.3:
in_array(null, [""], true); # false

To fix this, I simply checked if $class was null or "" and avoided the is_array call in this case.

People that install this library via composer don't need the examples, they just need the library itself. This PR removes the sample directories and files from the repository auto-generated ZIP archives. Developers that need some more info can still do a git clone or just look at this repo on GitHub.

Since PHP 8.1, passing null as the second parameter of explode() raises this deprecation error:

Deprecated: explode(): Passing null to parameter #2 ($string) of type string is deprecated

Let's fix it.

Hi @Anahkiasen,

This pull request fix a bug when using the HtmlObject\Traits\Tag::removeClass($classes) method.

Otherwise, when you try to remove a CSS class which isn't present, it'll remove a wrong CSS class, see the testCanRemoveClasses test for more info.

Because the array_search() PHP function returns the key for needle if it is found in the array, false otherwise. This array_search() function may return Boolean false, but may also return a non-Boolean value which evaluates to false.

So in the HtmlObject\Traits\Tag::removeClass() method of this package, we need to check if the $exists value is strictly not equals to false instead of using the !is_null($exists) check.

If this fix is merged and a new release is tagged, I'll update the Former dependency to release the final version of Former 5.0.0 🤞

By the way, many thanks for all the work you have done on this package and Former 👍

Have a good day, Tortue Torche

From 1.4.2 to 1.4.4 the behavior of data_foo() changed.

1.4.2: <input data_foo="true" /> 1.4.4: <input data_foo />

I saw that there were some changes about false/empty attributes, if it was intentional then disconsider this issue, otherwise it might be interesting to restore this behavior.

Thanks

// add two empty cells into row
$tr->nest('td', '');
$tr->nest('td', '');

// but there is only one
// because it uses empty string as child id o_O
print $tr; // <tr><td></td></tr>

It is easy predictable side-effect — node string content used as node id will fail at second inserted child with same content.