웹 표준: 무엇을, 왜, 그리고 어떻게

월드 와이드 웹은 흥미로운 곳입니다.

인터넷이 성장하고 보편화됨에 따라 우리가 세상과 상호작용하는 방식의 관점에서 보면 인터넷은 거대한 변화의 도구가 되었습니다.

많은 사람들과 마찬가지로 학교에서 웹 개발에 대한 나의 소개는 다소 암울했습니다. 우리 학교 ICT(Information Computing Technology) 수업은 Dreamweaver를 플랫폼으로 사용하여 개인 웹사이트를 시각적으로 편집하는 플랫폼으로 사용하여 "하이퍼링크란 무엇인가"라는 가장 큰 교훈을 얻었습니다. 우리는 우리 웹사이트의 HTML 소스도 보지 않았습니다!

그래서 HTML과 CSS에 대한 나의 교육은 주로 웹사이트의 "소스 보기" 옵션을 어지럽히는 데서 비롯되었습니다. 나는 부트스트랩이 실제로 무엇인지 알기 전에 비트와 조각을 함께 복사하여 붙여넣어 나만의 웹사이트를 만들고 부트스트랩용 템플릿을 다운로드하는 방법을 배웠습니다.

내가 당신에게 이것을 말하는 이유는 무엇입니까?

최근에 내 Twitter 추종자를 조사한 결과(정확한 과학입니다) 많은 사람들(투표한 사람의 43%)이 Web Standards에 대해 거의 알지 못했으며 투표한 사람 중 5%만이 적극적인 기여자라는 사실을 발견했습니다.

[설문조사] 당신은 웹 개발자입니까 아니면 땜장이입니까? 이전에 웹용으로 구축한 적이 있습니까?

당신이 완전 초심자이든 전업 웹 개발자이든 관계없이 이 질문에 답하십시오. > 웹 표준에 대해 무엇을 알고 있습니까?

도달을 위한 RT

— Amy-ing for a PhD(@RedRoxProjects) 16. 2018년 11월

사람들이 웹 개발을 배우는 방식을 보면 이것이 사실일 수 있다는 것을 완전히 이해할 수 있습니다. 웹사이트 구축 방법을 배우기 위한 온라인 자습서, 부트캠프 및 온라인 리소스의 양이 늘어나면서 독학으로 웹 개발자(나와 같은)가 웹용 콘텐츠를 구축하게 되었습니다.

이것은 인터넷의 위대한 성공 중 하나입니다. 누구나 거의 모든 것을 배울 수 있습니다. 학계 외부에서 학습을 위한 리소스가 점점 더 많아지는 것은 직업으로서 웹 개발에 접근하는 장벽을 낮추는 측면에서 정말 긍정적입니다.

온라인에 무료 리소스가 있더라도 웹 개발자가 되는 방법을 배우는 데에는 여전히 많은 장벽이 있습니다. 나는 이것들이 존재하지 않는다고 말하는 것이 아닙니다. 실제로 존재합니다. 그리고 우리는 이러한 문제를 해결하기 위해 커뮤니티로서 더 많은 일을 해야 합니다.

그러나 학습 과정의 다양화와 함께 압도적인 정보 와 지식 격차 를 비롯한 여러 문제가 발생합니다.

웹 맛이 나는 것을 구축하는 방법을 배울 때 " 어떻게 구축해야 할까요? " 이렇게 하면 " 왜 이런 식으로 빌드해야 합니까? " 를 동등하게 고려하지 않을 수 있습니다. " 또는 " 물건을 만들기 위한 모든 옵션은 무엇입니까? "

결과적으로 웹 관련 문제를 해결하는 여러 가지 방법에 압도되기 쉽습니다. 이로 인해 사용 가능한 옵션 중 더 나은(가장 강력하고 접근 가능하며 안전한 측면에서) 더 나은지 여부를 고려하지 않고 인터넷 검색 결과에서 첫 번째 솔루션을 선택할 수 있습니다.

Web Standards와 Web Standards를 지원하는 문서는 월드 와이드 웹의 '왜'와 '무엇'에 대한 많은 통찰력을 제공합니다. 웹 개발자를 위한 환상적인 리소스이며 기능적이고 액세스 가능하며 상호 호환되는 웹용 기능을 구축하는 데 도움이 됩니다.

이 게시물은 웹 표준에 대해 더 알고 싶어하는 웹에 관심이 있는 모든 사람을 돕기 위해 만들어졌습니다. 우리는 다음을 다룰 것입니다:

