중국에서 WEB 표준이 지속적으로 대중화됨에 따라 구조적 성능 동작 분리, 모듈화, 의미론 및 우아한 저하와 같은 개념도 프런트 엔드 직원의 WEB 표준 이해를 평가하는 데 중요한 항목이 되었습니다. SEO 이면의 상업적 가치 중 "의미화(Semanticization)"가 큰 주목을 받았습니다. 저는 새로운 프론트엔드 작업자로서 한때 "의미화(semanticization)"가 검색 엔진에 가장 유리한 태그를 사용하여 (x) HTML 구조를 구성하는 방법이라고 믿었습니다. 무게.
선배들의 많은 프론트 엔드 책과 많은 기사를 읽은 후, 나는 내 의식의 천박함을 깨닫기 시작했고 천천히 "의미화"의 가치를 깨달았습니다. 다음 내용은 개인의 일상생활 실천을 요약한 것에 불과하며, 더 멀리 보기 위해 여러 선배들의 의견을 모아 거인의 어깨에 올라선 것입니다.
"의미론적"이란 무엇입니까?
"의미론적"이란 인간의 개입을 줄이면서 정보를 연구하고 수집하여 기계가 웹 페이지를 이해할 수 있게 만들고 궁극적으로 인간에게 도움이 되는 기계의 능력을 말합니다. 구체적으로 BI 포럼의 한 네티즌의 유명한 설명을 빌리자면 "의미론은 여자친구를 평범한 친구로 대하지 않는다는 뜻입니다." 다음은 간단한 XML 형식의 예입니다.
그러나 CSS 제어를 통해 "친구"처럼 "여자 친구"를 쉽게 표시할 수 있습니다. 프리젠테이션 레이어에만 집중한다면 레이블은 CSS와 JS가 처리하도록 제공되는 "후크"일 뿐입니다. 여전히 "의미화"를 강조하고 있으며 이에 대해서는 아래에서 자세히 설명합니다.
의미론적 의미
1. 검색 엔진
검색 엔진 최적화에 관해서는 이미 많은 선배님들께서 Hx의 무게나 숨겨진 텍스트 등에 대해 풍부한 설명을 해주셨기 때문에 여기서는 자세히 설명하지 않겠습니다. 얼마 전 Wolfram(http://www.wolframalpha)이라는 소프트웨어가 있었습니다. .com/)의 검색 엔진은 Google이 각 웹사이트의 PR 가치에 따라 검색 결과를 정렬한다는 것을 알고 있습니다. 다른 검색 엔진에도 자체적인 알고리즘이 있으며 Wolfram은 사용자 입력 내용을 "이해"한다고 주장합니다. '누가 아드리안인가'를 입력했을 때, 울프람이 그런 피드백을 주었는데, 결과는 별로 정확하지 않았다.
프론트 엔드 작업과 관련하여 우리가 존경하는 "의미론"은 컴퓨터가 우리의 콘텐츠를 이해하도록 하는 것에 관한 것이 아닙니까? <acronym title="World Wildlife Fund">WWF</acronym>과 같은 간단한 예를 통해 컴퓨터는 WWF가 세계 물 포럼이 아닌 세계 야생 동물 기금이 될 자격이 있음을 이해할 수 있습니다. 그렇습니다. Wolfram과 같은 검색 엔진은 수명이 짧을 수 있지만 그들이 추구하는 비전, 즉 세계의 지식을 계산 가능하게 만드는 것은 실제로 우리가 추구할 가치가 있는 것입니다.
2.사용자 경험
먼저 예를 들어보겠습니다. 다음은 Dangdang.com(https://login.dangdang.com/Register.aspx)의 사용자 등록 양식이며, XHTML 구조의 일부를 가로채고 있습니다.
<span class="span_n">닉네임 설정:</span>을 <label class="span_n" for="txtNickName">닉네임 설정:</label>으로 변경하면 어떤 일이 발생하는지 실험해 보겠습니다.
마우스가 "Set Nickname"을 클릭하면 ID 이름이 "txtNickName"인 텍스트 입력 상자에 자동으로 포커스가 부여됩니다. 레이블 레이블 자체의 정의는 컨트롤(http://www. w3school.com.cn/tags/tag_label.asp), 모든 주류 브라우저는 기본적으로 레이블에 대해 동일한 지원을 제공합니다. 브라우저의 양식 컨트롤 자체는 CCS 포리스트 그룹의 영웅이 테스트한 후 레이블 레이블입니다. 음성 제어 작업에도 매우 효과적입니다. 또한 매우 좋은 경험입니다.
Dangdang.com도 마찬가지입니다. 홈페이지의 제품 목록은 여전히 작은 XHTML 코드 조각입니다.
가로채는 코드는 가격 부분입니다. 클래스 이름과 관계없이 "span class="del grey s10""94.00 "/span"을 "del class="del grey s10" date="로 변경하면 실험해 보겠습니다. ” cite="”》₩94.00 《/del》 《ins》₩46.00 《/ins》, 시각적인 변화는 없지만 페이지 주위를 알몸으로 달릴 때.
결과는 명백합니다. 프론트 엔드 작업자로서 우리는 사용자의 인터넷 속도가 너무 느려서(아마도 Thunder BT를 사용하고 있을 수도 있음) CSS를 로드할 수 없는 상황과 휴대폰의 상황을 고려해야 합니다. 사용자는 적절한 태그를 선택해야 합니다. HTML에 대한 몇 가지 기본 지식만 추가하면 됩니다. 또한 콘텐츠를 WORD 2007에 복사해 보세요.
스크린리더에서는 abr 태그와 img 태그의 alt 속성이 중요한데, 조건이 허락하지 않아서 개인적으로 경험해 볼 수는 없지만 이미 508절 같은 것이 있습니다. 정부 웹사이트에서 장애인을 무시하지 않도록 보호합니다.
3. 개발 효율성
의미가 풍부한 웹 페이지 구조는 초기 개발 및 이후 버그 수정에 큰 영향을 미칩니다. 구체적으로는 다음과 같은 간단한 제품 목록 코드와 같습니다.
"의미론적" 태그를 통해 제품 목록의 "후크"가 상위 레이어에 추가되어 이상적인 조건에서 스타일 수정을 위해 제품 목록의 전역 성능이 변경되는 것을 방지할 수 있습니다. 백엔드 개발자를 통해 웹 페이지 구조를 변경하고 인건비를 절감합니다. 그러나 현실로 돌아가서 제품과 상사의 다양한 요구에 직면하여 소규모의 경우 CSS 수정만으로 스타일을 완전히 바꾸는 것은 여전히 비현실적입니다. 요구사항과 버그가 있는 경우 가장 좋은 방법은 나중에 수정하고 사용할 수 있도록 초기 개발 단계에서 페이지에 대한 "후크"를 합리적으로 예약하는 것입니다. 현재로서는 풍부한 의미 체계 태그가 매우 실용적입니다.
팀 협업을 위해 시맨틱 ID와 클래스 이름 지정을 통해 팀 내 모든 사람에게 구조를 명확하게 할 수 있습니다. 요구 사항 변경으로 인해 빨간색 클래스가 있는 레이블이 파란색으로 변경되는 것을 상상해 보면 의미 있는 이름 지정이 필요한 이유를 이해할 수 있습니다.
래스터화 및 프레임워크에 대한 과거 논의에서 우리는 명명 규칙에 대해 생각해 보았습니다. 다음은 명명 방법에 대한 논의일 뿐이며 최근에는 완전한 레이아웃 세트를 접하게 되었습니다. 대부분이 처음 접했을 때 'area_01', 'layout_01' 등 이런 네이밍에 어지러움을 느꼈던 것 같아요. 현재 팀이 맡고 있는 프로젝트의 규모가 커서 이 방법이 적절한지 확신할 수 없지만, 한 가지 확실한 것은 이로 인해 새로운 사람들의 학습 비용이 증가하고 향후 개발을 위해서는 이 방법이 적합하다고 생각합니다. 결국 그 목적도 팀의 효율성 향상과 갈등 감소이기 때문에 YUI, Blueprint, 960 Grid System이 탄생한 것이라고 생각합니다. 추측이고, 앞으로는 그것이 확증될 수 있기를 바랍니다.
4. 산업 표준
천 명의 사람을 위한 천 개의 햄릿이 있습니다. 마찬가지로 천 개의 프런트 엔드도 동일한 성능이지만 다른 구조로 천 개의 페이지를 작성할 수 있습니다. 이것이 바로 CSS를 통해 페이지 재구성의 현재 상황입니다. 그러나 가장 기본적인 HTML 구조에 주의를 기울이는 사람은 거의 없습니다. 그 이유는 HTML 태그의 의미가 부족하기 때문입니다. 그 이상의 이유는 Gui Ge가 말했듯이 "비전문가는 문을 보고, 전문가는 흥분을 본다"고 말한 것처럼 프런트 엔드 작업에 대한 무관심 때문이라고 생각합니다. 이 업계에서 변화를 만들고 싶다면 전문화가 필수입니다. 즉, 자신의 발전을 고려하지 않는다면 "의미화" 문제를 논의할 필요가 없다는 것입니다.
"의미화"의 목표는 통일된 표준을 달성하는 것입니다. 미래의 인터넷은 "개방형 인터넷이어야 합니다. 데이터가 방해받지 않고 흐를 수 없고 정보 섬이 많고 마이크로포맷이 존재하는 지금과 같지는 않을 것입니다." 모범 사례, 개방형 인터페이스 및 공유 콘텐츠에 대해서는 아래에서 자세히 설명합니다.
의미론적 연습
위 내용에는 실무적인 내용이 대부분 포함되어 있으며, 여기에 요약 소개가 있습니다.
1.문서 구조
"의미화"하는 가장 간단한 방법은 구조부터 시작하여 콘텐츠의 의미와 가장 잘 일치하는 태그를 선택하고, "HTML 및 XHTML에 대한 권위 있는 가이드"를 다시 검토하고, 단순한 내용이 아닌 콘텐츠의 의미에 대해 더 많이 생각하는 것입니다. 페이지 렌더링을 기반으로 판단합니다. 우리는 이런 상황에 직면하게 되는데, 단순한 효과를 보기 위해서는 합리적인 의미를 추구하기 위해 구현하기가 그리 쉽지 않은 해결책을 선택해야 하는 것은 아닐까? 이것은 WEB 표준에 대한 프론트엔드 작업자의 양심이자 업무에 대한 이해이기도 하다고 생각합니다. Realazy는 매우 깊은 이해를 가지고 있습니다. /29/엔지니어-대-과학자/).
사전 제작 단계에서는 콘텐츠 의미에 따라 향후 상황을 고려하고 페이지에 대한 후크를 예약할 수도 있습니다. 물론 특정 문제를 자세히 분석해야 하며, 다양한 프로젝트 요구 사항에 따라 채택된 개발은 유연하고 적응 가능해야 합니다. 예를 들어 홍보용 특별 페이지의 경우 회의의 기본 전제 하에 향후 조정의 필요성이 크지 않기 때문입니다. 사용성과 접근성을 고려하여 개발을 채택해야 합니다. 신속한 개발 모드는 디자인 초안의 효과를 복원하는 데 중점을 두지만 대규모 웹 사이트의 효과에는 요구 사항이 분명히 다릅니다.
2. 명명 규칙
ID와 클래스에 대한 표준 명명 체계는 인터넷에 수시로 등장합니다. 내용의 의미에 따라 명명하는 것이 전체적인 원칙입니다. 인터넷에서 그림을 빌려오겠습니다.
사이드바의 위치를 바꾸고 싶다면 웹페이지 구조를 바꾸지 않고 CSS만 수정하면 되는데, 자주 발생하는 페이지 모듈의 경우 개발 과정에서 머리글/바닥글 등 자신만의 네이밍 규칙을 점진적으로 만들어가는 것을 추천합니다. /main/hd/bd /nav/box/mode 등에서는 하이픈 "-" 또는 낙타 표기를 사용하여 site-nav/quick-menu/secondaryContent/와 같이 더 복잡한 이름을 형성합니다.
그러나 구체적인 상황으로 돌아가서, 다양한 프로젝트는 특정 상황에 따라 명명 방법을 선택해야 하며, 타오바오와 같은 대규모 웹사이트는 래스터화와 의미적 명명을 조합하여 사용하는 것이 더 적합합니다. 페이지의 경우 스타일 수정을 통해 신속하고 민첩하게 대응할 수 있습니다. 대부분의 선언형 단일 페이지의 경우 페이지 작성자가 페이지를 빠르고 쉽게 완성할 수 있도록 구성하는 것이 좋습니다. 이름 짓는 데 너무 많은 시간을 소비하는 대신,
3. 마이크로포맷
마이크로포맷은 표준 XHTML 코드에 구조화된 데이터를 삽입하는 새로운 방법입니다. 간단히 말해서 확립된 클래스 명명 표준 세트를 사용하여 문서의 내용을 선언합니다. 마이크로포맷에 대한 대부분의 사람들의 이해는 hCard에서 시작됩니다. 다음은 간단한 hCard 예입니다(http://www.oppenheim.com.au/). 이것은 James Oppenheim이 바닥글에 적용한 hCard입니다.
그 중 vcard url fn 주어진 이름 adr 지역 지역 클래스 이름은 모두 마이크로 형식 형식화를 위해 생성됩니다. 또한 클래스 이름을 추가하기 위해 여러 개의 범위 태그가 추가된다는 점도 알아두셔야 합니다. 그렇다면 마이크로포맷의 중요성은 무엇입니까? Firefox용 Operator 플러그인을 통해 이력서(http://adriancheng.name/resume.html)에서 명함을 내보냈습니다.
내보낸 vcf를 다양한 이메일 클라이언트에 연락처 정보로 가져오거나 휴대폰의 주소록(http://tommyfan.com/blog/skill/add_phone_from_hcard/)으로 가져올 수 있음을 마이크로포맷을 통해 확인할 수 있습니다. 다양한 클라이언트가 웹 페이지의 데이터를 처리하는 것이 편리합니다. 물론 마이크로포맷의 역할은 웹 페이지의 API와 유사합니다. 물론 다른 형식 표준의 경우에도 가능합니다. 자세한 내용은 http://microformats.org/를 참조하세요.
결론
"의미화"의 실천은 매우 간단합니다. 프론트엔드의 가장 기본적인 부분이라고 할 수 있지만, 여러 가지 이유로 오해를 받거나 무시되어 마땅한 주목을 받지 못했습니다. 이 기사는 나의 지난 단계를 정리하고, 축적된 학습을 통해 모든 독자에게 WEB 표준에 대한 생각을 줄 수 있기를 바랍니다.