jonjohnjohnson
commented
5 years ago @r12a +1 for a logical mapping in rootMargin. Especially since intersectionObserver seems to be the encouraged solution for "stuck/unstuck" sticky position events where position schemes use both physical and logical box offset properties.
2.4. The IntersectionObserverInit dictionary https://www.w3.org/TR/intersection-observer/#intersection-observer-init
Are the margin values related to physical (fixed) sides, or logical sides?
I find myself wondering whether there might be an issue here when dealing with page localisation. If a developer sets different margin values for the sides of a box, these apply to the physical dimensions of top, right, bottom, left, and presumably relate to the position of content within the box created by the target element.
Suppose a rootMargin value is set on an English page where the target element has a larger margin to the left. In an Arabic/Hebrew localisation the larger margin could well appear on the right. In CJK or Mongolian vertically-set text, the larger margin may appear at the top.
The implication of this is that during localisation, the localisers will need to remember to change the javascript as well as the markup and styling - which is probably a much taller order than localising HTML and CSS (where the CSS needs explicit changes). It also decouples the sizing of the box from the transformations that can be applied using styling.
Note that CSS styling tries to deal with this problem by providing properties or values that accept terms such as start and end, rather than physically bound constructs.
I don't know what the solution to this would be, although i find myself wondering whether a parameter that allowed the javascript parser to take into account the styled margins or not might be useful.