• 웹 표준 소개(이것이 무엇이며, 왜 존재하며 누가 만드는가)
• 작업에서 표준을 탐색하고 사용하는 방법
• 새로운 표준과 기존 표준에 기여하는 데 참여할 수 있는 방법.

" 왜 웹 표준이 필요한가? "라는 질문으로 웹 표준에 대한 소개를 시작하겠습니다. "

표준 이전의 월드 와이드 웹

월드 와이드 웹은 정보 생태계라고 생각할 수 있습니다. 사람들은 웹에 제공되는 콘텐츠를 만듭니다. 그런 다음 이 콘텐츠는 사람들이 해당 정보에 액세스할 수 있도록 브라우저를 통해 전달됩니다.

Web Standards 이전에는 이 시스템의 어느 부분에도 고정된 규칙이 많지 않았습니다. 콘텐츠를 만드는 방법에 대한 공식적인 규칙이나 브라우저가 정보를 요청하는 사람들에게 해당 정보를 제공하는 방법에 대한 요구 사항이 없습니다.

그래서 웹은 다른 모양의 블록을 올바른 구멍에 분류해야 하는 어린이 장난감과 같은 방식으로 작동했습니다. 이 비유에서 다양한 유형의 브라우저는 다른 모양의 구멍이고 콘텐츠 또는 웹사이트는 밝은 색상의 블록입니다.

과거에는 콘텐츠 제작자로서 의도한 브라우저에 맞는 웹사이트를 만들었습니다. 예를 들어 Internet Explorer 구멍을 통과할 수 있도록 IE 모양의 블록을 만듭니다.

이것은 당신이 만든 이 웹사이트 블록이 그 구멍 하나에만 들어가고 다른 브라우저를 사용하여 볼 수 있도록 콘텐츠를 다른 모양으로 다시 만들어야 한다는 것을 의미했습니다.

90년대의 개발자들은 종종 그들이 구축한 모든 웹사이트의 3~4가지 버전을 만들어야 당시 사용 가능한 각 브라우저와 호환될 수 있었습니다. 더욱이 브라우저 제조업체는 경쟁을 개선하기 위해 경쟁업체와 접근 방식을 다양화하는 "기능"을 도입할 것입니다.

처음에는 콘텐츠 일치 장난감에 대한 인터넷 브라우저가 다음과 같이 보인다고 말하는 것이 더 공정했을 것입니다.

이는 브라우저가 거의 텍스트 기반 콘텐츠인 거의 동일한 내용을 처리하도록 제작되었기 때문입니다. 따라서 대부분의 경우 웹 사이트 블록은 들어갈 수 있는 구멍을 제외하고 대부분의 구멍에 맞습니다. 하지만 완벽하지는 않습니다.

브라우저가 개발되면서 기능을 추가하기 시작했고(예: 모양 변경) 각 브라우저 구멍을 통과할 블록을 만드는 것이 점점 더 어려워졌습니다. 이것은 심지어 한 번 특정 구멍에 들어갈 수 있었던 블록이 더 이상 그 구멍에 맞지 않는다는 것을 의미했습니다. 이러한 기능을 브라우저에 추가하면 역호환성이 좋지 않은 경우가 많습니다.

이것은 일부 개발자들에게 정말 피해를 입혔습니다. 호환성이 사용 가능한 각 브라우저에 대해 웹 사이트를 지속적으로 업데이트하고 리팩토링할 수 있는 콘텐츠 제작자로 제한되는 시스템을 만들었습니다. 다른 모든 사람들에게는 새로운 기능이나 버전이 출시될 때마다 웹사이트가 해당 브라우저에서 더 이상 작동하지 않을 가능성이 있었습니다.

웹 표준은 웹 생태계를 보호하고 모든 사람이 무료로 액세스할 수 있도록 개방하고 유지하기 위해 도입되었습니다. 웹을 보호 거품에 넣고 특정 브라우저에 맞는 웹 사이트를 구축해야 한다는 생각으로 해체합니다.

표준이 도입되었을 때 브라우저 제작자는 표준화된 작업 방식을 고수하도록 권장받았습니다. 결과적으로 콘텐츠 제작자는 상호 호환성이 쉬워지고 더 이상 동일한 웹 사이트의 여러 버전을 구축할 필요가 없었습니다.

참고 : 브라우저 간 상호 호환성에 대해 여전히 많은 뉘앙스가 있습니다. 표준이 도입된 지 20년이 넘은 오늘날에도 우리는 아직 "모든 것을 적용할 수 있는" 수준은 아닙니다.

다음은 웹 브라우저 개발의 역사에서 몇 가지 중요한 순간을 간략하게 살펴보겠습니다.

