▲GN⁺ 8달전 | parent | ★ favorite | on: HTML 스펙에서 XSLT 언급 제거 제안(github.com/whatwg)Hacker News 의견 몇 가지 주목할 점이 있음 이번 결정은 Chrome만의 단독 행동이 아니며, 이슈 트래킹과 관련 표준 회의 기록에서 모든 주요 브라우저의 대표자들이 지지 의사를 보임을 확인할 수 있음 최근 안건 역시 Mozilla 엔지니어가 제안함 PR 제출이 바로 머지된다는 의미는 아니며, 체크되지 않은 과제들도 꽤 남아 있음 하지만 여러 브라우저 벤더가 동의하는 상황에서 머지될 가능성이 높음 XSLT를 웹 플랫폼에서 제거할지 고민하는 이슈는 커뮤니티 의견 수렴을 위한 게 아닌 HTML 스펙 유지보수자들을 위한 논의 이슈임 이 이슈는 Chrome 엔지니어가 올렸지만, Mozilla 엔지니어들이 여러 차례 이 주제를 회의에서 제기했고 이미 벤더 합의가 있었다는 점이 큼 심각한 보안 취약점이 발견된 바 있음 libxslt의 메인테이너도 직접 사임했음 Chrome이라는 단어를 제목에서 빼줬음 원래 제출된 제목은 "Chrome intends to remove XSLT from the HTML spec"였음 Chrome의 텔레메트리 데이터에 따르면 실제로 XSLT를 사용하는 웹사이트가 거의 없음 제안으로 인해 전체 웹에 큰 영향이 있는 건 아니란 점을 최소한 데이터로 확인 가능함 과거 Mozilla와 Google(Chrome팀)에서 근무했던 개발자임 Chrome/Blink, Safari/Webkit, Firefox/Gecko 모두 XSLT 제거를 지지하는 건 알겠지만, 두 프로젝트는 자원이 부족하고, 한 곳은 새로운 기능을 무리하게 밀어넣는 경향이 강함 사파리와 파이어폭스 개발자가 이런 변화를 반길 이유도 있음 중요한 건 '권위 있는 사람들이 좋은 생각이라 생각하는가'가 아니라, '이 아이디어가 웹 플랫폼과 수십억 사용자에게 부정적인 영향을 줄 것인가'임 수십억 명 중 0.1%만 의존해도 상당한 규모임 아무도 쓰지 않으면 polyfill이 존재할 이유도 없음 만약 새로운 기능을 추가하려면 반드시 기존 기능을 없애야 하는 제로섬 게임으로 몰고 가는 것은 바람직하지 않음 구글은 충분한 자본과 인력이 있음에도 XSLT 지원을 일부러 안 하기로 선택하는 것임 여러 벤더가 동의한다고 해서 즉시 추진되는 사례가 종종 있었음 confirm/prompt 제거도 그랬으나 결국 무기한 보류됨 구글에서 공식적으로 제휴된 기능 제거 프로세스 문서가 있음 Google feature removal doc "벤더 단독 지지"가 실제 사용 현황을 제대로 검토하지 않았음 내가 읽은 두 스레드를 보면 구글이 피드백을 요청했는데, 피드백은 거의 다 "하지 말라"였음 하지만 구글은 "의견 고마워, 그래도 할게!"라는 반응을 보였음 만약 이슈가 보안 때문이라면, 오픈소스에 지원을 하거나, 더 안전한 라이브러리로 교체하거나, JS 샌드박스 내에서 유지 등 다양한 대안이 있었지만 대부분 무시당함 XSLT 3.0 같은 최신 버전 지원 요청도 꾸준히 있었으나 반영되지 않았음 XSLT는 오픈 웹을 지지하는 기술임에도, 구글은 10년 전부터 지원을 줄이고 방치하며 점유율 하락을 이유로 제거 시도를 지속해왔음 최근 XSLT가 다시 인기를 얻고 있는 시점에, 오픈 경쟁자 등장 전에 죽이려는 의도가 느껴짐 관련 이슈 많은 피드백이 "하지 마라"였다는 주장에 대해, 해당 스레드는 악의적 댓글, 비방 등으로 일찍 잠겼음 "이건 좋은 생각"이라는 의견은 평소 잘 달리지 않아서 반대 의견만 많은 것처럼 보일 수 있음 모두가 극단적인 언행을 해서 토론이 정리된 것이고, 스스로 자초한 일임 만약 "하지 마세요"라는 의견들이 실사용자거나 꼭 필요한 이유를 설명할 수 없다면, 개발팀이 무시하는 것은 합리적임 피드백 요청은 단순 찬반투표가 아님 XSLT 3.0을 JS/wasm 샌드박스로 옮겨 지원할 수만 있다면 좋겠음 약간의 성능 저하는 있겠지만, 양쪽 장점을 모두 취할 수 있음 XML에는 버전 관리 스키마, 네임스페이스 등 특성상 통합이 비교적 수월함 Angular 같은 js 프레임워크와 달리 신뢰성 높은 데이터 계약이 가능함 XML 패밀리의 성숙함 덕분에 전문 툴이 많아, 실제로는 XML/XSD를 텍스트로 직접 다루지 않아도 됨 구글은 "질문 형"으로 웹에 무슨 일이 벌어질지 미리 알려주는 식임 이전 관련 스레드 소개 XSLT 제거 주제 스레드 XSLT - 웹을 위한 네이티브, 제로 설정 빌드 시스템 관련 이슈로 플래그 처리된 다른 스레드도 있음 Google is killing the open web, today 브라우저가 특정 템플릿 엔진(XSLT)에 내장 지원을 할 필요가 있는지 의문임 Jinja 같은 텍스트 엔진이 아닌데, JS/wasm으로 재구현도 가능함 지금 브라우저들은 너무 무겁고, 신규 엔진 개발이 힘듦 "미니멀 브라우저"를 위한 더 간단한 표준(기본 태그, 레이아웃 등)만 있었으면 함 WebAudio, Canvas 등도 wasm 모듈로 구현 가능함(그리고 이렇게 하면 핑거프린팅도 방지할 수 있음) XSLT는 (특정 엔진이 아닌) 템플릿 엔진에 대한 "스펙"임, 다양한 구현체가 존재함 Mozilla는 libxslt 대신 transformiix 사용 Jinja는 단순 텍스트 작업이고, XSLT는 노드 레벨에 작동해서 훨씬 우수함 JS 변환은 XSLT 네이티브 변환보다 훨씬 느리고, 결과 캐싱도 어려움 XSLT를 구식 취급하는 시각을 나도 이해는 하지만, 지난 20년간 성능 면에서 비밀 병기로 잘 써왔음 구글은 결국 AMP 같은 대안으로 문제를 덮으려 들 가능성 높음 브라우저가 무거운 건 구글 탓임 XSLT는 언어(spec)이지 엔진이 아님 JS/wasm으로의 구현 변경은 내부 구현 문제이지, 언어를 웹 플랫폼에서 없앨 때 일어나는 일은 아님 오디오나 캔버스는 브라우저의 근본적인 I/O 기능임, wasm으로 옮기면 성능과 호환에 심각한 문제 발생 오디오의 일부는 wasm blob으로 옮길 수 있겠지만, 전체를 이전하는 건 힘듦 캔버스 컨텍스트나 WebGL 등은 GPU와의 직접 통합이 핵심이라 wasm으로 실현 불가임 결국 이런 기능들은 사실상 이미 기본 원시 API라서, 양보할 수 없는 영역임 낡은 XSLT 코드를 wasm으로 패키징해서 구버전 사이트 깨짐 없이 호환할 아이디어도 논의됨 실제로도 내부적으로 검토했지만 하지 않기로 결정함 아주 소수만 사용하는 웹과 거리가 먼 기능은 제거 대상이 될 수 있다고 생각함 하지만 보안 취약점을 명분으로 삼는 것은 찬성하지 않음 메모리 세이프 패키지 유무조차 확인하지 않은 상태에선 설득력이 떨어짐 실제 사용률이 0.001% 수준이라는 주장 있음 HTML 스펙의 기본 약속을 깨는 일은 굉장히 중대한 사안임 논의가 이 점을 깊이 다루지 않는 게 오히려 놀라움 HTML은 "이건 HTML이야. 신뢰해도 돼"라는 약속이었지만, 이제는 "지금만 HTML일 뿐, 앞으로도 그렇다는 보장은 없어"가 됨 XSLT 제거 논리라면 다른 오래된 기술들도 계속 잘릴 수 있음 결국 웹의 '롱테일'을 끊어내겠다는 제안임 향후 추가된 각종 웹 기술이 또 롱테일이 되어 더 많은 제거 대상이 생길 것이란 점도 고민 필요함 오래된 미디어와 소프트웨어 지원 관련해선 언젠가는 이식, 에뮬레이션, 아카이브 등으로 해결할 시기가 온다고 봄 변화에 대비할 충분한 시간과 도구 제공과 점진적 복잡성 누적을 피하는 균형이 필요함 실제 PR에서 삭제된 부분을 보면 HTML에 XSLT 지원을 요구하는 명시적 규정은 없어 보임 단순히 브라우저 지원 문제에 대한 반응이 크다는 점 정도임 PR 자체는 의외로 짧음 WHATWG가 HTML을 "Living Standard"(살아있는 표준)로 규정하면서, 실질적으론 더 이상 구현 표준이 아니라 브라우저 벤더들이 현재 작업 중인 상태를 공유하는 역할임 그래서 HTML5 같은 버전 표기도 없애고, 오로지 "HTML"만 쓰게 됨 Living Standard FAQ HTML standard FAQ 아이러니하게도 HTML/CSS/브라우저 스펙에 엄청난 양의 기능을 밀어넣은 대표적인 것도 바로 Google임 만약 구글이 "브라우저는 가벼워야 하며 이상한 것들은 JS 라이브러리에 맡기는 게 맞다"를 일관되게 옹호했다면 이번 조치도 이해할 만했겠지만, 전혀 그렇지 않음 FTP 지원 제거 이후부터 XSL의 운명은 이미 예견됨 브라우저들은 공격 표면 축소를 최우선으로 삼는 경향이 있음 다음 제거 후보는 SVG SMIL 애니메이션 속성, MathML 등 XML 관련 기능이 될 것 같단 생각임 관련 스레드 SMIL은 특정 애니메이션 시작/종료 타이밍을 기반으로 순차적 애니메이션 제어를 할 수 있는데, CSS 애니메이션은 아직 이 부분이 부족함 CSS는 계산을 이용한 타이밍 외엔 방법이 없음 Chromium도 한때 SMIL 제거 의지를 밝힌 적 있으나, CSS가 충분하지 않았기 때문에 너무 성급했었음 그 여파로 SMIL 관련 각종 안내문 등이 업데이트 없이 방치됨 공격 표면을 줄이는 것이 과연 좋은 것인지 나쁜 것인지 질문하고 싶음 기술자들과 일반 사용자가 우선순위가 다르긴 함 FTP 기능 제거가 언제 이루어진 것인지 궁금함 아직 주소창에서 ftp://로 접속이 되는 것으로 알고 있음 Blink와 WebKit의 XSLT 구현은 매우 비효율적임 전체 문서를 문자열로 바꿨다 다시 파싱하는 형태라서, 사용자 공간 라이브러리도 충분히 비슷한 성능을 낼 수 있을 듯함 Chromium XSLT 구현 예시1 Chromium XSLT 구현 예시2 Webkit XSLTProcessor 구현 Mozilla는 자체 구현(xslt 엔진)을 씀 호환성 문제는 MathML처럼 외부 개발자가 각 브라우저별 구현을 기여하는 접근이 대안일 듯함 이번 결정이 아쉽지만, 더 현대적인 XSLT 통합에 노력을 쏟지 않은 게 더 안타까움 사용은 불편했지만 브라우저에서 조금만 더 진화했다면 React 같은 프레임워크에 필적할 경쟁자가 될 수도 있었음 XML은 대기업의 복잡성만 없었다면 표준 자체는 매우 강력하고, 멋진 기술이었음 XSLT를 활용해 작고 간단한 xml/데이터를 html로 바로 변환하는 게 정말 좋았음 선택된 항목만 다르게 표시하는 작은 기능만 추가됐다면 정적 문서까지 다양한 활용이 가능했을 것으로 아쉬움 @whatwg가 토론이 "과열됐다"며 해당 이슈를 협업자 한정으로 잠갔다고 함 보기엔 꽤 합리적이고 차분했는데, 특정 벤더에 우호적이냐에 따라 ‘과열’의 기준이 달라지는 건 아닐까 싶음 "과열됐다"는 표현은 종종 반대 의견을 다루기 싫다는 뜻으로 해석됨 Reddit 등 다른 커뮤니티도 마찬가지임 실제로 그 아래 남아있는 1개의 댓글은 Google Chrome 소속 개발자가 "좋은 일 하셨다"고 남긴 것 약간 보기 민망한 느낌임 이슈 트래커에 문제 제기성 욕설, 음모론, 정치적 메시지 등 쏟아진 사례를 언급함 이런 식이면 생산적 논의 자체가 불가능해지며, 저장소 관리자들이 신속하게 토론을 막을 수밖에 없음 해당 저장소의 토론 잠금 조치는 실은 Apple 직원이 내린 것이라고 들었음 하지만 사람들은 이 이슈를 제기한 Google 직원의 책임으로 돌린다 함 구글이 최근 커뮤니티 의견 수렴을 내세워 열린 토론을 했지만, 그 후 모든 의견을 무시하고 관철시키려 하고 있음 관련 이슈 구식 웹 요소에 관한 전반적 고민이 필요함 내 경우 예전 웹페이지도 계속 제대로 작동해서 얻는 가치가 큼 HTML/JS가 호환성 지켜온 덕분에 수십 년 된 페이지조차 TLS 인증서만 붙이면 여전히 정상임 하지만 모든 유산 기술을 영원히 지원할 수는 없는 일이기도 함 Flash도 결국 에뮬레이터(Ruffle)를 통해 추억의 게임이나 사이트를 경험하는 식으로 넘어갔음 장기적으로는 구형 렌더링에 특화된 전용 브라우저나 에뮬레이터 사용도 대안이 될 수 있음 이미 이를 위한 XSLT polyfill 확장이 생겼음 Chrome은 이를 공식 배송하거나 유지보수하기를 원하지 않음 Ruffle과 매우 유사한 상황임
Hacker News 의견
몇 가지 주목할 점이 있음
이번 결정은 Chrome만의 단독 행동이 아니며, 이슈 트래킹과 관련 표준 회의 기록에서 모든 주요 브라우저의 대표자들이 지지 의사를 보임을 확인할 수 있음
최근 안건 역시 Mozilla 엔지니어가 제안함
PR 제출이 바로 머지된다는 의미는 아니며, 체크되지 않은 과제들도 꽤 남아 있음
하지만 여러 브라우저 벤더가 동의하는 상황에서 머지될 가능성이 높음
XSLT를 웹 플랫폼에서 제거할지 고민하는 이슈는 커뮤니티 의견 수렴을 위한 게 아닌 HTML 스펙 유지보수자들을 위한 논의 이슈임
이 이슈는 Chrome 엔지니어가 올렸지만, Mozilla 엔지니어들이 여러 차례 이 주제를 회의에서 제기했고 이미 벤더 합의가 있었다는 점이 큼
심각한 보안 취약점이 발견된 바 있음
libxslt의 메인테이너도 직접 사임했음
Chrome이라는 단어를 제목에서 빼줬음
원래 제출된 제목은 "Chrome intends to remove XSLT from the HTML spec"였음
Chrome의 텔레메트리 데이터에 따르면 실제로 XSLT를 사용하는 웹사이트가 거의 없음
제안으로 인해 전체 웹에 큰 영향이 있는 건 아니란 점을 최소한 데이터로 확인 가능함
과거 Mozilla와 Google(Chrome팀)에서 근무했던 개발자임
Chrome/Blink, Safari/Webkit, Firefox/Gecko 모두 XSLT 제거를 지지하는 건 알겠지만, 두 프로젝트는 자원이 부족하고, 한 곳은 새로운 기능을 무리하게 밀어넣는 경향이 강함
사파리와 파이어폭스 개발자가 이런 변화를 반길 이유도 있음
중요한 건 '권위 있는 사람들이 좋은 생각이라 생각하는가'가 아니라, '이 아이디어가 웹 플랫폼과 수십억 사용자에게 부정적인 영향을 줄 것인가'임
수십억 명 중 0.1%만 의존해도 상당한 규모임
아무도 쓰지 않으면 polyfill이 존재할 이유도 없음
만약 새로운 기능을 추가하려면 반드시 기존 기능을 없애야 하는 제로섬 게임으로 몰고 가는 것은 바람직하지 않음
구글은 충분한 자본과 인력이 있음에도 XSLT 지원을 일부러 안 하기로 선택하는 것임
여러 벤더가 동의한다고 해서 즉시 추진되는 사례가 종종 있었음
confirm/prompt 제거도 그랬으나 결국 무기한 보류됨
구글에서 공식적으로 제휴된 기능 제거 프로세스 문서가 있음
Google feature removal doc
"벤더 단독 지지"가 실제 사용 현황을 제대로 검토하지 않았음
내가 읽은 두 스레드를 보면 구글이 피드백을 요청했는데, 피드백은 거의 다 "하지 말라"였음
하지만 구글은 "의견 고마워, 그래도 할게!"라는 반응을 보였음
만약 이슈가 보안 때문이라면, 오픈소스에 지원을 하거나, 더 안전한 라이브러리로 교체하거나, JS 샌드박스 내에서 유지 등 다양한 대안이 있었지만 대부분 무시당함
XSLT 3.0 같은 최신 버전 지원 요청도 꾸준히 있었으나 반영되지 않았음
XSLT는 오픈 웹을 지지하는 기술임에도, 구글은 10년 전부터 지원을 줄이고 방치하며 점유율 하락을 이유로 제거 시도를 지속해왔음
최근 XSLT가 다시 인기를 얻고 있는 시점에, 오픈 경쟁자 등장 전에 죽이려는 의도가 느껴짐
관련 이슈
많은 피드백이 "하지 마라"였다는 주장에 대해, 해당 스레드는 악의적 댓글, 비방 등으로 일찍 잠겼음
"이건 좋은 생각"이라는 의견은 평소 잘 달리지 않아서 반대 의견만 많은 것처럼 보일 수 있음
모두가 극단적인 언행을 해서 토론이 정리된 것이고, 스스로 자초한 일임
만약 "하지 마세요"라는 의견들이 실사용자거나 꼭 필요한 이유를 설명할 수 없다면, 개발팀이 무시하는 것은 합리적임
피드백 요청은 단순 찬반투표가 아님
XSLT 3.0을 JS/wasm 샌드박스로 옮겨 지원할 수만 있다면 좋겠음
약간의 성능 저하는 있겠지만, 양쪽 장점을 모두 취할 수 있음
XML에는 버전 관리 스키마, 네임스페이스 등 특성상 통합이 비교적 수월함
Angular 같은 js 프레임워크와 달리 신뢰성 높은 데이터 계약이 가능함
XML 패밀리의 성숙함 덕분에 전문 툴이 많아, 실제로는 XML/XSD를 텍스트로 직접 다루지 않아도 됨
구글은 "질문 형"으로 웹에 무슨 일이 벌어질지 미리 알려주는 식임
이전 관련 스레드 소개
XSLT 제거 주제 스레드
XSLT - 웹을 위한 네이티브, 제로 설정 빌드 시스템
관련 이슈로 플래그 처리된 다른 스레드도 있음
Google is killing the open web, today
브라우저가 특정 템플릿 엔진(XSLT)에 내장 지원을 할 필요가 있는지 의문임
Jinja 같은 텍스트 엔진이 아닌데, JS/wasm으로 재구현도 가능함
지금 브라우저들은 너무 무겁고, 신규 엔진 개발이 힘듦
"미니멀 브라우저"를 위한 더 간단한 표준(기본 태그, 레이아웃 등)만 있었으면 함
WebAudio, Canvas 등도 wasm 모듈로 구현 가능함(그리고 이렇게 하면 핑거프린팅도 방지할 수 있음)
XSLT는 (특정 엔진이 아닌) 템플릿 엔진에 대한 "스펙"임, 다양한 구현체가 존재함
Mozilla는 libxslt 대신 transformiix 사용
Jinja는 단순 텍스트 작업이고, XSLT는 노드 레벨에 작동해서 훨씬 우수함
JS 변환은 XSLT 네이티브 변환보다 훨씬 느리고, 결과 캐싱도 어려움
XSLT를 구식 취급하는 시각을 나도 이해는 하지만, 지난 20년간 성능 면에서 비밀 병기로 잘 써왔음
구글은 결국 AMP 같은 대안으로 문제를 덮으려 들 가능성 높음
브라우저가 무거운 건 구글 탓임
XSLT는 언어(spec)이지 엔진이 아님
JS/wasm으로의 구현 변경은 내부 구현 문제이지, 언어를 웹 플랫폼에서 없앨 때 일어나는 일은 아님
오디오나 캔버스는 브라우저의 근본적인 I/O 기능임, wasm으로 옮기면 성능과 호환에 심각한 문제 발생
오디오의 일부는 wasm blob으로 옮길 수 있겠지만, 전체를 이전하는 건 힘듦
캔버스 컨텍스트나 WebGL 등은 GPU와의 직접 통합이 핵심이라 wasm으로 실현 불가임
결국 이런 기능들은 사실상 이미 기본 원시 API라서, 양보할 수 없는 영역임
낡은 XSLT 코드를 wasm으로 패키징해서 구버전 사이트 깨짐 없이 호환할 아이디어도 논의됨
실제로도 내부적으로 검토했지만 하지 않기로 결정함
아주 소수만 사용하는 웹과 거리가 먼 기능은 제거 대상이 될 수 있다고 생각함
하지만 보안 취약점을 명분으로 삼는 것은 찬성하지 않음
메모리 세이프 패키지 유무조차 확인하지 않은 상태에선 설득력이 떨어짐
실제 사용률이 0.001% 수준이라는 주장 있음
HTML 스펙의 기본 약속을 깨는 일은 굉장히 중대한 사안임
논의가 이 점을 깊이 다루지 않는 게 오히려 놀라움
HTML은 "이건 HTML이야. 신뢰해도 돼"라는 약속이었지만, 이제는 "지금만 HTML일 뿐, 앞으로도 그렇다는 보장은 없어"가 됨
XSLT 제거 논리라면 다른 오래된 기술들도 계속 잘릴 수 있음
결국 웹의 '롱테일'을 끊어내겠다는 제안임
향후 추가된 각종 웹 기술이 또 롱테일이 되어 더 많은 제거 대상이 생길 것이란 점도 고민 필요함
오래된 미디어와 소프트웨어 지원 관련해선 언젠가는 이식, 에뮬레이션, 아카이브 등으로 해결할 시기가 온다고 봄
변화에 대비할 충분한 시간과 도구 제공과 점진적 복잡성 누적을 피하는 균형이 필요함
실제 PR에서 삭제된 부분을 보면 HTML에 XSLT 지원을 요구하는 명시적 규정은 없어 보임
단순히 브라우저 지원 문제에 대한 반응이 크다는 점 정도임
PR 자체는 의외로 짧음
WHATWG가 HTML을 "Living Standard"(살아있는 표준)로 규정하면서, 실질적으론 더 이상 구현 표준이 아니라 브라우저 벤더들이 현재 작업 중인 상태를 공유하는 역할임
그래서 HTML5 같은 버전 표기도 없애고, 오로지 "HTML"만 쓰게 됨
Living Standard FAQ
HTML standard FAQ
아이러니하게도 HTML/CSS/브라우저 스펙에 엄청난 양의 기능을 밀어넣은 대표적인 것도 바로 Google임
만약 구글이 "브라우저는 가벼워야 하며 이상한 것들은 JS 라이브러리에 맡기는 게 맞다"를 일관되게 옹호했다면 이번 조치도 이해할 만했겠지만, 전혀 그렇지 않음
FTP 지원 제거 이후부터 XSL의 운명은 이미 예견됨
브라우저들은 공격 표면 축소를 최우선으로 삼는 경향이 있음
다음 제거 후보는 SVG SMIL 애니메이션 속성, MathML 등 XML 관련 기능이 될 것 같단 생각임
관련 스레드
SMIL은 특정 애니메이션 시작/종료 타이밍을 기반으로 순차적 애니메이션 제어를 할 수 있는데, CSS 애니메이션은 아직 이 부분이 부족함
CSS는 계산을 이용한 타이밍 외엔 방법이 없음
Chromium도 한때 SMIL 제거 의지를 밝힌 적 있으나, CSS가 충분하지 않았기 때문에 너무 성급했었음
그 여파로 SMIL 관련 각종 안내문 등이 업데이트 없이 방치됨
공격 표면을 줄이는 것이 과연 좋은 것인지 나쁜 것인지 질문하고 싶음
기술자들과 일반 사용자가 우선순위가 다르긴 함
FTP 기능 제거가 언제 이루어진 것인지 궁금함
아직 주소창에서 ftp://로 접속이 되는 것으로 알고 있음
Blink와 WebKit의 XSLT 구현은 매우 비효율적임
이번 결정이 아쉽지만, 더 현대적인 XSLT 통합에 노력을 쏟지 않은 게 더 안타까움
사용은 불편했지만 브라우저에서 조금만 더 진화했다면 React 같은 프레임워크에 필적할 경쟁자가 될 수도 있었음
XML은 대기업의 복잡성만 없었다면 표준 자체는 매우 강력하고, 멋진 기술이었음
XSLT를 활용해 작고 간단한 xml/데이터를 html로 바로 변환하는 게 정말 좋았음
선택된 항목만 다르게 표시하는 작은 기능만 추가됐다면 정적 문서까지 다양한 활용이 가능했을 것으로 아쉬움
@whatwg가 토론이 "과열됐다"며 해당 이슈를 협업자 한정으로 잠갔다고 함
보기엔 꽤 합리적이고 차분했는데, 특정 벤더에 우호적이냐에 따라 ‘과열’의 기준이 달라지는 건 아닐까 싶음
"과열됐다"는 표현은 종종 반대 의견을 다루기 싫다는 뜻으로 해석됨
Reddit 등 다른 커뮤니티도 마찬가지임
실제로 그 아래 남아있는 1개의 댓글은 Google Chrome 소속 개발자가 "좋은 일 하셨다"고 남긴 것
약간 보기 민망한 느낌임
이슈 트래커에 문제 제기성 욕설, 음모론, 정치적 메시지 등 쏟아진 사례를 언급함
이런 식이면 생산적 논의 자체가 불가능해지며, 저장소 관리자들이 신속하게 토론을 막을 수밖에 없음
해당 저장소의 토론 잠금 조치는 실은 Apple 직원이 내린 것이라고 들었음
하지만 사람들은 이 이슈를 제기한 Google 직원의 책임으로 돌린다 함
구글이 최근 커뮤니티 의견 수렴을 내세워 열린 토론을 했지만, 그 후 모든 의견을 무시하고 관철시키려 하고 있음
관련 이슈
구식 웹 요소에 관한 전반적 고민이 필요함
내 경우 예전 웹페이지도 계속 제대로 작동해서 얻는 가치가 큼
HTML/JS가 호환성 지켜온 덕분에 수십 년 된 페이지조차 TLS 인증서만 붙이면 여전히 정상임
하지만 모든 유산 기술을 영원히 지원할 수는 없는 일이기도 함
Flash도 결국 에뮬레이터(Ruffle)를 통해 추억의 게임이나 사이트를 경험하는 식으로 넘어갔음
장기적으로는 구형 렌더링에 특화된 전용 브라우저나 에뮬레이터 사용도 대안이 될 수 있음
이미 이를 위한 XSLT polyfill 확장이 생겼음
Chrome은 이를 공식 배송하거나 유지보수하기를 원하지 않음
Ruffle과 매우 유사한 상황임