-
Notifications
You must be signed in to change notification settings - Fork 31
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
Update the spec to match the current group consensus. #208
Conversation
- Use camel case for variable names. - Use list syntax. Mark list members as strings. - Be more explicit about "strictly conform to". - Remove canonical config. - Replace removeChild(). - "set and filter" take a "safe" boolean - Use "set difference" instead of intersection complement. - Introduce "dataAttributes" for data-* attributes. - Add special cases for javascript:-URLs and templates ("funky elements") back in - Minor edits.
235f8e6
to
2cf1b2f
Compare
7393024
to
bee5caa
Compare
5e9acec
to
e4d3ebe
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a number of nits doing a more detailed read through, but I wonder if this is the best use of time as we'll likely also get to this once it gets proposed to HTML. What do you think Daniel?
index.bs
Outdated
1. If |config| exists: | ||
1. Run [=sanitize=] on |fragment| using |config|. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems fine to inline again, but also unclear if config is actually conditional.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Inlined.
Config is conditional, because step 4 of canonicalize can return empty. The idea is that in the "unsafe" usages, one could in theory define a "no-op" config that doesn't do anything. But it seemed clearer to me to just skip the filtering step for "unsafe" ops where the user hasn't requested any filtering.
In terms of mechanism, I think the previous way was a bit confused. So I've now changed canonicalize to return an empty list / ordered map; and this check to check for emptyness.
Can you resolve the review comments that are addressed in the latest. commits? @otherdaniel Did you notice that your latest commit failed syntax validation? |
Will do.
I had not. That particular problem is now resolved, but I wonder if there's a way to replicate all the commit hooks locally. I chiefly rely on bikeshed's error messages. But the repo runs additional checks, like this WebIDL check, and it'd be good if I could run the same checks before pushing a new version. |
dc9adea
to
e7c3a93
Compare
e7c3a93
to
1138f3c
Compare
All comments should now be resolved, except for one about the potentially-empty config. (Which I don't think is much of an issue.) My plan would be to land this in its current version, unless I receive any additional comments, so that we can handle the rest in additional PRs. |
+1, let's land and do the remaining discussion about an empty config as a follow-up. Thank you @otherdaniel! |
SHA: db21b50 Reason: push, by otherdaniel Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This updates the current spec to the current group consensus. More work needs to be done, but with this the spec should roughly reflect the current discussion.
This closes out a whole lot of issues: Closes #200. Closes #199. Closes #188. Closes #186. Closes #183. Closes #181. Closes #148. Closes #147. Closes #101. Closes #59. Closes #45.