WebReflection / basicHTML

A NodeJS based, standard oriented, HTML implementation.
ISC License
126 stars 10 forks source link

few differences from actual browser API #16

Closed dsadhanala closed 6 years ago

dsadhanala commented 6 years ago

once again thanks for the awesome work!

More and more I use basicHTML, I really like it, especially it enabled me to write and run tests for customElements, for which I use to struggle a lot with JSDOM earlier.

Since basichtml goal is not necessarily to be 100% same as browser DOM api, not sure if this needs to be considered as enhancement or bug, you can close this, if you think it's a overkill, I'm just logging my findings.

To make tests run and return same results in actual browser, noted below differences:

  1. Element.tagName should always return upperCase() to match with browser API, ex: img > IMG.

I'm overriding for now with below.

Object.defineProperties(Element.prototype, {
    tagName: {
        get() {
            return this.nodeName.toUpperCase();
        }
    }
});
  1. may be it's HTML parser used in basichtml doing this, but void elements are being converted into XHTML instead of HTML5, ex: <img src="image.png" alt="alt text" /> where as actual browser returns <img src="image.png" alt="alt text">
  2. TIOLI, native attributes that are converted into properties on the element are not available ex: 'src', 'href' etc. I can extend by adding get/set onElement.prototype but getAttribute works for now without needing to do this.
WebReflection commented 6 years ago

basicHTML is explicitly XML friendly, and so is the DOM itself, example:

... should always return upperCase() ...

not really, try this:

document.body.innerHTML = '<svg><rect /></svg>';
document.body.querySelector('rect').tagName;
// "rect" not "RECT"

If you want to compare tag names either use i flag for RegExp or tagName.toUpperCase() to be sure.

This is not going to change because basicHTML works with NativeScript too and defines Custom Elements such <Page.titleBar> so it's mandatory to be case sensitive.

... void elements are being converted into XHTML ...

Yes, which should be irrelevant for everyone using it.

native attributes that are converted into properties

the HTMLElement sets some get/setter but there are no specialized classes such HTMLAnchorElement (for src) or others, but it's not a goal of this project to become a JSDOM like library, the point here is to keep it simple.

I start feeling like you want a 1:1 DOM/browser-like environment but JSDOM has no Custom Elements ... if that's your case, I think you should rather bother JSDOM about Custom Elements because I won't make this project a strict DOM/browser-like environment, there's already JSDOM for that.

Hopefully I didn't lower your expectations too much. If you have other questions, please feel free to ask.

dsadhanala commented 6 years ago

Thanks for your response, as I mentioned above, these are not blockers, just thought of checking with you also help log incase someone run into similar situation.

I have added work arounds in my code to move forward and should be ok without these changes to basicHTML.