I continued with single file in lauri branch and have implemented all essential features.
The maximum numbers of lines in one file is arguable but for me 300 lines seems acceptable.
What do you think - is it light weight enought and fits into scope?
I did not understand your documentation file docs.mli so I didn't touch master branch.
I also removed newlines from toString - there are no newlines and spaces in browser document methods.
Revert Raynos changes
This reverts commit 9196b73bba3d08c6d58347d43571d0b636eaaf4f.
We use Element.getAttribute and Element.setAttribute
to access data-* attributes.
Fix _getAttributesString and add more tests
Fix Text inheritance and add tests
@lauriro since innerHTML does not put whitespace or new lines in things when you create using dom manipulation the whitespace removal is good.
The docs.mli file is based on jsig with minor syntax deviations.
I think your code fits within scope.
The options are either to take your PR as is or do style normalization + factor it across one file per interface (Node, Element, innerHTML algorithm) whilst adding more tests.
Also apologies for splitting it up into multiple files whilst you had a branch, i only realized how annoying that is after I did it.
In my opinion there are no reasons for one file per interface (files with 7 line for Text and DocumentFragment).
About style normalization - it would be good to set up some style guidelines, so you don't have to fix my code.
As you can guess, for me my style seems quite acceptable :)
At the moment I don't see any missing feature and the current state is sufficient.
Minor optimizations would be mostly style changes and matter of taste - no real reason for performance optimization.
More tests and documentation would be useful for others
One of the reasons for file seperation is the ability to load a specific interface directly
var document = require("min-document")
var Document = require("min-document/document")
var Element = require("min-document/element")
I don't see any real use case for this ability, it is difficult to use just part of document.
I'll try this branch on projects I have that use min-document for rough integration testing and I'll try to make a list of back compat breaking changes.
Then assuming no bugs I'll merge this in (without refactoring) and publish as 0.4 or 1.0 depending on back compat changes.