tidy-html5: add head spec
=========================
- [x] Have you followed the [guidelines for contributing](https://github.com/Homebrew/homebrew-core/blob/master/CONTRIBUTING.md)?
- [x] Have you checked that there aren't other open [pull requests](https://github.com/Homebrew/homebrew-core/pulls) for the same formula update/change?
- [x] Have you built your formula locally with `brew install --build-from-source <formula>`, where `<formula>` is the name of the formula you're submitting?
- [x] Does your build pass `brew audit --strict <formula>` (after doing `brew install <formula>`)?
-----
There's demand for HEAD here, as evidenced by the fact that I needed it just now.
I realize this issue is kind of stale and hasn't generated a lot of interest, but I do want to contribute a new perspective. While it is true and unfortunate that the currently published version (October 2014) of the HTML5 standard waves its hands when it comes to the definition of URLs, the current working spec gives a very clear definition. To quote https://dev.w3.org/html5/spec-LC/urls.html:
> A URL is a string used to identify a resource.
>
> A URL is a valid URL if at least one of the following conditions holds:
>
> - The URL is a valid URI reference [RFC3986].
>
> - The URL is a valid IRI reference and it has no query component. [RFC3987]
>
> - The URL is a valid IRI reference and its query component contains no unescaped non-ASCII characters. [RFC3987]
>
> - The URL is a valid IRI reference and the character encoding of the URL's Document is UTF-8 or UTF-16. [RFC3987]
The message and trend here is very clear: IRIs as defined by RFC3987 are being promoted to first class citizens, especially in UTF-8/UTF-16 encoded documents.
@geoffmcl Omitting the warning when `--fix-uri no` is definitely a welcome change in the short term. (FYI, I also only use tidy-html5 to validate my documents, and I'm currently developing a website with non-ASCII paths.)
In the long term, I think there will come a day when `--fix-uri` should no longer default to `yes`, and I don't think it will be too far into the future.
@geoffmcl I just ran into this issue with 5.2.0 on macOS 10.12.2 (with UTF8-encoded Chinese characters in filenames), and I can confirm that the `issue-468` branch fixed it for me.