IE6, IE7에서 display:inline-block 사용하기 css 이야기 2012. 11. 20. 01:45
HTML 코딩을 하다보면

CSS의

display:inline-block

속성을 사용하고 싶을 때가 종종 있지만,

늘상 IE6, IE7 때문에 포기하고 만다.

IE6, IE7에서는 inline-block을

그냥 block으로 인식해버리기 때문이다.

그러나 IE6, 7에서도 inline-block을 사용 할 수 있다!

block을 inline-block으로 바꿔도 block으로 인식되는 문제가 있는데,

반면에 inline인 요소를 inline-block으로 바꿀 때는 문제가 되지 않는다.

IE6,7에서는 다음과 같이 속성을 주면 block을 inline-block으로 바꾸어 사용 할 수 있다.

div{display:inline-block;zoom:1;*display:inline/*IE7 HACK*/;
_display:inline;/*IE6 HACK*/}

이제 인라인 블럭을 사용하여 마크업을 해보자.



저작자표시

'css 이야기' 카테고리의 다른 글

CSS로 엘리먼트 회전시키기  (0) 2013.02.01
,
HTML 렌더링 순서에 따른 <script> 태그 사용 권장사항 html 이야기 2012. 11. 19. 00:18

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태그를 렌더링 하기시작하므로 크게 문제가 되지 않는다.)

저작자표시

'html 이야기' 카테고리의 다른 글

익스플로러에서만 이미지 엑스박스가 뜰 때  (0) 2013.01.06
내 홈페이지, 파비콘 적용하기  (0) 2012.12.18
inline-block 요소에 관한 고찰  (0) 2012.12.09
블록 요소 vs 인라인 요소  (4) 2012.11.11
HEAD> META 태그 총정리  (1) 2012.11.10
,
자바스크립트에서 false를 의미하는 것, 그리고 true를 의미하는것. JavaScript 이야기 2012. 11. 17. 00:20

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


일반적으로 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와 비슷한 효과를 주긴 하지만, 


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

저작자표시

'JavaScript 이야기' 카테고리의 다른 글

null과 undefined의 차이  (3) 2013.01.13
자바스크립트로 이미지 새로고침 하기  (0) 2013.01.05
자바스크립트 객체 생성과 리터럴 표기법  (0) 2012.12.17
자바스크립트 키코드  (0) 2012.12.14
자바스크립트에서 변수 타입에 관한 몇가지 알짜상식  (0) 2012.11.17
,
자바스크립트에서 변수 타입에 관한 몇가지 알짜상식 JavaScript 이야기 2012. 11. 17. 00:13

자바스크립트는 변수 타입에 대한 설정이 상당히 관대한 언어이다.


어떤 변수 타입에 관한 잘못을 저질렀을때 자바스크립트는 오류를 내보내는 것 대신에


숫자는 문자로, 문자는 또 숫자, 기타 등등 으로 상황에 따라 적절(?)하게 변화시켜준다.


필자가 코딩을 하며 경험한 자바스크립트 변수 타입 오토캐스팅에 관한 몇가지 사실들을 공유하고자 한다.


법칙 1) 문자열 + 숫자 ->숫자가 더해진 문자열


예컨대


var x='abc';

var y=3;

alert(x+y);     // 'abc3' 출력


가장 기본적인 사실로, 대부분의 웹개발자가 할고있는 사실이다.


법칙 2) 비교연산자를 사용할 때 숫자vs문자를비교하면 문자열을 자동으로 숫자로 변환하여 비교해준다.


3>'4'를 비교하면 false라는 결과가 출력될 것이다.


법칙 3) 비교연산자를 사용할 때 문자열인 숫자 둘을 비교할 때,

자릿수가 같으면 올바로 연산을 해주나, 자릿수가 다르면 문자열로 인식하여 비교한다.


예컨대 '3000'>'2500'의 결과는 true이나, '3000'>'500'은 false이다.


----> 자바스크립트에서 문자열을 비교할 때는 문자열의 유니코드 값을 비교한다.

'3000'>'500'인 이유는 3보다 5가 유니코드 값이 더 크기때문이다.


