Formidable
Formidable copied to clipboard
Gregwar
Attributes with single quotes not working in form
Any maintainers still checking this repo?
It seems like currently any attributes with single quotes turn into the attribute name, i.e. class='page-wrapper' will turn into class="class".
Single quotes are valid in html for attributes, and, more importantly for me, in our project we have data-json='{"json":"values"}' which will become data-json="data-json".
Hello,
I think escaping the quotes (") using HTML Entities is by far a better approach than using simple quotes, here is a snippet demostrating how it works using htmlentities() in php:
<script type="text/javascript">
function display() {
element = document.getElementById('something');
dataJson = JSON.parse(element.attributes['data-json'].value);
alert(dataJson['json']);
}
</script>
<body onload="display()">
<div id="something" data-json="<?php echo htmlentities(json_encode(["json" => "values"])); ?>">
<!-- Will result in: <div id="something" data-json="{"json":"values"}"> !-->
</div>
</body>
Else, how would you process JSONs containing both " and ' ?
{"message": "Sorry I'm late"}
Else, how would you process JSONs containing both
"and'?{"message": "Sorry I'm late"}
I would do it the same way that browsers do it, by parsing the HTML based on which type of quote is used.
Sorry, but do you really think it's a far better solution to work around it rather than to have Formidable parse valid HTML? Otherwise it's nothing more than a subset of HTML. From the HTML specification:
The HTML specification says: Attributes are placed inside the start tag, and consist of a name and a value, separated by an = character. The attribute value can remain unquoted if it doesn't contain spaces or any of " ' ` = < or > . Otherwise, it has to be quoted using either single or double quotes
The json is not generated by PHP. It would be less work to change Formidable than to change all of the JSON. Would you accept a pull request for it?
Yes of course, simple quotes are OK with HTML specifications anyway, so I agree with supporting it However I'm just pointing out that it might still be an issue if you have json containing both " and '
Awesome! But, it looks like if the value contains double quotes, it looks like it currently causes the string to terminate early.
Could you check out my pull-request? I think something like that would work in all attribute situations other than the special cases (type, name, etc).
There was indeed an issue since the attribute data was not escaped Does 3025618 solves your problem ? (Added unit test)