페이지의 width(폭)이 줄어듦에 따라
inline으로 있던 것들이 block으로 바뀌기도 하고,
서로간의 간격도 좁아지고,
버튼들이 오버레이 되기도 한다.
이걸 반응성인가 적응형 웹이라고 하던데
보기엔 쉬운데 엄청난 기능일 것이다!
물론 그것을 떠나서 디자인이 빛난다.
뭔가 얄쌉한 폰트에 얄쌉한 선들, 각진 박스들, 파란색의 깔맞춤, 미니멀한 아이콘들, 파스텔 분위기 등
디알못인 나도 한눈에 깔끔하다는 것을 알 수 있다.
자 코드를 inspect로 보았는데 코드가 너무 길어 <head>부분만 따로 떼왔다. 아래와 같다.
<!DOCTYPE html>
document Type을 가장 먼저 선언한다.
이를 DTD(Document Type Definition, 문서 형식 정의)라고 한다.
일단은 HTML이 버전이 여러개라서 이렇게 한다고 이해하자.
HTML5이 최신이고 최신버전을 사용한다는 선언을 한 것과 같다고 보면 된다.
참조 : https://www.w3schools.com/tags/ref_html_dtd.asp
<html lang="ko">
<html>이 어떤 언어 기반으로 썻는지를 작성한다.
lang의 값은 ISO Language Codes
https://www.w3schools.com/tags/ref_language_codes.asp
dir="ltr"이라고 붙는 경우도 있는데, dir은 방향성을 의미, 아마 direction의 약어인듯.
ltr은 좌측에서 우측 rtl은 아랍어와 같이 우측에서 좌측으로 기술되는 언어를 의미한다.
아무것도 안썻으니 기본값 default로 Left to Right 인듯.
<head>
<meta charset="UTF-8">
이건 눈에 익다.
<meta>는 metadata의 약어.
웹이 표시되지는 않지만, 구글과 같은 검색엔진이 파싱(parsing)하는데 유리하게 해준다.
자주 쓰이는 것은 description, keywords, author of the document, last modifed 등이 있다.
charset은 문자 인코딩을 선언, 보통 UTF-8을 사용한다.
참고 : https://developer.mozilla.org/ko/docs/Web/HTML/Element/meta
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
보면 meta는 name과 content라는 요소가 쌍을 이루고 서술되는 경우가 많다.
그리고 가장 위 viewport와 http-equiv는 HTML5에 들어서 나온 개념인 것 같다.
viewport에 대해 알아보자.
참고:
https://www.w3schools.com/css/css_rwd_viewport.asp
https://developer.mozilla.org/ko/docs/Glossary/Viewport
https://developer.mozilla.org/ko/docs/Mozilla/Mobile/Viewport_meta_tag
https://www.quirksmode.org/mobile/metaviewport/ // ideal viewport에 대해
https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html#//apple_ref/doc/uid/TP40008193-SW8 // 애플 문서
https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/UsingtheViewport/UsingtheViewport.html // 애플 문서
https://offbyone.tistory.com/110 // offbyone님 블로그, 설명 good
viewport는 사용자가 웹페이지에서 시각적으로 볼 수 있는 영역(user's visible area of a web page)이다.
그래서 기기마다 다르고, 모바일은 상대적으로 작고, 컴퓨터는 크다.
모바일 이전에는 웹은 데스크탑을 위해 만들어졌는데, 그래서 웹들은 디자인과 사이즈가 정적이였다.
모바일 이후 전체 웹 크기를 scale down해야 했는데 완벽하지는 않지만, 빠른 수정을 하기 위해 도입된 것이다.
웹표준은 아니지만 애플이 자사의 기기들을 지원하기 위해 사용하면서 사실상 표준처럼 사용된다.
모바일 브라우저들이 대부분 이 태그를 지원한다.
하지만 IE10의 마소놈들이 표준으로 @viewport rule을 W3C에 제안했기에
아이폰과 IE10을 동시에 타겟으로 설계하려면 2가지 방식으로 viewport 크기를 조절해야 한다...
(니가 뭔데 표준이야 라는 식의 기싸움 같기도 하고... 이렇게 되면 개발자만 고생이자나...)
(그냥 IE는 지원하지 말자...)
<!-- example -->
<head>
<meta name='viewport' content='width=device-width' />
<style type='text/css'>
@-ms-viewport { width: device-width; }
@-o-viewport { width: device-width; }
@viewport { width: device-width; }
</style>
</head>
그리고 visible viewpoint라는 개념이 있는데, 사용자가 확대한 경우, 전체 레이아웃과 달리 확대되어 작아진 영역을 가리키는 말이다.
그래서 아래와 같은 문제처럼
페이지가 뷰포트보다 작을 수 있다.
scale=1.0으로 하면 device-width에 딱 채워진다.
scale=1.5로 하면 visible viewpoint를 넘어서 채워진다.
모바일로 최적화된 사이트는 일반적으로 다음과 같은 태그를 포함한다.
사용자가 줌인, 줌아웃하여 화면을 확대, 축소할 비율을 설정할 수 있다.
<meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=3.0">
사용자가 크기 조정을 원하지 않을 때 :
<meta name="viewport" content="width=device-width, user-scalable=no">
devhyun은 initial-scale=1.0 이라고 했는데, 스케일이라는 것이 도입되어야 했다.
모바일들은 화면이 작지만, 픽셀크기와 밀도까지 제각각이라, 픽셀에 맞춰 랜더링하면 크기가 제각각이 되었다. 그래서 HDPI나 MDPI와 같은 개념을 활용해 동일한 물리적 사이즈로 랜더링 해야 했고, 그 배수로서 스케일이 도입되었다.
그리고 현재는 최대 980px의 뷰포트를 가상으로 랜더링하고, 그 이상의 해상도에 대해서는 이것을 scale-up하는 식
그래서 웹페이지는 980px을 넘어가면 좌우로 스크롤링하게 된다. 980px이 기준인 이유는 애플이 그렇게 시작해서 그렇다고...
또 기존의 img테그에서 width값을 px로 주어도 되지만 대부분 40% 80% 100% 식으로 주는 이유가, 이 viewport에 맞추기 위해서인 것으로 보인다. 실제로 viewport를 적용해도, pixel이 크면 visible viewport를 이미지가 넘어가 버린다.
이제 <meta http-equiv="X-UA-Compatible" contant="IE=edge">를 살펴보자.
https://gocoder.tistory.com/161
https://webisfree.com/2016-03-23/meta-태그-http-equiv-설정방법과-차이점
이건 인터넷 익스플로어(이하 IE)의 호환성보기에 따른 코드이다.
최근에 사이트를 개발했다면 마이크로소프트(이하 마소)의 최신 브라우저 edge를 설정한다.
만약에 구형 사이트라면 IE=10과 같은 코드로 되어있을 거다.
그러면 IE는 10버전에 맞게 그 사이트를 랜더링 하게 된다.
<meta name="google-site-verification" content="QSMuirmrBZ6_wn0rIAM9IGfAlwfYMQV0QKMDf6I42Vg" />
<meta name="author" content="opzyra">
<meta name="robots" content="ALL">
<meta name="NaverBot" content="All">
<meta name="Yeti" content="index,follow">
https://support.google.com/webmasters/answer/79812?hl=ko
google-site-verification은 구글 설명에서 보면 "Search Console에서 필요한 사이트 소유권을 확인하는데 사용된다고 합니다. 이 값이 사용자에게 제공된 값과 정확하게 일치해야 한다고 합니다. 일종의 사이트 주민번호 같은건가 보네요..."
author는 웹을 만든 개인이나 단체
robots, NaverBot, Yeti는 모두 검색엔진에 대해서 크롤링 및 색인 생성에 동작합니다.
Yeti는 네이버 검색봇이다.
https://developers.google.com/search/reference/robots_meta_tag?csw=1
https://www.fun-coding.org/crawl_basic2.html
색인이란 도서책의 목차 같은 건데, 빠르게 해당 정보에 접근하기 위해서 정리해둔 목차라고 이해하시면 됩니다.
검색엔진은 웹들을 색인화 해두어, 빠른 접근을 용이케합니다.
content값을 noindex로 한다면 그 페이지는 해당 검색엔진에 노출되지 않케됩니다.
모두 노출에 구글만 비노출로 하고싶다면
<meta name="robots" content="All">
<meta name="googlebot" content="noindox" />
all : 색인 생성이나 게재에대한 제한을 없앰, 기본값으로 명시적으로 표시해도 아무런 효과가 없음.
noindex : 검색결과에 이 페이지를 표시하지 않습니다.
nofollow : 이 페이지의 링크를 따라가지 않습니다.
none : noindex, nofollow 와 같음
이하 참조...
<title>데브현</title>
<meta name="description" content="안녕하세요. 브라우저로 사람을 연결하는 웹 개발자 김현호의 개인 포트폴리오 사이트 입니다.">
<meta name="og:title" content="데브현">
<meta name="og:type" content="website">
<meta name="og:url" content="https://devhyun.com/">
<meta name="og:image" content="https://devhyun.com/images/og.png">
<meta name="og:description" content="안녕하세요. 브라우저로 사람을 연결하는 웹 개발자 김현호의 개인 포트폴리오 사이트 입니다.">
title은 아는 것이고,
description은 이 페이지의 소개를 적는 곳이다. 그리고 og는 open graph의 약자이다
카카오톡에서 주소를 링크하면 주소만 나가는 것이 아니라 아래 간단한 그림, 제목, 소개가 나간다.
거기 표시되는 자료이다.
http://blog.ab180.co/open-graph-as-a-website-preview/
https://ogp.me // open graph 공식
사용중인 notion이라는 웹 노트 서비스에 bookmark를 누르면 og 형태로 표시된다.
<meta name="twitter:card" content="summary">
<meta name="twitter:title" content="데브현">
<meta name="twitter:description"
content="안녕하세요. 브라우저로 사람을 연결하는 웹 개발자 김현호의 개인 포트폴리오 사이트 입니다.">
<meta name="twitter:image" content="https://devhyun.com/images/og.png">
<meta name="twitter:domain" content="https://devhyun.com/">
이건 SNS에 og 형태로 표시하는 meta 태그이다.
이런식으로 표시된다.
일반형태로는 title과 description 2개만 적지만
og 때문에 type, url, image 이렇게 3개를 추가했고,
twitter는 image, domain만 추가하고 따로 card까지 설정했다.
twitter:card값으로는 summary 말고도 summary_large_image, photo 두가지가 더있다.
<link rel="shortcut icon" href="/images/favicon.png">
<link rel="stylesheet" href="/lib/material-icon/css/materialdesignicons.min.css">
<link rel="stylesheet" href="/lib/swiper/swiper.min.css">
<link rel="stylesheet" href="/lib/nprogress/nprogress.css">
<link rel="stylesheet" href="/lib/remodal/remodal.css">
<link rel="stylesheet" href="/lib/remodal/remodal-default-theme.css">
<link rel="stylesheet" href="/lib/tui-editor/tui-editor.css">
<link rel="stylesheet" href="/lib/tui-editor/tui-editor-contents.css">
<link rel="stylesheet" href="/lib/tui-editor/codemirror.css">
<link rel="stylesheet" href="/lib/tui-editor/github.min.css">
<link rel="stylesheet" href="/css/default.css">
<link rel="stylesheet" href="/css/lib.css">
<link rel="stylesheet" href="/css/client.css">
<link rel="stylesheet" href="/css/client.responsive.css">
여기서 부터는 meta가 아니라 link이다.
link는 보통 css를 연결하는 태그이고,
script는 JS를 연결하는 태그이다.
지금까지 내가 했던게 여기 잘 설명이 되어있네...
http://webberstudy.com/html-css/html-1/head-element/
rel은 relaion(관계)의 약어, href는 hypertext reference의 약어이다.
또 type="text/css"도 적어주는 경우가 있다.
<link href="style.css" type="text/css" rel="stylesheet">
<script type="text/javascript" src="javascript.js"></script>
과 같은 식
href의 실제 주소 외에도 type과 rel을 적어주는 이유는 Link가 다른 외부요소를 연결할 때도 쓰이기 때문
보면 가장 윗 link는 css가 아닌 png(그림 데이터의 하나)를 연결했다.
그밑으로는
머티리얼 디자인 아이콘, 스위퍼, n프로그레스, 리모델, 리모델기본테마
tui에디터, tui에디터 콘텐츠, 코드미러, 깃허브.민
기본값, 라이브러리, 클라이언트, 클라이언트 반응성
이렇게 13개의 css를 link했다.
inspect로 확인해 보면 서체를 포함한 14개의 css를 포함한 것을 볼 수 있다.
검색을 더 돌려보니 Spoqa Han Sans 서체는 default.css에서 import한 것을 알 수 있었다.
우연히도 css에서 인터넷에 올라온 서체를 @import하는 방법까지 배웠다.
<script async src="https://www.googletagmanager.com/gtag/js?id=UA-145435902-1"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag() { dataLayer.push(arguments); }
gtag('js', new Date());
gtag('config', 'UA-145435902-1');
</script>
</head>
그 밑으로는 Javascript를 연결해준다.
가장 먼저 구글 태그 매니저를 연결했다. 외부 JS인 것 같다.
https://tagmanager.google.com/#/home
js 라고만 표시되고 우측에 주소가 적혀있다. 클릭하니 굉장히 단순화된 변수들이 눈에 띈다.
안에 대충 읽어봤는데 변수들이 a, ab 이런식의 한두개의 스펠링으로 되어있고,
의미가 명확하지는 않지만 수많은 객체와 배열을 지정하는 것이 보인다.
스크롤 하면서 이런 것을 느꼇다.
이것이 알고리즘인가?
마치 어샘블리어 처럼 보인다...
스냡샷에도 Object.create ? Object.create나 return new b 와 같은 초월적이며 처음 보는 문법들을 볼 수 있다.
아마도 변수명을 저렇게 알아보기 힘들게 적은 것과 구글에서는 자신들이 사용하는 툴을 직접 만들어 쓴다는 사실을
조합해 볼때, 저런 변수들을 추상화하여 추적관리하는 그래픽 툴로 상당한 복잡도의 프로그래밍을 한다고
추측해 본다.
아니면 진짜 사람이 만들고, 데이터를 줄이기 위해, 변수명이나 함수명을들을 압축한걸지도 모른다.
아무튼 이게 js 맞나 싶을 정도로 외계어들이 득실하다...
자 여기 까지 head 부분을 알아보았다. 이제부터 body를 하나씩 뜯어보자.