법칙 4) 두 식중 하나가 NaN이면 항상 false를 반환한다.


물론 이경우는 숫자와 문자열을 비교했을때 자바스크립트가 믄자열인쪽을 숫자로


변환하다 NaN이 등장했을 경우이다.



저작자표시

'JavaScript 이야기' 카테고리의 다른 글

null과 undefined의 차이  (3) 2013.01.13
자바스크립트로 이미지 새로고침 하기  (0) 2013.01.05
자바스크립트 객체 생성과 리터럴 표기법  (0) 2012.12.17
자바스크립트 키코드  (0) 2012.12.14
자바스크립트에서 false를 의미하는 것, 그리고 true를 의미하는것.  (0) 2012.11.17
,
서버단? 클라이언트단? 개발 이야기 2012. 11. 13. 00:41

이 바닥에 있으면서 출처가 명확하지 않은 단어들이 업계에서 사용되는 걸 보고 처음에 의아해한 적이 있는데 그게 바로 '서버단', '클라이언트단', '네트워크단'이다. '단'은 여러군데에서 사용되고 있어 그 의미가 정확히 무슨 뜻인지 아느냐고 물어보면 다들 "그냥 그렇게들 쓰고 있는데요?" 하며 개의치 않는 분위기이다.


처음 '단'에 관한 이야기를 들었을 때 어떤 개발 영역의 단체를 뜻하는 것으로 생각했었다.


예를 들어 사람들이 '클라이언트단' 이라고 할 때에는 '클라이언트단에서 처리할 것이 별로 없다. 다만 서버단에 부하가 많다는 게 문제이다'와 같이 이야기한다고 하자. 여기서 쓰이는 '단'은 왠지 '집합'적 의미가 있어 보인다. 그럼 '둥글 단(團)'을 쓰는 게 맞는 것처럼 보인다. 예를 들어 사기단, 사절단, 도박단, 사업단 같은 것처럼. 하지만 '측'이라는 의미도 매우 강해보인다. 인용한 부분을 '측'으로 치환하면 '클라이언트측에서 처리할 것이 별로 없다. 다만 서버측에서 부하가 많다는 게 문제이다'처럼 말이 가능해진다. 그렇다면 '측'이 맞는 말이 아닐까?

아쉽겠지만 위의 논의와는 전혀 상관없이 사실 이 '측'과 '단'의 문제는 실제로는 영어 번역에서 온 문제이다. '측'은 'side'를 번역할 때 온 것으로 한자로는 '곁 측(側)'을 쓴다. '단'은 'level'을 번역할 때 온 것으로 한자로는 '층계 단(段)'을 쓴다. 즉 '클라이언트단', '서버단'은 각각 'client level'과 'server level'의 번역인 셈이다.

'측'은 대립되는 사물의 어느 한 쪽을 나타낼 때, '단'은 '계단'에서처럼 여러 개로 나뉘어진 경우에 쓴다.

따라서 엄밀히 말하면 예로 들었던 '클라이언트단에서 처리할 것이 별로 없다. 다만 서버단에 부하가 많다는 게 문제이다'라는 말은 다시 말하면 '데이터가 클라이언트를 거쳐 서버를 거친 후 어디론가 가는데, 클라이언트를 거칠 때에는 처리할 게 별로 없지만 서버를 거칠 때에는 처리가 많아 부하가 많다.'는 말로 풀어서 쓸 수가 있다.

그런데... 사실 '단'을 쓰는 게 그다지 안 어울리는 건 사실이다. 계단, 상단, 중단, 하단이라는 말은 그간 사용되어 온 말이기 때문에 어울리지만 '클라이언트단'은 왠지 어딘가 모르게 어색하다. '계층'이라는 말은 'layer'라는 말에 대한 번역으로 쓰이고 있기 때문에 이도 어쩔 수 없고 대표적인 level의 한국어 번역인 '수준'이라는 말을 쓸 수도 있지만 '수준'이라는 말이 가져다주는 뉘앙스, 이를테면 '수준이 낮다', '수준이 높다'처럼 상당히 위화적인 표현으로 대한민국 사회에서 굳어져 있어 알맞지 않다.

