why not

[사용자 친화 웹] 웹 표준1 본문

CodeStates/블로깅 챌린지

[사용자 친화 웹] 웹 표준1

novem 2023. 2. 28. 20:35

1. 웹 표준?

  • W3C(World Wide Web Consortium)에서 권고하는 ‘웹에서 표준적으로 사용되는 기술이나 규칙’
  • 사용자가 어떠한 운영체제나 브라우저를 사용하더라도 웹페이지가 동일하게 보이고 정상적으로 작동할 수 있도록 하는 웹 페이지 제작 기법을 담고있다.
  • 웹 개발에 사용되는 언어인 HTML(구조), CSS(표현), JavaScript(동작) 등의 기술을 다룬다.
  • 크롬, 엣지, 사파리, 오페라, 파이어폭스 등 최신 웹 브라우저들은 모두 웹 표준을 지원 -> 웹 표준에 맞추어 웹 페이지를 작성하면 어떤 브라우저를 사용하든 동일한 결과물을 얻을 수 있다.

1-1. 웹 VS 인터넷

1-1.1) 인터넷?

  • 전 세계적으로 연결되어있는 컴퓨터 네트워크 통신망을 의미
  • 웹, 온라인 게임, 모바일 앱등의 네트워크를 사용하는 다양한 서비스들을 모두 포함

1-1.2) 웹?

  • 문서, 이미지, 영상 등 다양한 정보를 여러 사람들과 공유하고 소통 할 수 있는 공간

1-2. 웹 표준의 장점

1-2.1) 유지 보수의 용이성

  • 각 영역이 분리되면서 유지 보수가 용이해졌고, 경량화된 코드로 트래픽 비용이 감소하는 효과가 발생한다.

1-2.2) 웹 호환성 확보

  • 웹 브라우저의 종류나 버전, 운영 체제나 사용 기기 종류에 상관없이 항상 동일한 결과가 나오도록 할 수 있다.

1-2.3) 검색 효율성 증대

  • 적절한 HTML 요소의 사용, 웹 페이지에 대한 정확한 정보 작성 등 검색 효율성과 관련된 내용도 웹 표준에서 다루고 있기 때문에 검색 엔진에서 홍보를 위한 비용을 들이지 않아도 더 높은 우선 순위로 노출이 가능하다.

1-2.4) 웹 접근성 향상

  • 브라우저의 종류, 운영 체제의 종류, 기기의 종류 등 웹에 접근할 수 있는 환경과 웹을 사용하는 사람들은 매우 다양하지만 웹 표준에 맞춰 개발하는 것 만으로도 이러한 문제를 해결할 수 있다.

 

2. Semantic HTML

  • semantic(의미의, 의미가 있는 이라는 뜻)과 HTML(화면의 구조를 만드는 마크업 언어)의 합성어
  • HTML이 구조뿐만 아니라 의미까지 갖도록 만드는 것

2-1. <div>와 <span>만 사용한 화면 구성 예시

2-2. 시맨틱 요소로 화면 구성

  • 2-1과 같은 구조로 화면을 나누되, 다른 종류의 요소를 사용한 예시
  • <div>와 <span>요소로만 화면을 구성했을 때보다, 각 요소의 이름만으로 화면에서의 역할과 내용을 명확하게 파악이 가능
  • 각 요소에 담길 내용과 기능 등의 의미를 확실하게 가지고 있는 요소를 시맨틱 요소라고 한다.

2-3. 시맨틱 HTML의 필요성

2-3.1) 개발자간 소통

  • 시맨틱한 요소를 사용하기만 하면 주석을 작성하여 설명, id나 class를 사용해서 일일이 표기 및 사용할 이름을 정하거나 의미를 설명하는데에 소요되는 시간을 절약할 수 있다.

2-3.2) 검색 효율성

  • 검색 엔진은 HTML 코드를 보고 문서의 구조를 파악하는데, <div>와 <span>만 사용한 문서에서는 모든 요소가 비슷한 중요도의 내용을 담고 있다고 판단하지만, 시맨틱 요소를 사용하면 중요도에 따라서 우선 순위를 정하여 최우선순위로 파악된 페이지를 검색 결과 상단에 표시하게 된다.
  • 만약 웹페이지를 광고비 등의 추가 지출없이 검색 엔진에 더 자주 나오게 하고 싶다면, 시맨틱 HTML을 잘 짜는 것만으로도 효과를 볼 수 있다.

2-3.3) 웹 접근성

  • 웹 접근성은 다양한 사용자와 사용 환경을 떠나서 항상 동일한 수준의 정보를 제공할 수 있어야 함을 뜻한다.

ex) 시각 장애인의 경우 웹 페이지에 접근할 때 스크린리더를 이용하게 되는데, HTML이 시맨틱 요소로 구성되어 있다면 화면의 구조에 대한 정보까지 추가로 전달해줄 수 있어 콘텐츠를 좀 더 정확하게 파악할 수 있게 된다.

2-4) 시맨틱 요소의 종류 및 실제 사용 예시(링크: MDN-Semantics)

