Coding Story

아이폰의 경우 사파리에서 웹 사이트를 홈화면(=바탕화면)에 추가 할수 있다.

웹 앱의 경우 홈버튼에 추가된 형태로 이용되어지도록 의도되어 많이 개발되기도 한다.

저렇게 아이콘이 나오게되는데, 그러면 홈화면에 저 아이콘이 해당 웹앱의 모양으로 추가된다.

방법은..

<link rel="apple-touch-icon" href="Sample.png">

저번에 알아보았던 파비콘과 달리 png파일을 이용할수 있다.

참고로 아이폰3GS의 경우 57X57 사이즈를 앱 아이콘으로 이용하며

아이폰4, 아이폰4S에서는 114X114(retina)크기로 제작하면 된다.

그리고 곧 출시될 아이폰5에서는 double retina display로 228X228로 하면될거같네요.

*iOS에서 바로가기 아이콘의 경우 기본적으로 위에서 부터 아래로 선명도를 달리하여 광택효과를 주게 되는데 만약 이 효과를 금지하려면 rel에 apple-touch-icon 대신 apple-icon-precomposed 를 설정하면 됩니다.

브라우저를 이용하다보면 

이렇게 탭에 웹 사이트 타이틀이 나오고

왼쪽에 아이콘이 하나 나오는데 저 아이콘을 파비콘이라 부른다.

파비콘은 브라우저마다 다르지만 타이틀 앞에도 있지만

이렇게

↑인터넷 익스플로러에서의 즐겨찾기 ↑크롬에서의 북마크

즐겨찾기,북마크,책갈피 등에서도 쓰이고 있다.

이 파비콘을 우리 웹사이트에도 적용해보려고 한다.

준비물 -> 먼저 파비콘 파일이 필요한데,

파비콘은 png,jpg,gif 등의 이미지 파일이 아닌 'ico'확장자를 가진 파일이어야 한다.

(웹검색을 하다보면 png를 ico로 바꾸는 방법이 많이 나와 있으니 참고하세요.)

필자같은 경우는 '애플웹'이라는 컨셉의 페이지를 운영하고 있으므로. 애플 아이콘을 파비콘으로 쓰고 있다.

파비콘 파일을 준비했으면 각자 호스팅에 올려주시고.

<link rel="shortcut icon" href="favicon.ico" />

href 속성내에 파비콘 경로를 써주면 된다.

*파비콘은 기본적으로 루트에 favicon.ico를 쓰면 해당 페이지의

파비콘이 자동적으로 지정되지만, link 태그를 이용해 지정해 주는것이 일반적이다. 

그런데, 이 퍼블리셔라는 사람들이 만들어 놓은 파일들을 보면,

개발자로서는 참 난감한 경우가 많다.

여러가지가 있지만, 나열해보면

1.웹 표준, 접근성에 맞지 않게 코딩.

2.테이블을 이용한 막코딩

3.js, php 활용을 고려하지 않은 모양만 갖춘 코딩.

등이 있다. 

여기서 1번,2번은 개인적으로는 퍼블리셔라고 불러주고 싶지도 않은, 

기본적 소양도 갖추지 못한 퍼블리셔라고 본다. 그냥 코더라고 부르겠다.

그런데...3번은 보자. 3번 같은 경우도 정말 자주 있는 일이다. 저런 경우에는 결국

개발자가 다 뜯어서 마크업부터 다시한다. 일을 두번하게 되는 샘이다.

왜 이런 일이 발생할까? 

그렇다! 그는 html, css에도 능숙하고, 웹표준, 접근성 마크도 여러번 달아봤지만, javascript와 php의 j, p 자도 몰랐던 것이다. 내가 만든 이 html에 어떤 조작이 가해져서

어떤 효과를 내고, 어떤 데이터를 가져올지 전혀 모르는 상태에서 마크업을 하니, 오히려

넘겨받은 파일이 정상인 것이 기적인 샘이다.

(물론, js도 능숙하게 다루지만 업무적 포지션이 퍼블리셔인, 진정한 퍼블리셔 분들도 많이 계신다.)

