-
Notifications
You must be signed in to change notification settings - Fork 6
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
Is there a definitive version of a type array? #22
Comments
I don't see any use for this to be defined with this precision. I always have thought of it as “an unordered list of classes starting in h-” |
Maybe that would be a better description then? The way it specifies “ There is also the question of what you mean by “classes”. Do you mean anything in the The DOM Here is a quick comparison between using the DOM method or doing your own string manipulation on the let output = []
for (let value of element.classList) {
if (value.substr(0, 2) === 'h-') {
output.push(value)
}
}
// output === [ "h-entry", "h-cite" ] let output = []
for (let value of element.getAttribute('class').split(/[\x09\x0A\x0C\x0D\x20]+/)) {
if (value.substr(0, 2) === 'h-') {
output.push(value)
}
}
// output === [ "h-entry", "h-cite", "h-entry" ] I feel like following the DOM specification and having the HTML parser handle parsing the attribute into a token list would be a good move for microformats. You are going to have to dive into the specification to figure out how to split the Following the spec also gives us ordered lists that should be the same between implementations. WHATWG specifically calls out interoperability as a reason for using ordered lists as often as possible (from the ordered set link above):
|
Again not really sure this is relevant in practice. |
It probably isn’t relevant for parsers. But it is relevant for tests and things like a JSON schema for validating microformats in JSON (e.g. for Micropub). If the spec does not define what the |
Maybe people who understand validating mf2 can give more input. I am not sure that validating mf2 outputs from parsers makes much sense. |
As came up today, per the latest JSON spec RFC 8259:
As opposed to:
If we were to strictly compare the JSON output of different parsers and compare arrays with order intact, they will be in conflict with each other. |
Say we have this HTML snippet:
What would you expect the following step in the parsing spec to return?
The PHP parser gives us the array in alphabetical order:
While the Go and Python parsers stick to the order as given:
In addition to this I would want to ask if people expect this array to give unique classes only or not? Is there any use to returning
[ "h-entry", "h-entry" ]
?Or maybe none of this needs to be defined and the answer to the question in the topic is just “an unordered list of classes starting in
h-
”.The text was updated successfully, but these errors were encountered: