43

I noticed scrollIntoView has some new options since last I looked.

Namely, block and inline. What's the difference between these two? I'm guessing {block: "start"} will align the top of the element with the top of the page, but I'm not sure how that would be different from inline, or how you would use both these options simultaneously?

dhilt
  • 18,707
  • 8
  • 70
  • 85
mpen
  • 272,448
  • 266
  • 850
  • 1,236

1 Answers1

123

The block option decides where the element will be vertically aligned inside the visible area of its scrollable ancestor:

  • Using {block: "start"}, the element is aligned at the top of its ancestor.
  • Using {block: "center"}, the element is aligned at the middle of its ancestor.
  • Using {block: "end"}, the element is aligned at the bottom of its ancestor.
  • Using {block: "nearest"}, the element:
    • is aligned at the top of its ancestor if you're currently below it.
    • is aligned at the bottom of its ancestor if you're currently above it.
    • stays put, if it's already in view.

The inline option decides where the element will be horizontally aligned inside the visible area of its scrollable ancestor:

  • Using {inline: "start"}, the element is aligned at the left of its ancestor.
  • Using {inline: "center"}, the element is aligned at the centre of its ancestor.
  • Using {inline: "end"}, the element is aligned at the right of its ancestor.
  • Using {inline: "nearest"}, the element:
    • is aligned at the left of its ancestor if you're currently on its right.
    • is aligned at the right of its ancestor if you're currently on its left.
    • stays put, if it's already in view.

Both block and inline can be used at the same time to scroll to a specified point in one motion.

Check out the following snippet to see how each works in action.

Snippet:

/* ----- JavaScript ----- */
var buttons = document.querySelectorAll(".btn");

[].forEach.call(buttons, function (button) {
  button.onclick = function () {
    var where = this.dataset.where.split("-");
    document.querySelector("div#a1").scrollIntoView({
      behavior: "smooth",
      block: where[0],
      inline: where[1]
    });
  };
});
/* ----- CSS ----- */
body {
  padding: 500px;
  width: 2000px;
}

header {
  position: fixed;
  top: 0;
  left: 0;
  width: 100;
}

div#a1 {
  width: 1000px;
  height: 300px;
  background: url(//www.w3schools.com/css/trolltunga.jpg);
  background-repeat: no-repeat;
}
<!----- HTML ----->
<header>
  <button class="btn" data-where="start-start">T-L</button>
  <button class="btn" data-where="start-center">T-C</button>
  <button class="btn" data-where="start-end">T-R</button>
  <button class="btn" data-where="center-start">C-L</button>
  <button class="btn" data-where="center-center">C-C</button>
  <button class="btn" data-where="center-end">C-R</button>
  <button class="btn" data-where="end-start">B-L</button>
  <button class="btn" data-where="end-center">B-C</button>
  <button class="btn" data-where="end-end">B-R</button>
</header>

<div id = "a1"></div>
Angel Politis
  • 10,955
  • 14
  • 48
  • 66
  • 6
    Thank you. Good explanation. However, "aligned inside the visible area of its scrollable ancestor" doesn't appear to be the whole truth -- Chrome is scrolling both the iframe *and* the parent page. Seems strange that it's even allowed to do that. – mpen Feb 06 '18 at 17:09
  • 1
    Yes, I noticed it while running the snippet. It's probably not supposed to occur, but it's clearly mentioned that it's an experimental technology, so they'll likely fix it soon. – Angel Politis Feb 06 '18 at 18:18
  • 4
    Thank you for this, the `block` and `inline` properties are not clearly explained on the MDN site. – hsimah Apr 19 '18 at 01:31
  • So we can tell that `block` is for vertical scroll positioning and `inline` for horizontal, is that right? – Matteo Gaggiano Feb 13 '19 at 12:30
  • @MatteoGaggiano Yes. According to [documentations](https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView). – ShahinSorkh Feb 13 '19 at 14:37
  • 3
    @AngelPolitis "it's an experimental technology, so they'll likely fix it soon." - so said the guy a year and a half ago. :D – Eddy Howard Jul 09 '19 at 19:34
  • 2
    @AngelPolitis unfortunately, this fell in the "less than likely" category. :P – Eddy Howard Jul 11 '19 at 15:44
  • 1
    As the technology matures with time, hopefully, this issue will be addressed @EddyHoward – Angel Politis Jul 11 '19 at 17:51
  • 1
    I came to this post after noticing strange behavior with block: 'center' (which is the behavior I wanted causing jsfiddle's UI to scroll out of view and get stuck. This seems to be a bug in Chrome since even refreshing the page won't fix it. The problem doesn't occur with block: 'nearest' but this doesn't work for what I'm doing (which is using position: fixed to make a table's header fixed without screwing up the table metrics). Short version: Chrome's scrollIntoView is still buggy. – podperson Dec 30 '19 at 18:51
  • 1
    As of today (March 26, 2022), I verify that the bug still exists. The scroll is applied to the main window too, which is not what we want. – user2078023 Mar 26 '22 at 17:36