차라리 '단계'라는 말이 좀더 어울리지 않을까?


아직 수년차에도 접어들지 못한 초보 개발자이지만 직관적이고 익숙해지지 않아도 어색하지 않을수 있는, 입문자들도 쉽게 이해할수 있는 개발용어가 사용되길 기대해본다.

저작자표시

'개발 이야기' 카테고리의 다른 글

웹 표준, 웹 접근성은 퍼블리셔의 기득권을 위해 존재하는 것이 아니다.  (2) 2013.02.08
IT 개발자들이 매트릭스에서 깨어나길 바라며  (0) 2013.01.16
개발자와 퍼블리셔를 나누지 마세요!  (29) 2012.12.17
프론트엔드 개발자에 대한 고찰  (3) 2012.11.12
front-end 개발자 vs back-end 개발자?  (2) 2012.11.08
,
프론트엔드 개발자에 대한 고찰 개발 이야기 2012. 11. 12. 11:47

누구나 알다시피 최근 웹 기술의 경향은 단연 클라이언트 쪽에 집중되어 있다.

수 년전을 비교해 보면 엄청난 변화이다. 웹 개발은 크게 프론트엔드와 백엔드로 나누어져 있지만, 국내에서는 프론트엔드 보다 백엔드 개발자 흔히 '웹 프로그래머' 혹은 '웹 개발자'라고 부르는 사람들의 가치가 더 높았다. 다시 말해서 몸값이 더 비쌌다는 이야기다.

하지만, 웹 프론트엔드가 더 복잡해지고 다양한 기술이 쏟아지면서, 프론트엔드 개발자에 대한 수요와 가치가 증가하였고, 이쪽 기술 직군의 정의가 점점 어려워지고있다.

과거 프론트엔드 개발자는 백엔드 개발을 할 기술이 없거나 그 전단계에 하는 견습 정도로 여겨지곤 했었는데, 이와 달리 현재에는 백엔드 개발이 어려워서 이거나 프론트엔드 개발이 쉬워서가 아닌 프론트엔드 개발 자체가 좋아서 프론트에 남아서 개발을 하는 개발자가 많다. 


웹 프론트엔드 직군이란?

2000년대 초반만 하더라도 웹 개발에서는 웹마스터, 웹개발자, 웹디자이너로 나눠져 있었다. 대부분 웹 디자이너가 마크업을 담당했는데, (웹 표준 마크업의 주요성이 덜할 당시) 효율성을 위해 웹 디자이너가 만든 PSD 파일을 짤라서 HTML로 코딩만 하는 'HTML 코더'라는 직종이 있었다.

하지만, 2000년대 중반 부터 웹 표준 마크업의 중요성이 대두되면서 포털 업계를 중심으로 'UI 개발' 직군이 중요한 화두로 떠 오른다. (X)HTML과 CSS를 중심으로 DOM을 핸들링하는 자바스크립트까지 다루는 기술셋을 가진 개발자들이다.


역할에 따른 모델 제안
분명한 사실은 HTML/CSS/JS 기술을 떠난 프론트엔드 개발은 불가능하다. 요즘에는 게임도 웹으로 만들고 2D/3D 그래픽도 웹으로 하는 시대다.

 

 

습득 요구 지식

특징 

   HTML 코더

 HTML, CSS

 테이블 기반 코딩을 주로 하는 2000년대 초반의 프론트 엔드 개발자가 주로 HTML 코더였는데, 현재 업계에서도 어느정도 남아있는것 같다.

   웹 퍼블리셔

 HTML, CSS, 

웹표준, 웹접근성, 크로스 브라우징

 웹 표준이 중시되면서 생기기 시작한 직군. HTML,CSS를 이용한 페이지를 출판하는 일을 한다. 

   UI 개발자

 HTML,CSS, 웹표준, JavaScript

웹 표준에 기반한 사용자 UI를 개발한다 

   RIA 개발자

 플래시, FLEX, AIR, Silverlight

데스크탑 리치기술을 이용하여 보다 다양하고 인터랙티브한 웹사이트를 만드는 직군. 

   프론트 엔드 개발자