요소 종류 설명  
<header> 페이지나 요소의 최상단에 위치하는 머릿말 역할의 요소 페이지 최상단에 위치-> 사이트 전체에서 사용할 수 있는 내용이 포함됨
ex) 로고, 사이트 이름, 구성 메인 페이지, 다크모드, 검색 폼 등의 콘텐츠
<article>, <main> 등 다른 요소의 머릿말 역할로도 사용
ex) <aside> 요소 안에 들어있는 <header>요소
<nav> 메뉴, 목차 등에 사용되는 요소 네비게이션 바의 역할, 링크들을 담는다.
<aside> 문서와 연관은 있지만, 직접적인 연관은 없는 내용을 담는 요소 메인 콘텐츠와 관련이 있으나 직접적인 연관은 없는 내용이들어가는 요소
ex) 제목별 북마크, 페이지 하단의 콘텐츠 오류 제보 등의 내용
<main> 이름 그대로 문서의 메인이 되는 주요 콘텐츠를 담는 요소 페이지의 메인 콘텐츠가 들어가는 요소
해당 페이지의 주제와 관련된 내용이 담긴다.
<article> 게시글, 뉴스 기사 등 독립적으로 구분해 재사용할 수 있는 부분을 의미하는 요소. 각각이 <article>을 구분하기 위한 수단이 필요하며, 보통 제목(<hgroup>)을 포함하는 방법을 사용 게시글, 뉴스 기사처럼 독립적으로 구분해 재사용할 수 있는 부분을 의미하는 요소
재사용하는 부분인 만큼, 각각의 <article>을 식별할 수 있는 요소가 필요
ex) <hgroup> 요소를 사용하여 식별하는 경우가 많다.
<section> 문서의 독립적인 구획을 나타내며, 딱히 적합한 의미의 요소가 없을 때 사용. 제목(<hgroup>)을 포함하는 경우가 많다. 문서의 독립적인 구획을 나타내며, 딱히 적합한 의미의 요소가 없을 때 사용
적합한 의미의 요소가 없을 때 사용하기 때문에, 의미를 부여하기 위한 요소를 포함시키는 것이 좋다.
<hgroup>을 포함하는 경우가 많다.
<hgroup> 제목을 표시할 때 사용하는 요소(<h1> ~ <h6>) 제목을 표시하기 위해 사용하는 요소
숫자가 클 수록 글자의 크기는 작아짐
숫자가 작은 제목이 숫자가 큰 제목을 포함하는 방식으로 사용
<footer> 페이지나 요소의 최하단에 위치하는 꼬릿말 역할의 요소 페이지나 요소의 최하단에 위치하는 꼬릿말 역할의 요소
사이트 제공자, 저작권, 정책, 사이트맵 등의 내용을 포함

 

3. 자주 틀리는 마크업

3-1. 인라인 요소 안에 블록 요소 넣기

-> HTML 요소는 표시 방법에 따라 인라인 요소와 블록 요소로 나뉜다.

3-1.1) 인라인 요소

  • 콘텐츠가 차지하는 만큼만 화면 영역을 차지
  • 항상 블록 요소 안에 들어가야 함
  • ex) <span> <a>

3-1.2) 블록 요소

  • 가로로 넓게 화면 영역을 차지
  • ex) <div> <h1>
<a href=""> <h1>나쁜 예시 1</h1> </a>
<span> <div>나쁜 예시 2</div> </span>

 

3-2. <b>, <i> 요소 사용 대신 <strong>,<em> 요소 사용

3-2.1) <b>요소(글씨를 굵게 만들 때 사용) & <i>요소(글씨를 기울일 때 사용)

  • 웹 표준에 부합하지 않기에 사용을 지양하는 것이 좋다.
  • 시맨틱 하지 않은, 표현을 기준으로 이름이 지어진 요소

3-2.2) <strong>요소(콘텐츠 매우 강조하기) & <em>요소(콘텐츠 강조하기)

<b>글씨를 두껍게</b>   -- 대체하기 -->  <strong>콘텐츠 매우 강조하기</strong>
<i>글씨 기울이기</i>   -- 대체하기 -->  <em>콘텐츠 강조하기</em>

 

3-3. <hgroup> 불필요한 사용 지양

  • 시맨틱 요소로서의 역할을 간과한 채 글자에 스타일 속성을 적용하기 위한 목적으로 사용하는 경우가 많은데, 이럴 경우 사용자에게 완전히 잘못된 화면 구조 정보를 전달하게 된다.
// 나쁜 예시
<h1>엄청 큰 글씨</h1>
    <h3>적당히 큰 글씨</h3>
  <h2>큰 글씨</h2>
          <h6>엄청 작은 글씨</h6>
      <h4>그냥 글씨</h4>

// 좋은 예시
<h1>제목</h1>
  <h2>큰 목차</h2>
    <h3>작은 목차</h3>
    <h3>작은 목차</h3>
  <h2>큰 목차</h2>
    <h3>작은 목차</h3>
      <h4>더 작은 목차</h4>
      <h4>더 작은 목차</h4>

 

