Html

7장 순수 하이퍼미디어 설계 왜 HTML인가? HTML은 세상에서 가장 인기 있는 하이퍼미디어 유형이다. HTML의 기능 텍스트 문서의 중첩 구조를 표현할 수 있다. 택스트 콘텐트와 기타 태그를 표현할 수 있다. 하이퍼미디어 컨트롤 HTML은 다음과 같은 하이퍼미디어 컨트롤을 내장하고 있다. <link>, <a>, <img>, … 플러그인 애플리케이션 의미 체계 HTML은 사람이 이해할 수 있는 문서를 다룬다. HTML은 원래의 용도 외의 목적으로 사용하기가 매우 쉽다. HTML4는 세 가지 일반 속성을 더 가진다. rel : 연결되는 리소스와 지금 리소스 사이의 관계를 정의 id : 문서 내 한 요소를 식별하는 고윳값 class : 태그의 애플리케이션 의미 체계를 전달하는 용도(속하는 클래스를 정의) 마이크로포맷 hCard같은 마이크로포맷은 HTML에 추가적인 애플리케이션 의미 체계를 더하게 해준다. hMaze 마이크로포맷 새로운 hCard같은 마이크로포맷을 정의하는 것은 쉽다. 몇개의 클래스의 의미만 정의하면된다. 마이크로데이터 마이크로데이터는 HTML 5용으로 마이크로포맷을 다듬은 것이다. 다섯 개의 새로운 속성이 있다 itemprop : 마이크로포맷이 class 속성을 사용하던 방식으로 사용 itemscope : boolean. 태그에 마이크로데이터가 있는가를 표시 itemtype : 해당 마이크로데이터의 의미를 확인할 수 있는 곳 itemid itemref 마이크로포맷을 사용할땐 class=hCard 가 붙은 태그 내부가 모두 hcard 포맷임을 알 수 있다. 마이크로데이터는 그렇지 않다. itemscope 내부는 itemtype 이 가리키는 문서로 작성되어 있다고 표현된다. 예시 1 2 3 4 5 <div itemscope itemtype="https://www.naver.com/..."> <div itemprope="cell"> ... </div> </div> 마이크로포맷은 rel로 연결 관계를 정의할 수있지만 마이크로데이터는 그렇지 않다. itemtype 문서에는 나타날 것. 리소스 상태 변경하기 스위치를 누르면 리소스의 상태와 관계가 변경된다고 해보자 이 스위치를 조작하는 요청은 하이퍼미디어로 어떻게 구현될까? 폼에 애플리케이션 의미 체계 추가하기 rel 속성은 두 리소스 사이의 관계를 나타낸다. ‘리소스 상태를 변경하라’는 의미를 가진 rel 값을 만들 수 있을까? 리소스들이 나열되고 그 리소스를 요청하는 것은 GET 요청이다. 하지만 리소스 상태 변경은 GET 요청을 쓸 수 없다. POST를 써야한다. 이때 HTML이 정의한 하이퍼미디어 폼을 사용하면 된다. 대신, rel 속성은 지원하지 않는다. 이 switch 클래스도 hMaze 마이크로포맷에 추가할 수 있겠다. 1 2 3 <form action="/switches/4" method="post"> <input class="flip" type="submit" value="Flip it!"/> </form> 하이퍼미디어의 대체재는 미디어다 요즘 API 문서들에는 많은 메서드가 개별 API 호출로 노출되고, 상세하게 문서화되어 있다. 이는 다시 말해, 사람이 읽을 문서를 하이퍼미디어 대체재로 사용하고 있다는 것이다. 사람 대신, 이 정보를 받도록 의도된 대상(소프트웨어)에 맞춰 작성해야 한다. 스위치를 나타내는 두 버전을 살펴보자 1 2 3 4 스위치를 조작하려면 다음 주소로 POST 요청을 보낸다. https://api.example.com/swithches/{id}?action=flip {id}는 스위치 ID다. 스위치가 있는 셀에 있을 때에만 스위치를 조작할 수 있다. 1 2 3 4 5 6 7 <div class="swithch"> <span class="position">down</span> <form action="/swithches/4" method="post"> <inpuit class="flip" type="submit" /> </form> </span> </div> 애초에 하이퍼미디어 컨트롤을 사용할 수 있을 때만 제시되므로, 셀에 있을때에만 조작할 수 있다는 경고문구는 제공할 필요도 없다. HTML의 제약 기술적으로 HTML은 일반 하이퍼미디어 포맷이 아니라 도메인 특화 표준이다. 여기서 발생하는 한계들이 있다 PUT, DELETE는 HTML 하이퍼미디어 컨트롤로는 표현할 수 없다. HTML 4의 폼은 두 가지 종류의 엔티티 바디만 만들 수 있다. application/x-www-form-urlencoded multipart/form-data HTML 4는 JSON과 달리 숫자와 문자열을 구분하지 않는다. HTML 4는 날짜를 표시할 방법을 정의하지 않는다. HTML5가 문제를 해결해 줄까? 보완점 날짜 문제 ⇒ time 태그로 해결 숫자 문제 ⇒ 일반적으로 동작하지 않음 몇 가지 컨트롤을 더 정의하나, 여전히 유용하지 않음 input 태그 검증을 위한 방법 정의 일부는 보완되나, 하이퍼미디어 포맷으로서의 HTML을 급격히 변화시키지는 않는다. 하이퍼텍스트 애플리케이션 언어 웹 API에 특화되어 설계된, HTML의 기본 개념인 하이퍼링크만 가져온 HAL(Hypertext Application Language)가 있다. HAL은 두 가지 방식으로 제공된다. XML(application/hal+xml) JSON(application/hal+json) HTML과 HAL의 차이 HTML에는 여러가지 경우에 따라 <a>, <img>, <form> 을 사용한다. ...

