재삐신생의 권태로운 이야기

어떤 코드든 굉장히 단순하지만, 긴~ 코드들을 줄여서 쓰기위해 Class등을 활용한다더가 해서 나름의 프레임웤같은 걸 응용해서, 쉽게 코딩을 한다 치자. 그것을 뜯어보는 사람은 오히려 단순한 Query문도 복잡하게 돌아가는 형태에 머리가 지끈지끈 그렇다고, low한 수준을 모두 따딱거리자니, 시간낭비 인력낭비 적당한 대안이라면, 이미 공용화된 프레임웤을 사용하는 것이라 하겠다. 결론이 나왔으나, 대안이 되지 못하는 슬픈 현실..

HTML 4.01에서 표준모드로 TR에 CSS padding을 먹히면 되는지 XHTML1.0에서는 그게 확실히 안되다. 이런 고민들로 머리가 아프다. 과연 무엇이 정답?? DTD doctype에 대한 고민을 없애기 위한 대안으로도 적합한 HTML 5 그래서, 빨리 HTML 5가 널리 쓰이는 날이 왔으면 좋겠다. 깔끔하자나!! 그리고 IE7도 제발 쓰지마세요 ㅠㅠ

HTML코더로써, 외국계열의 개발자들의 목소리로 일명 DIV코딩이 표준화되고 있다. 디자인-CSS마크업&컨텐츠-HTML CSS만으로, 다른느낌을 구현할 수 있다는건데, 뭔가 좋아보인다. TABLE은 구조를 바꾸지 않는 이상, CSS로는 변경이 불가능 한게 단점이지만, DIV코딩을 하다보면, 아직도 여전히 많이 쓰이는(적어도 국내에선), 그래서 익숙한 TABLE코딩이 그리워진다.사실 Align이 자유로와서, 정말 하드코딩을 하기엔 TABLE이 정말 쉽다. TR TD로 그리드 디자인하긴 정말 좋다. 그래서 많이들 쓰이는 거겠지.. 그렇게 장단점이 있지만, DIV코딩에 애착이 있다.하지만 페이지가 수가 많아지면 CSS도 엄청난게 복잡해져서, 각 클래스와 ID값을 찾아보면 오히려 수정이 더 복잡하기도 하다. 지..

또또 IE의 문제점을 보고하게 되었습니다. 스타일 최적화를 하는 과정에서TH의 기본정렬은 center TD의 기본정렬은 left TR에 정렬을 적용하면 하위TD에 정렬이 적용되는 건 EASY합니다. 하지만 문제점은 이것이었습니다.문제! : 여기의 정렬은 왼쪽일까요? 오른쪽 일까요? 예전 코드들이라 테이블로 레이아웃을 잡았죠, 아!!ㅠㅠ아무튼, 아직 접할 기회가 많네요; 오늘 간단하게 실험을 해본결과 저런 상황일때DTD xhtml 1.0으로 잡고 해봤슴다. IE9 쿼크 IE9 표준 크롬 18.0.xx 파폭 12 사파리 5.1.5 왼쪽 가운데 왼쪽 왼쪽 왼쪽 놀랍지 않습니까??ㅠㅠ이것때문에 시간을 얼마나 버렸는지!! align속성이 상속되어버립니다;ㅠㅠIE표준모드에서만 문제가 생기더군요!! 어처구니가 없었네..

IE에서 생기는 A요소와 IMG요소의 점선 테두리가 보기 안좋아서여러가지 방법으로 처리를 합니다. CSS도 IE에 특화된selector-dummy:expression(this.hideFocus=true); 혹은 A요소에 이벤트를 걸어주는onfocus="this.blur()" 등의 방법이 있었고,네이년과 구글링을 해보면function bluring(){if(event.srcElement.tagName=="A"||event.srcElement.tagName=="IMG") document.body.focus();}document.onfocusin=bluring; 이런 코드가 많이 눈에 띈다. 코드를 분석해보자.일단 onfocusin이벤트는 IE에만 존재한다.(고로, IE에서만 bluring함수가 실행됨)그리고..

무엇이 다른가?? Bold Strong 차이점이 보이시나요?? 거의 모든 브라우져에서 처리하는게 똑같다고 봅니다. 그렇다면,쉽게 해석 할수 있습니다. 개념의 차이 strong는 문단에서 강조를 뜻하는 "논리적"요소로 생각하면 됩니다. 강조한다는 뜻!b는 그냥 Bold를 의미하는겁니다. 그냥! 두껍게하라는 뜻! 그다지 큰 의미를 둘 순 없지만 확실히 의미는 조금 다르다는 걸 알 수 있습니다! 비슷한 예로와 도 있지요~!

단순히웹로그를 분석하는 데 매우 중요한 리퍼러(Referer / Referrer)에 대해서서버사이드 언어로만 구현하여 DB저장을 하다가 구글 분석기는 스크립트로 뭘 한던데......??생각이 들어서 찾아보니 document.referrer 어라?? 왜 저걸 몰랐지??이미 예전부터 있던 레퍼런스인듯 한데?? 구버전 IE에서 시도했던거 같기도 하다..문제가 있어서 사용을 안한건지 모르겠다만...흠!! 직접 사용하여서, GET방식으로 외부서버로 DB저장이 가능하였다.좋다. 이게 구글 분석기의 원리였구나!! 굳!! 굳!! 굳!! 근데?? 자바스크립트는 클라이언트사이드언어인데, 그렇다면 브라우저 환경에 영향을 받을 수도 있을 것 같다.서버에서는 요청을 받으면서 헤더에서 리퍼러를 가져올 것인데 document의 r..

Hex CodeEntity CodeNumber CodeCharacterDescription """Quotation Mark &&&Ampersand ⁄//Slash <<Greater Than Sign ‚&#130;‚Single Low-9 Quote „&#132;„Double Low-9 Quote††&#134;†Dagger ‡&#135;‡Double Dagger ‰&#137;‰Per Mill Sign ‹&#139;‹Single Left Angle Quote ‘&#145;‘Left Single Quote ’&#146;’Right Single Quote “&#147;“Left Double Quote ”&#148;”Right Double Quote ™&#153;™Trademark Symbol ›&#155;›Sin..

이전의 글을 응용해보았다. 스크립트는 클라이언트단의 언어이기 때문에(?)아무튼, 독립링크(퍼멀링크)가 필요한 페이지이지만, 서버쪽 처리를 할 필요가 없을경우예를 들어 링크가 www.domain.com/post.php?param1=value1#!param2=value2라는 URL을 사용할 경우에 #!뒤의 값으로, 스크립트처리를 해서, 다른 컨텐츠를 보여주는 방식이다.몇몇 모듈과 페북에서 응용하는 걸 확인했다. #은 원래 a요소의 name값으로서 페이지내의 위치를 링크로써 찾는 것으로 알고있었는데, 약간 다르게 응용하는 거이다. 그래서 만든 스크립트function glp(name){name = name.replace(/[\[]/,"\\\[").replace(/[\]]/,"\\\]");var regexS = ..

자바스크립트로 url 파라미터 읽기 정규식 활용 좋네요~!!