오늘 목표는 애플 웹사이트 클론 코딩을 마무리하는 것이었다.
하지만 또 다른 스크롤 버그를 발견했다. 아무래도 스크롤 위치에 따라 변수에 값을 할당해서 사용하다보니 각종 버그가 많은 것 같다.
정말 이 버그 때문에 오늘 하루를 모두 써버렸다.
이 부분에 관해서는 강의에 버그 수정 영상도 있었기에 쉽게 해결할 수 있을 것 같다고 생각했는데, 강의에서 수정한 것이 나는 마음에 들지 않았다.
우선, 버그가 나타난 원인을 알아보면 작성한 코드에서는 스크롤의 높이를 window.innerHeight를 기준으로 px로 설정하고 있다. 하지만 브라우저의 특성인지 정확하게는 모르겠지만 새로고침을 할 때, 스크롤이 새로고침을 하기 전의 위치에 남아있었다.
만약 페이지의 중간 쯤에서 새로고침을 하고 나면 중간 쯤에서 로드가 되는 것이다.
이때, 예를 들어 300px에서 새로고침을 했다면, 로드가 완료되었을 때 300px에 스크롤 바가 위치해 있는 것이다.
하지만 작성한 코드에서는 300px에서 새로고침을 했다면 일정한 범위만큼 스크롤이 내려간 상태로 로드가 되는 것이었다. 1920x1080에서는 약 4118px정도 내려갔다.
4118px이 어떻게 나온 것인지에 대해서는 잘 모르겠다.
단순 계산으로 계산해봤을 땐 스크롤의 높이를 지정할 때 window.innerHeight의 5배로 하고, padding을 50vh만큼 줬는데, (innerHeight * 5) + (padding / 2)를 하면 4118px의 값이 나오긴 한다.
이건 중요하지 않고 어쨋든 스크롤은 처음에 300px에 위치해 있다가 로드가 완료되고, 각 scene들의 높이가 할당될 때 그만큼 아래로 밀려나는 것 같다는 것이 내 생각이다.
그래서 load이벤트가 실행되기 전에 미리 scene에 높이를 할당하면 되지 않을까? 라는 생각으로 시도해봤지만 여전히 결과는 같았다. 어쩌피 로드가 되기 전이라고 해도 자바스크립트를 실행하기 이전부터 스크롤 값이 존재하는 것 같다.
또, 신기한 것을 발견했는데 js를 defer로 연결했을 때, innerHeight가 데스크탑 환경에서는 예를 들면 960px로 잘 나오는데 모바일 환경에서는 html의 모든 요소 높이의 합이 innerHeight로 출력되었다. 이 이유를 알기 위해서 검색을 해봤는데, 아직 찾지 못했다.
그래서 defer을 사용하지 않는 방법을 택했다.
결국, 강의에서 알려준 방법대로 모든 scene을 display:none으로 숨기고, load가 완료되었을 때 display:none을 없애주는 방법으로 했다.
이 방법을 사용해서 해결을 했는데, 아직도 마음에 들지 않는 것은 특정한 위치에서 새로고침을 하면 조금 위로 올라간 상태로 로드가 되는 것이다.
정말 고치고 싶은데 시간은 없고, 내일 다시 해보려고 한다.
이유는 대충 알 것 같은데, 각 scene에 높이를 설정할 때 2번째 scene은 offsetHeight를 기준으로 높이를 설정하는데, display:none으로 되어 있기 때문에 offsetHeight가 0으로 설정된다. display:none이 풀린 이후에 다시 한 번 높이를 설정해주지만 그래도 문제가 생기는 것 같다.
아무래도 offsetHeight가 아닌 다른 방법으로 높이를 설정할 수 있게 해야 할 것 같다.