다시 말해서, 퍼블리셔가 js나 php, jsp가 어떻게 돌아가는지 전혀 알지 못하면, 이러한 사태가 빈번히 발생 할 수 있다.

퍼블리셔는 js와 서버 언어에 대한 지식을 키우는 데 게을리 하지 않아야 한다는게 프론트 엔드 개발자로서의 입장이다.

일부 퍼블리셔는 말한다.  (그러면서 그들이 할줄 아는 것에 덧붙여 js도 할줄 아는 ui 개발자와 동등한 대우를 받기를 원한다.)

"웹 접근성, 표준 지키고 크로스 브라우징 레이아웃 마크업 하기도 바쁜데 js도 해야하나요? 내가 왜 js를 해야하나요?

그거 개발자가 하는 거잖아요?"

그러면 이렇게 답변해주고 싶다.

"그러면 퍼블리셔는 프론트 엔드 개발자가 아니네요? 똑같은 대우 해달라고 하지마세요."

바쁘다는 핑계로 자기가 왜 js를 해야 하냐고 주장하지만, 필자의 느낌은,

솔직히 말해서, js를 하고 싶지않고, 변화를 강요받고 싶지 않은 퍼블리셔가 많은것 같다.

주변에서 계속해서 js를 권유하기 때문에 js 자체게 반감을 갖고, 비하하는 퍼블리셔도 종종 보인다.

(실제로 주변 지인 퍼블리셔들의 이야기를 들어보면, js부터는 다양한 개발 방법론이 있는 언어 단계로 접어들어,

그 장벽이 결코 낮지 않다고 한다.)

 분명히 위의 말에서, '이것저것 하느라 바쁜데'라는 말은

누가 들어도 공감 할 수 있는 사실이다. 그러나 필자가 요구하는 것은 js의 업무적인 추가를 요구하는 것은 아니다.

기본적으로 js가 어떻게 구동되며, 퍼블리싱 된 제품을 어떻게 이용 하는지를 알고 퍼블리싱하기를 바라는 것이다.

퍼블리셔라는 포지션은 분명 사라질 수 없는 포지션임은 틀림 없으며, 퍼블리셔도 마크업을 전문적으로 하는

프론트 엔드 개발자의 일환임에도 틀림없다.

그러나 js만을 다루며 html, css를 무시하는 사람이 프론트 엔드 개발자가 아닌 js 코더이듯, 

html, css를 다루며 웹표준, 웹접근성 마크 다는 것을 어떤 대단한 기술을 가진 것인 냥 유세를 부리는

퍼블리셔는 프론트 엔드 개발자가 아니다. 그냥 마크업 코더일 뿐이다. 그런 사람들에겐 이렇게 말 해주고 싶다.

"표준이랑 접근성 그거 난 옛날부터 할줄 알아서 다음단계로 넘어온 거거든요?"

자바스크립트는 객체 중심 언어이다.

그래서 자바스크립트는 항상 변수를 만들고, 그 변수에 인스턴스(객체형 혹은 자료형 변수)를 생성하여 담아서 이용하는 것으로 부터 시작된다.

자바스크립트의 데이터 타입의 종류는 요약하면 다음과 같다.

-숫자(number)

 ex ) var no = new Number(); (기본 값은 0)

-문자열(string)

 ex ) var str = new String();

-참거짓(boolean)

 ex ) var isTrue = new Boolean();(기본 값은 false)

-객체(object) 

  ex ) var obj = new Object();

-함수(function)

 ex ) var func = new function(){};

-배열(array)

 ex ) var arr = new Array();

-정규식(regexp)

 ex ) var reg = new RegExp();

그런데, 이 객체들을 생성 할 떄 

우리는 생성 연산자 'new'를 이용하여 생성 한 후, 그 다음 라인에

생성한 객체(혹은 자료)에 대한 정보를 추가로 담는 식으로 활용한다.

여기까지가 자바스크립트에서의 변수의 유형과 생성 방법이다.

그런데, 자바스크립트와 같은 객체 중심, 혹은 지향 언어에서는 객체의 리터럴(literal) 표기법을 지원하게 되는데,

이 리터럴이라는 것의 사전적 의미를 보면 '문자 그대로의' 라는 의미이다.

