(HTML-CSS) 3. 레이아웃

김동우·2021년 7월 6일
0

wecode

목록 보기
14/32

잠깐! 시작하기 전에

이 글은 wecode에서 실제 공부하고(이제 사전 스터디는 아닙니다.), 이해한 내용들을 적는 글입니다. 글의 표현과는 달리 어쩌면 실무와는 전혀 상관이 없는 글일 수 있습니다.

또한 해당 글은 다양한 자료들과 작성자 지식이 합성된 글입니다. 따라서 원문의 포스팅들이 틀린 정보이거나, 해당 개념에 대한 작성자의 이해가 부족할 수 있습니다.

설명하듯 적는게 습관이라 권위자 발톱만큼의 향기가 조금은 날 수 있으나, 엄연히 학생입니다. 따라서 하나의 참고자료로 활용하시길 바랍니다.

글의 내용과 다른 정보나 견해의 차이가 있을 수 있습니다.
이럴 때, 해당 부분을 언급하셔서 제가 더 공부할 수 있는 기회를 제공해주시면 감사할 것 같습니다.


서론

어느덧 wecode에서의 HTML-CSS 공부 2일차입니다.

오늘의 주제는 다양한 개념들을 포함하고 있는 layout, 레이아웃입니다.

평소에 flex 만을 사용해서 레이아웃을 구성하는게 습관인데, 생각보다 다양한 것들이 있었음에도 외면하지 않았나 싶습니다.

그럼에도 사실 flex의 다양한 기능과 편리함을 생각하면 아무래도 포기하기 어려울 것 같습니다.

알고 있는 것과 모르고 있는 것의 결정적 차이는 선택의 범위에 있다고 생각하니, 이번 글은 알고 있음에도 왜 사용하지 않는지에 대해 더 초점을 맞추겠습니다.


position

먼저 layout에서 가장 먼저 생각할 개념은 널리 알려진 CSS 속성, position 입니다.

지난 사전 스터디 때 만들었던 자기소개 페이지에는 수많은 position 속성들이 들어가 있는데, 뷰포트의 넓이가 달라지더라도 그림 내 아이콘이 일정하게 위치한 것이 예가 되겠습니다.

그 외에도 스크롤바를 내릴 때 마다 변경되는 글귀들은 언제 어디서나 화면 정중앙에 위치해 있었습니다.

그것 또한 position과 transform 속성을 이용한 가운데 정렬의 예입니다.

이 position이 왜 layout을 짤 때 등장하는 개념인지 오늘 한 번 생각해봅시다.

Z-index

먼저, 새로운 개념에 대해 먼저 얘기하고 넘어갑시다.

position 속성이 layout 구성에 유의미한 영향을 끼칠 수 있는 이유는 뭘까요?

저는 position이 적용된 모든 elements들은 속성을 부여받는 순간, 2D 평면에서 3D 입체 구조로 변환된다고 생각합니다.

한 평면에서 겹침이 허용될 일 없던 상태에서 갑자기 Z 축에서의 위치를 가질 수 있게 되는 것이죠.

겹침이 허용되면 div, section 등의 태그 내부에 수많은 elements를 넣는 것과는 전혀 다른 화면을 구성할 수 있게 됩니다.

부모가 다른 다양한 elements가 동시에 화면 내에 존재할 수 있게 되며, 이는 우리가 더 다채로운 화면을 구성할 수 있게 되는 계기가 됩니다.

이 때 Z-index 는 elements의 Z축 좌표가 됩니다.

수가 커지면 커질수록 위로 올라서며, 다른 요소들을 덮게 됩니다.

반대로 음수를 지정해줄 수도 있는데, 저는 보통 background로 사용하고 싶은 elements에 대해 음수를 부여하곤 합니다.

position과 함께 사용되는 속성이니 알아두는게 좋다고 생각합니다.

position : relative;

relative의 경우는 이름부터 무언가 관련이 있다는 생각이 들게 됩니다.

position : relative 속성을 부여받은 HTML elements는 자기 자신을 기준으로 이동합니다.

즉, 이전의 default 값인 position : static 상태가 기준이 됩니다.

이는 position을 조정하는 top, right, bottom, left 등의 기준이 원래 자기 자신의 위치가 되는 것입니다.

