CSS 셀렉터가 XPath보다 훨씬 쓰기 쉬움
최근 PHP의 새 DOM API가 HTML과 CSS 셀렉터를 네이티브하게 아주 쉽게 다루게 해준다는 내용으로 발표도 했음. 예전에는 CSS를 XPath로 변환해야 했음
[1] https://speakerdeck.com/keyvan/parsing-html-with-php-8-dot-4...
브라우저 스타일링 중심으로 발전해 와서, XPath처럼 텍스트 내용 기반 선택 같은 기능이 없는 건 아쉬움
예전에 제안은 있었지만 브라우저 렌더링 맥락에서 성능 문제가 생길 수 있어 스펙에 못 들어간 걸로 알고 있음
LLM도 CSS 셀렉터를 꽤 잘 다룸
문서 편집 에이전트를 만들면서 문서를 HTML로 보여주고, LLM이 CSS selector만 지정해서 필요한 조각을 컨텍스트로 끌어오게 했는데 거의 마법처럼 잘 됨
클라이언트 쪽에서는 querySelector/querySelectorAll이 워낙 널리 쓰이니, 이제 PHP의 새 DOM에도 그게 들어온 게 반가움
사람들이 익숙한 방식 그대로 쓸 수 있음
CSS 문법과 CSSWG가 정의하는 규칙·함수·단위 같은 전체 체계를 분리해서 부를 이름이 있으면 좋겠음
이쪽에 꽤 가능성이 있는데, 다른 활용 사례를 이야기하거나 조사하려면 결국 CSS 파서가 들어간 GitHub 코드를 뒤져보며 사람들이 어떤 기묘한 걸 만드는지 확인하는 수밖에 없어 보임
가벼운 노드 기반 마크업 언어와, 템플릿에 무엇이 들어갈지 표현하는 CSS 셀렉터, 그리고 이 조각들을 어떻게 결합할지 제어하는 CSS 비슷한 문법을 섞은 이상한 템플릿 엔진 비슷한 것도 만지작거리고 있음
표준에서는 이미 꽤 명확히 분리돼 있다고 봄 https://www.w3.org/TR/selectors-3/
DOM 스펙도 이걸 참조함 https://dom.spec.whatwg.org/#selectors
그래서 CSS selector라는 통칭은 이미 맞고, 그냥 selector라고 불러도 됨 DOM selector라는 이름이 더 깔끔할 수도 있지만, 정적 CSS에서 쓰는 셀렉터나 JS 엔진 바깥의 다른 DOM 엔진(XML parser, PHP DOM API 등)에서 쓰는 셀렉터까지 생각하면 오히려 더 헷갈릴 수도 있음
또 :hover나 ::target-text처럼 브라우저 렌더링·탐색에 직접 묶인 특수 셀렉터도 있음
다만 브라우저나 CSS와 덜 결합된 최소 질의 문법 부분집합에는 별도 이름이 있으면 유용할 수 있음
이게 어떤 시나리오를 해결하는지 잘 모르겠음
지금도 자식에 따라 부모를 조건부로 바꿀 수 있음. 예를 들어 pre는 기본 패딩이 16px이고, 직접 자식이 code면 &:has(> code)로 0으로 만들 수 있음
사실 이건 처음엔 서로 다른 두 아이디어가 닮아 보인다는 데서 출발했고, 그 연결을 여러 방향으로 밀어본 쪽에 가까움
결론도 "현대 CSS의 한계를 고쳐야 한다"보다는, CSS 비슷한 문법을 Datalog 비슷한 시스템에 얹으면 트리 형태 데이터를 다루는 일을 더 많은 엔지니어에게 친숙하게 만들 수 있지 않을까에 가까움
여기서 말하는 건 한 번의 스타일 계산으로 해결하는 게 아니라, 선택자에 매칭된 대상의 기저 데이터 자체를 수정하는 문법임
즉 DOM에 새 자식 요소나 속성을 추가하는 쪽 이야기임
지금의 LLM은 CSS를 잘 못 다루는 편이라, 오히려 이걸 시도해 보면 LLM이 더 단순하게 추론할 수 있는지 확인해보고 싶어짐
실제 쓸모는 잘 떠오르지 않지만 그래도 멋지긴 함
음... 이거 그냥 JQ 아닌가 싶음
CSS는 어느 정도 좋아하지만, 점점 복잡성 creep이 심해지는 건 싫음
프로그래밍 언어가 비프로그래밍 언어보다 더 강력해진다는 논리는 이해하지만, HTML·CSS·JavaScript를 계속 복잡하게 키우느니 차라리 그 전체를 대체하는 다른 무언가가 나오는 편이 낫다고 느낌
HTML5의 새 요소들도 대부분 왜 필요한지 잘 모르겠어서 거의 안 씀. 결국 많은 컨테이너는 고유 ID가 붙은 div일 뿐이라고 생각하게 됐고, 심지어 내부 링크용 href 탐색을 위해 그런 ID에 별칭 같은 게 있었으면 싶었음 [data-theme="dark"] [data-theme="light"] :focus { outline-color: black; } 같은 것도 머리로 해석하는 데 너무 오래 걸려서 더 이상 우아하고 단순하지 않게 느껴짐
반면 h2 { color: red; }는 여전히 단순함 ancestor(X, Y) :- parent(X, Y). 같은 표현도 벌써 생각하기 싫어짐. :-는 대체 뭐고, 웃는 얼굴처럼 보임 @container style(--theme: dark) { .card { background: royalblue; color: white; } }에서 읽기를 멈췄음
예전엔 잘 작동하던 표준이 시간이 갈수록 망가지는 것 같아 이상함
내 의도는 CSS에 문법과 의미를 더 얹자는 쪽이 아니라, CSS에서 아이디어를 훔쳐와서 논리/관계형 질의 언어와의 유사성을 활용해 새로운 무언가를 만들자는 쪽에 더 가까움
예를 들어 [data-theme="dark"] [data-theme="light"] :focus { outline-color: black; }는 영어식 의사코드로 풀면, data-theme="dark"인 X가 있고 그 자식 Y가 data-theme="light"이며 포커스 상태면 Y의 outline-color를 black으로 하라는 뜻에 가까움
그래서 이건 Datalog 식으로 outline-color(Y, black) if data-theme(X, "dark") and parent(X, Y) and data-theme(Y, "light") and focused(Y)처럼 쓸 수 있음 :-를 if로, 쉼표를 and로 바꾼 셈임
더 나아가 Y.outline_color := black if X.data-theme == dark and Y.parent == X and Y.data-theme == dark and Y.focused처럼 적어서, attr(X, val)을 X.attr == val 같은 UFCS 비슷한 문법 설탕으로 보이게 만들 수도 있음
더 ALGOL 계열처럼 보이게 하려면 forall Y { Y.outline_color := black if Y.data_theme == "dark" and Y.focused and Y.parent.data_theme == "light" }처럼도 가능함
여기서는 Y를 명시적으로 도입하고 조인 하나는 암묵화해서 더 일반적인 프로그래밍처럼 보이지만, 실제로는 Datalog 엔진이 의존성이 바뀔 때마다 이런 루프를 효율적으로 돌려주는 셈임
Hacker News 의견들
CSS 셀렉터가 XPath보다 훨씬 쓰기 쉬움
최근 PHP의 새 DOM API가 HTML과 CSS 셀렉터를 네이티브하게 아주 쉽게 다루게 해준다는 내용으로 발표도 했음. 예전에는 CSS를 XPath로 변환해야 했음
[1] https://speakerdeck.com/keyvan/parsing-html-with-php-8-dot-4...
브라우저 스타일링 중심으로 발전해 와서, XPath처럼 텍스트 내용 기반 선택 같은 기능이 없는 건 아쉬움
예전에 제안은 있었지만 브라우저 렌더링 맥락에서 성능 문제가 생길 수 있어 스펙에 못 들어간 걸로 알고 있음
문서 편집 에이전트를 만들면서 문서를 HTML로 보여주고, LLM이 CSS selector만 지정해서 필요한 조각을 컨텍스트로 끌어오게 했는데 거의 마법처럼 잘 됨
사람들이 익숙한 방식 그대로 쓸 수 있음
CSS 문법과 CSSWG가 정의하는 규칙·함수·단위 같은 전체 체계를 분리해서 부를 이름이 있으면 좋겠음
이쪽에 꽤 가능성이 있는데, 다른 활용 사례를 이야기하거나 조사하려면 결국 CSS 파서가 들어간 GitHub 코드를 뒤져보며 사람들이 어떤 기묘한 걸 만드는지 확인하는 수밖에 없어 보임
가벼운 노드 기반 마크업 언어와, 템플릿에 무엇이 들어갈지 표현하는 CSS 셀렉터, 그리고 이 조각들을 어떻게 결합할지 제어하는 CSS 비슷한 문법을 섞은 이상한 템플릿 엔진 비슷한 것도 만지작거리고 있음
https://www.w3.org/TR/selectors-3/
DOM 스펙도 이걸 참조함
https://dom.spec.whatwg.org/#selectors
그래서 CSS selector라는 통칭은 이미 맞고, 그냥 selector라고 불러도 됨
DOM selector라는 이름이 더 깔끔할 수도 있지만, 정적 CSS에서 쓰는 셀렉터나 JS 엔진 바깥의 다른 DOM 엔진(XML parser, PHP DOM API 등)에서 쓰는 셀렉터까지 생각하면 오히려 더 헷갈릴 수도 있음
또
:hover나::target-text처럼 브라우저 렌더링·탐색에 직접 묶인 특수 셀렉터도 있음다만 브라우저나 CSS와 덜 결합된 최소 질의 문법 부분집합에는 별도 이름이 있으면 유용할 수 있음
예전에 컨퍼런스에서 봤던 https://github.com/braposo/graphql-css가 떠오름
농담 프로젝트였지만, 패턴을 다른 맥락으로 옮겨 심고 다시 쓰는 방식이 의외의 걸 가능하게 한다는 점을 잘 보여줘서 좋았음
바로 그런 식으로 서로 다른 맥락의 패턴을 가져다 써보려는 중임
대부분은 별 데까지 안 가더라도, 해커 감성으로는 꽤 흥미로움
pyastgrep은 https://pyastgrep.readthedocs.io/en/latest/에서 보듯이 Python 문법을 질의할 때 CSS 셀렉터를 쓸 수 있음
기본값은 XPath고, 예를 들면
pyastgrep --css 'Call > func > Name#main'처럼 가능함내가 가리키고 싶었던 방향과 거의 정확히 맞닿아 있음
이게 어떤 시나리오를 해결하는지 잘 모르겠음
지금도 자식에 따라 부모를 조건부로 바꿀 수 있음. 예를 들어
pre는 기본 패딩이 16px이고, 직접 자식이code면&:has(> code)로 0으로 만들 수 있음결론도 "현대 CSS의 한계를 고쳐야 한다"보다는, CSS 비슷한 문법을 Datalog 비슷한 시스템에 얹으면 트리 형태 데이터를 다루는 일을 더 많은 엔지니어에게 친숙하게 만들 수 있지 않을까에 가까움
즉 DOM에 새 자식 요소나 속성을 추가하는 쪽 이야기임
지금의 LLM은 CSS를 잘 못 다루는 편이라, 오히려 이걸 시도해 보면 LLM이 더 단순하게 추론할 수 있는지 확인해보고 싶어짐
실제 쓸모는 잘 떠오르지 않지만 그래도 멋지긴 함
음... 이거 그냥 JQ 아닌가 싶음
CSS는 어느 정도 좋아하지만, 점점 복잡성 creep이 심해지는 건 싫음
프로그래밍 언어가 비프로그래밍 언어보다 더 강력해진다는 논리는 이해하지만, HTML·CSS·JavaScript를 계속 복잡하게 키우느니 차라리 그 전체를 대체하는 다른 무언가가 나오는 편이 낫다고 느낌
HTML5의 새 요소들도 대부분 왜 필요한지 잘 모르겠어서 거의 안 씀. 결국 많은 컨테이너는 고유 ID가 붙은
div일 뿐이라고 생각하게 됐고, 심지어 내부 링크용href탐색을 위해 그런 ID에 별칭 같은 게 있었으면 싶었음[data-theme="dark"] [data-theme="light"] :focus { outline-color: black; }같은 것도 머리로 해석하는 데 너무 오래 걸려서 더 이상 우아하고 단순하지 않게 느껴짐반면
h2 { color: red; }는 여전히 단순함ancestor(X, Y) :- parent(X, Y).같은 표현도 벌써 생각하기 싫어짐.:-는 대체 뭐고, 웃는 얼굴처럼 보임@container style(--theme: dark) { .card { background: royalblue; color: white; } }에서 읽기를 멈췄음예전엔 잘 작동하던 표준이 시간이 갈수록 망가지는 것 같아 이상함
예를 들어
[data-theme="dark"] [data-theme="light"] :focus { outline-color: black; }는 영어식 의사코드로 풀면,data-theme="dark"인 X가 있고 그 자식 Y가data-theme="light"이며 포커스 상태면 Y의outline-color를 black으로 하라는 뜻에 가까움그래서 이건 Datalog 식으로
outline-color(Y, black) if data-theme(X, "dark") and parent(X, Y) and data-theme(Y, "light") and focused(Y)처럼 쓸 수 있음:-를if로, 쉼표를and로 바꾼 셈임더 나아가
Y.outline_color := black if X.data-theme == dark and Y.parent == X and Y.data-theme == dark and Y.focused처럼 적어서,attr(X, val)을X.attr == val같은 UFCS 비슷한 문법 설탕으로 보이게 만들 수도 있음더 ALGOL 계열처럼 보이게 하려면
forall Y { Y.outline_color := black if Y.data_theme == "dark" and Y.focused and Y.parent.data_theme == "light" }처럼도 가능함여기서는 Y를 명시적으로 도입하고 조인 하나는 암묵화해서 더 일반적인 프로그래밍처럼 보이지만, 실제로는 Datalog 엔진이 의존성이 바뀔 때마다 이런 루프를 효율적으로 돌려주는 셈임