출처: Rhiannon Williams의 "웹 브라우저: 간략한 역사"

표준이 필요한 이유

표준의 역사와 표준이 도입된 이유에 대해 조금 알면 World Wide Web에 대한 표준의 이점을 볼 수 있습니다. 하지만 웹 표준에 계속 기여하는 것이 왜 중요한가요? 다음은 몇 가지 이유입니다.

웹을 무료로 유지하고 모두에게 액세스 가능

Web Standards 커뮤니티가 없다면 브라우저 제작자는 월드 와이드 웹의 기능이 무엇인지에 대한 결정을 내릴 것입니다. 이는 웹이 독점 상품이 되어 가장 큰 기업만이 미래에 대해 발언권을 갖게 될 수 있습니다.

소스 코드를 더 간단하게 만드는 데 도움이 됩니다. 개발 및 유지 관리 시간 단축

더 많은 브라우저가 등장하고 브라우저 제조업체가 접근 방식을 다양화하기 시작하면서 여러 브라우저에서 동일한 방식으로 제공되는 콘텐츠를 만드는 것이 점점 더 어려워졌습니다. 이것은 웹 페이지의 소스 코드를 부풀리는 것을 포함하여 완벽하게 호환되는 웹 사이트를 만드는 데 필요한 작업의 양을 늘렸습니다. 오늘날 개발자로서 우리는 여전히 [X 스크립트]를 포함하는 이상한 작업을 수행해야 하므로 [X 웹 브라우저]에서 작동하지만 Web Standard가 없으면 훨씬 더 나쁠 것입니다.

웹을 보다 쉽게 ​​접근할 수 있는 곳으로 만들기

웹 표준은 웹 사이트가 보조 기술과 상호 작용할 수 있는 방식을 표준화하는 데 도움이 됩니다. 브라우저 제조업체와 웹 개발자가 공통(또는 때로는 더 나은) 최종 사용자 경험을 유지하기 위해 보조 기술로 해석할 수 있는 지침을 페이지에 통합할 수 있음을 의미합니다.

이전 버전과의 호환성 및 검증 허용

웹 표준은 표준을 준수하는 새 웹 사이트가 이전 브라우저 버전에서 작동할 수 있도록 하는 기반을 만들었습니다. 이전 버전과의 호환성에 대한 이러한 아이디어는 웹에 액세스할 수 있도록 유지하는 데 매우 중요합니다. 이전 브라우저가 콘텐츠를 예상한 대로 정확하게 표시할 것이라고 보장하지는 않지만 웹 문서의 구조가 적절하게 이해되고 표시되도록 합니다.

더 나은 SEO(검색 엔진 최적화) 유지 지원

Web Standards가 처음 도입되었을 당시의 주요 숨겨진 이점 중 하나는 Web Standards 호환 웹 사이트가 검색 엔진에서 더 쉽게 검색할 수 있다는 것이었습니다. 이는 2000년대 초반 Google 검색이 검색 엔진 세계의 주요 업체가 되면서 더욱 분명해졌습니다.

공통 지식 풀 만들기

웹 표준이 있는 세상은 모든 개발자가 따르고 이해하고 익숙해질 수 있는 일련의 규칙이 존재하는 장소를 만듭니다. 이론적으로 이것은 한 개발자가 표준을 준수하는 웹사이트를 구축할 수 있고 다른 개발자가 큰 어려움 없이 이전에 중단한 부분을 선택할 수 있음을 의미합니다. 실제로 표준은 이에 대한 기반을 제공합니다. 그러나 이 아이디어는 잘 문서화된 코드를 작성하는 개발자에게 크게 의존합니다.

웹 표준이 되는 것은 누가 결정합니까?

표준은 사람이 만듭니다. 웹과 인터넷 공간에는 강력한 합의 문화가 존재합니다. 이는 많은 대화와 많은 토론을 의미합니다.

표준이 개발되는 그룹을 "표준 개발 조직" 또는 SDO 라고 합니다. 웹 공간의 주요 SDO에는 IETF(Internet Engineering Task Force), W3C(World Wide Web Consortium), WHATWG 및 ECMA TC39가 포함됩니다. 역사적으로 Web Standards Project(WaSP)와 같은 그룹도 조직에서 웹 표준을 채택하도록 옹호했습니다.