즉, (위에서 예제를 살펴봤던 순서대로) 자바스크립트에서 리터럴 표기법을 살펴보면 다음과 같다.

var no=3;

var str='';

var isTrue=true;

var obj={nation:'korea',age:15};

var func=function(){
}

var arr=[];

var reg=/[a-z]/g;

사실, 우리가 흔히 써오던 변수를 선언하고, 데이터를 담는  일반적인 방식이다.

그런데, 이렇게 쓰면 무언가 정규적이지 않고, 비 공식적인 것 같으며, 심지어

성능을 저하하는 코딩을 하고있다는 느낌이 들기도 한다.

위의 방식처럼 'new' 연산자를 이용하여 먼저 객체를 만들고, 그 값을 수정 해 나가는 것이

정규적이고, 절차를 지키는 방법이며, 성능 향상에 기여하는 것처럼 보인다. 

하지만 우리가 생각 한 것과 다르게 리터럴 표기법은 비 정규적인 (흔히 말하는 야매)도 아니고,

성능 저하를 불러오지도 않으며, 코드는 더 짧으며, 엔진의 해석 속도 면에서도 오히려 더 빠르다.

몇가지 장점이 있는데, 우선 코드가 더 짧으며, (몇 바이트, 몇 라인이라도 줄지 않겠는가?),

자바스크립트 인터프리터의 해석분량도 줄어들며,(데이터를 생성 함과 동시에 담는다. 위의 생성방식으로는 먼저

생성을 한 후, 데이터를 한땀한땀 담아야 한다.) 더 쉽고,  더 빠르다.(실제로 소위 말하는 모던브라우저들의 엔진에서는

자바스크립트의 리터럴 표기법에 대한 최적화가 되어있다고 한다.)

조금은 복잡한 내용이지만 동적 데이터 접근에 대한 호환성도 제공한다.

(이는 new 연산자를 이용하여 인자를 동적으로 제공 할 시 문제가 생기기도 한다는 이야기가 있다.)

어쨌든 결론은 '생성자 사용을 지양하고 리터럴 표기법을 사용하자'라는 것이다.

JavaScript event.keyCode 자바스크립트 이벤트 키코드표

---------------------------------------

키코드표

---------------------------------------

←(백스페이스) = 8

TAB = 9

ENTER = 13

SHIFT = 16

CTRL = 17

ALT = 18

PAUSEBREAK = 19

CAPSLOOK = 20

한/영 = 21

한자 = 25

ESC = 27

스페이스 = 32

PAGEUP = 33

PAGEDN = 34

END = 35

HOME =36

←(중간) = 37

↑(중간) = 38

→(중간) = 39

↓(중간) = 40

INSERT = 45

DELETE = 46

0 = 48

1 = 49

2 = 50

3 = 51

4 = 52

5 = 53

6 = 54

7 = 55

8 = 56

9 = 57

A = 65

B = 66

C = 67

D = 68

E = 69

F = 70

G = 71

H = 72

I = 73

J = 74

K = 75

L = 76

M = 77

N = 78

O = 79

P = 80

Q = 81

R = 82

S = 83

T = 84

U = 85

V = 86

W = 87

X = 88

Y = 89

Z = 90

윈도우(왼쪽) = 91

윈도우(오른쪽) = 92

기능키 = 93

0(오른쪽) = 96

1(오른쪽) = 97

2(오른쪽) = 98

3(오른쪽) = 99

4(오른쪽) = 100

5(오른쪽) = 101

6(오른쪽) = 102

7(오른쪽) = 103

8(오른쪽) = 104

9(오른쪽) = 105

.(오른쪽) = 110

/(오른쪽) = 111

*(오른쪽) = 106

+(오른쪽) = 107

-(오른쪽) = 109

F1 = 112

F2 = 113

F3 = 114

F4 = 115

F5 = 116

F6 = 117

F7 = 118

F8 = 119

F9 = 120

F10 = 121

F11 = 122

F12 = 123

NUMLOCK = 144

SCROLLLOCK = 145

=(중간) = 187

-(중간) = 189

