https://github.com/wavetermdev/htmltoken
fork of golang.org/net/html HTML tokenizer to allow for case sensitive tags and attributes
https://github.com/wavetermdev/htmltoken
Last synced: 3 months ago
JSON representation
fork of golang.org/net/html HTML tokenizer to allow for case sensitive tags and attributes
- Host: GitHub
- URL: https://github.com/wavetermdev/htmltoken
- Owner: wavetermdev
- License: bsd-3-clause
- Created: 2024-07-23T19:58:07.000Z (over 1 year ago)
- Default Branch: main
- Last Pushed: 2024-11-02T17:50:20.000Z (about 1 year ago)
- Last Synced: 2025-07-17T16:56:42.757Z (6 months ago)
- Language: Go
- Size: 34.2 KB
- Stars: 1
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
This is a fork of part of the golang.org/x/net/html package.
## v0.2.0
For v0.2.0 we made a more radical change to the [tokenizer](https://pkg.go.dev/golang.org/x/net/html#Tokenizer) package.
We added a new syntax to allow attributes to be set with '{}' syntax.
Any valid JSON expression is allowed within the curly brackets (this more
closely matches JSX syntax).
```
```
To support proper decoding in the client, attributes now have a an `IsJson bool` field
which is set to true if an attribute was parsed with the new {} syntax.
If you only need the case-sensitive tokenization for tags/attributes it is
recommended to use v0.1.0 and not v0.2.0.
## v0.1.0
It is not a complete fork as we only want to modify and change https://pkg.go.dev/golang.org/x/net/html#Tokenizer. So this is the minimal amount of code to get html.Tokenizer working.
The reason for the fork is to allow for returning of case-sensitive tag names and attribute names. The current package normalizes the tag names and attribute names by calling (the equivalent of) strings.ToLower on them before returning them to the caller. We made a very small two line change in token.go to remove those ToLower calls. Other changes involve copying enough code from other files to get all the dependencies satisfied and get it compling again.
Why did we not fork the entire package? Because the rest of the html package is a _validating_ html parser and is quite complicated. As the HTML rules can change over time, it would need to be continually updated and synced with the upstream to keep it compliant. As the actual syntax (tokenization rules) of HTML does not change often, this part of the package is likely much more stable.