Open gsf opened 10 years ago
That would be a pain in the ass because outerHTML
would have to be a getter. I've avoided getters so far.
I figured there might be a catch. Any other ideas on how to test element output across server and browser?
I would also like support for outerHTML
so the exact same code can run client/server.
This seems like a good use for a getter in the constructor to so I'm curious why you want to avoid it:
Object.defineProperty(this, 'outerHTML', {
get: function() { return this.toString() }
})
Otherwise this lib would have to monitor changes to itself and render upon each to the property; which sounds a lot more horrible IMO.
@Raynos out of curiousity, what is your reason for avoiding getters in this codebase? I've been looking at adding some additional properties to nodes (e.g. attributes
, firstChild
, nextSibling
, DOMText.nodeValue
) which would be simpler to implement with getters (and avoid duplicate data consistency bugs). What's the best approach to adding such properties to this library? Would you accept a pull request that implemented them using getters, or simply assigning duplicate properties?
@chromakode
getters have been avoided for ES3 compatibility. Generally all modules I author use ES3 + (subset of ES5 that is shimmable).
Thanks for the clarification :+1:
Because
toString()
on an element in the browser returns something like "[object HTMLDivElement]", I have a helper function like this in my tests that run on both server and browser:Could elements in min-document have an outerHTML as well for parity?