언젠간 곧 개선되겠지만, 묵은 때같은 존재죠.
https://github.com/rhymix/rhymix/issues/2311
.btn 같은 일반적인 클래스명에 !important를 붙여버리다니
굳이 붙여야만 했을까 싶네요.
.btn 속성을 좀더 규칙을 정해서
.xe-btn 이라고 해두던가-_-
혹은 .xe-btn-wrap .btn 이라고 하던가..
일괄적으로 규칙을 정해서 수정해주시면 좋겠습니다.
관리자에서 사용하는 클래스명과 일반적인 클래스명이 구분되서 들어가줘야하지 않나 싶네요.
개인적으로는 !important를 빼버리고, 필요없는 스타일(text-shadow, background-image, filter) 속성은 지워버리고 사용합니다. 매번 업데이트마다 덮어쓰기가 번거롭지만 사실 저게 없어도 하등 사용하는데 전혀 불편함은 없습니다. 오히려 군더더기 없는 스타일이 더 깔끔합니다.
ps. 굳이 유지하고자 하신다면 저 클래스를 유지하면서 개선하는 쉬운 방법도 있습니다.
관리자화면, 게시판설정화면 등에서는 body class="x" 선언하고 .x .btn 이런 식으로 해도 충분한 요소입니다.

eond
Lv. 13
# 라이믹스 스킨 제작은 어디? >>>> XE 레이아웃, 라이믹스 스킨제작은 이온디에서 커스터마이징해드립니다.
# 빠른 라이믹스 커뮤니티용 호스팅을 찾고 계신가요? >>>> 이온디호스팅 서비스는 PHP8 & Redis 서버 캐시를 활용하여 라이믹스에 최적화된 호스팅 서비스를 제공해드립니다. (서버세팅시 웹패널, 내도메인메일서비스도 함께 구축해드립니다.)
https://eond.com
# 빠른 라이믹스 커뮤니티용 호스팅을 찾고 계신가요? >>>> 이온디호스팅 서비스는 PHP8 & Redis 서버 캐시를 활용하여 라이믹스에 최적화된 호스팅 서비스를 제공해드립니다. (서버세팅시 웹패널, 내도메인메일서비스도 함께 구축해드립니다.)
https://eond.com
댓글 22
자료 만들면서 .btn 클래스를 고집하는 분들도 정말 답답합니다. (소신 발언)
.btn은 그냥 예약어라고 간주하고, <button class="myBtn"> 처럼 다른 클래스를 쓰면
XE의 레거시 스타일은 무시하고 내 마음대로 커스터마이징할 수 있는데 말이죠.
아, 확장변수 입력란은 코어에서 생성한다고요?
$('.btn').addClass('myBtn').removeClass('btn');
내가 선호하는 특정 라이브러리 때문에 무조건 .btn을 사용해야겠다!!! 라고 고집하신다면
.btn 기본 스타일을 제거하는 방법도 몇 년 전부터 지원합니다.
@php
define('DISABLE_XE_BTN_STYLES', true);
@endphp
뭐 언젠가는 정리될 레거시이지만, 지금도 회피할 방법을 다 제공해 드리는데
회피하지 않고 계속 들이받으면서 불편하다고 투덜거리는 것이 지겹지도 않나요?
누가 .btn 쓰라고 칼 들고 협박한 것도 아니고...
무서워요 😖
저.. 이거랑 관계는 없지만, 템플릿에서 중괄호 중첩되면 파싱 에러나는 거는 혹시 어쩔 수 없는 문제인 것인가요? AI가 의외로 힘들어하는 부분이라 혹시 개선될 수 있을까 해서요.
템플릿 v2 (Blade) 문법을 쓰시면 훨씬 낫습니다. AI도 Blade를 훨씬 잘 이해하고요.
아! 그렇군요. 설명을 보니 2.2부터 정식지원이라고 되어있는데 2.1.19에서도 사용가능한건가요? 이미 솔루션을 다 만들어놓으셨는데 몰랐네요.. ㅠ.ㅠ
코어를 업데이트 하지 못하는 사정이 있는게 아닌 이상 업데이트 하시는건 어떠신지요?
코어에 소소한 수정이 되어있는 곳이 3군데 있는데 2군데가 기억이 나질 않아요 엉엉 분명히 어쩔 수 없는 이유가 있어서 수정한 걸텐데 머드라 밖에 기억이 나질 않습니다 ㅠㅠ
저도 개인적으로 자료나 외부 납품할 때에 .btn은 피하는 편 입니다.
이미 코어에서 예약해서 쓰고 있는거나 다름없는 class들은 피해야지요.
만약 정말 특정 라이브러리 or 프레임워크에서 .btn을 바꿀 수 없다면 XE버튼 스타일을 끄면 되고요
대안이 없는 것은 아닌데 급한게 아니라면 천천히 기다려보시죠 ㅎ
클래스 규칙에 !important 붙인것을, 오히려 회피하는 방법을 만드는게 더 이상해보여서요.
그걸 만들바에 올바른 방법으로 고치는게 더 맞는 방법이 아닐까 같이 이야기나눠보고 싶었습니다.
이제는 고쳐지겠지만 몇년째 안 고치는게 희한해서요. 그리고 같이 이야기나눠보면서 좀 더 올바른 방향이 나오지 않을까 생각했습니다.
고쳐진다라기 보다는 개선이 맞는거 같습니다.
"언젠가는" 개선이 되겠지만, 현재로써는 회피 방법이나 대안이 많으니 우선순위는 내려갈 수 밖에 없겠죠 ^^
요즘은 Tailwind도 쓰고 다양한 프론트엔드 프레임워크들이 많이 개선되어서 내가 원하는 class로도 제어할 수 있는 만큼 다양한 방법을 모색해보시는 것도 좋겠습니다 ㅎㅎ
레거시 코드에 !important가 있으면 올바르지 않은 것인가요?
코어에서 오래 전부터 예약어로 취급하고 있는 클래스명을 단지 내가 쓰고 싶은 단어라고 해서, 임의로 다른 스타일로 덮어씌우기 편하게 바꿔 달라고 하는 것은 올바른 사용법인가요? !important 쓰지 말라고 하는 고수님들께 한번 여쭤보세요. 애초에 겹치는 클래스명을 사용하지 않는 것이 더 올바르다고 말씀하시지 않을까요?
이건 옳고 그름의 문제가 아니고 개인 취향의 문제라고 생각합니다. 그러니까 당연히 우선순위는 저 아래에...
과도한 !important의 사용은 유지보수를 어렵게 하고, 다른 써드파티 모듈 간의 CSS 특이성을 저해한다고 생각합니다.
!important를 단계적으로 최소화하고, 제가 봤을 땐 저게 없어도 무방하다고 보여지고, .x .btn 이런 식의 사용이 더 맞지 않을까 봅니다.
레거시 시스템 호환성이라는 제약 하에서 나름 체계적으로 고민한 흔적은 보이지만 좀 더 현대적 관점에서는 오히려 지금의 방법보다는 제가 제안드린 방법으로의 개선이 더 낫지 않을까 싶어 화두를 던져보았습니다.
저는 공통된 클래스명은 절대 안쓰고있지만 일부 구입한 스킨에서 btn을 쓰는경우가 있더라구요 ㅠㅠ
뭐 눈에 보이면 하나하나 고치고 있습니다.
이게 귀찮음... 맞아요!
코어가 이러니까 따라라 식 접근은 기술 부채를 누적시키기도 합니다. 기진곰님은 현실적 제약(레거시 코드, 기존 사용자, 개발 리소스) 을 말씀하셨지만 결국 .btn 클래스에 !important를 사용한 것은 과거 레거시 자료(btn 클래스 속성을 사용하는 자료로 인해 관리자 버튼이 영향일 끼치게 된 이유 때문에 !important 속성을 썼는데 결국 중요한 것은 btn 요소에 대한 더 세심한 CSS 규칙을 적용하는 것이 원론적인 해결방법이지, 지금처럼 disabled 속성을 적용해라는 것은 맞지 않는 대안이라고 생각합니다.
문제의 본질은 DISABLE_XE_BTN_STYLES 옵션으로 설정을 바꾸는 것이 아니라,
프론트엔드적인 관점에서 CSS 아키텍처 개선이 이뤄져야 하는 부분이라고 봅니다.
// 이런 식의 임시방편과 같음
if (문제가생기면)
{
기능을끄기();
}
else {
원래대로하기();
}
/* 레거시 자료들이 .btn을 남용 → 관리자 버튼 스타일이 깨짐 */
.btn {
background: #007bff !important; /* 강제로 덮어쓰기 */
}
/* 컨텍스트별 명확한 구분 */
.xe-admin .btn, .admin-panel .btn, body.admin .btn {
background: #007bff; /* !important 없이도 충분한 특이성 확보 */
}
레거시 자료의 .btn 남용
→ 관리자 스타일 깨짐 → !important로 강제 해결
→ 다른 라이브러리와 충돌 → DISABLE 옵션으로 또 회피 → 더 복잡한 설정 관리 필요
disable 하고 쓰세요는 외딴 섬으로 가는 티켓입니다.
!important를 작성하는 것이 잘못된 것이라고 말하는게 아니라
네임스페이스 기반 접근이 훨씬 건전한 해결책이라고 생각합니다.
네, 그렇죠. disable 상수 선언은 누군가의 요구로 생겨난 미봉책일 뿐이고,
가장 완벽한 해결책은 처음부터 내 자료에 다른 자료와 동일한 클래스명을 사용하지 않는 것입니다.
솔직히 서드파티가 .btn을 쓰는 것이 이걸 수정하지 못하고 있는 근본적인 이유입니다.
!important가 옳으냐 그르냐, 컨텍스트별로 구분하네 마네 하는 것은 지엽적인 이슈일 뿐이예요.
우리는 학원에서 가르치는 모범답안이 아니라, 사방에 레거시가 널려 있는 현실에서 일하는 사람들이니까요.
그런데 살았는지 죽었는지도 모르는 레거시 자료 제작자분들에게 수정을 요구할 수는 없으니,
그나마 만만한 게 코어라서 코어한테 바꿔달라고 하는 거 아닌가요?
서드파티 자료에서 Context라는 클래스를 만들어 쓰면 미친놈이라고 하겠죠?
이론적으로는 이것도 Rhymix\Framework 네임스페이스 안에 들어가 있어야 옳습니다만...
현실은 그렇지 않죠. 여기에 불만이 있다면 저 말고 제로님께 따지셔야 합니다.
.btn이라고 다를 게 뭡니까?
근데
<button type="button" class="btn verifySMS" style="">인증</button>
요런 휴대폰 인증 버튼이나 생일 달력 삭제버튼은
사용자가 원치 않아도 btn이 들어가는게 맞는거죠?
이부분도 커스텀 할 수 있으면 좋을것 같아요. (예전에 /extravar/skins/default/form_types 어디서 본것 같기도하구 이건 확장변수일것 같아서) ㅎㅎ
저기다가 JS로 class 명을 끼워넣게 만들어야해서 코드가 길어지기도해서요
요기에 있긴하네요. 근데 고치면 안되는 코어긴하구
\rhymix\modules\member\tpl\js\signup_check.js
extravar 모듈의 default 스킨을 복사해서 다른 스킨을 만드시면 됩니다.
코어에서 기본 제공하는 구린 디자인이 싫다면 스킨을 만드는 것이 가장 확실하죠.
스킨은 그대로 두고 서드파티에서 $('.가입폼 .btn').removeClass('btn') 이렇게 클래스만 삭제하거나,
아예 버튼 자체를 날려버리는 과격한 커스터마이징도 코어 수정 없이 다 됩니다.
오 ㅎㅎㅎ 너무좋은데요 ㅎㅎ
$('.가입폼 .btn').removeClass('btn') 이거 하면 지금 CSS 중구난방된거 훨씬 더 예쁘게 정리될것 같아요 감사합니다!! ㅎㅎ
근데 혹시 extravar가 확장변수의 tel 등등 말고
tel 등등도 다 포함되어있는게 맞을까요?
확장변수의 tel 등등과 그냥 tel 등등은 무엇이 다른가요?
extravar 모듈 스킨은 회원 확장변수와 문서 확장변수를 입력하거나 표시할 때만 관여합니다.
아아 게시판에서의 확장변수의 tel과
회원 가입의 tel (아 생각해보니 기본 회원가입에 tel이 없고 커스텀으로 추가한 TEL 이니 확장변수로 보는게 맞겠네요ㅎㅎㅎㅎ)
이것 또한 확장변수로 보면되는거고 이미 개별 스킨으로 처리가 가능하게 되어있었네요 감사합니다! ㅎㅎㅎ
오늘도 배워갑니다.