HTML5 의 의외성 [1탄] 시멘틱 정보
HTML5 의 의외성 [1탄] 시멘틱관련링크
https://sir.kr/pb_tip/3451
66회 연결
본문
위 URL 로 게시글 이동하였습니다.
HTML5, 그러니까 웹 표준 이라 불리는것에 대하여 이야기를 조금 남겨보도록 하겠습니다^^.
HTML5 부터는 시멘틱(태그)의 사용 자체가 관대해지고, 응용의 폭이 아주 넓어졌는데요,
제가 생각하는 가장 흥미로운 점이 대중적으로는 잘 알려지지 않은 것 같더라구요..^^
웹 표준이 제안하는 시멘틱 구조는
<HEADER>, <HGROUP>, <NAV>, <ARTICLE>, <ASIDE>, <SECTION>, <FOOTER>
위와 같은데 주로 <DIV>, <UL>, <LI> 에 국한되어 사용하고 있지않나 라는 생각이 듭니다.
개인적으로는 <header>, <nav>, <article>, <footer> 마저도 흔하게 발견되지않고,
<hgroup> 은 활용 사례를 거의 본적이 없습니다...
역시 IE 가 가장 큰 원인이었다고 생각합니다.
그 옛날엔 프레임셋부터 시작해서 테이블로 레이아웃을 짜던 시절도 있었죠? ㅎㅎ 그때 생각하니 아찔하네요.
<TABLE> 태그에는 <thead>, <tbody>, <tfoot> 과 같은 규칙을 제안하며 "표" 로써의 역할을 권고하였습니다.
그리고 <th>, <td> 로 다시 한번 더 분류하여, 데이터의 제목과 내용을 구별 할 수 있게함과 동시에,
레이아웃 디자인은 레이어(블럭)의 개념으로 <div> 를 사용하도록 유도하였습니다.
이 즈음부터 UI 라는 개념이 적립되기 시작했고 JQUERY 의 보편화로 UX 라는것이 알려지기 시작하였기도 합니다.
잘 아시다시피 웹 표준은 "문서의 규칙을 통일하여 모든이가 차별없이 데이터를 경험하도록" 하는 것이 목표였습니다.
<IMG> 나 <A> 태그에는 name 이나 alt 같은 시각장애인을 위한 정보를 함께 기입할 것을 권고하였구요.
또 <IMG> 태그와 같이 </마침> 이 없는 태그는 <IMG SRC="asdf.jpg" /> 로 마무리 하는 것 또한 권장하였습니다.
그렇게 <!DOCTYPE HTML> 은 편견없는 사용자 경험 을 위해 발표되었습니다.
그런데 말입니다,
의외로 작성자의 편의 또한 함께 제공되었지만, 잘 활용되지 않고 있는 규칙이 있습니다.
바로, 시멘틱을 자유롭게 생성 할 수 있음을 말입니다!
두가지 정도의 예시와 힌트를 들어보자면
1. FONT AWESOME
FONT AWESOME 의 경우 <i> 태그를 사용합니다.
그런데 <i> 태그는 FONT-STYLE 의 Italic 으로 미리 약속이 되어있는 시멘틱 입니다.
그럼에도 불구하고 <i class="fas-icon fa-icon" /> 의 형태로 주로 사용되고 있고, 흔히들 사용함에도 의심을 품지 않습니다.
2. STRONG { FONT-WEIGHT }
<STRONG> 태그의 등장 이전에는 <B> 태그가 보편적으로 사용되었지만,
W3C 는 직관적인 문서 작성을 목적하여 <STRONG> 을 사용하도록 한 것입니다.
따라서 문서로 표현하고자 하는 정보를 명확한 시멘틱-네이밍으로 새롭게 작성하는 행위에 소극적일 필요가 없습니다.
예를 들자면 <SIR>그누보드</SIR> 를 사용하는것은 의외로 좋은 문서 작성이라고 판단 할 수도 있습니다.
SIR 은 그누보드의 웹사이트니까요.
새로운 선언을 남용한다면 CSS 스타일시트로 DISPLAY 형태나 MARGIN, PADDING 등
해당 시멘틱의 기본 설정을 계속해서 해주어야하니 꽤나 불편한 일은 맞습니다.
하지만 이점을 유용하게 사용할 수 있는 방법이 있다면,
FONT AWESOME 처럼 새로운 규칙을 생성하고 웹 사이트 전역 태그로써 활용하는 것 입니다.
텍스트에 밑줄을 긋고자 한다면 <U> 태그를 사용하고, 굵기는 <STRONG> 을 사용합니다.
그렇다면 텍스트에 윗줄을 그어주고자 한다면 <UP> 이라는 시멘틱을 생성하여 대략 아래와같이 스타일링을 해준다면
어디에서건 유용하게 사용할 수 있게됩니다.
<style>
UP { display: inline-block; padding-top: 2px; border-top: 1px solid #000; }
</style>
<span>이렇게 글을 쓰다가 <up>윗줄이 필요할 때</up> 이렇게도 사용할 수 있음을 의미합니다.</span>
흥미롭게 읽어주신다면...........
다음 글은 "표" 와 "리스트" 의 차이, 그리고 리스트의 올바른 사용법에 대해서 남겨보겠습니다.
그런데 게시판이 여기가 맞나 모르겠네요^^;;;;;;;;
추천
6
6
댓글 14개
좋은글입니다
현재 제 경험상으론 자유로운 시맨틱태그는 유지보수면에서 어렵지않나 생각이 드네요
협업이 필수인 프로젝트에선 내가 원해서 만든다고 모두가 쓸것도 아니고, 나 이후의 사람이 이것을 알고 사용하게만들기가 쉽지않을것같네요
글을 쓰고보니 협업이란 이유로 새로운 시도가 번번히 막히는것같아 안타깝네요
현재 제 경험상으론 자유로운 시맨틱태그는 유지보수면에서 어렵지않나 생각이 드네요
협업이 필수인 프로젝트에선 내가 원해서 만든다고 모두가 쓸것도 아니고, 나 이후의 사람이 이것을 알고 사용하게만들기가 쉽지않을것같네요
글을 쓰고보니 협업이란 이유로 새로운 시도가 번번히 막히는것같아 안타깝네요
어느정도 동감합니다만..
협업이 이루어지는 실무에서는 코드에 대한 주석을 작성하는것에 소홀하지 않고,
ID 와 CLASS 의 구분, 합의되거나 약속된 네이밍을 사용하는게 더 중요할거라 생각됩니다.
새로운 시멘틱의 제안은 브랜드 이미지부터 보안적인 요소까지 정말 다양한 방면으로 활용이 가능합니다.
협업이 이루어지는 실무에서는 코드에 대한 주석을 작성하는것에 소홀하지 않고,
ID 와 CLASS 의 구분, 합의되거나 약속된 네이밍을 사용하는게 더 중요할거라 생각됩니다.
새로운 시멘틱의 제안은 브랜드 이미지부터 보안적인 요소까지 정말 다양한 방면으로 활용이 가능합니다.
적용해 보아야 겠습니다. 좋은 글 감사합니다. ^^
퍼블리셔팁 게시판에 올려주시면 좋을 것 같습니다.
https://sir.kr/pb_tip
커뮤니티에 새 글로 노출되기도 해서 더 많은 분들이 좋은 글 읽으실 수 있는 기회가 될 것 같네요.
https://sir.kr/pb_tip
커뮤니티에 새 글로 노출되기도 해서 더 많은 분들이 좋은 글 읽으실 수 있는 기회가 될 것 같네요.
아닛... 직접 댓글을... 감사합니다...
해당 게시판으로 옮기도록 하겠습니다^^
퍼블리셔팁 게시판은 [code] 마크다운이 되지않네요 ㅜㅜ
해당 게시판으로 옮기도록 하겠습니다^^
퍼블리셔팁 게시판은 [code] 마크다운이 되지않네요 ㅜㅜ
화력도 이 게시판이 더 쎄네요. ㅠㅠ
[code] 는 확인해보겠습니다.
[code] 는 확인해보겠습니다.
화력은 이 게시판이 더 쎄지만, 오래 보관되기는 저 게시판에 더 좋은 것 같고..
의견주시면 그에 따르겠습니다 ㅎㅎ
의견주시면 그에 따르겠습니다 ㅎㅎ
좋은글 감사합니다.
좋은 글 잘 읽었습니다 : )
규칙이란 것에 대해 가끔 생각해 봅니다
좋은 규칙이란 무엇인가?
사용자 정의의 태그를 적극 활용하는 것도 좋지만
그로 인해 혼란이 생기기도 합니다
"이게 과연 지원을 하는 태그인가"라는 자문을 하게 되죠
무슨 태그지 처음 보는데...
고민을 하게 됩니다
사용자 정의 태그로 구성되어진 잘 짜여진 구조는 더할 나위 없이 좋지만
그로 인해 소스 분석에 들어가야 하는 개발자 입장에서는 간혹 난감할 때가 있습니다
주석을 착실히 달아 놨다면 괜챦은데
두리 뭉실 넘긴 상태에서 다른 이가 넘겨 받았다면
혼란만 가중됩니다
내가 모르는 새로 나온 태그 형식인지 혹은 잘못된 구조인지 아니면 자바스크립트 등에서
데이터를 구분하기 위한 하나의 매개체인지 파악해야 하는 시간이 필요합니다
혼자 개발하고 혼자 사용하는 개인 홈페이지엔
어떠한 구조적인 실험을 해도 괜챦지만
여럿이 사용하거나 혹은 그누보드 처럼 불특정 다수가 사용해야 하는 공용성을 가졌다면
예시로 주신 FONT AWESOME 처럼 널리 사용되어져 익히 알려진 사용자 정의 태그가 아닌
이상 사용함에 있어서 의미 전달이 먼저 전제 되어야 할 거 같습니다
규칙이란 것에 대해 가끔 생각해 봅니다
좋은 규칙이란 무엇인가?
사용자 정의의 태그를 적극 활용하는 것도 좋지만
그로 인해 혼란이 생기기도 합니다
"이게 과연 지원을 하는 태그인가"라는 자문을 하게 되죠
무슨 태그지 처음 보는데...
고민을 하게 됩니다
사용자 정의 태그로 구성되어진 잘 짜여진 구조는 더할 나위 없이 좋지만
그로 인해 소스 분석에 들어가야 하는 개발자 입장에서는 간혹 난감할 때가 있습니다
주석을 착실히 달아 놨다면 괜챦은데
두리 뭉실 넘긴 상태에서 다른 이가 넘겨 받았다면
혼란만 가중됩니다
내가 모르는 새로 나온 태그 형식인지 혹은 잘못된 구조인지 아니면 자바스크립트 등에서
데이터를 구분하기 위한 하나의 매개체인지 파악해야 하는 시간이 필요합니다
혼자 개발하고 혼자 사용하는 개인 홈페이지엔
어떠한 구조적인 실험을 해도 괜챦지만
여럿이 사용하거나 혹은 그누보드 처럼 불특정 다수가 사용해야 하는 공용성을 가졌다면
예시로 주신 FONT AWESOME 처럼 널리 사용되어져 익히 알려진 사용자 정의 태그가 아닌
이상 사용함에 있어서 의미 전달이 먼저 전제 되어야 할 거 같습니다
네, 좋은 피드백 감사합니다.
"이게 과연 지원을 하는 태그인가" 라는 혼란은 태그라는 단어의 기본 의미로 해결 될 것 같습니다.
흔히 HTML5 문서는 "마크업" 문서라고 부르며 여기서 태그란 단연 "마킹" 의 의미를 가지고 있습니다.
누가 작성했는지, 왜 작성했는지, 무엇을 위해 작성했는지를 알 수 있게 해줍니다.
생산성이 떨어지고, 의미를 적시하지 못하는 새로운 규칙은 사용하지 않는게 당연히 좋구요.
역설적으로는 W3C 에서 제안된 HTML5 의 시멘틱 구조조차도 적극적으로 활용하고 있지 않다는점은 많은분들께서 반성이 필요한 맥락인 듯 합니다.
새로 나온 태그 형식.. 이 있을수도 있지만 사용되고 있는 기본 시멘틱보다 사용되지 않고 있는 시멘틱이 실제로 더 많구요, 다른곳에 마크업 테스트를 해보거나, 개발자도구로 들여다보면 고민의 시간을 줄일 수 있을겁니다.
그리고 자바스크립트는 시멘틱 자체 네이밍보다 ID 를 이용하는것이 보편적이고 효과적입니다.
그런데 자바스크립트와 PHP, 엘레멘트 ID, CLASS 등등에는 자신있게 변수명을 작성하면서
왜 HTML 문서에서의 "마크업" 은 보수적으로 바라보는지 잘 이해가 되지 않습니다.
물론 @예뜨락 님께 드리는 이야기가 아니며, 산업군 전반적인 의문입니다.
오히려 폰트어썸의경우 <i> 태그를 italic 이 아닌 icon 으로 변조하여 사용하고 있다는 부분에서 더욱 합리적인 의심이 필요합니다.
외려 모던웹, 웹 2.0 시대 이후로 퍼블리싱 혹은 프론트엔드 작업을 시작하였다면
폰트어썸, 부트스트랩과 같은 써드파티 프레임워크, 악세사리등으로 인해 HTML 문서 작성법의 본질적 의미를 파악하는것이 쉽지않겠다 생각하고 있습니다.
"이게 과연 지원을 하는 태그인가" 라는 혼란은 태그라는 단어의 기본 의미로 해결 될 것 같습니다.
흔히 HTML5 문서는 "마크업" 문서라고 부르며 여기서 태그란 단연 "마킹" 의 의미를 가지고 있습니다.
누가 작성했는지, 왜 작성했는지, 무엇을 위해 작성했는지를 알 수 있게 해줍니다.
생산성이 떨어지고, 의미를 적시하지 못하는 새로운 규칙은 사용하지 않는게 당연히 좋구요.
역설적으로는 W3C 에서 제안된 HTML5 의 시멘틱 구조조차도 적극적으로 활용하고 있지 않다는점은 많은분들께서 반성이 필요한 맥락인 듯 합니다.
새로 나온 태그 형식.. 이 있을수도 있지만 사용되고 있는 기본 시멘틱보다 사용되지 않고 있는 시멘틱이 실제로 더 많구요, 다른곳에 마크업 테스트를 해보거나, 개발자도구로 들여다보면 고민의 시간을 줄일 수 있을겁니다.
그리고 자바스크립트는 시멘틱 자체 네이밍보다 ID 를 이용하는것이 보편적이고 효과적입니다.
그런데 자바스크립트와 PHP, 엘레멘트 ID, CLASS 등등에는 자신있게 변수명을 작성하면서
왜 HTML 문서에서의 "마크업" 은 보수적으로 바라보는지 잘 이해가 되지 않습니다.
물론 @예뜨락 님께 드리는 이야기가 아니며, 산업군 전반적인 의문입니다.
오히려 폰트어썸의경우 <i> 태그를 italic 이 아닌 icon 으로 변조하여 사용하고 있다는 부분에서 더욱 합리적인 의심이 필요합니다.
외려 모던웹, 웹 2.0 시대 이후로 퍼블리싱 혹은 프론트엔드 작업을 시작하였다면
폰트어썸, 부트스트랩과 같은 써드파티 프레임워크, 악세사리등으로 인해 HTML 문서 작성법의 본질적 의미를 파악하는것이 쉽지않겠다 생각하고 있습니다.
문서를 시멘틱하게 적재적소에 의미를 가진 태그를 잘 넣어놓고 효율적으로 문서의 의미를 전달하자는 좋은 내용이네요~!!
그런데 제가 아는 것과 조금 차이가 있거나 생각이 다른 부분이 있어서 조심스럽게 적어봅니다 ^_^;
1.
본문에 말씀해주신 <b> 태그와 <strong> 태그는 그 중 어느것이 더 권장되는 것 이라기보다는 <b> 시각적으로 텍스트를 더 굵게 처리하는데 목적이, <strong> 태그는 의미론적(맥락적으로)으로 '강조하고 싶은 구역'을 지정하는데 목적이 있기 때문에 목적에 따라 사용하면 되지 않을까 싶습니다. <b>는 시멘틱한 의미를 가지지 않습니다.
https://www.w3.org/TR/2012/WD-html-markup-20121025/strong.html#strong
https://www.w3.org/TR/2012/WD-html-markup-20121025/b.html#b
2.
마찬가지로 <i>태그 또한 시멘틱한 의미를 가지는 요소가 아니라 단순히 글자를 기울여보이도록 하는, 시멘틱한(맥락적인) 의미가 없는 요소이기 때문에 그것을 icon을 출력하는 글리피콘 태그로 사용을 하든지, 단순히 활자를 기울이는 태그로 활용을 하든지 문서에 어떠한 맥락적 의미부여도 하지 않습니다. 더욱이 <i class="fa fa-iconname" aria-hidden="true"></i>처럼 사용하기 때문에 태그는 선언이 되었지만 태그의 영역은 '' 이고, aria-hidden="true" 속성을 통해 접근성을 위한 보조기구(스크린리더)에서 제외하기 때문에 이것은 어떤 '의미'를 전혀 지니지 않게 되는 시각적 디자인요소로만 사용됩니다.
https://www.w3.org/TR/2012/WD-html-markup-20121025/i.html#i
3.
HTML5 에서 닫는태그가 없는 태그 <img> <input> 같은 경우 XHTML로 작성된 문서에서는 <img/><input/>으로 작성하여야 하지만, <!DOCTYPE html>을 사용하는 HTML5에서는 기본적으로는 생략하도록 되어있고, 선택적으로 슬래시를 넣어 사용할 수 있도록 정의되어있습니다.
- 6.1.2.2 Void Elements
https://dev.w3.org/html5/html-author/#void-elements
4.
저는 커스텀 태그 사용에 반대하는 입장이어서 사용하지 말아야할 이유를 적어보겠습니다.
4-1. 공식 권고
희박한 확률이겠지만 향후에 HTML5 표준스펙으로 정의될 태그와 충돌하게 될 가능성을 만들게 됩니다.
"Authors must not use elements, attributes, or attribute values that are not permitted by this specification or other applicable specifications, as doing so makes it significantly harder for the language to be extended in the future."
https://html.spec.whatwg.org/multipage/dom.html#elements
확장성 등을 이유로 공식 문서에서는 사용하지 말 것을 권하고 있습니다.
4-2. CSS만을 고려한 커스텀 태그 활용의 비효율성
UP { display: inline-block; padding-top: 2px; border-top: 1px solid #000; }
위의 예에서 처럼 CSS 재활용성을 위한 목적으로 사용하기에는 포기해야 하는 내용이 너무 많습니다.
- 브라우저에 따라 해석이 다르게 될 수 있는 위험성을 내포하게 됩니다.
- 검색엔진에 웹사이트를 색인하는 방식에 부정적인 영향을 줄 수 있습니다.
- 태그 선택자는 DOM 탐색이 느립니다. (https://css-tricks.com/efficiently-rendering-css)
4-3. "시멘틱을 자유롭게 생성 할 수 있음을 말입니다"
라고 말씀하신 부분에 대해서..
커스텀 태그로 규칙성을 만들고, 기능을 부여하는 것은 가능하지만, 맥락적인 의미(시멘틱)를 부여할 수는 없습니다. 어떠한 태그의 스펙을 규정하고 의미를 부여해 웹표준으로 확정(Living Standard)해 브라우저 개발사에 권고하는 일은 WHATWG (https://html.spec.whatwg.org/, https://ko.wikipedia.org/wiki/WHATWG) 에서 하고 있습니다.
<UP></UP> 과 같은 커스텀 태그를 사이트 전역에 CSS로 디자인을 입히고, 자바스크립트로 접근하고 제어하면서 '기능적'으로 최적화된 레이아웃과 인터페이스를 작성하고 디자인을 뽑아낸다고 해도, 검색엔진은 해당 사이트에서 사용된 커스텀 태그가 하는 일이 무엇인지 해석할 수 없기 때문에 그것이 비록 '기능적'일지라도 '의미론적' 이지는 않습니다.
브라우저 내부에 빌트인 되어있지 않은 알 수 없는 태그에 대해 모든 브라우저가 동일하게 해석하지 않습니다. 모든 브라우저가 알려지지 않는 DOM의 박스모델을 block 으로 해석하지는 않는 것이 하나의 예입니다. 본문에 언급해주신대로 불필요한 user agent stylesheet 와 같은 역할을 도울 사전 작업이 필요할수도 있겠지요. 이 밖의 구체적인 사례를 알지 못하지만, 브라우저 호환에 관련한 위험을 내포하게 된다는 것입니다.
4-4. 커스텀 태그에 대한 의견
위의 내용들은 '강제'되는 내용은 아닙니다. 대부분의 모던 브라우저에서는 커스텀 태그를 DOM으로 잘 해석해주기 때문에 명확한 목적성을 가지고 커스텀 태그를 사용하고자 한다면 사용해도 좋겠지만, 특수하지 않고 일반적인 경우, 시멘틱하게 작성하여 포털 사이트 등에서 문서를 널리 배포하고자 하는 목적을 가진 페이지라면 <UP></UP>과 같은 커스텀 태그 사용은 자제하는 것이 좋지 않을까요?
그런데 제가 아는 것과 조금 차이가 있거나 생각이 다른 부분이 있어서 조심스럽게 적어봅니다 ^_^;
1.
본문에 말씀해주신 <b> 태그와 <strong> 태그는 그 중 어느것이 더 권장되는 것 이라기보다는 <b> 시각적으로 텍스트를 더 굵게 처리하는데 목적이, <strong> 태그는 의미론적(맥락적으로)으로 '강조하고 싶은 구역'을 지정하는데 목적이 있기 때문에 목적에 따라 사용하면 되지 않을까 싶습니다. <b>는 시멘틱한 의미를 가지지 않습니다.
https://www.w3.org/TR/2012/WD-html-markup-20121025/strong.html#strong
https://www.w3.org/TR/2012/WD-html-markup-20121025/b.html#b
2.
마찬가지로 <i>태그 또한 시멘틱한 의미를 가지는 요소가 아니라 단순히 글자를 기울여보이도록 하는, 시멘틱한(맥락적인) 의미가 없는 요소이기 때문에 그것을 icon을 출력하는 글리피콘 태그로 사용을 하든지, 단순히 활자를 기울이는 태그로 활용을 하든지 문서에 어떠한 맥락적 의미부여도 하지 않습니다. 더욱이 <i class="fa fa-iconname" aria-hidden="true"></i>처럼 사용하기 때문에 태그는 선언이 되었지만 태그의 영역은 '' 이고, aria-hidden="true" 속성을 통해 접근성을 위한 보조기구(스크린리더)에서 제외하기 때문에 이것은 어떤 '의미'를 전혀 지니지 않게 되는 시각적 디자인요소로만 사용됩니다.
https://www.w3.org/TR/2012/WD-html-markup-20121025/i.html#i
3.
HTML5 에서 닫는태그가 없는 태그 <img> <input> 같은 경우 XHTML로 작성된 문서에서는 <img/><input/>으로 작성하여야 하지만, <!DOCTYPE html>을 사용하는 HTML5에서는 기본적으로는 생략하도록 되어있고, 선택적으로 슬래시를 넣어 사용할 수 있도록 정의되어있습니다.
- 6.1.2.2 Void Elements
https://dev.w3.org/html5/html-author/#void-elements
4.
저는 커스텀 태그 사용에 반대하는 입장이어서 사용하지 말아야할 이유를 적어보겠습니다.
4-1. 공식 권고
희박한 확률이겠지만 향후에 HTML5 표준스펙으로 정의될 태그와 충돌하게 될 가능성을 만들게 됩니다.
"Authors must not use elements, attributes, or attribute values that are not permitted by this specification or other applicable specifications, as doing so makes it significantly harder for the language to be extended in the future."
https://html.spec.whatwg.org/multipage/dom.html#elements
확장성 등을 이유로 공식 문서에서는 사용하지 말 것을 권하고 있습니다.
4-2. CSS만을 고려한 커스텀 태그 활용의 비효율성
UP { display: inline-block; padding-top: 2px; border-top: 1px solid #000; }
위의 예에서 처럼 CSS 재활용성을 위한 목적으로 사용하기에는 포기해야 하는 내용이 너무 많습니다.
- 브라우저에 따라 해석이 다르게 될 수 있는 위험성을 내포하게 됩니다.
- 검색엔진에 웹사이트를 색인하는 방식에 부정적인 영향을 줄 수 있습니다.
- 태그 선택자는 DOM 탐색이 느립니다. (https://css-tricks.com/efficiently-rendering-css)
4-3. "시멘틱을 자유롭게 생성 할 수 있음을 말입니다"
라고 말씀하신 부분에 대해서..
커스텀 태그로 규칙성을 만들고, 기능을 부여하는 것은 가능하지만, 맥락적인 의미(시멘틱)를 부여할 수는 없습니다. 어떠한 태그의 스펙을 규정하고 의미를 부여해 웹표준으로 확정(Living Standard)해 브라우저 개발사에 권고하는 일은 WHATWG (https://html.spec.whatwg.org/, https://ko.wikipedia.org/wiki/WHATWG) 에서 하고 있습니다.
<UP></UP> 과 같은 커스텀 태그를 사이트 전역에 CSS로 디자인을 입히고, 자바스크립트로 접근하고 제어하면서 '기능적'으로 최적화된 레이아웃과 인터페이스를 작성하고 디자인을 뽑아낸다고 해도, 검색엔진은 해당 사이트에서 사용된 커스텀 태그가 하는 일이 무엇인지 해석할 수 없기 때문에 그것이 비록 '기능적'일지라도 '의미론적' 이지는 않습니다.
브라우저 내부에 빌트인 되어있지 않은 알 수 없는 태그에 대해 모든 브라우저가 동일하게 해석하지 않습니다. 모든 브라우저가 알려지지 않는 DOM의 박스모델을 block 으로 해석하지는 않는 것이 하나의 예입니다. 본문에 언급해주신대로 불필요한 user agent stylesheet 와 같은 역할을 도울 사전 작업이 필요할수도 있겠지요. 이 밖의 구체적인 사례를 알지 못하지만, 브라우저 호환에 관련한 위험을 내포하게 된다는 것입니다.
4-4. 커스텀 태그에 대한 의견
위의 내용들은 '강제'되는 내용은 아닙니다. 대부분의 모던 브라우저에서는 커스텀 태그를 DOM으로 잘 해석해주기 때문에 명확한 목적성을 가지고 커스텀 태그를 사용하고자 한다면 사용해도 좋겠지만, 특수하지 않고 일반적인 경우, 시멘틱하게 작성하여 포털 사이트 등에서 문서를 널리 배포하고자 하는 목적을 가진 페이지라면 <UP></UP>과 같은 커스텀 태그 사용은 자제하는 것이 좋지 않을까요?
퍼블리싱 관련하려 이렇게나 수주높은 의견을 나눌 수 있음에 감사합니다!
네, 강제되는 내용이 아닙니다.
그리고 Strong 과 B 를 시멘틱으로써 이야기 드린 이유를 저보다 더 상세하게 잘 알려주신 것 같아서 참 좋습니다!
사실 이 부분에서 Marquee 태그까지 언급할까말까 살짤 고민했습니다 ㅎㅎ
새로운 엘레먼트는 DOM 의 서칭이 쉽지 않지만 다른 댓글로 언급드렸다시피 반대로 보안적인 측면에서는 조금 더 유리한 측면이 있을 수 있습니다.
하지만 본문에서 더 강조하여 이야기하고 싶던점은,
<div class="Gnb"></div> 와 <nav> </nav> 와 같은 실용적이게 권장된 시멘틱 등을 더욱 자극적이게 이야기하고싶었던게 맞습니다.
본문에서 모든 엘레먼트를 커스텀해서 사용하세요. 를 시사하진 않았습니다.
그래서는 안되구요.
하지만 모든 브라우저, 로봇이게 정확한 사용자경험 디자인을 알려주고자 한다먼
<body>
<header>
<hgroup></hgroup>
<nav>
<ul><li></li></ul>
</nav>
</header>
<article>
<section id="">
<div class=""><div>
</section>
</article>
<aside></aside>
<footer></footer>
</body>
위와 같은 형태의 작성이 더 적극적이게 모던웹을 팔로우하는 방향이 아닌가 하는 것 입니다.
여기서 잠깐.
본문에 들었던 예로 <sir>그누보드</sir> 을 hgroup 속에서 사용하게된다면 <sir> 이라는 커스텀태그를 복잡하게 해석할 필요가 있을까요?
DOM 추적에 대한 걱정을 할 필요가 없습니다.
이미 head subject 영역에 속해있는 커스텀태그이며,
<sir></sir> 만을 입력한채 사이트네임에만 해당하는 단어만 아래와같이 기재한다면 말입니다.
<hgroup>
<h1><sir><?php echo $config('title'); ?></sir></h1>
</hgroup>
그누보드 이외의 단어를 담고있지 않습니다.
물론 실제 사용에서는 php 문항을 제거하고 jquery 나 javascript 로 해당 dom 에 php 문을 입력해두는게 더 좋은 방법이 되겠지요.
그렇다면 <sir> 이라는 입력을 단 한번을 위해서 사용한다면 그 또한 의미가 없다고 생각합니다.
하나의 웹사이트를 만들 때 사이트의 이름을 불러다 사용할일이 참 많습니다.
아티클 영역에서도, 푸터에서도, 웹사이트의 명칭을 꽤 자주 불러서 사용할 수 있게 됩니다.
다만 div 작성을 위주로하여 class 혹은 id 으로써의 네이밍을 Header, gnb, content, footer 등을 사용하는것보다, 제안된 정확한 시멘틱을 사용하여 의견주신것처럼 "인류를 넘어 로봇까지 쉽게 읽을 수 있도록" 마크업하는것이 우선적 과제라 생각합니다.
디테일하고 소중한 의견 감사합니다.
이러한 주제에 다양한 의견이 소통되어 더 많은분들이 한번쯤이라도 생각해볼 수 있는 계기가 된다면 참 좋겠습니다.
국내 IT 산업에서 퍼블리셔가 제대로 대우받지 못하는것은 "무사안일주의" 에서 나오는게 아닐까 싶습니다.
디자이너가 넘긴 디자인을 코더로써 표현만 하는것으로 마무리짓고, 프론트엔드가 아닌 퍼블리셔의 단계에서도 충분히 많은것을 실험하고 도전할 수 있음에도 보편적인 작성법을 고수하게된다면, 프론트엔트와 백엔드의 경계마저 무너져가는 시점에 퍼블리셔라는 직업군 자체가 무의미해지지 않을까 합니다.
좋은의견 감사합니다!
네, 강제되는 내용이 아닙니다.
그리고 Strong 과 B 를 시멘틱으로써 이야기 드린 이유를 저보다 더 상세하게 잘 알려주신 것 같아서 참 좋습니다!
사실 이 부분에서 Marquee 태그까지 언급할까말까 살짤 고민했습니다 ㅎㅎ
새로운 엘레먼트는 DOM 의 서칭이 쉽지 않지만 다른 댓글로 언급드렸다시피 반대로 보안적인 측면에서는 조금 더 유리한 측면이 있을 수 있습니다.
하지만 본문에서 더 강조하여 이야기하고 싶던점은,
<div class="Gnb"></div> 와 <nav> </nav> 와 같은 실용적이게 권장된 시멘틱 등을 더욱 자극적이게 이야기하고싶었던게 맞습니다.
본문에서 모든 엘레먼트를 커스텀해서 사용하세요. 를 시사하진 않았습니다.
그래서는 안되구요.
하지만 모든 브라우저, 로봇이게 정확한 사용자경험 디자인을 알려주고자 한다먼
<body>
<header>
<hgroup></hgroup>
<nav>
<ul><li></li></ul>
</nav>
</header>
<article>
<section id="">
<div class=""><div>
</section>
</article>
<aside></aside>
<footer></footer>
</body>
위와 같은 형태의 작성이 더 적극적이게 모던웹을 팔로우하는 방향이 아닌가 하는 것 입니다.
여기서 잠깐.
본문에 들었던 예로 <sir>그누보드</sir> 을 hgroup 속에서 사용하게된다면 <sir> 이라는 커스텀태그를 복잡하게 해석할 필요가 있을까요?
DOM 추적에 대한 걱정을 할 필요가 없습니다.
이미 head subject 영역에 속해있는 커스텀태그이며,
<sir></sir> 만을 입력한채 사이트네임에만 해당하는 단어만 아래와같이 기재한다면 말입니다.
<hgroup>
<h1><sir><?php echo $config('title'); ?></sir></h1>
</hgroup>
그누보드 이외의 단어를 담고있지 않습니다.
물론 실제 사용에서는 php 문항을 제거하고 jquery 나 javascript 로 해당 dom 에 php 문을 입력해두는게 더 좋은 방법이 되겠지요.
그렇다면 <sir> 이라는 입력을 단 한번을 위해서 사용한다면 그 또한 의미가 없다고 생각합니다.
하나의 웹사이트를 만들 때 사이트의 이름을 불러다 사용할일이 참 많습니다.
아티클 영역에서도, 푸터에서도, 웹사이트의 명칭을 꽤 자주 불러서 사용할 수 있게 됩니다.
다만 div 작성을 위주로하여 class 혹은 id 으로써의 네이밍을 Header, gnb, content, footer 등을 사용하는것보다, 제안된 정확한 시멘틱을 사용하여 의견주신것처럼 "인류를 넘어 로봇까지 쉽게 읽을 수 있도록" 마크업하는것이 우선적 과제라 생각합니다.
디테일하고 소중한 의견 감사합니다.
이러한 주제에 다양한 의견이 소통되어 더 많은분들이 한번쯤이라도 생각해볼 수 있는 계기가 된다면 참 좋겠습니다.
국내 IT 산업에서 퍼블리셔가 제대로 대우받지 못하는것은 "무사안일주의" 에서 나오는게 아닐까 싶습니다.
디자이너가 넘긴 디자인을 코더로써 표현만 하는것으로 마무리짓고, 프론트엔드가 아닌 퍼블리셔의 단계에서도 충분히 많은것을 실험하고 도전할 수 있음에도 보편적인 작성법을 고수하게된다면, 프론트엔트와 백엔드의 경계마저 무너져가는 시점에 퍼블리셔라는 직업군 자체가 무의미해지지 않을까 합니다.
좋은의견 감사합니다!
네 ^_^ 저도 이렇게 흥미로운 주제에 대해 대화를 할 수 있어서 즐겁습니다!
이런 대화를 좋아해서 근처에 사는 개발자 친구랑도 이런 논의, 토론도 자주합니다.ㅎㅎ 답변 감사드립니다.
좋은 글 전반에 동의드린다는 말씀 먼저 드리면서, 여전히 조금 다른 의견이 있어서 추가 댓글 드립니다~!
제 의견을 결론부터 말씀드리자면 "모든 커스텀 태그는 전혀 '시멘틱'하지 않고 따라서 시멘틱은 자유롭게 생성할 수 없다." 입니다.
HTML5에서 의미하는 '시멘틱'은 '규약'과 같은 성격을 가집니다. 사전에 모두에게 약속되어 있어야 한다는 것이죠.
그래서 접하는 모두가 그 의미를 혼동하지 않고 같은 맥락으로 이해하기 위해 미리 표준 제정 기관(WHATWG)에서 태그를 '규정'하고 '약속'하여 웹표준으로 공표합니다.
그러면 브라우저 개발사에서는 태그가 규약된 대로 사용될 수 있도록 브라우저를 개발하고, 웹사이트 제작자는 규약을 참고해 문서에 태그를 마크업을 하고 또 구글과 같은 포털은 웹 문서를 크롤링, 파싱하면서 규약을 기준으로 규격화된 정보를 수집하는 것입니다.
그렇기 때문에 <sir> 가 '그누보드'라는 의미를 지니는 시멘틱한 태그로 사용될 수 있으려면 WHATWG 에서 "<sir></sir> 태그는 '그누보드'라는 의미를 가진다." 라고 웹표준으로 공표 해야만 가능한 일입니다.
물론 특정 태그가 특정 단어를 지칭 하도록 의미부여하지는 않겠지만요. 즉, 브라우저 개발사들이 WHATWG 에서 제정한 표준을 자신의 브라우저에 도입하기로 합의한 이상, 시멘틱한 태그는 WHATWG 만이 만들 수 있습니다.
<sir>그누보드</sir>가 사이트 전반에 '반복적으로 매우 자주' 사용 된다고 해도, <sir> 이라는 커스텀 태그는 아무런 의미를 지니지 않습니다.
반복 사용으로 <sir> 이라는 커스텀 태그가 '그누보드'를 지칭하는 맥락(시멘틱)이 된다면 일례로 <button>등록</button>을 반복적으로 사용하는 경우에도 button 태그는 오로지 등록으로써의 의미만 가지게 되어야 맞는 것이기 때문입니다.
아시다시피 button은 input[type="submit"] 의 요소로도, 양식 reset의 요소로도, 자바스크립트를 제어하기 위한 상호작용 트리거로써의 요소로도 사용될 수가 있습니다.
결국 <h1><sir>그누보드</sir></h1> 의 코드는 <h1><div>그누보드</div></h1> 이 코드와 기능적으로도, 의미론적으로도 동일합니다. 동일하게 <sir>과 <div>는 아무런 의미도 가지지 않죠.
그렇다면 <sir></sir>은 불필요한 DOM을 중첩한, 의미없는 마크업이 됩니다.
본문에서 예로 드신 폰트어썸 글리피콘의 경우에서도, 글리피콘 심볼을 사용하기 위해 <i> 태그를 반복적으로 사용하는 것은, 단지 반복된 사용으로 코드를 작성하는 작성자에게 i 태그가 '아이콘'을 출력하기 위해 사용된 것 같다는 느낌을 줄 뿐입니다. 반복된 태그를 사용하는 것이 아무런 맥락적 의미를 가지지 않은 <i> 태그에 '아이콘' 이라는 맥락적(시멘틱한) 의미를 부여하는 것은 아니라는 것 입니다. 어떻게 얼마나 사용 되었느냐와 관계없이 <i> 태그는 웹표준에서 정의된 그대로 "서체를, italic 하게, 기울임꼴로 보이도록 하는 추가 의미를 내포하지 않은(비 시멘틱한) 태그"인 것 입니다.
따라서 제 결론은 "<UP>, <sir>과 같은 사용자정의요소(Custom Elements, DOM)는 기능적, 의미론적으로 <div>와 동일하고, 시멘틱한 의미부여도 불가능하므로, 보안상의 이유와 같은 특별한 목적이 없다면 사용하지 않는 것이 바람직하다." 는 것 입니다.
저도 일을 할 때 가능한한 웹표준 명세를 참고해 시멘틱하게 문서를 작성하려고 노력 하고 있습니다.ㅎㅎ
하지만 태그 사용 맥락에 대한 정의가 추상적이고, 유사하지만 다른 다양한 케이스에 대응하기 어려워 실 적용에 애를 많이 먹고 있죠.
'시멘틱'에 관련해서는 디버깅도 되지 않기 때문에 작업 후 찝찝한 경우도 많고요. 문서에 태그를 마크업하는 일은, 생각보다 상당한 숙련과 노하우를 요하는 작업이라고 생각합니다.
마크업만으로도 문서의 구성과 의미를 전달하기 쉽도록 시멘틱하게 작성하는 것이 좋다는 슈가스컬님 의견에 동의드립니다. 저도 열심히 배워가는 중입니다^^
댓글에 적은 내용에서 제가 잘못 알고 있는 부분이 있을수도 있으나, 그렇다면 저에게도 바로잡을 수 있는 기회가 될 것 같고, 제가 알고 있는 내용이 맞는 것이라면 본문에서 오해할 수 있는 내용이 좀 더 명확하게 설명될 수 있을 것 같다는 생각으로 작성하였으니 슈가스컬님께서 얹잖아 하지 않으셨으면 좋겠습니다~! 또 제가 잘못 이해하고 있는 부분이 있으면 지적해주시면 감사드리겠습니다^^
이런 대화를 좋아해서 근처에 사는 개발자 친구랑도 이런 논의, 토론도 자주합니다.ㅎㅎ 답변 감사드립니다.
좋은 글 전반에 동의드린다는 말씀 먼저 드리면서, 여전히 조금 다른 의견이 있어서 추가 댓글 드립니다~!
제 의견을 결론부터 말씀드리자면 "모든 커스텀 태그는 전혀 '시멘틱'하지 않고 따라서 시멘틱은 자유롭게 생성할 수 없다." 입니다.
HTML5에서 의미하는 '시멘틱'은 '규약'과 같은 성격을 가집니다. 사전에 모두에게 약속되어 있어야 한다는 것이죠.
그래서 접하는 모두가 그 의미를 혼동하지 않고 같은 맥락으로 이해하기 위해 미리 표준 제정 기관(WHATWG)에서 태그를 '규정'하고 '약속'하여 웹표준으로 공표합니다.
그러면 브라우저 개발사에서는 태그가 규약된 대로 사용될 수 있도록 브라우저를 개발하고, 웹사이트 제작자는 규약을 참고해 문서에 태그를 마크업을 하고 또 구글과 같은 포털은 웹 문서를 크롤링, 파싱하면서 규약을 기준으로 규격화된 정보를 수집하는 것입니다.
그렇기 때문에 <sir> 가 '그누보드'라는 의미를 지니는 시멘틱한 태그로 사용될 수 있으려면 WHATWG 에서 "<sir></sir> 태그는 '그누보드'라는 의미를 가진다." 라고 웹표준으로 공표 해야만 가능한 일입니다.
물론 특정 태그가 특정 단어를 지칭 하도록 의미부여하지는 않겠지만요. 즉, 브라우저 개발사들이 WHATWG 에서 제정한 표준을 자신의 브라우저에 도입하기로 합의한 이상, 시멘틱한 태그는 WHATWG 만이 만들 수 있습니다.
<sir>그누보드</sir>가 사이트 전반에 '반복적으로 매우 자주' 사용 된다고 해도, <sir> 이라는 커스텀 태그는 아무런 의미를 지니지 않습니다.
반복 사용으로 <sir> 이라는 커스텀 태그가 '그누보드'를 지칭하는 맥락(시멘틱)이 된다면 일례로 <button>등록</button>을 반복적으로 사용하는 경우에도 button 태그는 오로지 등록으로써의 의미만 가지게 되어야 맞는 것이기 때문입니다.
아시다시피 button은 input[type="submit"] 의 요소로도, 양식 reset의 요소로도, 자바스크립트를 제어하기 위한 상호작용 트리거로써의 요소로도 사용될 수가 있습니다.
결국 <h1><sir>그누보드</sir></h1> 의 코드는 <h1><div>그누보드</div></h1> 이 코드와 기능적으로도, 의미론적으로도 동일합니다. 동일하게 <sir>과 <div>는 아무런 의미도 가지지 않죠.
그렇다면 <sir></sir>은 불필요한 DOM을 중첩한, 의미없는 마크업이 됩니다.
본문에서 예로 드신 폰트어썸 글리피콘의 경우에서도, 글리피콘 심볼을 사용하기 위해 <i> 태그를 반복적으로 사용하는 것은, 단지 반복된 사용으로 코드를 작성하는 작성자에게 i 태그가 '아이콘'을 출력하기 위해 사용된 것 같다는 느낌을 줄 뿐입니다. 반복된 태그를 사용하는 것이 아무런 맥락적 의미를 가지지 않은 <i> 태그에 '아이콘' 이라는 맥락적(시멘틱한) 의미를 부여하는 것은 아니라는 것 입니다. 어떻게 얼마나 사용 되었느냐와 관계없이 <i> 태그는 웹표준에서 정의된 그대로 "서체를, italic 하게, 기울임꼴로 보이도록 하는 추가 의미를 내포하지 않은(비 시멘틱한) 태그"인 것 입니다.
따라서 제 결론은 "<UP>, <sir>과 같은 사용자정의요소(Custom Elements, DOM)는 기능적, 의미론적으로 <div>와 동일하고, 시멘틱한 의미부여도 불가능하므로, 보안상의 이유와 같은 특별한 목적이 없다면 사용하지 않는 것이 바람직하다." 는 것 입니다.
저도 일을 할 때 가능한한 웹표준 명세를 참고해 시멘틱하게 문서를 작성하려고 노력 하고 있습니다.ㅎㅎ
하지만 태그 사용 맥락에 대한 정의가 추상적이고, 유사하지만 다른 다양한 케이스에 대응하기 어려워 실 적용에 애를 많이 먹고 있죠.
'시멘틱'에 관련해서는 디버깅도 되지 않기 때문에 작업 후 찝찝한 경우도 많고요. 문서에 태그를 마크업하는 일은, 생각보다 상당한 숙련과 노하우를 요하는 작업이라고 생각합니다.
마크업만으로도 문서의 구성과 의미를 전달하기 쉽도록 시멘틱하게 작성하는 것이 좋다는 슈가스컬님 의견에 동의드립니다. 저도 열심히 배워가는 중입니다^^
댓글에 적은 내용에서 제가 잘못 알고 있는 부분이 있을수도 있으나, 그렇다면 저에게도 바로잡을 수 있는 기회가 될 것 같고, 제가 알고 있는 내용이 맞는 것이라면 본문에서 오해할 수 있는 내용이 좀 더 명확하게 설명될 수 있을 것 같다는 생각으로 작성하였으니 슈가스컬님께서 얹잖아 하지 않으셨으면 좋겠습니다~! 또 제가 잘못 이해하고 있는 부분이 있으면 지적해주시면 감사드리겠습니다^^
언짢음은 전혀 없고, 오히려 좋은 의견을 나눌 수 있음에 기분이 좋습니다^^
누가 맞고 틀리다. 를 이야기하기 보단 더 좋은 방향성에 대한 피드백을 나눔에 있어
저희뿐만 아니라 본 글을 읽어주시는분들께 더 좋은 정보로써 전달이 될 것 같고,
한편으로는 한번쯤 더 생각해보게하는 계기가 될 수 있을것같아 즐겁습니다.
해당 본문의 '시멘틱' 이라는 주제를 이야기함에 있어 어떠한 문서를 발췌하거나 참조하여 작성한 글이 아니고 근 20여넌간의 html 문서작성에서 비롯된 주관적인 의견이 대부분이라, 오류가 많을수도 있음에도 좋은 피드백을 작성해주셔서 외려 감사합니다.
어떠한 논점을 대화하기 위해서는 분명 '사실과 근거' 가 바탕이 되어야하는것이 올바른 토론이라 생각하기에 @묵선옹 님의 답변은 오히려 저의 주관적인 이야기에 대한 "객관적인" 피드백이라 생각하여 더 많은분들께 도움이 되리라 생각합니다.
주관적인 생각에 객관적인 의견이 부딪힐 때, 때론 감정적인 오해가 생길 순 있지만 그만큼 더 "토론" 으로써 시너지가 발생될 수 있고, 더 많은 이들의 참여도를 발생시킬 수 있음에 지극히 긍정적이고 바른 "토론"의 형태임에 이견이 없습니다.
--
<h1><sir /><h1> 과 <h1><div></div><h1> 의 "맥락적 의미는 같다." 동감합니다.
하지만 <sir> 이라는 태그를 예로 든 이유는 "브랜딩" 에 가까운 목적이 있었음을 다시금 이야기드리고 싶습니다.
<up> 의 요소를 언급한 것은 시각적인 전달을 위함이었습니다.
물론 <p class="up"> 으로도 충분히 대체될 수 있습니다.
하지만 근래의 웹사이트 개발은 "컴포넌트 개발" 과 "재활용" 이 최대 이슈라고 생각하는데, 그러할 경우 별도의 시멘틱구조를 뒤엎어선 안된다라는 접근보다는 "필요에 의한 특수성을 부여하고 생성 하는것에 소극적일 필요가 없다". 라는 메시지를 전달하고자함이 컸습니다.
다시말해 조금 더 과감하고, 실험적인 사용에 적극적인 참여가 필요하고, 이러한 적극적인 시도를 위해서는 기존에 제안된 <header><nav><article><footer> 등을 ID 나 CLASS 로써 <div> 에 덧붙여 사용하기보다는 구조적으로 열거되고 제안된 "시멘틱" 을 단편적으로 어떠한 데이터를 담아내거나, 레이아웃을 구성하는것에 사용되는것을 줄이고, 용도에 잘 맞는 방향으로 사용되었으면 하는 바램입니다.
보안적인 측면을 이야기하자면 예를들어 <phonenumber></phonenumber> 라는 엘레먼트를 생성한다면 개인정보를 담는 객체이기에 로봇이 수집하지 못하도록하는 1차적인 보안요소로써의 사용이 될 수 있다고도 사료됩니다.
그리고 다시금 언급하는 <i>. italic 의 요소로 사용되어야 하는 <i> 를 글리피콘화 시키는 class="fas-icon" 은 폰트어썸이 보편화 된 후 코딩을 배우기 시작한 이들에게는 혼돈의 카오스로 인도될 수 있는 요소일수도 있겠다 생각힙니다. <i>가 정의된 사용법을 모른채 <p class="italic"> 과 같이 새롭게 클래스를 생성하여 사용되는 경우 또한 너무 많이 보아왔기 때문입니다.
"당연히 이렇게 하는거 아니야?" 식의 충격적인 사례들을 너무 많이 보아왔기 때문이기도 합니다.ㅠㅠ
위첨자 <sup> 아래첨자 <sub> 사용또한 본적이 없고
svg 파일이 유행하기 시작한 이래로 <img src="*.svg /> 를 사용하는 어처구니 없는 경우 또한 수시로 발견되고..
<address><tel><small><blockquote> 이 사용된바도 본적이 없습니다.
참 직관적이고 좋은 시멘틱인데도 불구하고말이죠.
WHATWG 에서의 온프레미스는 WWW(월드와이드웹) 에서의 주요한 사항일 수는 있지만, 법을 어기는 사람이 없다면 공권력이 필요하지 않고, 계약서류상의 특약사항보다 헌법이 더 상위의 근거가 되기도 합니다. 하지만 개개인의 자유또한 보장되는것이 WWW 와 민주주의의 기본 원칙임을 고려한다면 새로운 규칙의 생성또한 "가능" 하고 조금 더 실험적이고 발전적인 코딩이 우리네의 밥줄이라는 메시지를 남기는것이 본 글의 요지 였습니다.
물론 저 또한 완전무결한 웹표준 코딩을 하지 못합니다.
@묵선웅 님의 말씀처럼 규칙을 어긋나는 태그를 생성해서 사용하기도하고, 귀찮음의 핑계로 alt, name 등을 생략하기도 합니다.
하지만 조금 더 자유롭고 크리에이티브한 코딩을 해 볼 필요는 있다 생각합니다.
"보편적 인식" 이라는 프레임을 벗어나는것을 반항이라 생각하지 마시고 "새로운 것" 을 시도할 때 본인만의 아이덴티티가 형성이 되고, 그것이 변화를 일으키게 하는 움직임이 될 수 있음을 시사하고 싶습니다!
누가 맞고 틀리다. 를 이야기하기 보단 더 좋은 방향성에 대한 피드백을 나눔에 있어
저희뿐만 아니라 본 글을 읽어주시는분들께 더 좋은 정보로써 전달이 될 것 같고,
한편으로는 한번쯤 더 생각해보게하는 계기가 될 수 있을것같아 즐겁습니다.
해당 본문의 '시멘틱' 이라는 주제를 이야기함에 있어 어떠한 문서를 발췌하거나 참조하여 작성한 글이 아니고 근 20여넌간의 html 문서작성에서 비롯된 주관적인 의견이 대부분이라, 오류가 많을수도 있음에도 좋은 피드백을 작성해주셔서 외려 감사합니다.
어떠한 논점을 대화하기 위해서는 분명 '사실과 근거' 가 바탕이 되어야하는것이 올바른 토론이라 생각하기에 @묵선옹 님의 답변은 오히려 저의 주관적인 이야기에 대한 "객관적인" 피드백이라 생각하여 더 많은분들께 도움이 되리라 생각합니다.
주관적인 생각에 객관적인 의견이 부딪힐 때, 때론 감정적인 오해가 생길 순 있지만 그만큼 더 "토론" 으로써 시너지가 발생될 수 있고, 더 많은 이들의 참여도를 발생시킬 수 있음에 지극히 긍정적이고 바른 "토론"의 형태임에 이견이 없습니다.
--
<h1><sir /><h1> 과 <h1><div></div><h1> 의 "맥락적 의미는 같다." 동감합니다.
하지만 <sir> 이라는 태그를 예로 든 이유는 "브랜딩" 에 가까운 목적이 있었음을 다시금 이야기드리고 싶습니다.
<up> 의 요소를 언급한 것은 시각적인 전달을 위함이었습니다.
물론 <p class="up"> 으로도 충분히 대체될 수 있습니다.
하지만 근래의 웹사이트 개발은 "컴포넌트 개발" 과 "재활용" 이 최대 이슈라고 생각하는데, 그러할 경우 별도의 시멘틱구조를 뒤엎어선 안된다라는 접근보다는 "필요에 의한 특수성을 부여하고 생성 하는것에 소극적일 필요가 없다". 라는 메시지를 전달하고자함이 컸습니다.
다시말해 조금 더 과감하고, 실험적인 사용에 적극적인 참여가 필요하고, 이러한 적극적인 시도를 위해서는 기존에 제안된 <header><nav><article><footer> 등을 ID 나 CLASS 로써 <div> 에 덧붙여 사용하기보다는 구조적으로 열거되고 제안된 "시멘틱" 을 단편적으로 어떠한 데이터를 담아내거나, 레이아웃을 구성하는것에 사용되는것을 줄이고, 용도에 잘 맞는 방향으로 사용되었으면 하는 바램입니다.
보안적인 측면을 이야기하자면 예를들어 <phonenumber></phonenumber> 라는 엘레먼트를 생성한다면 개인정보를 담는 객체이기에 로봇이 수집하지 못하도록하는 1차적인 보안요소로써의 사용이 될 수 있다고도 사료됩니다.
그리고 다시금 언급하는 <i>. italic 의 요소로 사용되어야 하는 <i> 를 글리피콘화 시키는 class="fas-icon" 은 폰트어썸이 보편화 된 후 코딩을 배우기 시작한 이들에게는 혼돈의 카오스로 인도될 수 있는 요소일수도 있겠다 생각힙니다. <i>가 정의된 사용법을 모른채 <p class="italic"> 과 같이 새롭게 클래스를 생성하여 사용되는 경우 또한 너무 많이 보아왔기 때문입니다.
"당연히 이렇게 하는거 아니야?" 식의 충격적인 사례들을 너무 많이 보아왔기 때문이기도 합니다.ㅠㅠ
위첨자 <sup> 아래첨자 <sub> 사용또한 본적이 없고
svg 파일이 유행하기 시작한 이래로 <img src="*.svg /> 를 사용하는 어처구니 없는 경우 또한 수시로 발견되고..
<address><tel><small><blockquote> 이 사용된바도 본적이 없습니다.
참 직관적이고 좋은 시멘틱인데도 불구하고말이죠.
WHATWG 에서의 온프레미스는 WWW(월드와이드웹) 에서의 주요한 사항일 수는 있지만, 법을 어기는 사람이 없다면 공권력이 필요하지 않고, 계약서류상의 특약사항보다 헌법이 더 상위의 근거가 되기도 합니다. 하지만 개개인의 자유또한 보장되는것이 WWW 와 민주주의의 기본 원칙임을 고려한다면 새로운 규칙의 생성또한 "가능" 하고 조금 더 실험적이고 발전적인 코딩이 우리네의 밥줄이라는 메시지를 남기는것이 본 글의 요지 였습니다.
물론 저 또한 완전무결한 웹표준 코딩을 하지 못합니다.
@묵선웅 님의 말씀처럼 규칙을 어긋나는 태그를 생성해서 사용하기도하고, 귀찮음의 핑계로 alt, name 등을 생략하기도 합니다.
하지만 조금 더 자유롭고 크리에이티브한 코딩을 해 볼 필요는 있다 생각합니다.
"보편적 인식" 이라는 프레임을 벗어나는것을 반항이라 생각하지 마시고 "새로운 것" 을 시도할 때 본인만의 아이덴티티가 형성이 되고, 그것이 변화를 일으키게 하는 움직임이 될 수 있음을 시사하고 싶습니다!