Today I Learned 날짜 2024년 4월 15일 월요일 내용 나는 이메일 템플릿 만드는 기계다. 오늘 하루에만 무려 4개의 템플릿을 만들었다. 이정도면 스스로를 템플릿 공장이라고 불러도 될까? 물론 택도 없다. 개선해야 할 부분이 있기 때문이다. 공통 footer를 따로 처리하지 않았다. 모든 이메일 템플릿이 동일한 footer를 적용하는데 다 복붙했다. 별도의 html로 만들고 include 했어야 했는데.. 그러지 못한 이유는 footer를 포함하여 템플릿 전체를 하나의 table로 처리했기 때문이다. 시간이 허락한다면 분리 작업을 해야겠다. padding을 사용하지 않았다. 그동안 나름 터득한 방법은 여백이나 줄 간격, padding을 테이블의 한 요소(행 또는 열)로 처리하는 것이었다. 이에 대한 설명은 2월 16일 TIL을 참고하자. 어쩄든, 기존에 작성된 이메일 템플릿은 이 경우를 테이블의 열을 나타내는 td 에 style로 padding-left, padding-top등을 먹이는 방식이었다. 시간이 허락한다면 고쳐야겠다. 회고 하지만 시간은 쉽게 허락해주지 않음. ...

Today I Learned 날짜 2024년 3월 28일 목요일 내용 새로운 스프린트를 시작해야 하지만 이전 것에 발목잡혔다. 이메일 HTML 이메일의 내용이 조건에 따라 달라지도록 구현했다. 기능 자체는 작동이 되는데, 여러모로 디테일이 많이 부족했다. 두 선이 겹친듯 안겹친듯 출력된다 던가, 옆 마진이나 패딩이 다르다던가…. 한 번 할 때 신경써서 세세하게 할껄. 삭제 로직 어드민 내에서 앱을 삭제할 수 있는 기능을 추가했지만 이상하게 작동이 안됐다. 알고보니, 삭제 과정에서 이유를 저장하는 테이블에 데이터를 저장해야하는데, 테스트 서버에 마이그레이션을 까먹어서 저장을 못해 오류처리 되는 문제였다. 항상 병합 후 취해야 하는 조치가 있다면 꼭 기록해두자. ...