인터넷 및 웹 표준에서 작업하는 그룹은 일반적으로 로열티 프리 체제에서 운영됩니다. 즉, 웹 표준을 사용할 때 관련 특허를 보유한 사람처럼 누구에게도 비용을 지불할 필요가 없습니다. 웹 브라우저나 웹사이트를 구축하기 위해 누군가에게 로열티를 지불해야 한다는 생각이 지금은 터무니없게 보일 수 있지만, BT와 같은 조직이 하이퍼링크 개념의 소유권을 주장하려는 것은 그리 오래되지 않았습니다. 아래 나열된 것과 같은 표준 조직은 웹을 무료로 유지하는 데 도움이 됩니다(또는 최소한 라이선스 비용이 없음).

IETF란 무엇입니까?

IETF는 인터넷 표준 조직의 조부모입니다. TCP/IP(전송 제어 프로토콜/인터넷 프로토콜) 및 DNS(도메인 이름 시스템)와 같은 기본 인터넷 기술이 표준화된 곳입니다. IETF에서 개발된 또 다른 핵심 기술은 들어 본 적이 있는 HTTP(Hyper-Text Transport Protocol)입니다.

HTTP2의 부상과 이후의 (UDP 기반) HTTP3 개발에 주의를 기울였다면 바로 여기에서 작업이 발생합니다. IETF에서 대부분의 작업은 Open Systems Interconnection 모델의 하위 수준에 중점을 둡니다.

W3C란 무엇입니까?

W3C(World Wide Web Consortium)는 회원 조직, 정규 직원, 초청 전문가 및 대중이 함께 협력하여 웹 표준을 개발하는 국제 커뮤니티입니다. 웹 발명가이자 이사인 Tim Berners-Lee와 CEO인 Jeffrey Jaffe가 이끄는 W3C의 사명은 웹을 최대한 활용하는 것입니다.

커뮤니티는 1994년 MIT(Massachusetts Institute of Technology)에서 CERN과 공동으로 설립되었습니다. 이 게시물을 작성하는 시점에서 W3C는 475개의 회원 회사 및 조직을 보유하고 있으며 MIT(미국), ERCIM(프랑스), KEIO 대학(일본) 및 Beihang 대학(중국)의 4개 학술 기관 간의 컨소시엄으로 존재합니다.

W3C에서의 작업은 작업 그룹 과 커뮤니티 그룹 에서 발생합니다. 커뮤니티 그룹은 새로운 웹 기술을 중심으로 많은 초기 혁신이 일어나는 곳입니다. 새로운 웹 표준은 커뮤니티 그룹에서 생성할 수 있지만 공식적으로는 "사전 표준"으로 간주됩니다. 커뮤니티 그룹은 귀하가 소속되거나 소속된 조직이 W3C 회원인지 여부에 관계없이 누구나 참여할 수 있습니다.

W3C 워킹 그룹은 새로운 웹 표준이 공식적으로 만들어지는 곳입니다. 작업 그룹은 일반적으로 표준 제출로 시작하며, 종종 일부 브라우저에서는 이미 제공되고 있습니다. 그러나 이러한 표준을 개선하기 위한 기술 작업은 표준이 "W3C 권장 사항"으로 최종 승인되기 전에 이러한 그룹 내에서 발생합니다. W3C에서 무언가가 "권장" 단계에 도달할 때쯤에는 웹에서 가장 자주 구현되고 널리 사용됩니다.

워킹 그룹은 회원 조직에 소속되지 않은 사람들이 일부가 되기가 더 어렵습니다. 그러나 그룹에 초대된 전문가가 될 수 있습니다. 워킹 그룹이 더 많은 프로세스로 참여하고 운영하기가 조금 더 어려운 한 가지 이유는 W3C 워킹 그룹에 가입함으로써 조직과 회사가 W3C의 특허 정책에 명시된 로열티 프리 라이선스에 동의함으로써 그들이 지적 재산권 보유자이기도 하기 때문입니다. .

W3C 자문 위원회 위원 Natasha Rooney는 W3C 작업의 많은 부분을 설명하는 W3C Process Document for Busy People이라는 훌륭한 문서를 작성했습니다.

WHATWG는 무엇입니까?

WHATWG는 원래 W3C의 스플린터 그룹이었습니다. 일부 브라우저 공급업체가 W3C가 HTML을 추진하는 방향에 동의하지 않았기 때문에 2007년에 형성되었습니다. WHATWG는 계속해서 HTML이 개발되고 발전되는 곳입니다. 그러나 HTML 사양에 참여하는 커뮤니티에는 여전히 W3C 커뮤니티의 많은 사람들이 포함되어 있으며 WHATWG와 관련된 많은 사람들이 W3C 작업 그룹에 참여합니다.

