New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
STYLE_GET seems broken #546
Comments
Could you try it in 0.12? |
@ziflex hello, same result on my side with ycombinator example
example code checked quickly, seems good to me. |
Hi, I've took a look and seems to me it's the correct behaviour, as it's checking for the element styles. @ziflex what do you think about adding If you say so, I'll try to implement it. |
hoo, maybe you are right, I didn't even think about it, it is very rare to have properties directly on the element today, that would be a good idea 👍 |
Can we think about adding an optional 3rd parameter to Also, we would need to add a new property to a HTML element. |
if you add this I would advise enabling this option by default |
I wonder what implications might be if we always return computed styles? |
I think returning computed styles is the natural thing to do here. Most use-cases I can think of, you'd be interested in what styles are currently applied to an element. The only use-case I can think for getting the style that's attached to a specific element would be UI testing (i.e. "assert that style X is attached to element Y"). Can anyone think of another use-case? |
Ok, I think the resolution would be this:
|
seems good! |
@d2bit do you wanna take it? |
Thx :) |
Describe the bug
Not sure because it's my first test on it but STYLE_GET seems broken
To Reproduce
will return [{},{},{}...]
Expected behavior
font-family: Verdana, Geneva, sans-serif
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: