-
Notifications
You must be signed in to change notification settings - Fork 523
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
Don't call public API methods; instead call their backing algorithms #55
Comments
Fixed Not sure the best way to address |
For getBoudningClientRect lets used Domenic's text and file a bug against cssom-view asking for a name for this algorithm so we can refer to it directly. |
Added Dominic's text in #71. |
Has this been done? |
I filed a bug on cssom-view: |
I'm reopening this as it's not fixed. (And #401 got closed so I guess this is preferred.) |
I sent in a PR to cssom-view, w3c/csswg-drafts#7446 |
A few places in the spec refer to public API methods:
This is not quite the right thing to do, since it implies that e.g. if I do
Element.prototype.getBoundingClientRect = () => { throw new Error("boo"); }
, you'll call that overriden function.Instead, the correct thing to do is to refer to the backing concept or algorithm behind that method. For unobserve, you'd probably define something in the processing model like
"To remove an intersection observer o from an Element target, perform the following steps: ..."
Then unobserve() algorithm would do "Remove the intersection observer this from target," and instead of doing "invoke unobserve()," you would do a similar thing.
For getBoundingClientRect(), things are more annoying, since CSSOM View hasn't factored themselves appropriately. There you could do something like "Let boundingClientRect be a DOMRectReadonly obtained by the same algorithm as that of Element's getBoundingClientRect() performed on target."
The text was updated successfully, but these errors were encountered: