@@ 45,3 45,13 @@ Be nice to let inputs their own ngrams/vocabulary!
@formaction, @formenctype, @formmethod, @formtarget - where to send form data.
@formnovalidate - disables postprocessing validation.
Be nice to let forms link to newline seperated "phrases" which can be used to fill in multiple inputs simultaneously, more conversationally.
+
+## Collaborator thoughts
+@alcinnz
+1) Knowing that you have a tree rather than a buffer as the underlying data structure for the output is the most important detail. It means, for example, that you can treat forms that are children of navigation differently than those that appear in tags more likely to be the focus of the page
+
+2) You'll probably have at least 2 C APIs before you're done - one that tries for minimal processing on the C side and another that tries to expose as much as possible to C programmers. The things I want a library for are going to take much longer than what I want a browser for, if that helps you to focus on defining that boundary in a way that's minimally invasive to producing a GUI application for the desktop
+
+3) If you just want a regexp engine that can compile and evaluate Posix regexps supplied by developers, you probably won't find much better than the TRE library. Ignoring the extra features, it has a small code footprint and makes efficient algorithm choices for matching
+
+Free text is a whole other issue. You owe it to yourself to make it as easy as possible for others to serve their personal biases with minimal intervention from you 😎