요약
Chrome과 Edge가 XSLT 지원을 없애면서 깨지는 것과 깨지지 않는 것을 정리한 글입니다.
doctor-seo.net에 올라온 글입니다. 제목으로 보면 Chrome과 Edge가 XSLT(XML 문서를 HTML 같은 다른 형식으로 바꾸는 변환 언어) 지원을 빼면서 영향을 받는 것과 받지 않는 것을 나눠 설명합니다. 원문을 읽지 못했습니다. 사이트가 봇 확인 화면만 보여 줬습니다.
HN 반응
- 일부 이용자는 인라인 스크립트나 JS·WebAssembly로 만든 XSLT 변환기로 대신할 수 있다고 했고, 서버에서 변환하면 영향이 없다는 보충도 나왔습니다.
- 브라우저 독점 업체가 보안을 핑계로 기능을 없앤다는 반발이 있었고, 토론은 XHTML처럼 엄격한 파싱이 웹에 나았을지를 두고 번졌습니다.
XSLT가 사라진다는 소식을 처음 들었을 때, JS로 같은 걸 하려면 어떻게 해야 할지 궁금해졌습니다. 페이지를 불러오는 동안 클라이언트 쪽에서 템플릿을 처리하되 "콘텐츠가 깜빡이는 현상"은 없게 하고 싶었거든요. 알고 보니 아주 좋은 방법이 있었습니다. document.currentScript 바로 옆에 요소를 덧붙이는 인라인 스크립트를 쓰는 겁니다. Lean Rada가 이 내용을 쓴 글이 여기 있고 https://leanrada.com/notes/inline-rendering-currentscript/ 저도 따로 글을 썼습니다. https://vladimirslepnev.me/write
이렇게 하는 대신에:
이러면 어떨까요?
덜 예쁘고 따옴표도 전부 이스케이프해야 하지만, 그래도 쓸 만합니다.
Trusted Types를 켜 두면 그건 안 됩니다.
Lean Rada 글 정말 재미있네요!
저는 아직도 XSLT를 씁니다. 26년째입니다. 백엔드에서 XML 문서를 만들고, 그걸 여러 보고서용 HTML로 바꿉니다. XSLT에는 요즘 템플릿 언어에 없는 기능과 힘이 많습니다.
요즘 나온 템플릿 언어 중에 갈아탈 만한 게 있습니까?
네, 이제 Chrome과 Edge에서는 XSLT가 안 되니까요.
그분 댓글만으로는 변환을 서버에서 처리한 뒤 HTML로 내려보내는 건지 알 수 없어요. 그런 구현도 예전부터 있었거든요. 브라우저가 정체해 있던 최신 XSLT 기능을 쓸 수 있었으니까요.
JS나 WebAssembly 기반 XSLT 변환기는 여전히 돌릴 수 있습니다.
브라우저 업체들이 했어야 하는 일이 바로 이겁니다. 변환용 wasm 모듈 링크를 제공하는 식으로요. 그랬다면 더 나았을 겁니다.
내가 줄곧 틀렸다고 납득시키는 데는 이만한 방법이 없죠.
1단계: 브라우저 시장을 독점한다.
2단계: 가짜 보안 위협을 만들어 낸다.
3단계: 막을 방법은 Flash처럼 완전히 없애는 것뿐이라고 모두를 속인다.
3-a단계(덤): 버그를 고칠 사람이 없다. 자원을 전부 UI/UX 실험에 쏟았으니까.
이제 Flash가 없다는 걸 일깨워 줘서 고맙네요. 잊고 있던 축복을 새삼 헤아리게 됩니다.
Flash가 사라진 건 스티브 잡스가 더 나은 방법을 찾자고 간곡히 호소하면서, 당시 점유율이 한 자릿수에 불과하던 자기네 소박한 브라우저를 따르라고 했기 때문입니다.
Flash를 쓸모없게 만든 건 HTML5 canvas와 자바스크립트의 발전입니다. 예전에는 브라우저에서 자바도 돌릴 수 있었다는 걸 잊지 마세요!
아쉬운 일입니다. XHTML 시절에는 XSLT가 웹사이트의 모듈화를 훨씬 깔끔하게 만들어 줄 수 있는 명세였는데요. 저도 예전에 XSLT로 분리된 컴포넌트를 합치는 초기 웹사이트 제작 도구를 만든 적이 있는데, jQuery 없이는 자바스크립트를 쓸 만하지 않던 시절이라 정말 강력했습니다. 하지만 XHTML이 HTML5에 밀려 버려지면서 XSLT는 사실상 쓸모가 없어졌습니다. 이렇게 오래 살아남은 것만으로도 대단하고, 주로 XML 파일에 스타일을 입히는 용도로 남겨 둔 것 같습니다.
HTML5가 한 걸음 더 나아가 표준 XML, 혹은 XML과 호환되는 DOM 인코딩을 정의할 수도 있었고, 하다못해 권장이라도 할 수 있었습니다. 하지만 반(反)XML 정서는 노골적이고 악의적이었습니다. 그래도 널리 쓰이는 XSLT 프로세서는 HTML5를 입력으로 받고 출력까지 하도록 만들어져 있습니다. 다만 그 기능이 얼마나 완전한지, 공식이든 비공식이든 어떤 표준에 근거하는지는 잘 모르겠습니다. (W3C가 HTML5 스냅샷을 버전이 붙은 표준으로 묶으려 했을 때, 그런 게 있었을지도 모르겠네요.)
저는 WDDX와 XML-RPC를 겪고 나서 XML에 대한 열의를 잃었지만, HTML의 토대로서는 당시 최선이었습니다. 툴체인을 아우르는 경쟁자가 없는 걸 보면 지금도 그럴지 모르고요. XSLT도 마찬가지입니다. 문법이 동형(homoiconic)이라는 선택만 빼면요. 사실 저는 XSLT가 막다른 길이라는 게 분명해진 한참 뒤에야 다시 XSLT로 돌아왔습니다. 좋은 도구는 좋은 도구입니다. 제멋대로 방치되고도 여전히 그렇다는 게 그 증거고요.
궁금한데, DOM에서 정확히 어떤 부분이 XML과 호환되지 않나요?
가물가물한 기억이지만, 암묵적으로 닫히는 태그(예: img)일 겁니다.
XML도 암묵적으로 닫히는 태그를 처리할 수 있습니다. 명세에서는 이걸 "empty"라고 부르죠.
https://www.w3.org/TR/xml/#sec-starttags
XML의 빈 태그는 암묵적으로 닫히는 게 아닙니다. 명시적인 /가 필요합니다.
XML은 <img />는 처리할 수 있지만, HTML이 처리하는 것처럼 <img> 뒤에 태그 수프가 이어지는 건 처리하지 못합니다.
(HTML5가 한 걸음 더 나아가 표준 XML, 혹은 XML과 호환되는 DOM 인코딩을 정의할 수도 있었고, 하다못해 권장이라도 할 수 있었습니다.)
그러면 그걸 xhtml5라고 부를 수 있었겠네요. 아쉽게도 그런 건 없죠. 아, 잠깐, 있네요 https://html.spec.whatwg.org/multipage/xhtml.html
(하지만 반XML 정서는 노골적이고 악의적이었습니다.)
아니요, xhtml은 그냥 나쁜 발상이었습니다. 문제만 잔뜩 만들고 해결한 건 하나도 없었어요.
(xhtml은 그냥 나쁜 발상이었습니다. 문제만 잔뜩 만들고 해결한 건 하나도 없었어요.)
글쎄요, XHTML 파서(와 직렬화기)는 훨씬 단순하고, 그건 꽤 의미 있는 문제를 해결하는 거죠.
xhtml이 만드는 문제가 뭔데요?
(XHTML 파서(와 직렬화기)는 훨씬 단순하다)
그럴 수는 있지만, html과 xhtml을 함께 처리하는 파서는 html 파서 하나보다 복잡합니다. html이 이미 굳어진 상태이니 xhtml은 html을 대체하는 게 아니라 추가로 얹히는 셈이 되고요.
가장 큰 문제는 조금만 깨진 XHTML 문서도 렌더링에 실패한다는 점입니다. HTML은 훨씬 너그럽죠.
지나고 보니, 웹이 처음부터 그랬다면 우리가 더 나았을 거라고 생각합니다. 어떤 브라우저에서든 콘텐츠를 테스트해 보는 순간 깨졌는지 바로 알 수 있었을 테니까요.
하지만 이미 깨진 콘텐츠가 잔뜩 있는 상황에서 나중에 도입할 수 있는 건 아니었습니다.
말씀은 감사하지만, 정반대입니다. 웹이 성공한 건 HTML과 HTTP가 텍스트 편집기만 있으면 사람이 쉽게 쓸 수 있는 쉬운 표준이었기 때문입니다. HTML은 프로그래머가 아닌 사람도 쓸 수 있었습니다.
"엄격하게 파싱한다"고 해서 뭔가가 어려워진다고는 생각하지 않습니다. 오히려 쉽게 만드는 데 도움이 된다고 봅니다. 피드백이 명확하고 테스트하기 쉬우니까요.
하긴, 저는 늘 문자열 기반(stringly typed)보다 강한 타입 쪽을 선호해 왔습니다.
그건 HTML을 마크업이 아니라 코드로 보는 발상입니다.
HTML과 마크다운이 라텍스(LaTeX)보다 널리 퍼진 건 앞의 둘이 더 너그럽기 때문입니다.
저는 마크업으로 보고 있습니다. 제 주장은 그대로입니다. 파싱에서 "너그러움"은 기능이 아니라 버그라고 생각합니다.
너그러움은 파싱하고 싶은 콘텐츠를 만드는 사람들이 콘텐츠를 만들기 시작하게 유도하는 데 아주 유용합니다. 세계 최고의 파이프라인이 있어도 집어넣어서 흘려보낼 게 없으면 소용없죠. Flash가 죽으면서 "누군가 canvas와 webgl용으로 마찰 없는 훌륭한 편집기를 만들어 주겠지" 했지만, 결국 모든 창작 에너지는 로블록스에 빨려 들어가 돈벌이가 됐고 세상은 더 나빠졌습니다. 그 비극을 보세요.