scrollIntoView block vs inline

Question

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?

Tiloine

Answer 1

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>

Kiri

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. – Tiloine

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. – Kiri

Thank you for this, the block and inline properties are not clearly explained on the MDN site. – Roubaix

So we can tell that block is for vertical scroll positioning and inline for horizontal, is that right? – Utah

@MatteoGaggiano Yes. According to documentations. – Blowsy

@AngelPolitis "it's an experimental technology, so they'll likely fix it soon." - so said the guy a year and a half ago. :D – Maurita

@AngelPolitis unfortunately, this fell in the "less than likely" category. :P – Maurita

As the technology matures with time, hopefully, this issue will be addressed @EddyHoward 🙏 – Kiri

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. – Lugansk

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. – Imperfective