Frudy
6k
2020-10-13 22:59:59
7
880

마크업이 어려운 또다른 이유가 생겼어요


이것도 고민중에 하나인데요,


css문법에 좀 익숙해진거같아도 마크업 자체는 여전히 어려워요..

굳이 반응형, 크로스 브라우징, 겁나이쁜 애니메이션이 아니더라도...


마크업은 뭔가 융통성이 많이 필요한거같아요.


똑같은 글자라도,

이게 어느 페이지에서 어떤 내용을 담고있는 글자인지에 따라 처리가 다르게 되야되거든요.


예시로,

똑같이 글자가 길어져도, ...처리 해도 되는 경우가 있고 안되서 다른방법을 찾아야하는 경우가 있어요.

이걸 결정하는 요소는 "어느 페이지" 에 "어느 내용"인지에 따라 다 달라요.


무슨 테이블 구조의 UI에 회원주소가 쭉 나오는데

서울시 강남구 역삼동 어쩌구 저쩌구....... 라고 웹페이지에 나와있으면 어색하지않지만,

홍길........ 라고 웹페이지에 나오면 어색해요.


이걸 ...처리할지 다르게 처리할지 결정하는 요소는 내용이 "주소" 인지 "이름" 인지 에요.


이런 예시는 간단히 넘어가겠지만,

웹페이지에 나오는 컨텐츠 종류가 어디 뭐 한두갠가요, ㅋㅋㅋㅋㅋㅋ ㅠㅠ

보통 이런 내용은 ...처리하더라 보통 이런내용은 ...처리말고 다른방법으로 하더라 하는

경험이 쌓이기 전까지는.. 좀 어려울거같아요.


css문법 자체는 쬐끔 익숙해졌기 때문에,

누가 "이거는 길어지면 ...처리해!" 했을 때 ...처리할 수 있고

누가 "이 숫자값은 커지면 그냥 123만 이렇게 퉁쳐!" 하면 처리할 수 있는데,

...처리할지 숫자뒤에 단위붙일지를 스스로 판단하는게 아직 어려워요.



회사에서 관련문제 겪어가지고 퇴근후에 딱 2시간정도 고민했어요.


대체로 이런 종류는 ...처리하더라 대체로 이런 숫자값은 커지면 뒤에 단위붙이더라

그대신 이런 숫자값은 그러면 안되더라

근데 이런 숫자값은 절대 커질일 없으니 안-심하고 대비 안한상태로 넘어가도 되더라


이런식으로 "규칙성"을 좀 찾아보려고 했으나 실패했어요.



그대신 CSS 문법은 정확하게 공부할 수 있는 방법이 있더라구요.

오늘도, 드롭다운 남이만든거 안쓰고 직접 만들어서 회사 프로젝트에 적용시키려다가

참신하게 UI버그를 3갠가 만들었었는데, 이거 원인 분석해보면서

transition, display, visibility, opacity에 대해 공부가 많이됐어요.


약 10개월전에 transition은 이런식으로 하면 걍 잘 되더라 하는 인식 대로 10개월을 보낸줄도 몰랐어요.


뭐 암튼 12시까지 한시간정도 남았네요,

2시간 고민해도 답안나왔으니 다른 고민거리를 또 풀어봐야겠슴미다..

0
  • 댓글 7

  • 고뿌
    1k
    2020-10-13 23:27:58

    그건 마크업이 어려운게 아니라 '기획'에 안 적혀있는것을

    물어보지않고 스스로 판단해서 해야하는 '업무적 스트레스'에 가까워보이네요.

    이해는 합니다. 일일히 물어보며 하기엔 개발 텐션이 떨이지니까요.

    그럴땐, 선개발 후 기획/디자인단에서 검토시에 피드백을 주면 그때 하는것도 방법입니다.

    '아! 그렇군요!'하면서 연기력이 좀 좋아야 하죠. 마치 인지하지 못했던 부분인것처럼.

  • Frudy
    6k
    2020-10-13 23:46:46

    네? 

    다른회사는 기획서에 웹페이지의

    각 요소별로 길어졌을때 이렇게 처리하라고 까지 적어주나요?


    이게 다른회사에서는 기획자의 업무에요?

  • Frudy
    6k
    2020-10-13 23:48:06

    음... 잘못이해했네요

    ㅋㅋㅋㅋㅋ ㅠㅠ 네 그것도 방법이긴해요.

  • 고뿌
    1k
    2020-10-14 00:29:00

    텍스트량에 따른 '시각적 정책'이 개발자의 영역일리 만무하죠.

    당연히 디자이너/기획자의 영역입니다.

  • mirheeoj
    11k
    2020-10-14 01:24:37

    이미 다른 분이 답변해주셨지만, 요구사항에 없었던거라 몰랐다, 요구사항 정해주면 그렇게 하겠다 이런 식으로 하시는게 가장 합리적일 것으로 봅니다. 또는 기획단계에서 브레인스토밍이 있다면 그런 문제에 걸릴만한 부분을 미리 알려주시는 것도 방법입니다. 

    개발 중간에 임의대로 처리하면 거기서도 또 말 나옵니다. 개발자가 생각하기엔 합리적 처리방법처럼 보여도 다른 사람 입장에선 그렇지 않을 수 있기 때문입니다. 심지어 개발자끼리도 갈릴 수 있는 부분이고요. 또한 해당 부분이 예기치 않은 버그를 낳을 수도 있는데 이러면 책임소재 부분에서 굉장히 난감해질 수 있습니다. 



  • Frudy
    6k
    2020-10-14 08:53:35

    헐....

    프론트앤드 개발자 영역인줄 알았는데.......

    네 감사합니다 부담을 한결덜었어요.

  • 고뿌
    1k
    2020-10-16 00:29:28

    네? 프론트앤드 개발자 영역이요?

    텍스트량에 따른 시각적 처리 정책이라니까요...-_-;;

  • 로그인을 하시면 댓글 을 등록할 수 있습니다.