이 게시물을 작성하는 시점에서 W3C와 WHATWG 간의 관계는 유동적입니다. 개발자의 관점에서 이는 개발자가 웹 기술이 특정 브라우저에서 사용될 수 있는 "진실"을 반영하기 위해 MDN과 같은 리소스에 의존할 수 있기 때문에 그다지 중요하지 않습니다. 그러나 특정 표준 개발에 참여할 위치가 명확하지 않은 문제가 발생했습니다. WHATWG에는 자체 로열티 프리 라이센스 계약인 WHATWG 참여 계약도 있습니다.

"왜 CG"란 무엇입니까?

웹 인큐베이터 커뮤니티 그룹(WICG, Why-CG 로 발음됨)은 W3C 내의 특별 커뮤니티 그룹으로, 여기에서 일부 새롭고 새로운 웹 기술이 논의되고 개발됩니다.

새로운 표준, 기존 표준에 대한 새로운 기능 또는 웹에 통합되어야 한다고 생각하는 새로운 기술에 대한 훌륭한 아이디어가 있는 경우, 이미 논의 중인 항목이 있는지 확인하기 위해 먼저 여기에서 확인하는 것이 좋습니다. 그렇다면 훌륭합니다! 이러한 토론에 참여하고 지원을 제공하십시오. 그렇지 않다면 제안하십시오! 그것이 바로 이 그룹을 위한 것입니다.

ECMA TC39는 무엇입니까?

Ecma는 유럽의 컴퓨터 시스템을 표준화하기 위해 1961년에 설립된 정보 통신 시스템 표준 기관입니다. 그 이름은 이전에 "유럽 컴퓨터 제조업체 협회"로 알려졌으나 1994년 조직이 전 세계적으로 출범한 이후 지금은 "Ecma International - 정보 및 통신 시스템 표준화를 위한 유럽 연합"이라고 합니다.

ECMA-262 표준은 JavaScript로 알려진 스크립팅 언어의 표준화된 사양인 ECMAScript 언어 사양을 간략하게 설명합니다. ECMA-262는 10개의 에디션이 발행되었습니다(10번째 에디션은 2018년 6월에 발행됨).

TC39(Technical Committee 39)는 JavaScript를 발전시키는 위원회입니다. 여기에 나열된 다른 그룹과 마찬가지로 그 구성원은 대부분의 주요 브라우저 제조업체를 포함하는 회사입니다. 위원회는 회원 조직에서 파견된 대표와 초청된 전문가가 참석하는 정기 회의를 갖고 있습니다. TC39는 다른 많은 그룹과 마찬가지로 합의를 달성하기 위해 운영되며, 합의된 합의는 종종 구성원에 대한 의무로 이어집니다(구성원 조직이 구현해야 하는 미래 기능 측면에서). TC39 프로세스에는 일련의 단계를 통한 제안 가속화가 포함되며, 한 단계에서 다음 단계로의 제안 진행은 위원회의 승인을 받아야 합니다.

웹 표준 프로젝트란 무엇입니까?

Web Standards Project는 1998년에 90년대 브라우저 간에 발생한 기능 대결에 대한 저항으로 형성되었습니다. 브라우저 제조업체가 W3C에서 제시한 표준을 준수하도록 하는 것이 주요 목표입니다.

조직이 성장하고 브라우저 전쟁이 끝나자 프로젝트의 초점이 바뀌기 시작했습니다. 이 그룹은 표준 지원을 개선하기 위해 브라우저 제조업체와 협력하고, 웹사이트 제작을 위한 도구를 만든 소프트웨어 제조업체에 컨설팅하고, 웹 디자이너와 개발자에게 웹 표준의 중요성에 대해 교육하기 시작했습니다. 이 요점 중 마지막으로 InterAct 웹 커리큘럼 프레임워크가 생성되었으며 현재 W3C에서 유지 관리하고 있습니다.

Web Standards Project는 2013년에 중단되었습니다. 프로젝트의 구성원과 지지자들의 노고에 감사하는 마지막 블로그 게시물이 3월 1일에 작성되었습니다. 이 게시물의 끝맺는 말에서 독자들은 웹 표준 프로젝트의 작업이 완전히 끝난 것이 아니며 웹이 자유롭고 개방적이며 상호간에 유지되도록 계속 신경을 쓰는 수천 명의 개발자에게 책임이 있음을 상기시킵니다. 작동 가능하고 접근 가능한 자원.

웹 표준이 되는 방법은 무엇입니까?

그렇다면 표준은 어떻게 만들어지는가? 짧은 대답은 많은 토론을 통해 얻을 수 있습니다.

새로운 표준에 대한 제안은 일반적으로 커뮤니티 그룹(특히 W3C의 경우) 또는 관련 GitHub 저장소에서 제기된 문제를 통해 토론으로 시작됩니다.

