nathanboktae / chai-dom

DOM assertions for the Chai assertion library using vanilla JavaScript
Other
76 stars 26 forks source link

Support shadowDom in displayed #23

Closed bennypowers closed 7 years ago

bennypowers commented 7 years ago

closes #22

nathanboktae commented 7 years ago

Thanks for the submission! One area this regresses on is CSS with !important will override inline styles. Got an idea how you can handle both scenarios?

bennypowers commented 7 years ago

What about one-size fits all: always use window.getComputedStyle?

Sent from my LGE Nexus 5 using FastHub

bennypowers commented 7 years ago

BTW I'm using this on elements that have display: none ! important but no style attribute and it works. Also passes yarn test. also appears to work with elements that have a style attr Sent from my LGE Nexus 5 using FastHub

nathanboktae commented 7 years ago

The 3rd case is users testing a Dom node not attached to the body with an inline display style. getComputedStyle will always return "" for displayed, despite inline styling.

bennypowers commented 7 years ago

Can we check for that case specifically?

if el is not attached and has style.display
  check style.display
otherwise
  check getComputedStyle

?

bennypowers commented 7 years ago

See also this incredible library https://github.com/UseAllFive/true-visibility

bennypowers commented 7 years ago

Take a look at this gist. I wasn't able to get it to work in all cases. it's giving false negatives on cases like this:

https://gist.github.com/bennypowers/80cfb099afc578d6e601dbde1ac9a180

test('edit controls should display', (done) => {
  flush(() => {
    edit.$.frameNext.should.be.visible;
    done();
  });
});
nathanboktae commented 7 years ago

Can we check for that case specifically?

That's what the current code does...

See also this incredible library

Meh, "true visibility" is a bag of hurt and can go on forever if you want. For example some things not covered in that snippet

  1. opacity: 0.01
  2. absolutely positioned element off screen (it may be covered)
  3. absolutely position element overlapping this element
  4. font and background color are the same ....

Really I'd rather have something like that separate from this library. There are no tests for all those cases too. Not to mention calling getComputedStyle is expensive and it's called everywhere, etc.