`(왼쪽콤마) = 192

\(중간) = 220

비록 IE 6,7의 득세(?)로 인하여 display:inline-block을 사용 할 일은 많지 않지만,

native style이 인라인 블럭인 요소를 다루며 겪었을 몇가지 이슈를 소개하고자 한다.

(img, input 등이 있다.)

인라인 블럭 요소라 하면,

글자 그대로, 인라인 요소의 특성과 블럭 요소의 특성을 합쳐 놓은 요소라 할 수 있다.

다시말해서,

블럭 요소의 '면적 가질수 있는 것과 마진 패딩 등의 특성'과

인라인 요소의 줄바꿈 되지 않고 텍스트 처럼 취급 특성 (엄밀히 말하면 텍스트도 인라인이다. 요소가 아닐뿐..)

을 가진 요소가 인라인-블럭 요소라고 볼 수 있다.

근데 이 인라인 블럭을 다루다 보면 겪는 문제가 있다.

위 네모 박스들은  50X50의 인라인 블럭(span) 요소들이다.

분명히 마진, 패딩에 0을 주었는데 위와 같이 간격이 벌어진다.

무슨 짓을 해도 소용 없다.

우연히 부모 요소에 font-size:0을 주니 붙는다. 왜 이러한 현상이 발생할까?

십중 팔구 다음과 같이 마크업 되어 있을 것이다.

--------------------

<span></span>

<span></span>

<span></span>

<span></span>

<span></span>

<span></span>

-----------------

그렇다! 저 공백은 '엔터 한칸' 때문에 발생하는, inline-block은 텍스트 이기 때문에, 스페이스를 무시하지 못해서

발생하는 문제인 것이다. 스페이스 한칸은 font-size에 비례해서 나타나기 때문에,

font-size가 0이라면 스페이스도 0 처리되어 공백이 사라졌던 것이다.

여러가지 해결 방법이 있겠지만, 굳이 들여쓰기를 해야한다면 다음과 같이 코딩 하는 방법도 있다.

-------------

<span></span

><span></span

><span></span

><span></span

><span></span

><span></span> 

-------------

그러나 필자라면..그냥 다 붙여서 쓰고만다.

웹 퍼블리싱 분야에서 업무를 하다 보면

웹에 관련해 생겨난 몇가지 용어에 대해 혼동이 올때가 있다.

바로, '웹 표준, 웹 접근성', '크로스 브라우징' 등이다.

이 세 단어는 매우 밀접한 연관에 겹치는 부분도 있고, 잘못 사용되는 경우도 많다.

이들 용어의 간략한 정의를 살펴보면 아래와 같다.

-크로스 브라우징 : 한개의 브라우저가 아닌 여러 브라우저에서 동등한정보를 보여주는 것.

-웹 표준 : W3C 등의 표준화 기구에서 정의 해준 명세에 맞게 마크업 하는 것.

-웹 접근성 : 이용자, 이용자의 장비에 관계없이 이용할 수 있는 웹 사이트를 구성하는 것.

(시각장애인 등도 이용 할 수 있으며, 여러 PC나 장비에서도 접근 할 수 있는 웹 사이트.)

약간의 설명을 붙이자면 이렇다.

일반적으로 웹 표준은 크로스 브라우징의 상위 단계이고, 웹 접근성은 웹 표준의 상위 단계이지만,

웹 표준을 맞춘다고 해서 크로스 크라우징이 해결되는 것은 아니며, 웹 접근성은 지켰지만

웹 표준과 크로스 브라우징이 해결되는 것은 아니다.

-크로스 브라우징에서는 브라우저 마다 있는 버그나 상이한 렌더링을 해결해야 하기 때문이다.

또 크로스 브라우징은 되었지만 표준에 맞지 않을 수도 있다.

-웹 접근성에 맞게 사이트를 구성했지만 W3C의 명세에 맞지 않는 코드가 존재 할 수 있다.

이 세 가지 사항 모두 올바른 웹 페이지를 구성 하는데 있어 상당히 중요하고, 이 모두를 충족시키는 일은

그만큼 어려운 일이기도 하다.  대부분의 웹 사이트가 이 셋중 어느 한두가지, 또는 모두를 빠뜨리는 경우가 허다하다.

하지만 사명감을 가지고 있하는 프로 웹 개발자라면 이제 이 모두를 고려하여 웹 사이트를 구성 하도록 노력해야 할것이다.

HTML 파일을 브라우저 렌더링 할때 다음과 같은 순서로 렌더링한다.

<head> 태그 -> <head> 태그 내 script, link (stylesheet) 

-><body> 태그 -><body>태그 내 이미지, 문서요소

그런데.....

만약에 <head>태그 구조가 다음과 같다고 해보자>

<head>

<script src="file1.js"></script>

<script src=" file2.js"></script>

<script src=" file3.js"></script>

<script src=" file4.js"></script>

<script src=" file5.js"></script>

</head>

웹 페이지를 들어오는 사용자들은 5개의 js파일을 보기 전에는 웹페이지의 어떤 구조도,이미지도 

볼 수 없다는 말이 된다. 

일반적으로 사이트의 외관 구성은

css(link 태그) + body 태그로 구성하게 되는데, 저뒤에 숨어있는 자바스크립트 파일들이

맨 위에 위치하는 바람에 사이트가 어떻게 생겼는지를 보여주기도 전에 한참을 기다려야 하는것이다.

이에 대한 해결책으로 

yahoo에 근무하며, 'High Perfomance Web Site' 를 저술한 Steve Souder는

'put script to bottom!'(스크립트는 바닥에 넣으세요.) 라고 말했다.

즉, </body>바로 위에 스크립트 태그를 몰아넣으면, 

<head>와 <body>의 내용을 전부다 불러온 후에, 스크립트 파일을 로드하기 시작하기 때문에,

위와 같은 문제를 해결 할 수 있다.

또 한가지 방식으로는 'defer'속성인데, script에 defer 속성을 주는것이다.

<script src="file1.js" defer="defer"></script>

위와 같이 말이다. 그러면 모든 파일이 로드 된 후에 스크립트를 로드하기 시작한다.(window.onload 이벤트와 거의 동시 시작)

게다가 HTML 4.01에 포함된 표준이다! 근데 왜 </body> 위에 스크립트를 놓는 방법을 소개했는지 궁금하지 않은가?

....표준이지만.............IE에서..........만 지원된다.

인터넷 익스플로러의 장점도 찾게되고, 살다보니 별일이다.

--------------------------------------------------

 ‘Put Scripts at the Bottom‘ 에서 속도 차이를 직접 확인해보시라.

(여담이지만 script 태그를 불러오는 순서는 직렬 방식으로, 위의 예로 보면

file1.js ->file2.js -> file3.js ... 순으로 처리하지만, link 태그같은 경우는 병렬식으로 link 태그의

 스타일 시트를 불러옴과 거의 동시에 body태그를 렌더링 하기시작하므로 크게 문제가 되지 않는다.)

자바스크립트에서 조건문을 쓸 때

일반적으로 if 문 안에 true,또는 false가 올 만한

값을 넣고 사용을 한다.

하지만 자바스크립트가 허용해주는 예외가 있다.

그것은 바로 0, undefined, NaN, null , ''(빈문자열), [](빈 배열) 등 무언가 공백이나 오류를 의미하는 값은 false로 인식,

 값이 있는 상수, 값이 있는 변수 등은 true로 인식한다. 

예컨대 

if (3)

{
}

는 항상 실행되는 문장이다.

이 사실을 어떻게 활용할수 있을까?

첫번째로는 값의 존재 유무를 체크하는 것이다.

예컨대 

if (document.getElementById('test'))

{

}

라 하면, "document 상에 test라는 아이디를 가진 엘리먼트가 존재하면 중괄호내 문장을 실행"이

라는 의미가 되는것이다.

또한가지는, 우리가 흔히 사용하는

return;, 또는 return 0;

이라는 문장. 보통은 이 문장을 기점으로 이벤트를 중지시키려고 사용하지만,

return false; 가 좀더 명시적이고 올바른 표현이다.

return 0, return이 분명 자바스크립트 상에서 return false와 비슷한 효과를 주긴 하지만, 

진정한 프로그래머라면 코드의 가독성을 높이는 명시적인 코딩을 해야하지 않을까?