search

w3c / IntersectionObserver

Intersection Observer
https://www.w3.org/TR/intersection-observer/
Other
3.62k stars 523 forks source link

rootMargin should allow 0 without units #244

Open cezaraugusto opened 7 years ago

cezaraugusto commented 7 years ago

having to write 0px or 0% seems unnecessary and is error-prone for developers used to type this way with CSS margin shorthand.

related #126

midzer commented 7 years ago

rootMargin with 0 work for latest browsers. Firefox 52 throwed a warning for me in this case. Thats why I've updated the docs https://github.com/w3c/IntersectionObserver/commit/22b8b74f2ab28959c088aabba80bb17cee0d72a4

cezaraugusto commented 7 years ago

are you talking about beta/nightly versions? I tried the following which succeeded only in FF:

new window.IntersectionObserver(() => {}, {rootMargin: 0})

Latest stable tests:

I guess that's something browser vendors should take care and nothing from the spec to be done?

rjgotten commented 5 years ago

Can't believe that this is still a problem even now, with Chrome 73. rootMargin: "100px 0 0 0" continues to throw a SyntaxError which complains that values 'must be specified in pixels or percent'

What is the actual spec-mandated behavior here? (And if it doesn't allow unit-less zero values, then that is asinine and should be changed.)

lebnic commented 4 years ago

Still relevant, indeed rootMargin: "100px 0 0 0" or rootMargin: "0" or rootMargin: "200px 0 0" throws an error...

This is problematic, because documentation states that Can have values similar to the CSS margin property, (ref: https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API)

pikeas commented 3 years ago

Still happening as of April 2021. @lebnic is right, the rootMargin documentation says that it follows the syntax for margin, which means 0 should be a valid value.

emilio commented 3 years ago

Well, the documentation is not the spec. Spec is here and it doesn't do anything with <number> tokens, so zero is not allowed. That's not to say it couldn't be changed potentially, just that as things stand, the documentation is wrong and browsers are right.

rjgotten commented 3 years ago

As it stands even that official spec mentions that the rootMargin value is provided

in a manner similar to CSS’s margin property

The problem is the spec declares rootMargin to be composed as a list of <dimension> values, when it should be composed of a list of <length-percentage> values, just like margin is. (And just like basically every other property that has to do with dimensionality or position is.)

Imho, this is spec-error that has trickled down to implementation error. As simple as that.

emilio commented 3 years ago

"similar to" is not quite a formal definition. It is a bit more complicated than just <length-percentage>, because at least as things stand, it's not clear what e.g. font-relative units would do. So you probably want something like <length-percentage>, but only allowing absolute lengths or percentages.

wolfbeast commented 2 years ago

This has my vote. Current implementations make an empty or whitespace string be equal to 0px, but "0" is not? That's madness.

wolfbeast commented 2 years ago

In anticipation of this spec error being resolved, I've adjusted the Goanna implementation to accept unitless values as it simply makes a lot more sense to have it aligned with margin and similar dimensional properties.

miketaylr commented 2 years ago

It makes sense to treat "0" as "0px", I think, somewhere around step 4 of https://w3c.github.io/IntersectionObserver/#parse-a-root-margin.