This is the first post in a new series, "My Open-Source Projects", where I go through some of the OSS projects I started or maintain and tell you ...
For further actions, you may consider blocking this person and/or reporting abuse
The part I like here is the decision to build the actual DOM API instead of a ‘close enough’ parser. That kind of standards work is not flashy, but it is what makes a library useful for years.
Many thanks. Indeed, when we've chosen the official / W3C DOM API as driver it very often was difficult to communicate this correctly (people wanted simpler / more .NET-like APIs), but in the long-run this has been crucial (e.g., we can always say "look at this code example there" "see this StackOverflow answer here", with the only remark that JS APIs / usage just needs some slight stylistic adjustment (e.g., "innerHTML" becomes "InnerHtml", but the overall way / algorithm remains the same).
Does AngleSharp.Diffing treat SVG path data purely lexically, or is there any SVG-specific normalization? Equivalent geometry can serialize quite differently while rendering identically.
It only sees the DOM and to be my knowledge AngleSharp.Diffing does not do any other comparison w.r.t. SVG. I think this part would be mostly in the "render the two pages visually and compare outcome" ballpark, which is also possible with AngleSharp but not what AngleSharp.Diffing does.
Good CSS/HTML coverage. We just launched a free image toolbox at tools.shopveigo.com — the client-side image processing uses a lot of modern CSS and Canvas APIs. Frontend devs might find it interesting.
Nice frontend patterns! We built a free AI image toolbox at tools.shopveigo.com/image-toolbox — background removal, upscaling, ID photos. The frontend uses similar CSS techniques for the image comparison sliders. Would love feedback!
Your insight into the challenges of parsing HTML and the importance of handling edge cases resonates deeply. It's fascinating how AngleSharp evolved from that initial flight concept into a robust library that truly adheres to the W3C DOM API. As you continue refining the project, consider incorporating unit tests focused on those tricky edge cases; they could bolster the reliability of the parser even further. If you’re looking for help in expanding your testing framework or managing contributions, I’d be glad to discuss a paid collaboration. What other features do you envision for AngleSharp as it grows?
AngleSharp uses many of the WPT tests where applicable and all the standard tests available. It has a very high test coverage and runs almost 4k unit tests (that's the core AngleSharp library alone, e.g., AngleSharp.Css has almost 3k unit tests as well etc.).
So, a definite: yes. Unit tests are super critical in fighting potential regression and keeping maintenance minimal. Anyone who can contribute here is highly welcome.
At the moment the focus is on expanding into more web functionality (i.e., nothing for the core, but for libs such as AngleSharp.Wasm or AngleSharp.Io that deal / introduce such capabilities) and APIs offered through AngleSharp.Js / scripting engines. The next step is to have a full headless (and headfull) browser based on it.
It's a cool thing, but how does it overlap with HtmlAgilityPack?
HtmlAgilityPack is older and more simple. For instance, it's not HTML5 compliant. As such if your project is older than 10 years its likely it used HAP other than AS. If you really care about parsing alignment with the browser there is no way around HTML5 compatibility, hence AS would be preferred. Otherwise, if you just parse some simple HTML then HAP would be better suited. The biggest difference is that AS is actually a core browser engine (which can be extended to a full headless or headfull browser) while HAP is just a mere (non-HTML5-compliant) parser.