서로 다른 SDO에 걸쳐 상승이라는 공통 주제가 있는 것 같습니다. 토론이 시작된 후에는 조직 내로 이동하고 각 수준에서 결정 위원회는 해당 토론의 승격을 승인하기 위해 합의에 도달해야 합니다. 이것은 토론이 제안이 될 때까지 반복되고, 그 제안이 초안이 되고 초안이 공식 표준이 됩니다.

이제 이전에 언급했듯이 공식 표준이 아닌 것이 일부 브라우저에서 사용되지 않는다는 의미는 아닙니다. 사실 어떤 것이 표준이 될 때쯤이면 이미 사용 가능한 많은 브라우저에서 널리 사용되고 있을 것입니다. 이 경우 표준의 역할은 새로운 기능에 대한 정규화 및 채택 프로세스의 일부입니다. 무엇인가에 대한 예상 용도를 설명한 다음 브라우저 제조업체와 개발자가 이 기대치를 준수할 수 있는 방법을 설명합니다.

TPAC이란 무엇입니까?

W3C는 매년 1회의 대규모 행사를 개최합니다. 일주일 간의 다중 그룹 회의는 수요일에 1일 간의 회의가 없는 회의(기술 총회)와 자문 위원회(모든 조직에 대해 한 사람으로 구성된 그룹) 회의가 결합됩니다. 또는 W3C 회원인 회사). 기술 총회와 자문 위원회를 합치면 TPAC(종종 tee-pac 으로 발음됨)를 얻을 수 있습니다. W3C에서 운영하는 이벤트이지만 WHATWG, IETF 또는 TC39에서 "출처"하는 사람들도 종종 볼 수 있습니다.

올해는 삼성인터넷인들이 모여 TPAC에 참여했습니다. 우리는 또한 잘 대표되지 않는 그룹의 사람들을 TPAC 및 Web Standards 커뮤니티로 데려오기 위한 다양성 장학금을 후원했습니다.

나의 첫 TPAC

팀이 TPAC에 대해 이야기하는 것을 처음 들었을 때 나는 무엇을 기대해야 할지 몰랐습니다. TPAC 웹사이트에서 이벤트에 대한 정보를 읽은 후 등록을 하고 여행을 예약했습니다. 얼마 지나지 않아 나는 팀과 함께 런던에서 리옹으로 가는 기차를 탔습니다.

도착하자마자 나는 내 끈과 모든 행동이 일어나고 있는 다양한 방의 지도를 받았습니다. 참석한 3일 동안 내 목표는 가능한 한 많은 접근성 유형의 것들에 참여하는 것이 었습니다. 첫 날 일이 시작된 지 얼마 되지 않아 도착한 나는 내가 앉고 싶은 접근성 지침 워킹 그룹의 닫힌 문을 바라보고 서 있었습니다. 그 순간 많은 일들이 머릿속을 스쳐지나갔다. "쉬는 시간까지 기다려야 할까요?" "아니, 바보짓 하지마, 아직 한 시간이나 남았어." “노크해야 하지 않을까?” "하지만 그냥 들어가는 것보다 방해가 되지 않을까요?" "아마 나는 아예 들어가지 말아야 할지도..." 하지만 몇 분 후에 나는 용기를 내서 방으로 걸어 들어갔다.

사람들이 랩톱으로 테이블에 앉아있는 둥근 테이블이 설정되었습니다 (이 세션의 많은 부분에서 일반적입니다). 사람들이 좀 더 관찰적인 역할에 참여할 수 있도록 방 가장자리 주위에 배치된 여러 좌석과 함께. 각 그룹은 또한 W3C 회원이라면 누구나 참여할 수 있는 IRC의 채팅방을 가지고 있었습니다(TPAC에 직접 참석 여부에 관계없이). 나는 테이블 중 하나의 끝에 앉았다. 그것이 에티켓의 관점에서 하는 것이 적절한 것인지 여부는 아직 확실하지 않습니다.

처음에는 공연장 밖에 있는 거대한 곰 동상만큼 내 존재가 눈에 띄지 않을까 걱정했다. 그러나 그 방에 아무도 나의 도착에 대해 신경을 쓰지 않았고 그래서 토론은 계속되었습니다. 그룹은 Silver Task Force에서 수행 중인 작업에 대한 업데이트를 수신하는 단계로 넘어가려고 했습니다. 접근성 표준 자체를 보다 쉽게 ​​접근할 수 있도록 하려는 커뮤니티 그룹입니다.

