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

또또 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 파라미터 읽기 정규식 활용 좋네요~!!

TINYINT[(M)] [UNSIGNED] [ZEROFILL] - 범위 : -128 에서 127 (UNSIGNED 일 경우 0 에 255) SMALLINT[(M)] [UNSIGNED] [ZEROFILL] - 범위 : -32768 에서 32767 (UNSIGNED 일 경우 0 에 65535) MEDIUMINT[(M)] [UNSIGNED] [ZEROFILL] - 범위 : -8388608 에서 8388607 (UNSIGNED 일 경우 0 에 16777215) INT[(M)] [UNSIGNED] [ZEROFILL] - 범위 : -2147483648 에서 2147483647 (UNSIGNED 일 경우 0 에 4294967295) - 주의 : 모든 연산은 "signed BIGINT" 로 이루어진다. 따라서 더하기 ..

필드 지정시 날짜와 관련이 되면 이전부터 많이들 TIMESTAMP를 사용하였는데요 일단, 둘의 차이점을 알아봅시다 TIMESTAMP만의 특성입니다. 서버의 시간에 의존(UTC에 따라 변형된다는 의미로 해석하면 될 것 같네요) 범위가 '1970-01-01 00:00:01' UTC to '2038-01-09 03:14:07' UTC로 제한됨 on update CURRENT_TIMESTAMP 옵션을 사용할 수 있다. 이러한 차이는 쉽게 말하면 DATETIME는 순수하게 상수로 된 날짜로 인식하지만, TIMESTAMP는 서버시간에 의한 의존하는 날짜 개념이죠.(서버 time zone 변경시, 바뀝니다) 해외서버를 사용한다면, 문제를 일으킬 수 있는 부분입니다. 국내에서만 사용 할 경우는 별다른 문제가 일어나지 ..

예전부터 플래시를 HTML코드에 넣을때 embed나 object코드를 사용하게 된다. 일반적으로 표준으로는 object코드를 넣지만 이걸 스크립트를 활용하여 써 넣는다. 이유 중에 하나가, 그냥 를 삽입하면 마우스 포커스시에, object에 포커스되는 외곽선이 보이기 때문이었는데 스크립트로 넣으면 그런일이 생기지 않는다. 그렇게 시간은 흘렀고 2012년 플래시는 사장되는 분위기지만 여전히 꽤나 쓰이고 있다. 그러다 어제 IE의 메모리 문제와 관련하여 문제점이 또 생겼다. 필자가 쓰던, 코드로 삽입된 플래시가 IE9에서 매우 늦게 뜨는 것이다. 다른 부분이 다 뜨고, 한참이 지나야 뜬다. 심각하다. 개발자 도구로 살펴보니, 쓸데없는 파라미터들이 많이 삽입이 되며, 이상한 CSS가 삽입되는걸 발견했다. ob..