약간의 조정이 필요한 경우에 사용하기는 좋은 속성으로, 저는 조금 다른 용도로 더 자주 사용합니다.

position : absolute;

absolute의 경우 top, right, bottom, left로 지정된 수치만큼 떨어진 위치에 존재하게 하는 속성입니다.

이렇게 보면 relative와 같아 보이는데, 조건이 있습니다.

화면이나 자기 자신의 이전 상태가 아닌 부모 elements를 기준으로 이동하며, 해당 부모 elements의 기준은 position : static; 이 아닌 상위 elements가 됩니다.

모든 elements가 position 속성이 없다면 absolute 속성을 부여받은 elements의 부모는 당연히 body가 됩니다.

즉,

<body>
  <section class="relative">
    
    <div>
      <div class="absolute"></div>
    </div>
    
    <div class="absolute2"></div>
    
  </section>
</body>
.relative{
	position : relative;
}

의 코드에서 absolute와 absolute2의 position 값 기준은 둘 다 section tag, .relative가 됩니다.

만약 absolute를 감싸는 div에 마찬가지로 .relative(class="relative")가 존재한다면 position 기준으로 서로 다른 부모 elements를 가지게 됩니다.

이를 이용해 저는 relative - absolute의 조합으로 보다 다양한 position 속성을 조작하고 있습니다.

실제로 relative의 경우 position 변경에 영향을 끼치는 속성값이 없으면, static과 동일하게 보이기에 가장 적합하다고 생각합니다.

absolute나 fixed는 그와 달리 조금 번거로운 과정이나 원치 않는 결과를 확인할 수 있습니다.

position : fixed

fixed의 경우 특수한 경우에 사용됩니다.

주로 우리가 보는 화면의 header와 footer, 혹은 velog 글의 우측에 존재하는 목차를 감싼 박스가 가지는 속성입니다.

스티커와 같은 효과를 내며, 문서의 어느 곳에 가더라도 elements가 해당 위치를 벗어나지 않게 해줍니다.

잘 이용하면 상당히 편리하며, 저의 거의 모든 페이지에 등장하는 속성인 것 같다는 생각이 들었습니다.

display

display는 HTML elements가 가지는 다양한 visual 속성입니다.

화면에서 해당 elements가 가지는 길이 혹은 높이, 또는 부모 elements의 정렬 방식에 영향을 끼칠 수 있는 특징들을 포함하고 있는 속성입니다.

저는 화면에 비춰지는 elements 특징을 특정 방식으로 표현한 것이라고 생각하겠습니다.

display : none - visibility : hidden

말 그대로 둘 다 화면에 아무것도 보여주지 않겠다는 속성입니다.

차이점은 display : none의 경우 해당 elements를 렌더링 하지 않으므로, elements는 문서 어디에도 존재하지 않습니다.

그렇기에 기존 elements 들의 배치에 영향을 끼칠 수 있습니다.

visibility : hidden의 경우 opacity : 0 와 같은 효과를 냅니다.

그러나, 클릭이 되거나 하는 경우를 방지할 수 있으며, 기존 elements들의 배치에 영향을 끼치지 않습니다.

display : none 의 경우 기존 배치에 영향을 끼치는 반면, hidden은 끼치지 않으니 무조건 hidden 만을 사용해야 하는 것은 아닙니다.

어제 글에서처럼 적절한 사용처를 충분히 고려하고 사용해야겠습니다.

inline

inline 속성의 elements의 크기는 임의로 변경할 수 없으며, 해당 elements의 content 크기가 됩니다.

span tag가 대표적인 예인데, span의 경우 문장의 길이에 해당하는 크기만을 가집니다.

즉, 화면 내에 차지하는 공간이 정직한 속성이라 볼 수 있습니다.

그렇기에 임의로 개발자가 크기를 변경하는 것을 용인하지 않는 보수적인 속성으로도 생각할 수 있습니다.

  1. font-size 변경을 통해 공간의 크기를 결정할 수는 있습니다.

  2. width, height 등의 속성을 변경할 수는 없습니다.

  3. block, flex에 존재하는 다양한 정렬속성을 적용할 수 없습니다.

  4. 글에 줄바꿈을 적용할 수 없습니다.

inline-block

inline-block 의 경우 덜 보수적인 개념입니다.

