mozilla :: #layout

19 May 2017
12:34noxWhat's the purpose of ComputeDistance?
14:40mstangenox: I might be completely wrong about this, but I think SMIL has some kind of fixed-velocity animation
14:41noxmstange: Asking because I think what we do for the type that represents <length> | <percentage> in that method is completely wrong in Servo.
14:42mstangeok, I don&#39;t know enough about this to answer
14:43mstangenox: redirecting you to birtles / hiro / dbaron
14:43noxWe more or less convert every part to f64 and then return Ok(((this.length - other.length) as f64)^2 + ((this.percentage - other.percentage)^2)
14:43noxI think if there are mixed lengths and percentages we should return an error instead.
15:52sheppytobytailor: I was told you might be able to answer a question about an issue I&#39;m having with Intersection Observer as I work on sample code for the docs.
15:52sheppytobytailor: Reading the spec, it seems that each time a target element&#39;s intersection ratio passes one of the entries in the observer&#39;s thresholds, the callback should be called. But it appears that we only call the callback the first time isIntersecting changes and the ratio exceeds at least one of the entries in threshold list.
15:52sheppytobytailor: Or it gets called when isIntersecting changes, then a second time when the first threshold is passed. Then it doesn&#39;t get called again until isIntersecting flips again. Pretty sure that&#39;s not what&#39;s supposed to happen, is it?
15:53sheppyAt any rate, I don&#39;t get called nearly as often as I expect to given the way I read the spec...
16:07dbaronnox: yeah, I think it&#39;s for SMIL paced animations, but birtles would know for sure. We also used to use it for reversing transitions, but now we just implement the behavior described in https://drafts.csswg.org/css-transitions/#reversing
16:16bkellyanyone know where the reftest harness lives?
16:17bkellyI&#39;m trying to figure out how it knows when to take its screenshot
16:17bkellyand if it uses setTimeout() as part of that code
16:17mikoThis maybe https://hg.mozilla.org/build/mozharness/ ?
16:19mikoThe actual reftest tool is in https://dxr.mozilla.org/mozilla-central/source/layout/tools/reftest
16:20tobytailorsheppy: can you point me to an example?
16:20bkellymiko: thanks!
16:20tobytailorsherry: preferable jsbin
16:25sheppytobytailor: https://jsfiddle.net/pjf13tkq/1/
16:25tobytailorsheppy: we do have a test for that case too: http://searchfox.org/mozilla-central/source/dom/base/test/test_intersectionobservers.html#505. would be interested to see where your case differs
16:25* sheppy looks
16:26tobytailorsheppy: ic
16:27tobytailorsheppy: so your observed target doesn&#39;t change over time
16:27tobytailorsheppy: in that case you only get one notification
16:27sheppySame target (or targets; my full example has several).
16:27sheppyReally. Hum. That&#39;s interesting.
16:27tobytailorif you would resize your target over time, you would get multiple ones
16:28sheppyHm. That seems counterintuitive; wouldn&#39;t the ratio be what matters rather than changes to the target element itself?
16:28tobytailoryes
16:28tobytailorthe api tries to solve the problem &quot;when is it visible and how much&quot;
16:28* sheppy starts thinking about how to rewrite his code to not need to be notified for each threshold crossed.
16:29tobytailornot really &quot;where&quot;
16:29tobytailoryou can calculate that yourself
16:29sheppyThe way the spec is written seems to say that you get called each time you cross a threshold, given how the previous threshold is tracked etc.
16:29tobytailorsheppy: use requestAnimationFrame multiple times and resize your element
16:29sheppySo this is interesting and will mean rewriting a bunch of documentation. :)
16:30tobytailor:)
16:30tobytailorsorry for that
16:30sheppyHappens. I&#39;m just very intrigued because this so very much doesn&#39;t seem to be what the spec says to do, so I&#39;m curious about how I&#39;m misinterpreting the spec.
16:30* sheppy reads the algorithm yet again.
16:31tobytailorthe spec says to run the algorithm for each target in observers internal
16:31tobytailornot for each thresold
16:31tobytailorthe latter would result in what you expected
16:32tobytailorsheppy: would love to hear what other things you think don&#39;t behave spec conform
16:33sheppytobytailor: Yeah, I see that, but since it&#39;s saving the previous threshold, wouldn&#39;t the next time the &quot;Run the Update Intersection Observations Steps&quot; algorithm is called result in the next threshold being notified on if passed?
16:33tobytailor&quot;Let thresholdIndex be the index of the first entry in observer.thresholds whose value is greater than intersectionRatio&quot;
16:34sheppyRight...
16:34tobytailorthe first time the algorithm runs in your example is when the target is already fully visble
16:34tobytailormeaning ratio >= 1.0
16:34sheppySo it doesn&#39;t work backward.
16:34tobytailorno
16:34sheppyAh-ha.
16:35sheppyThat&#39;s my mistake; I assumed the algorithm worked both directions.
16:35tobytailorthesholds is &quot;a list of thresholds, sorted in increasing numeric order&quot;
16:35sheppyI read too much text that said &quot;any time the intersection ratio crosses a threshold&quot; without anything saying it had to be in a specific direction.
16:36tobytailorwe can always propose a spec change if you think some wording is too confusing
16:36sheppyThe list being in increasing order just seems like a data management thing; doesn&#39;t necessarily preclude processing in both directions. So that wasn&#39;t clear to me. I see it now, sort of.
16:36tobytailorif not ordered you would have to scan from both sides
16:37tobytailorand the spec should mention that
16:37sheppyI get why it happens the way it does now, anyway. I think there are too many places (probably mostly blog posts and such) that neglect to mention that &quot;cross a threshold&quot; means &quot;cross a threshold getting larger&quot; :)
16:37tobytailoryeah, I myself got some changes made to the way threshold behavior is explained in the spec
16:37sheppyOr something to that effect. So I read into it a bit, I suppose. Hm.
16:37tobytailorso I hear ya
16:37sheppyThat&#39;s a shame. Was relying on the ability to get notified in both directions in this rather extensive example. :)
16:38tobytailoryeah, but that would also somehow imply that your element changed over time
16:38tobytailorwhich it doesnt
16:39sheppyWhy would it imply that? It would just imply that you&#39;ve reversed your scroll direction.
16:39sheppyAnd you&#39;re now scrolling your element back into view.
16:39sheppy(in this case)
16:39tobytailoryeah, if you scroll you would actually get multiple events
16:39tobytailorbecause we run the algorithm multiple times in between
16:40tobytailorit always happens before rendering
16:40tobytailorin your case it only happens once
16:40tobytailoryou are not triggering re-rendering
16:40sheppyOh! The algorithm only runs on a re-render... hm.
16:40tobytailorthe spec says that too :)
16:41sheppyI missed seeing that.
16:41* sheppy looks again
16:41tobytailorsee https://wicg.github.io/IntersectionObserver/#event-loop
16:41sheppyYeah, I see it now.
16:41sheppyI even read that section.
16:41sheppyDidn&#39;t connect the dots though.
16:42sheppyThis leaves me tempted to just make a trivial change to my element to force re-rendering so that the API does what I want it to do, which is probably hideous. :)
16:42sheppyLike changing the color from rgb(255, 255, 255) to rgb(254, 254, 254) or something :)
16:43tobytailorjust make your example scrollable
16:43sheppyJust having the page longer than the window height isn&#39;t enough?
16:43sheppy(which is the case, for me at least, with this jsfiddle)
16:45tobytailorchanging the color doesn&#39;t change the ratio
16:45tobytailorthat wouldn&#39;t help
16:45sheppyOK, yeah, sure. Changing the height by a pixel back and forth then :D
16:45tobytailorstart having the target out of the viewport
16:46tobytailorthen bring it into viewport somehow
16:46tobytailorvia scrolling or animating
16:46tobytailorthat gives you what you want
16:46sheppyWill it just keep on working in both directions after that? That&#39;s curious.
16:46tobytailorchanging the size also doesn&#39;t help :)
16:46tobytailorif its still fully in viewport
16:46tobytailorthe api measures visibility, not dimensions
16:47tobytailorif its 100x100 or 50x50, ratio is still 1.0 if its in the viewport
16:47sheppyRIght. Of course.
16:47sheppyHm.
16:48sheppyOK, I know what I need to do. I just realized I&#39;m doing two checks in my actual example where only one is needed, and I think that will let me go back down to having just one threshold.
16:48sheppyAnd then things should just do what I expect.
16:49sheppyBut I definitely have some updates to do to a few articles :)
16:50tobytailorchanged your example a bit: https://jsfiddle.net/pjf13tkq/2/
16:51tobytailorto make it start b being scrolled out of view
16:51tobytailorscroll it into view and you should get your events
16:52sheppyYeah, that kind of works... although having to have it scrolled out of view to start with is a little odd. I think I have another solution; will try it after lunch. Thanks for your patient help.
16:52sheppyI may or may not be back for more, but at least I&#39;m not banging my head against the wrong wall now. :)
16:53tobytailornp :)
16:54tobytailorand having it scrolled out of view is not odd at all, thats exactly the use case that api is for
16:55tobytailorrunning out of battery, back online in ~30min
16:56sheppyHm, the descriptions of the API always seem to suggest it&#39;s for going both off and on screen, so it&#39;s odd that starting onscreen complicates things a bit. Ah well.
20:00sheppytobytailor: So... if I have an observer which is configured with thresholds being just 0.75, and my callback is called, if isIntersecting is true, shouldn&#39;t the intersectionRatio always be at least 0.75? What am I still missing that this isn&#39;t the case?
20:05tobytailorit should be at least 0.75 yes
20:05tobytailoryou might get 0 in some cases
20:05sheppyYeah, I&#39;m getting a lot of values less than that, so I&#39;m a little confused.
20:05tobytailorratio === 0 but isIntersecting == true
20:05sheppyAnything between 0.024 and 0.63...
20:06tobytailorthats weird
20:06tobytailorcan I see the test?
20:06sheppyWorking to see if I can make a simplified test case
20:08sheppytobytailor: https://jsfiddle.net/pjf13tkq/4/
20:08sheppyThreshold list is simply 0.75, and it outputs to console the intersectionRatio only if isIntersecting is true.
20:19tobytailorinteresting
20:19sheppyYou see it too?
20:20tobytailoryeah...
20:20tobytailorin ff and chrome
20:20sheppyChrome too? That is odd.
20:21tobytailoryeah, I use 58
20:21sheppyI haven&#39;t tried this particular one in Chrome...
20:22sheppyThis little quirk is seriously confusing my code, since it never sees my actual threshold reached. :)
20:22sheppySince the notifications are firing at like 0.03 and 0.4 and whatever random ratios instead of 0.75 or more.
20:23tobytailoryeah, I can see that
20:27tobytailorwhat ff are you using?
20:31sheppyLet&#39;s see, this is Nightly from 2017-05-02.
20:31sheppyRestarts of Firefox have been so slow for me the last few years that I don&#39;t tend to do it much.
20:35sheppyBut if you need me to restart it say the word.
20:37tobytailornah. im testing it with latest nightly
20:37tobytailorgotta dig more into this. it def feels weird
20:38sheppytobytailor: OK. I&#39;m going to pause work on the Intersection Observer docs for a bit then. I hesitate to keep working on it when my samples are acting weird. :)
20:38sheppyHard to feel confident in your work when that happens.
20:38tobytailorsure
20:39sheppyWant me to file a bug for this?
20:39tobytailorcan you at least confirm real quick that you see the same in chrome?
20:39sheppytobytailor: sure, sec
20:40sheppyYeah, seeing it in Chrome too.
20:42tobytailorok. thats good or not. please file a bug for that.
20:42sheppyYep.
20:42tobytailorthanks!
20:42sheppyInterestingly, the numbers I see in Chrome are tending to be much larger than in Firefox, just still usually a lot lower than 0.75
20:49tobytailorfound the issue
20:49sheppytobytailor: oh?
20:49tobytailorits time for both of us to be emperrased
20:49tobytailor:)
20:50sheppyOh god
20:50sheppy:D
20:50tobytailorits threshold not thresholds
20:50sheppySome stupid typo in my code I assume?
20:50tobytailor:)
20:50sheppyOh hell
20:50sheppyThat&#39;d do it.
20:50tobytailordidn&#39;t see it either
20:50tobytailor:)
20:50sheppyMight explain why my larger example has been misbehaving as much as it has, too.
20:50tobytailorcould be
20:50tobytailor:)
20:51sheppyI knew when I first saw that it&#39;s called &quot;threshold&quot; in some places and &quot;thresholds&quot; in others that this would happen.
20:51tobytailoryeah, but no matter how you call it, it is confusing in one way or the other
20:52tobytailorthresholds: 0.75 would be confusing too
20:52sheppytrue
20:52tobytailormaybe we should spit out a warning if that happens
20:52sheppyThat would be really handy.
20:53sheppyThe sad thing is that I basically wasted my whole day on this. :D
20:53tobytailorhehe
20:53tobytailorhappens
20:53sheppyTrue
20:54tobytailorso what happens in that case is that the actually thresholds list ends up being [0]
20:54sheppyyep, which explains everything
20:54tobytailoryep
20:55tobytailorworth mentioning that in the docs?
20:55sheppyYeah, at least a little &quot;Hey, just in case you run into this...&quot;
20:55* sheppy goes in to add that
20:57sheppytobytailor: The tricky thing is that in the options it&#39;s called &quot;threshold&quot; but it&#39;s InterfaceObserver.thresholds.
20:57sheppyThat&#39;s weird. :)
20:58tobytailorright
20:58tobytailorthat is weird
20:58sheppyI mean, it&#39;s bordering on cruel. :)
23:04bkellydbaron: do you know what is responsible for drawing the dotted line around focus elements? try to figure out this reftest failure: https://treeherder.mozilla.org/logviewer.html#?job_id=100568803&repo=try&lineNumber=4111
23:05dbaronbkelly: in most cases it&#39;s just an &#39;outline&#39;
23:06dbaronbkelly: e.g., from http://searchfox.org/mozilla-central/source/layout/style/res/html.css#706
20 May 2017
No messages
   
Last message: 8 days and 2 hours ago