이러한 토론을 위해 테이블에 앉는 것은 정말 흥미로웠습니다. 처음 참석하는 동안 일부 언어에 익숙해지는 데 시간이 걸렸습니다('준수' 및 '규범'과 같은 용어). 접근성을 중요하게 생각하는 사람들로 가득 찬 방 안에 있는 것이 매우 좋았습니다. 이 작업 그룹의 많은 참석자는 접근성 요구 사항이 있는 웹 사용 측면에서 실제 경험의 입장에서 말했습니다. 지난 3년 동안 디지털 음악 기술의 접근성 요구 사항을 조사한 결과, 이 그룹의 구성원들이 제기한 질문을 들으며 매우 편안했습니다.

이 첫 번째 토론에서 Silver Task Force가 선보인 작업은 저에게 정말 흥미를 불러일으켰습니다. 표준을 일반적으로 더 쉽게 접근할 수 있도록 만들고 더 쉽게 탐색하고 더 맞춤화된 조언과 안내를 제공하는 방식으로 구성하는 방법에 대한 상당히 신선한 관점처럼 느껴졌습니다. 다음 며칠 동안 저는 이 (훨씬 작은) 그룹에 합류하여 대화에 참여할 기회를 가졌습니다. 이는 정말 긍정적이었습니다. TPAC 이후로 Silver Task Force의 커뮤니티 그룹에 합류했으며 새해에는 주간 모임에 참여할 계획입니다.

TPAC의 좋은 점 중 하나(워킹 그룹의 의장이 아니거나 일종의 주도적인 역할을 하는 사람들을 위한)는 세션에 들락날락할 수 있다는 것입니다. TPAC에 있는 며칠 동안 참석한 것 중에는 Web Incubator 커뮤니티 그룹(WICG)의 세션, 저명한 커뮤니티 구성원의 대화 및 새로운 웹 기술 시연이 있는 개발자 모임, 그리고 Diversity가 있었습니다. W3C 회의 포함. Samsung Internet 팀과 함께 TPAC에 갔을 때 추가 보너스는 한국에 기반을 둔 우리 팀의 사람들과 미국의 다른 Samsung 팀원들을 만날 수 있다는 것이었습니다.

작업에서 웹 표준을 사용하는 방법

이제 웹 표준의 이유와 이유를 알았으니 작업에서 웹 표준을 사용하는 방법은 무엇입니까?

Mozilla 개발자 네트워크 웹 문서(MDN 웹 문서)

우리(삼성 인터넷 팀)는 특정 웹 표준이나 기술에 대해 더 알고 싶다면 MDN(Mozilla 개발자 네트워크) 웹 문서로 시작하는 것이 좋습니다. MDN WebDocs는 Mozilla 프로젝트로 시작했지만 최근에는 웹 개발자가 웹 플랫폼 기술에 대한 브라우저 간 문서를 찾는 곳이 되었습니다.

작년에 삼성은 Bocoup, Google, Microsoft 및 W3C와 함께 MDN WebDocs 제품 자문 위원회를 구성하여 MDN이 이 위치를 유지할 수 있도록 했습니다.

MDN에서 기술을 검색하면 브라우저 지원이 무엇인지 알려주는 브라우저 호환성 매트릭스가 표시됩니다. 또한 가장 관련성이 높고 최신 버전의 표준에 대한 링크를 찾을 수 있습니다. 표준에 대한 링크를 따라가면 해당 표준 및 해당 기술 사양을 설명하는 관련 웹 페이지로 이동합니다. 이 페이지는 구조가 다소 '학문적'이기 때문에 처음에는 다소 압도적일 수 있습니다.

문서 탐색에 대한 몇 가지 팁을 제공하기 위해 가장 친숙한 표준인 W3C 웹 콘텐츠 접근성 지침(2.1)을 살펴보겠습니다.

이것은 W3C 웹 표준의 형식입니다. 페이지 왼쪽에 목차가 있으며 내용은 버전, 보고서 및 편집자 세부 정보로 시작하는 매우 구조화된 헤더로 구성되어 있습니다. 표준의 이러한 헤더는 종종 표준의 관련 부분을 인용 하는 데 사용됩니다. 그러나 하드 디스크의 영숫자 메모리가 없는 사람들을 위해 두려워하지 마십시오. 이러한 사항을 반드시 알아야 하는 것은 아닙니다.

웹 표준 탐색에 대한 첫 번째 조언은 이러한 표준에 압도되지 않도록 하는 것입니다. 저처럼 비학문적 경로를 통해 웹 개발에 입문했다면 이러한 문서의 구조가 처음에는 매우 형식적으로 보일 수 있으며 언어도 그렇게 느낄 수 있습니다. 이것이 이것을 정보 소스로 사용하지 않는 이유가 되지 않도록 하십시오. 솔직히 말해서 웹이 작동하는 방식과 이유를 찾는 데 사용할 수 있는 가장 좋은 정보 소스이기 때문입니다.