3-4. <br /> 남발 지양하기

  • <br />은 쭉 이어지는 텍스트 흐름에 줄 바꿈을 해주기 위해서 사용하는 요소
  • 요소 사이에 간격을 만들기 위한 목적으로 남발해서는 안된다.
  • 요소 사이에 간격이 필요한 경우에 아예 별도의 단락으로 구별하거나 CSS 속성을 주어 여백을 조정해주는 것이 바람직함.
// 나쁜 예시
요소 사이에 여백을 주고싶을 때
<br />
<br />
이렇게 하시면 안 됩니다.

// 좋은 예시 1
<p>요소 사이에 여백을 주고싶을 땐</p>
<p>아예 별도의 단락으로 구별하세요.</p>

// 좋은 예시 2
  //HTML 파일
<p class="margin">요소 사이에 여백을 주고싶을 땐</p>
<p class="margin">CSS 속성으로 여백을 설정해주세요.</p>

  //CSS 파일
.margin { margin: 10px }

 

3-5. 인라인 스타일링 사용

  • 웹 표준을 지키기 위해서는, HTML과 CSS 코드를 분리해서 작성하는 것이 바람직하다.
//HTML 파일
<head>
  <style>
    h1 { color : "red" }
  </style>
</head>

(O) <h1>스타일링 속성은 CSS로 작성해주세요.<h1>
(O) <h2>style 요소를 사용해도, CSS 파일을 따로 작성해도 괜찮습니다.<h2>
(X) <h3 style="color: blue">이렇게 인라인 스타일링으로는 사용하지 마세요.</h3>  
 
//CSS 파일
h2 { color : "yellow" }

 

4. 크로스 브라우징(Cross Browsing)

웹 사이트에 접근하는 브라우저의 종류에 상관 없이 동등한 화면과 기능을 제공할 수 있도록 만드는 작업을 의미함

모든 브라우저에서 완전히 똑같은 화면이 보이도록 만드는 것은 불가능 하기에 동일한이라는 표현을 사용하지 않는다.

크로스 브라우징의 목표는 모든 브라우저에서 동등한 수준의 정보와 기능을 제공하는 것이다.

 

4-1. 크로스 브라우징 워크 플로우

4-1.1) 초기 기획

  • 어떤 웹 사이트를 만들 것인지 결정
  • 어떤 콘텐츠와 기능이 있어야 하는지, 디자인은 어떻게 할지 등의 사항을 결정
  • 이 사이트의 고객이 누구일지, 고객이 사용하는 브라우저는 무엇일지, 기기는 무엇일지 고민이 필요
  • 타겟 고객층이 주로 사용하게 될 브라우저와 기기를 파악 후, 여기에 맞는 기술을 사용해서 개발할 수 있도록 기획

4-1.2) 개발

코드를 작성할 때 사용하는 코드가 각 브라우저에서의 호환성이 어떤지 파악하고 사용

MDN, Can I Use 등의 사이트에서 코드의 호환성을 확인할 수 있다.

코드를 작성하다보면 크로스 브라우징을 힘든 상황을 만나게 될 수도 있는데, 이를 인정하고 대체 수단을 마련해야한다.

개발중인 웹 사이트가 일부 오래된 브라우저에서는 어쩔 수 없이 제대로 기능하지 않을 수도 있다는 사실을 알고 받아들여야 한다.

4-1.3) 기능 테스트 / 발견

  • 안정적인 데스크톱 브라우저(크롬, 엣지, 파이어폭스, 오페라, 사파리 등)에서 테스트를 진행
  • 휴대폰 및 태플릿 브라우저(삼성 인터넷, 사파리, 안드로이드 기기의 크롬 등)에서 테스트를 진행
  • 그 외에도 초기 기획 단계에서 목표했던 브라우저가 있다면 해당 브라우저에서 테스트를 진행
  • Window, Linux, Mac 등 다양한 운영 체제에서도 테스트를 진행
  • 직접 테스트를 수행할 수도 있지만, 자동으로 테스트를 진행해주는 도구를 이용하는 것도 방법이다.
  • TestComplete, LambdaTest, BitBar 등의 크로스 브라우징 테스트 툴이 있다.

4-1.4) 수정 / 반복

-> 테스트 단계에서 버그가 발견되었다면 수정 필요

  • 버그가 발생하는 위치를 최대한 좁혀서 특정
  • 버그가 발생하는 특정 브라우저에서의 해결 방법을 정함
  • 섣불리 코드를 수정했다가는 다른 브라우저에서 버그가 발생할 수 있으므로, 조건문을 작성해 다른 코드를 실행하게 하는 방식으로 고쳐나가는 것을 지향
  • 수정이 완료되면 3번 과정부터 반복
 

 

 

 

'CodeStates > 블로깅 챌린지' 카테고리의 다른 글

[사용자 친화 웹] 웹 접근성  (0) 2023.03.03
[사용자 친화 웹] 웹 표준2 (SEO)  (0) 2023.03.02
자바스크립트 엔진  (0) 2023.02.27
Redux  (0) 2023.02.24
[React] 상태 관리  (0) 2023.02.23