상위 능력 전반과 백엔드 영역 능통 

프론트 엔드 개발자라고 적어놓고 위 능력들을 고루 갖추었다고 써놓았는데, 사실 그렇다고 위에 있는 개발자들이 프론트 엔드 개발자가 아니라는 것은아니다. 필자 개인적인 생각으로 이정도는 해야..진정한 프론트엔드 개발자라고 할수있지않을까하는 개인적은 생각을 반영하여 작성해보았다. 



위에서부터 순차적으로 습득 요구 지식이 어느정도 누적 되는 것을 볼수있는데, 


코더 -> 웹퍼블리셔 -> UI개발자 -> (RIA개발자) ->Front-End 개발자


순으로 능력을 덧붙이며 한단계씩 발전한다는 느낌이 강하다.


필자 개인적인 생각으로


HTML 코더나 웹 퍼블리셔 역시도 프론트 엔드 개발자라는 생각은 변함이 없고, HTML,CSS를 등한시 하는것은 아니지만,


HTML,CSS만 할줄 아는 사람과 HTML,CSS,JS를 모두 하는 사람을 동등하게 바라볼 생각은 없기에,


웹 퍼블리셔 까지는(HTML코더는 더더욱,) 미완성의 프론트 엔드 개발자가 아닐까 생각해본다.


[웹 퍼블리셔가 프론트 엔드 개발의 제일 윗단으로, 기획과 디자이너와의 조율을 한다는 견해도 있으나, 필자 경험상 그런 역할은 주로 PL이 맡아서 하는 경우가 대부분이었다.]



웹 FT의 미래는 더 밝다!
프론트엔드 개발자보다 백엔드 개발자들의 몸값이 높고, 백엔드 중에서도 자바나 닷넷 개발자가 PHP나 Python을 쓰는 개발자 보다 몸값이 높은 아이러니한 상황은 국내만의 이상한 현상이다. (웃긴 건 Yahoo, Facebook , Twitter모두 PHP를 주력 개발 언어로 쓴다.)

아직도 "HTML이나 자바스크립트 하는게 뭔 개발이야?"라고 하는 분들께 나는 꼭 이 한마디를 보태 드린다. "구글에서는 아이비리그 나온 박사들도 다 HTML이랑 자바스크립트 해야 하거든요?"







저작자표시

'개발 이야기' 카테고리의 다른 글

웹 표준, 웹 접근성은 퍼블리셔의 기득권을 위해 존재하는 것이 아니다.  (2) 2013.02.08
IT 개발자들이 매트릭스에서 깨어나길 바라며  (0) 2013.01.16
개발자와 퍼블리셔를 나누지 마세요!  (29) 2012.12.17
서버단? 클라이언트단?  (6) 2012.11.13
front-end 개발자 vs back-end 개발자?  (2) 2012.11.08
,
블록 요소 vs 인라인 요소 html 이야기 2012. 11. 11. 03:16


항목 

인라인 

블록

인라인-블록

   영역

 컨텐츠 크기 만큼

지정 값 또는

지정 안할시 너비는 부모의 가로 크기, 세로는 컨텐츠 크기

지정 값 또는 지정 안할시 너비는 

   정렬

텍스트 정렬에 영향 받음.

(텍스트의 위치를 지정하는 모든 속성) 

마진(auto), 패딩 이용

(테이블 내의 경우 verertical aline)

 텍스트 정렬에 영향 받음.

(텍스트의 위치를 지정하는 모든 속성) 

   박스모델

margin-left,right / padding, border ,float

margin(width 값 고정일 때 auto 지정 가능),

padding,border ,float

margin(auto 불가),padding,border ,float

   중첩 요소

 인라인만 가능

블록,인라인 모두 가능 

인라인만 가능 

   특징

포지션이 텍스트와 

유사하게 처리된다.

(vertical-align 영향 받음)

 양 옆에 요소를 둘수 없다.

포지션이 텍스트와 유사하게 처리된다.

(vertical-align 영향 받음) 

   대표 엘리먼트

span, a, strong, em 

div, h1~6, p,  ul, li 