다음은 웹 표준 작업을 위한 몇 가지 빠른 팁입니다.

• TL;DR 버전
  첫째, 웹 표준에 대한 TL;DR이 없다는 것을 이해하는 것이 중요합니다. 이렇게 길고 포괄적인 문서인 이유는 반드시 있어야 하기 때문입니다. 우리가 웹 개발에 대해 기대하는 구조와 기대에 관해서는 돌이킬 수없는 돌이 없습니다. 그러나 (프로 팁과 정보 압도를 피하는 방법) 표준의 개요부터 시작하여 소개 문서에 대한 링크를 따라가는 것입니다. 내 예에서 WCAG 2.1 표준 문서는 웹 콘텐츠 접근성 지침 개요에 대한 다른 링크된 페이지로 안내합니다. WCAG 2를 충족하는 방법에 대한 빠른 참조 가이드를 포함하여 다양한 유용한 문서를 제공합니다.

• 용어집을 활용하라
  이것은 웹 표준의 맥락에서 단어와 구의 정확한 의미를 이해하는 데 도움이 됩니다. 현실을 직시하자; 여러 의미를 가진 용어가 너무 많습니다. 용어집을 확인하면 보다 학술적인 용어를 탐색하는 데 도움이 됩니다.

• '페이지에서 찾기'는 당신의 친구입니다
  개요에 익숙해지고 웹 표준 내에서 사용되는 용어에 대한 아이디어를 얻었으면 필요한 정보에 대한 문서 검색을 시작할 수 있습니다. 웹 표준은 다양한 방식으로 사용할 수 있도록 설계되었습니다. 포괄적인 이해를 얻으려면 처음부터 끝까지 읽는 것이 좋습니다. however, you can also drop in and out of the sections as you require them. The good folks creating web standards have made efforts to ensure that referential content is linked to the source and any helpful resources are also included, which helps support the kind of “on demand” usage that is common. Take this example from WCAG 2.1:

• If you're not sure — ask!
  This community is put together from a bunch of people who care and have an investment in the future of web technologies. If you want to make sure you are adhering to Web Standards but maybe have got caught up in a language barrier, and you're struggling to interpret what is meant by a phrase within a web standard, there are many folks out there that can help. You can raise issues through the W3C GitHub repositories for the W3C Web Standards or join the conversations about Web Standards through the suggested resources on the participate section of the W3C website.

어떻게 참여합니까?

So, now that you know how to read up on your standards, what about getting involved?

Well, here are a few places to start:

• GitHub repositories for standards
  The WC3, TC39, WhatWG and WICG all have organizations on GitHub that contain repositories for the work they are doing. Be sure to check in on the READme, contribution guidelines and code of conduct (if there is one) before you begin. Use the issues of a repository to look at what is currently being discussed in terms of future developments for the standard it relates to.
• The W3C website
  Here you can look at all the working groups, community groups, and forums. It is a great place to start; if you join the organization and become a member of a community group or working group you'll be invited to the ongoing discussions, meetings, and events for that group.
• The WhatWG website
  For all things WhatWG. Here there are guides on how to participate, FAQs, links to the GitHub repositories and a blog that is maintained by members of the WhatWG.
• The WICG website
  Whilst the Web Incubator Community Group can be found from the W3C website, they are worth a separate shout-out here as they have their own web community page and Discourse instance. (For those of you not familiar with Discourse, it allows communities to create and maintain forums for discussion.)
• The TC39 standard
  This is pretty comprehensive and includes links to the ways in which you can to contribute to the standard.
• Speak to Developer Advocates
  Many Web Developer Advocates are members of an SDO or known to be working on standards; teams like ours (the Samsung Internet Developer Advocates) are often involved in the work of Web Standards and happy to talk to developers that are interested in them. After all, standards have a huge impact on the future of the web and in turn the work that we do. So, depending on the web standard that interests you, you'll be able to find folks like us (who are part of the work for those standards) through social media spaces like Twitter or Mastodon.

읽어 주셔서 감사합니다! Remember that web standards impact everyone that builds or consumes websites, so the work of Web Standards is something we should all care about.

If you want to chat more about web standards, accessibility on the web, web audio or open-source adventures — you can find me on Twitter and I'm also on Mastodon.

A huge thanks to Daniel Appelquist, who helped bring this article together.