CSS 20주년

§

웹문서에서의 css 사용이 처음으로 발표된 시점은 1996년 12월 중순 이었습니다. 그래서 올해가 css 가 출시된지 20주년이 되는 해 입니다.

css_20_years

제가 처음 css 를 접한게 1999년 말이나 2000년도 초 였던 것 같습니다. 제 로펌 사이트를 처음 구축할 때였는데, 플래시와 테이블로 짜여진 레이아웃들 사이에 약간의 css 가 낑겨들어가 있었습니다. ㅋㅋㅋ

그 당시 css 의 모습은 html 태그와 크게 다르지 않았습니다. 텍스트 크기 조정이라던지 색상을 입히는 수준의 간단한 모습이었기 때문에, html 태그 사용을 할 줄 안다면 누구나 쉽게 이해할 수 있는 모습이었습니다.

제가 웹사이트에 가장 처음 손을 댄 부분은 text-indent 였습니다. css 지식이 부족한 제 로펌 사이트 개발회사에서 첫 문단에 tab (들여쓰기?) 을 구현 하기 위해 투명한 gif 를 끼워 넣었는데, 이걸 빼버리고 css 로 text-indent 를 준게 제가 웹에서 가장 먼저 작업한 부분이었습니다. 지금와서 생각해보니, 저는 html 보다 css 를 더 먼저 작성한 셈 입니다. ㅋㅋㅋ

당시 css 가 정말 복잡해 질 수 있는 부분은 레이아웃이었는데, 그때는 누구나 다 테이블 코딩 일색이었기 때문에 css 가 크게 복잡해 질수도 없었던 때 입니다.

웹문서를 구축하는데 있어 살짝살짝 양념정도로 사용되었던 거죠.

그리고 css 는 세번의 큰 변화가 있었습니다.

1. float 모델을 사용한 페이지 레이아웃 사용시작

2. css3

3. 반응형 웹

한국 개발자 분들 중에는 몇년전까지도 css 로 레이아웃을 짜는 방법에 적응하지 못해 끝까지 테이블 코딩에 이미지를 덕지덕지 붙이는 방법을 고수하는 분들이 계셨었습니다. (그누보드의 경우 불과 2-3년전까지도 테이블 코딩으로 만들어진 모습을 고수하기도 했었습니다.)

또 css3는, “그거 IE 에서는 작동안되서 못써” 라며 아예 배우는 것 자체에 관심을 두지 않는 분들이 대부분이셨고.

평생 IE 는 W3C 규격에 맞추지 않을 것 같았지만, IE9 부터 마소는 W3C 규격에 맞는 브라우져를 만들어내는 노력을 하기 시작하며, 큰 변화가 일어나기 시작했고, 더구나 테이블 코딩에서는 구현이 불가능에 가까운 반응형 기법이 일반화 되며, 테이블 코딩 하시던 분들은 은퇴하시고 치킨을 튀기게 되셨습니다.

20년이 지난 지금의 css 는 어떤 모습일까요?

일단 적용자체가 pre-processor 와 post-processor 를 통해 refactoring 되어야 하는 경우가 많고, variable 과 mixins 같은 프로그래밍 개념이 도입되었으며 extend, nesting, grid, flexbox 모델 등, 불과 몇년전과 비교해도 상당히 복잡해졌습니다.

제대로 기초를 닦고 입문하는데만 6개월 정도의 시간이 소요된다고 합니다. (물론 그 후 부터는 크로스 브라우징의 생지옥이 시작되겠죠. ㅋㅋㅋ)

저 같은 경우 css 가 어렵다고 느껴본적이 한번도 없었던 이유가 거의 15-6년동안 아주 조금씩 노하우가 쌓여온거라 반응형 css 를 익혀야 했을때 조금 불편함 (?) 을 느꼈던 것 빼놓거는, 매우 순탄했습니다. ㅎㅎ

코딩을 하기전 눈으로 코딩을 하는 수준이 되어 버려서 아마 죽을때 까지도 css 는 절대 안 잊어 버릴듯 합니다. 한창 일할때는 하루에 천줄 가까운 css 를 뽑아내기도 했었습니다. 지금도 4-500줄 정도는 쉽게 뽑습니다.

함정은, 돈받는 일이 아니면 한줄도 작성하기가 싫다는. . . >.

css_level4

앞으로의 css 는?

