HTTP 203: Gotchas (S1, Ep6)

[MUSIC PLAYING] PAUL: So it’s my turn to get
things off my chest I feel. I recently built the
Chrome Dev Summit site. JAKE: And a mighty fine job
I thought you did, as well. PAUL: Thanks, pal. JAKE: That’s all right. PAUL: But on my journey
through building that, I discovered some gotchas. First up– position
fixed– tell me what you think position
fixed actually does? JAKE: Takes an element
out of document flow, and it positions it
relative to the viewport. PAUL: The what? JAKE: The viewport. PAUL: The viewport. The viewport. JAKE: Right. PAUL: Right. JAKE: Was I right? PAUL: When you apply a position
fixed to a child of something that has a
transform– so you got another one with a transform–
and another element inside, which is position fixed. The position fixed
behavior changes. The transformed element becomes
a new initial containing block. JAKE: Whoa. What? PAUL: Yeah, it’s like a new
viewport inside the viewport. So the way I did
is it, because I had these cards that
were transforming, at the end of the transition,
I’d scale all the transforms, so that I didn’t see
weirdness on the content– so frustrating. Gotcha number two– pop state. JAKE: Oh, yeah, I’ve
done pop state before. PAUL: Yeah. Did you know that it
restores scroll positions? JAKE: No, actually I didn’t. PAUL: Right. So this is bonkers to me. You’re doing something
with the history API, you’re pushing states on,
you’re popping states off, because you’re handling
app state yourself. But what the browsers
all do is they go, I know what you want to do. I know you want to restore
the scroll position at the point at which
you did push state. Which is, if you’re doing
something async, right? If you’re doing something– JAKE: Which is what I’ve
always done in the past. PAUL: –yeah, then
all of a sudden, your page would
just snap down to its previous scroll position. I thought I can fix this. I’ll work around
it– gun fingers. JAKE: [CLICKING SOUND] pow pow. PAUL: What I’ll do is I’ll
have a single listener for scroll position, and when it
switches, after the pop state, it’ll do one scroll. I’ll reverse it. [? JAKE: P–Pull ?] me back. PAUL: And they’ll be like,
haha, never happened– shazam. No. Because Chrome does
that– it does the scroll after the pop state. Firefox does it before. So you actually don’t know
where you scrolled from. You just know that you’re
pretty certain you’re not in the scroll position
you were before. Talking of scrolling–
last one– body. Did you know you can’t stop
the body from scrolling? JAKE: That’s the name of
my next album, actually. PAUL: Yeah, Jake. That’s great. JAKE: Mousewheel events? PAUL: You could, but that’s
not going to work on mobile. JAKE: On mobile– which
you have touch events. PAUL: No. No. JAKE: Because then
you’re going to have to re-implement
all of scrolling. PAUL: All the fling
physics-y stuff. JAKE: And if you do that,
you’ve lost performance, lost everything, your life. PAUL: Forget it. Not doing that. Don’t like it. Don’t want it. Because what happens, again,
these cards, they expand. They’ve got scrollable
content inside. When they reach the bottom
of their scrolling content, the body goes, I will deal this. I’ll start scrolling now. Well, there is an escape hatch,
an ability for a developer to go, you know what? I want to take control of this. I know what’s supposed
to happen here. I will deal with it. So extensible web says, nah. JAKE: Nah. PAUL: Right? Exactly. Good news, though. In spec land, in
discussion world, there is before scroll,
which is an event, and its corresponding CSS
properties around what scrolling should be blocked on. But the default behavior
still remains as it is today. It gives developers more options
to say, I know what I’m doing. Please let me put the
car into my manual– JAKE: Manual. PAUL: –or stick shift, as it
were, and we’ll go from there. So from an extensible
web point of view, yay. JAKE: Yay. [MUSIC PLAYING] JAKE: [LAUGHING]

12 Replies to “HTTP 203: Gotchas (S1, Ep6)”

  1. Building for the web is awesome, but sometimes you can find yourself baffled by gotchas. Check out the latest episode of #HTTP203 where @Paul Lewis tells @Jake Archibald about three he recently discovered!

  2. @Paul Lewis I've gotten around the scrolling issue with popstate by calling window.scroll(0, 0) inside requestAnimationFrame.

  3. In regards to the body scrolling issue, why not just set overflow to hidden on the body when you open a card and then remove it when you close the card? Since the card is taken out of the flow it still scrolls and the body's position is kept. Worked on chrome for me, I can't test on Firefox at the moment but I don't see why it wouldn't work there.

  4. @Google Developers the content of the video is 10/10, but please fix or try better next time with the cameras, the rotations and who to focus. Thanks !

  5. You guys named the show 203 deliberately so we read the following and feel like idiots. I hate you! lol

    "203 Non-Authoritative Information
    The returned metainformation in the entity-header is not the definitive set as available from the origin server, but is gathered from a local or a third-party copy. The set presented MAY be a subset or superset of the original version. For example, including local annotation information about the resource might result in a superset of the metainformation known by the origin server. Use of this response code is not required and is only appropriate when the response would otherwise be 200 (OK)."

  6. The best way of getting the body to stop scrolling is by using an overflow-y hidden property. However, it's pretty flawed, things such as the middle mouse button or child elements with certain transitions will cause the body to still scroll.

  7. popstate didn't used to restore scroll position, iirc…pressing 'back' used to go back to the previous URL instead of where you were previously scrolled at….very irritating

Leave a Reply

Your email address will not be published. Required fields are marked *