Today I Learned 날짜 2024년 3월 26일 화요일 내용 다 고쳤다고 생각했는데, 이젠 위젯 수정 과정에서 발생한 오류들이… 위젯 수정 후 렌더링 썸네일 렌더링과는 별개로, 처음 위젯을 생성할 때는 상품의 썸네일 이미지도 가져와서 설정하는 로직이 있다. 그런데, 이미 존재하는 위젯을 수정하는 과정에서 상품을 추가할 때는 썸네일을 가져오지 않았다. 추가해주었다. 레이아웃 수정 행,열의 값이나 레이아웃 형태를 변경하면 위젯이 고장나버리는 문제가 있었다. 디자인 옵션은 받은 값을 통채로 덮어씌워져서 개별 값이 문제가 될 리가 없었다. 로그를 확인해보니 currency가 문제가 있었다. 뜬금없이 애는 또 왜…. ...

Today I Learned 날짜 2024년 2월 16일 금요일 내용 Email Template를 깨달은 남자 난 더이상 Email에 담을 HTML을 만드는 게 두렵지 않다. 깨달아버렸기 때문이다. 2가지 과정에서 깨달음이 있었다. Div가 아닌 Table 이메일 서버가 HTML을 출력할 때 의도하지 않게 해석하는 경우가 많다. <head> 나 <body>를 읽지 않는 경우도 많고 <div>를 제대로 처리하지 않아 padding이나 margin이 엉망이 되기도 한다. 검색해보면 가장 많이 나오는 말은 <table>, <tr>, <td> 태그를 사용하라는 것. 이 태그는 테이블을 만드는데 사용되는데, tr은 table row의 약자로 행을 의미하고 td는 table data로 행 내에 들어갈 정보를 의미한다. 사실 가로(열)로 이해해도 무방하다. ...

Today I Learned 날짜 2024년 2월 15일 목요일 내용 앱을 삭제한 스토어의 데이터에 접근하는 법 은 없었다. Shopify partner에게 답변이 왔는데, webhook 시그널의 전달과 access token 무효화는 비동기적으로 발생해서 접근할 수 없다고 한다. 당장은 방법이 없어, 우리 서버 내 데이터만 삭제하는 걸로 Task를 종료했다. 아름다운 사람은 머문 자리도 아름답다는 누군가의 말처럼, 우리가 삭제된 이후에 우리의 흔적을 남기지 않도록 하고 싶은데 마땅한 방법이 떠오르지 않는다. 앱을 삭제하는건 Shopify 쪽에서 발생하는 일이라 우리가 제어할 수 있는 방법이 없다. 미래를 볼 순 없는 노릇이니 삭제할 만한 shop을 고를 수도 없고.. 삭제 이후에는 재설치하지 않는 한 access_token을 얻을 수 없는데 어찌해야 할까.. 짱구좀 굴려봐야겠다. ...

Today I Learned 날짜 2024년 1월 12일 금요일 내용 타운홀미팅이 있어 오전밖에 시간이 없었다. 딱히 시간이 있었다고 해결이 됐을 것 같진 않지만.. SEO HTML의 <meta> 태그는 해당 페이지에 대한 다양한 정보를 표현하기 위해 사용한다. 쉬운 부분이라 다들 알겠지만, 나는 속성에 대해 몰랐던 부분이 있었는데, title 속성은 없다. meta가 아니라 head에 title 태그를 추가하면 된다. 최근 keyword 속성은 잘 쓰지 않는다. 너도 나도 이것 저것 추가를 많이 하다보니 알고리즘이 신경쓰지 않는다고 한다. description : 뭔가 읽기 편하고, 간결한게 좋을 것 같지만 사실 최근에는 검색의 핵심이다. 타겟 유저가 검색에 포함할 법한 단어가 포함되어 있는 것이 좋다. 따라서 동어반복은 좋지 않다. 그렇다고, 말이 안되는 단순 단어 나열만 작성하면 알고리즘이 무시한다. 이정도…? 구글 검색 봇의 마음은 참 갈대같다. ...