특징은 다양하지만, 정리하면 별게 없습니다.

  1. font-size 변경을 통해 공간의 크기를 결정할 수 있습니다.

  2. inline-block, block의 특징이 있기 때문에 width, height 등의 속성이 존재하고, 변경 가능합니다.
    font-size 만으로 해결할 수 없는 세밀한 조정이 가능합니다.

  3. 그러나 inline의 특징이 있어 줄바꿈, text-align 등의 정렬은 적용할 수 없습니다.

block

우리가 흔히 아는 p, div, section, 그 외 등등 tag의 default display 속성입니다.

  1. font-size, width, height 등의 값을 조작하여 크기를 결정할 수 있습니다.

  2. text-align 등을 활용해 대부분 하위 elements 로 존재하는 inline tag의 정렬이 가능합니다.

  3. 줄바꿈을 적용할 수 있습니다.

  4. 그러나 text-align 등의 속성으로 스스로를 정렬할 수는 없습니다.

flex

제가 주로 사용하는 개념의 display 입니다.

justify-content, align-items, flex-direction 등등 유용한 속성이 많습니다.

( 1분코딩 - flex )

위 글은 제가 추천하는 CSS flex 강의 글입니다.

꼭 보시는 것을 강추합니다.

flex의 경우 container 개념을 제대로 활용할 수 있는 다양한 속성이 존재합니다.

하나의 페이지를 container로 구성해 다양한 배치를 시도해봅시다.

float

제 기준에서 가장 이해가 어려운 layout 구성 방식입니다.

이번에 공부한 내용이지만, 배치 방식, 배치 이후 elements 들의 상태(위치, 정렬)등 사용하기에 마음이 끌리는 방식은 아니었다고 생각합니다.

저는 개인적으로 다른 방법으로는 block을 어떻게 배치하는지만 이해하고 넘어가기로 했습니다.

none, right, left

좌우 양방향을 float의 속성값으로 갖습니다.

float : left 의 경우 해당 block을 왼쪽에 두고, 나머지 요소들이
( document width - block( = float : left ) width ) 에서 시작해 block의 크기만큼을 문서에서 배제하는 형태로 존재하게 됩니다.

만약, 문서(viewport)의 길이(width)가 해당 float block과 다른 요소를 함께 담을 수 없을 정도로 작아진 경우에는 float 특성이 없는 elements를 아래로 내리게 됩니다.

이에 저는 position, flex container 등과 같은 방법과는 달리 viewport 변경에는 상대적으로 취약한 개념이 아닐까 생각하게 되었습니다.

height, clear

그보다도 float의 가장 큰 문제는 사용하기 번거롭다는 점인데, 높이가 그 예시가 됩니다.

부모 element가 float이 아니거나, clear를 사용하지 않는 상태에서 자식이 float block이라면 겉보기에 position과 비슷하게 z축 특성을 가지게 됩니다.

부모 elements 위로 자식 elements(float block)이 위치하게 되는데, 이는 우리가 원하는 결과는 아니라는 점이 주요한 문제가 됩니다.

이를 극복하기 위해서는 부모 또한 float block이 되거나, clear 값을 가진 빈 태그를 추가해주어 높이르 인식하게 해주어야 합니다.

또는 overflow 속성을 활용해야 하는데, 이 쯤에서 이미 float block 활용에 대한 생각이 남김없이 사라져버렸습니다.

그 외 방법은 여기에서 확인하실 수 있습니다.

결론

확실히 예전 것을 무시하지 않고, 잘 활용한다면 좋은 경우도 있다고 생각했으나, 대부분의 기능은 물론 새로운 기능을 보유한 신기술을 외면하면서까지 유지하고 싶은 생각은 없는 것 같습니다.

더 나은 경험을 제공하는 것, 그리고 보다 더 무결점의 웹을 만들고 싶은 생각이라면 float은 지양할 수 밖는 개념인 것 같습니다.

제 웹에 유지보수 사항과 불필요한 코드 조각의 추가, 계산 외의 결과화면 출력 등의 리스크가 생기지만 리턴이 전혀 없기에 현재로써는 필요가 없지 않을까 생각하기 때문입니다.

또한 선택의 범위가 넓어지더라도 선택이 크게 달라지지 않았다는 점에서 신기하긴 합니다.

그래도 모르는 것보다는 아는 것이 중요한 시대에서 새로운 경험을 했습니다.

0개의 댓글