img, input 



여기까지 인라인, 블록, 인라인 블록에 대하여 살펴보았는데, 여기서 빼놓지 말아야 할 중요한 사실이 있다.


첫째. 바로 블록 요소 또는 인라인 요소 안에 어떤 요소를 중첩 시킬수 있느냐의 문제인데,

위 표에서는 블록 안에는 블록,인라인 모두 가능하고 인라인,안에는 인라인만 가능하다고 쓰여있는데 좀더 생각해볼 필요가 있

다.


1.인라인 내부에 인라인을 쓰더라도 문제가 되는 경우


의미만을 주거나 스타일만을 주는, 예컨대 strong, font, em, b, i등의 인라인 요소 안에는


다른 인라인 요소를 중첩 시켜서는 안된다.


가령, <i><a href="#">여기</a></i>

와 같은 중첩은 잘못이다. (여러의미, 스타일을 동시에 주기위한 중첩은 가능,


가령 <i><b>bold italic</b></i> 로 두효과를 주기위해 사용가능하다.)


2.블록 내부에 블록을 쓰더라도 문제가 되는 경우


다른 문제는 없지만, p,h1~6 류는 블록요소들이지만 다른 블록 요소를 중첩시킬수 없다.'


(+추가, ul,ol,dl 등 목록 밑에는 지정된 요소가 들어가야 한다.

예컨대 ul,ol 밑에는 li만을, dl 밑에는 dt,dd이다. 여담이지만 dt,dd,li 아래로는 예외없이 사용가능하다.)


3.강제로 display를 바꾼 경우의 문제


강제로 display를 바꿨더라도, 그 속성의 원래 속성을 상정한 후, 위 규칙을 따른다.


가령 span이 블록 요소가 되더라도 안에 div, p 등을 중첩해서는 안되고,


div가 인라인 요소가 되더라도 a 태그 안에 중첩될수 없다.


->validator 통과상 문제이기에 유효성 검사기는 그요소의 현재 display를 체크해주지는 않기 때문인데,


단순히 유효성 검사상 문제 떄문에 위 규칙을 지켜야 하는 것은 아니고, 조금 엄격한 브라우저에서는


레이아웃이 뒤틀리게 보여질수 있기 때문이다. 


(필자 같은 경우 span안에 div를 넣고 IE8에서 레이아웃이 틀어지는 것을 보고

무작정 IE8 탓만 한적이 있다. 그것은 IE가 나쁜것이 아닌 필자가 마크업을 잘못했기 때문이다. 아, 물론 IE8이 좋은브라우저 라는것은 아니다..^^;)


둘째는 float에 관한 문제인데,(자세한 이야기는 CSS이야기 탭에서 합시다.^^)


블록 요소에 float을 주기 전에, 기본적으로 width 값을 설정해 주는것이 맞다. 그러나 지정하지 않으면

마치 인라인에서 너비를 결정할 때 컨텐츠 크기로 결정하는 것처럼 컨텐츠 크기가 가로 사이즈가 된다.