Today I learned 날짜 2024년 1월 2일 요일 내용 올해 첫 업무 시작. Email CSS 고객에게 발송할 이메일 양식 HTML 의 CSS를 계속 진행하고 있다. 위아래에 margin이 적용되지 않았다. 구글링 결과, 플랫폼이나 브라우저 마다 Email Template 렌더링이 제각각이라는 말이 많았고 특히 부모의position 을 relative 로 두고 자식을 absolute 로 두었을 때 위치가 적용되는지에 대해 너무 의견이 분분했다. 나는 템플릿을 table로 구성해두었는데, table의 위치에 margin 을 적용하지 않고 빈 셀 하나를 추가해주는 방식으로 구현했다. ...

Today I learned 날짜 2023년 12월 29일 금요일 내용 어제 막힌 난점은 해결했다. 도커 컨테이너 내에서 스크립트를 실행하니 메일은 발송되었다. 딱히 추가로 건드려야 할 설정이나 변수는 없었다. 기존에는 안되었는데, 로직상 가져온 데이터가 없었기 떄문에 발송되지 않았던 모양이다. 로컬 DB에는 테스트를 위한 적절한 리뷰 데이터가 없기 떄문에, 메일에 담을 데이터들을 임의의 값으로 지정해주었더니 헤결됐다. 수신자를 내 이메일로 설정해서, 어떤 화면이 고객이 보게 되는지 확실히 볼 수 있었다. HTML에 데이터를 담는 것도 금방 해결되었는데, 이미 우리 서비스에 Jinja2 템플릿을 사용하고 있었기 때문이다. 그냥 양식에 맞춰 변수를 집어넣기만 해주었다. 생각지도 못한 부분에서 하루종일 고생했는데, 이메일에 담길 HTML을 로컬에서 열어보았을 떄와 메일로 받아보았을 떄가 다르다. local에선 적용된 padding이 안되있는 경우라던가, 예상 외의 상황이 많다. 이러한 특징은 각 메일 플랫폼별로 모두 다르다고 한다. 고객이 네이버, 구글, 아웃룩 등 받을 곳은 무궁무진한데 출력되는 형식이 매번 달라지니 이메일 만드는게 쉽지 않은 것 같다. 난 그냥 CSS도 못하는데… ...

Today I Learned 날짜 2023년 12월 14일 목요일 내용 테스트 서버에 데모버전 어드민 페이지 기능이 배포되었다. 환경변수 이전 TIL에서도 언급했듯, 유저에게 체험할 기회를 줄 데모 쇼핑몰과 데모 어드민 사이트는 우리가 환경변수로 계정 정보를 설정해야 했다. 이 계정 정보가 Shopify인지, 알파리뷰인지가 헷갈렸다. local에서 입력했던 정보로 알파리뷰와 Shopify 에서 각각 로그인했을 때, Shopify에서만 로그인이 되길래 Shopify 계정 정보라고 생각했다. 그런데, “우리가 Shopify 계정을 검증할 수 없는데 왜 받아야 하는가?”에 대해 대답할 수 없었다. 관련 코드를 열심히 찾다가 내가 간과했던 사실을 깨달았다. 데모버전 로그인에서는 비밀번호에 대한 검증 로직을 지웠다! 계정 정보를 우리가 설정한다는 이유로 지웠던 기억이 이제야 났다. 내가 테스트 했던 계정은 같은 ID로 알파리뷰와 Shopify에 모두 가입되어있다보니 헷갈렸던 문제였다. ...