W3C 에서 Selectors Level 4 를 발표한지 3년이나 지났지만, 아직 브라우져 vendor 들이 기술지원을 하지 못해 활용화 되고 있지는 못합니다. Selectors Level 4 에서는 css 가 자스 (javascript) 수준으로 DOM 을 찝어낼 수 있는 수준이 되어 버리기때문에, 좋게 보면 css 의 기능이 더욱더 강력해 지는 것 이고, 나쁘게 보면 입문해야 하는 문턱이 더 높아지게 됩니다.

지금도 css 는 거의 준 프로그래밍 언어 수준으로 보게 되는데, Selectors Level 4 가 활성화 되기 시작하면 css 는 하나의 고유 언어로 자리잡게 될 것 같습니다.

hackya 는

Attorney, front-end developer, digital media artist, WordPress enthusiast, & a father of 4 wonderful children.

Tags: ,

카테고리: ,

Ω

8 Comments

  • 7사단 says:

    핵캬님 글을 보면 항상 공부해야 할 내용이 생겨나는 신기한 마술이.. ㅠㅠㅠ

    레벨4 라는 것도 공부해야 하는군요. 흠냐…

    • Matthew says:

      네. Selectors Level 4 는 벌써 크롬이나 IE Edge 에서 많이 적용되어 있는 상태입니다. 아직 IE 11 사용자들이 있으니까 IE 11 믿고 Level 4 나중에 배워도 되지 라고 생각하지 마세요.

      아차 싶으면 벌써 늦어버려서 나중에 멘붕오십니다.

      ES6 공부는 잘 하고 계신가요? 저는 괴롭고 있습니다. ㅠㅠㅠㅠ 진도가 안나가네요. ‘jQuery 를 ES6 로 바꿔주는 변환기가 있으면 얼마나 좋을까’ 하는 개멍청하고 말도 안되는 상상이나 합니다. ㅋㅋㅋㅋ

  • Jin says:

    최근에 그누보드로 만들어진 사이트를 워드프레스 기반으로 옮겼는데 테이블코딩때문에 옮긴 글들이 워드프레스에서 레이아웃이 다 깨져서 난리도 아니었죠 ㅠ 지금은 jquery로 스타일을 동적으로 다 제거했습니다. db에서 원본글을 regex로 다 수정해야지 해놓고 귀찮아서 계속 jquery로만 냅두고 있네요 ㅎㅎ

    저도 이제 막 프론트엔드 개발자로 입문하려고 하는데 CSS3가 생각만큼 쉽지 않아서 고생하고 있습니다. ㅠ 독학이라 누구한테 물어볼것도 없어서 항상 이 블로그에 많은 도움을 받고 있습니다.

    • Matthew says:

      front-end 절대 어렵지 않습니다. 단지 괴로울 뿐 입니다. 그리고 눈치싸움 (?), 줄잘서기 (?) 이런 부분도 완전 ㅎ ㄷ ㄷ 합니다.

      자스는 말할 것 도 없고, css 만 해도, SASS 나 LESS 냐 를 선택을 했어야 하는데, LESS 노선을 탄 개발자들은 완전 망했거든요.

      또 SASS 도, 그냥 SASS 냐 SCSS 냐 를 놓고 결정해야 했는데, 그냥 SASS 에 남았던 사람들은 낙동강 오리알 되었고.

      그런데 이제는 또 SASS 고 SCSS 고, 둘다 필요없고, postCSS 로 가야 한다는.

      모듈 빌드/bundle 같은 경우도 NPM 이냐 Bower 냐 Browserify 냐 Gulp 냐 Grunt 냐 Webpack 이냐를 놓고 결정을 해야 했는데, 최종승자는 Webpack 이고 그나마 NPM 은 생존하게 된 수준.

      저는 오랜기간의 얘기를 하는게 아닙니다. 불과 지난 2-3년 동안 선택해야 했던 노선들을 말씀드리는 겁니다.

      이래서 front-end 가 괴롭습니다. css 는 그나마 좀 선택을 해야 하는 노선이 단순한거고, 자스는, ….

      그냥 이글 구글 번역기로 번역해서 보시면, 자스가 지금 어떤 상태인지 대략 감이 오실 것 같습니다.

      https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.2el1xit1n

      No JavaScript frameworks were created during the writing of this article. ( 이글을 쓰는 동안 새로은 자스 프레임워크가 출시 되지 않았습니다.) 라고 본글에 적혀있는걸 반박하는 댓글이 베플 먹은. ㅋㅋㅋ

      무려 1,800명으로 부터 호감을 얻었는데, 이게 웃기면서도 눈물나는거죠.

      요즘 front-end 는 완전 빛의 속도로 발전하고 있어서, 현업들도 하루에 1-2 시간 무조건 공부해야 합니다.

      front-end 는 완전 밑빠진 독에 물붙기 라고 생각합니다. 현재로서는 희망도 끝도 보이지 않습니다. 온힘을 다해 발버둥 쳐야 겨우 물위에 떠있을 수 있는 그런 기분?

      완전 절망적 입니다.

      • jtmoon says:

        백엔드에 비하면(물론 백엔드 추세도 그리 한가한건 아닙니다만 ㅠㅠ) 프론트엔드는 정말 빛의 속도로 기술이 발전하고 있어서 정말 뭐부터 공부해야할지 감도 안잡히는게 요즘 현실입니다 ㅠㅠ
        전 개인적으로 이런 상황일수록 pure한 자스랑 css를 더 열심히 파야 한다고 생각해요. css를 대체할 bss가 나타나고, 자스가 뜬금없이 사장되고 새로운 스크립트 언어가 생겨나는 등 패러다임의 전환이 이루어 지지 않는한, 결국 자스와 css의 프레임워크들이 생겨날게 뻔히 보이거든요 ㅋㅋ

        • Matthew says:

          css 프레임워크가 몇개 존재하는데, 저는 그런 제품들을 보며 한숨만 나옵니다. 완전 극혐이거든요. 편의성을 제공한다며 그렇지않아도 복잡해질 수 있는 css 를 더 복잡하게 만들어 놓은!!!

          그리고 그런 css 프레임워크를 쓰게 되면 그 개발자는 css 가 어떻게 작동되는지에 대한 본질? 에서 더 멀어져서 오히려 css 를 더 이해하지 못하게 됩니다. 그래서 저는 css 프레임워크에 대해 상당히 좋지 않게 생각합니다. 필요없는, 사용도 하지 않을 css 를 달고 다니게 되니 로딩속도도 더 느려지고, 백해무익한 사악한 제품이라고 생각합니다.

          비슷한 류로 부트스트랩이 존재합니다. (아, 비슷한게 아니라 부트스트랩은 css 프레임워크 보다 더 나쁜 제품이죠.)

          저도 쓴글이 있는데,

          http://hackya.com/kr/부트스트랩은-과연-백해무익한-것-일까/

          이글도 좋습니다.

          http://est0que.tistory.com/2128

          자스는, 저 같은 경우 너무 오랫동안 jQuery 에 안주해 있었고 자스 공부를 게을리 했었어서, (jQuery 가 다 해주니까 따로 자스 공부할 이유가 없었거든요) 지금 완전 멘붕인 상태입니다.

          업친데 덥친격으로 지금 ES6 (새로운 자스 규격) 까지 익혀야 하는… OTL 하… babel 로 죽어라고 compile 만 하고 있다는. ㅠㅠㅠㅠ 돌아버리겠습니다.

  • Estoque says:

    css shape를 쓰셨군요

    아주 예전에 제가 인디자인을 처음 배우던 시절에 image knock out을 배우면서 CSS도 이런게 되면 얼마나 좋을까 라는 생각을 했었는데 말이죠 ㅋㅋ

    그래도 아직까지 출판 소프트웨어랑 비교해볼때 웹이 아직 부족한게 많은 것은 사실이지만 얼마 지나지 않아 거의 근접한 수준으로 올라올거라고 예상됩니다. ㅎㅎ

    • Matthew says:

      인디자인은 image knock out 보다는 image wrap around (텍스트로 이미지 를 감싸는 방법, 제가 위에 css shape 으로 구사한 것 과 동일한) 기법을 구사하기가 편합니다.

      image know out 은 포토샵에서 쉽게 만들 수 있고, css 로는 clip-path 로 구현가능합니다.

      물론 IE 에서는 Edge 에서도 지원하지 않아서

      http://caniuse.com/#search=clip-path

      무용지물이죠. OTL

      이래서 제가 IE 만든 인간들 찾아가서 다 죽여버리고 싶은 살인충동을 느낄때가…. ㅋㅋㅋ

Leave a Reply

Your email address will not be published. Required fields are marked *