(IE6같은 경우는 너비를 주지않고 float할 경우 문제가 발생한다.

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


이상으로 인라인 ,블록 요소에 대해 정리해 보았는데,


나름 필자가 공부하면서 헷갈렸던 것 위주로 정리해보았다. 마크업을 하는데 있어


상당히 중요한 사실이지만 빼놓고 가기 쉬운부분이니 확실하게 알아두도록 하자.

저작자표시

'html 이야기' 카테고리의 다른 글

익스플로러에서만 이미지 엑스박스가 뜰 때  (0) 2013.01.06
내 홈페이지, 파비콘 적용하기  (0) 2012.12.18
inline-block 요소에 관한 고찰  (0) 2012.12.09
HTML 렌더링 순서에 따른 <script> 태그 사용 권장사항  (2) 2012.11.19
HEAD> META 태그 총정리  (1) 2012.11.10
,
HEAD> META 태그 총정리 html 이야기 2012. 11. 10. 20:31

*문자 인코딩


<meta http-equiv="Content-Type" content="text/html; charset=euc-kr">

 

*일정 시간이 지난 후 자동으로 페이지 새로고침


<meta http-equiv="Refresh" content="시간(초)">

 

*일정 시간이 지난 후 자동으로 페이지 이동


<meta http-equiv="Refresh" content="시간(초);url=주소">

 

*검색엔진에서 검색되는 키워드


<meta name="Keywords" content="html,tag,mata,메타,태그">

 

*캐쉬 막기


<meta http-equiv="Pragma" content="no-cache">


*캐쉬 만료(파기)일


<meta http-equiv="Expires" content="Mon, 08 Sep 2003 10:10:10 GMT">

** 보통 캐쉬막을때 <meta http-equiv="Expires" content="0"> 사용

 

페이지 들어갈때 나갈때  트랜지션 효과


<meta http-equiv="Page-Enter" content="revealtrans(duration=1,transition=12)">
<meta http-equiv="Page-Exit" content="revealtrans(duration=1,transition=12)">

 

페이지에 대한 정보


<meta name="Description" content="META 태그에 관한 정보">

 

컨텐츠 제작자


<meta name="Author" content="이름">

 

제작 툴


<meta name="Generator" content="Ultra Edit">


저작권 정보


<meta name="Copyright" content="2012 이나라학생">


<meta name="format-detection" content="telephone=no">

 

[출처] meta tag 총정리|작성자 노원오디

'html 이야기' 카테고리의 다른 글

익스플로러에서만 이미지 엑스박스가 뜰 때  (0) 2013.01.06
내 홈페이지, 파비콘 적용하기  (0) 2012.12.18
inline-block 요소에 관한 고찰  (0) 2012.12.09
HTML 렌더링 순서에 따른 <script> 태그 사용 권장사항  (2) 2012.11.19
블록 요소 vs 인라인 요소  (4) 2012.11.11
,
함수의 아규먼트와 파라미터의 차이 프로그래밍 이야기 2012. 11. 10. 13:47


아규먼트(argument) 와 파라미터(parameter) 흔히들 구분하지 않고 사용한다.

하지만 이 둘은 분명히 차이가 있다.


PARAMETER란?


한글 그대로 번역하면 '매개변수'란 뜻이다. 즉,


함수를 정의 할 때

외부로부터 받아들이는 임의의 값을 의미한다.

가령 

function f(x,y){

return x+y;

};

에서 x,y가 파라미터라고 할수 있다.

 그럼 ARGUMENT란?

우리말로는 '인수' 라고 번역되는데,

함수를 호출할 때 이 때 사용하게 되는 일련의 값들을 아규먼트라고 부른다.

예컨대 위에 파라미터의 예를 들었던 함수를 호출한다고 하면,

f(3,4);

에서 3,4등이 아규먼트이다.


즉, '파라미터의 값으로 아규먼트 3과 4를 대입하였다'

라는 의미가 성립하는것이다.


이처럼 파라미터와 아규먼트는 분명 같은위치에 있지만 다른의미로 쓰이는 것을 알수 있다.



'프로그래밍 이야기' 카테고리의 다른 글

카멜 표기법(Camel Casing Notation)  (0) 2012.12.18
,
2012년 국내 웹 브라우저 점유율 웹표준 이야기 2012. 11. 8. 22:02

 

국내 시장 특성상 아직은 IE의 점유율이 떨어질줄 모르지만

개발자 입장으로선 IE7만 사라져 준다면........

(사실 2년 전만해도 'IE6만 사라져준다면......'하고 빌었었는데.

사람의 욕심이란 이렇게 무섭다.)

지금 IE7의 점유율을 보니 국내에서 IE7이 사라질날도 머지않은듯 하다.

그래도 아직은.......IE8까지는..사라져주었으면 하는 욕심이.......

아니 IE보다는 다른 Modern Browser가 우리나라에서도 적극적으로

이용되는 날이 왔으면 하는 바램이다.

'웹표준 이야기' 카테고리의 다른 글

'웹 표준'에 관한 오해  (0) 2012.12.22
웹 표준, 웹 접근성, 크로스 브라우징,에 대한 바른 의미  (1) 2012.12.09
,

티스토리툴바