-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Boolean or not Boolean (attributes) #867
Comments
I forgot to add the RFC822 I've now also tested with Windows 10 Mail (latest version), and found (slightly but not entirely surprisingly) it does not support the HTML5 empty attribute syntax either: So I definitly don't think Option 1 above is viable. There are too many people using Windows 10 Mail! OTOH, at least we now know that the Windows 10 Mail app is still lagging at least 10 years behind in terms of conformance to specifications (incidentally, and quite annoyingly, it doesn't support |
What changes do you propose upstream to achieve it? The spec seems to suggest both Need to open an issue and see what they might be open to. That will then decide what should happen next.. |
See #831 (comment) Really, an option to short-circuit the namespace tests and simply return However, I think that list is back to front. It should be listing attributes known as Boolean, rather than the other way round. Any unknown attribute should be classified as non-Boolean. So that's at least two PRs... |
I opened an issue for this upstream to see what they say before submitting a PR. Please comment on it if you have anything to add! |
Thanks! Would you be so kind to post the link? |
Arising from #831 is the handling of Boolean vs non-Boolean attributes by the Emogrifier package when parsing and serializing HTML, with respect to the empty attribute syntax.
The empty attribute syntax (e.g. in
<input disabled>
or<img alt>
as opposed to<img alt="">
) is permitted for all attributes in later versions of the HTML5 specification. However, in HTML 4 this syntax is technically an attribute value with an implicit attribute name, and only works for certain attribute keywords.The current behaviour derives simply from that of PHP’s
DOMDocument
/libxml
implementation, which is as follows:DOMAttr
node has aDOMText
child after parsing.As seen in the initial implementation for #831, this behaviour would change were
Masterminds/html5-php
to be used as is for HTML parsing and serializing (all attributes with an empty string value would be serialized with the empty attribute syntax).Moving forward, we have several options:
I do not think option 1 is viable, for the following reasons:
<a href="">
is rendered as a link whereas<a href>
is not).With option 2 or 3, I think we should also (first) add tests to enforce the desired behaviour (even though these would effectively be testing a third-party library), then there are a couple of alternative approaches that could be taken:
Masterminds/html5-php
classes to achieve the desired behaviour;Masterminds/html5-php
to make the desired behaviour available via a simple option.It is worth noting that logic exists in
Masterminds/html5-php
for whether to serialize attributes using the empty attribute syntax depending on whether they are Boolean, but it is currently only enacted if the document has an explicit, non-default namespace.The text was updated successfully, but these errors were encountered: