alt w <tag한번에 감싸기>
한번에 다른줄 선택
방향키로 옮기기 alt + 방향키
한줄삭제 cmd +del
스페이스 ? 들어가게 ?
" " : 공백(스페이스 한 칸)을 의미.
띄어쓰기를 할 때는 키보드의 스페이스키(가장 길쭉한 키)를 한 번 눌러 "공백 문자" 즉 빈 칸을 한 개 삽입합니다. 그런데 HTML 문법에서는, 일반 텍스트 편집에서와 달리, 공백 2개를 연속으로 사용해도 2칸을 띄어쓸 수 없습니다. 공백을 아무리 많이 삽입해도 공백 1개로 간주됩니다. 그래서 공백을 여러 개 사용해야 할 때는, 빈 칸을 이렇게 표현해 줍니다. 그러면 브라우저가 기호를 빈 칸으로 표시해 줍니다.
예제:
aaa bbb
이렇게 aaa와 bbb 사이에 공백을 4칸 넣어줄 때에는
aaa bbb
이렇게 합니다. 진짜 공백과 기호를 번갈아서 쓰면 됩니다.
정규표현식으로 어떻게 다듬을 것인가? 회원과 관련된 페이지 12~15페이지 정도 나온다.
table
th
tr
td
인라인에서 블록으로 바꾸면, 요소 display (inline)를 block으로 지정한다 해도, 그 안에
일반적으로 인라인 요소들은 인라인 요소만 중첩이 가능하다.인라인 요소의 정렬은 텍스트 정렬읭 ㅕㅇ향을 받는다. 대표적인 인라인 요소로는 span, strong 등 존재
span안에 p 태그 (x)
hr태그, p태그는 블럭요소
구획이 나뉘어질 떄 사용 (상위레벨로 생각하면 됨 -qhek) 블럭 레벨 확인해보기. 
CSS ( cascading style sheets )
HTML을 꾸며주는 살에 해당.
선택자(selector)
property(속성)
value(값)
선언(declaration) color:yellow;
(세미콜론 붙여야 한다)
선언블록은 중괄호로 묶을 것
article{
font-family:'맑은 고딕';
}
세미콜론으로 끝을 알리기 떄문에 한줄로 이어서 쓸 수 있다. 하지만 가독성을 위해서, 특별한 경우가 아니라면 권장하지 않음.
내부 css : html head에 로 넣은 것
외부 css : 외부 css파일 생성해서 <
외부 css 보다 내부 css가 더 우선순위가 높습니다!
인라인>내부>외부 순서로 생각해주시면 될 것 같아요
<style>
@import url("016.css");
</style> import로 부를 때, 뭘 먼저 줘야하는지
reset css >>
피그마에서 alt누르고 클릭하면 간격볼 수 있음. 그거대로 코딩하면 됨.
피그마 *가서 주어진대로 만들어보기!
Reset css : 모든 css초기화시켜서 원하는 디자인 만들 수 있다.
피그마에서 다른 마우스 커서 숨길 때 사용하는 단축키입니당
- Window : [ctrl] + [alt] + \
- Mac : [option] + [command] + \ 공백처리, 주석
/ ~ /주석 처리.
h1{ black;
}
벤더프리픽스 알아서 그것에 맞게 작성해주는 자동완성 사이트 존재 . id는 페이지에서 한번만.
class는 여러번 사용가능
a href="#id이름">
#만 넣으면 아이디가 없다는 의미 특정페이지 #eval 식으로 되어있음(최상단 아닌 페이지)
원래는 최상단을 봐야하는데 , indexing할 때도 아이디 잘 사용해야 한다./* 바로 밑에 있는 p태그만 적용해라 */ li>p{ color: blue; }
<!DOCTYPE html> <html lang="ko"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>형제 선택자</title> <style> h1+ul+ul{ color: red; } </style> </head> <body> <h1>hello world</h1> <ul> <li>hello</li> <li>hello</li> <li>hello</li> <li>hello</li> </ul> <ul> <li>hello</li> <li>hello</li> <li>hello</li> <li>hello</li> </ul> </body> </html>
h1 인접한 ul -> ul의 색을 바꿔줘라. 2번째 ul 색 달라짐
일반 형제 선택자
h1~ul {} 앞 요소 이후 나오는 모든 요소 스타일 적용
속성 선택자
https://youtu.be/fXIoeZ-h43c
selector연습
https://flukeout.github.io/
## 가상 클래스 선택자
실제로 html에 존재하지 않는 클래스지만 마치 클래스를 놓은것 처럼 작동한다고 하여 가상 클래스 선택자로 부름- 1
- 2
- 3
- 4
- 5
ineternet explorer 지원종료!
가상요소 선택자는 콜론이 2개, 간혹 가상요소 선택지에 1개
vieport ->
우선순위 계산해주는 사이트
0 0 0 0 적어놓고 우선순위 계산
id> class> tag순으로 style적용됨
https://specificity.keegan.st/
bootstrap 무료 템플릿 ->5달러면 3천~4천 페이지줌
우선순위에 따라 스타일 안먹힐 수 있기에 ! 중요하다.
스타일 안먹히면 color:red !important; (긴급상황시 ). 원래는 쓰면 안됨~!
동일한 우선순위면 마지막 적용. 동일한 tag아니면 id>class>tag 순으로 적용된다.
픽셀 -
하나의색만 표현할 수있는 빔이 있는데 모니터 뒤에서 쏜다고 생각.
rem : root기준 배율입니다. html의 최상위 태그가 이기때문에 html을 기준으로 하는거구요^^
em : 부모에게 상속받은 글자사이즈 기준 배율입니다. ^^ 꼭 를 지칭하는건 아니구요, 부모요소에게 상속받은 값 기준이예요
em 은 부모의 영향받음
rem은 부모보다는
img의 면적?에 따라 적절한 이미지 한개를 보여주는 srcset 공부가 더 필요해보임.
https://heropy.blog/2019/06/16/html-img-srcset-and-sizes/
첫 번째, srcset 속성은 ‘이미지 소스의 세트’라는 의미입니다.
같은 비율의 다양한 크기를 가지는 동일 이미지들을 최소 2개 이상 명시하는 속성이죠.
만약 1개 이미지 소스만 명시하려면 src 속성을 사용하시면 됩니다.
두 번째, 제가 본문과 댓글에서 지속해서 강조하고 있는데,
srcset 속성은 브라우저에 이미지 선택권을 위임하는 속성으로,
개발자는 어느 환경에서 어떤 크기의 이미지가 선택될 것인지 알 필요가 없으며, 알더라도 그냥 모르는 척하는 것이 정신 건강에 좋습니다.
수많은 사용자 환경의 각 브라우저는 사용자에게 최적 크기의 이미지를 보여주기 위해 항상 노력하고 있습니다.
그러다 보니 대표적으로 브라우저가 큰 이미지를 한 번 불러왔으면, 오히려 해상도가 떨어지는 작은 이미지를 또 불러올 필요를 느끼지 못해 뷰포트 크기가 변경되어도 이미지 갱신이 일어나지 않는다고 보시면 됩니다.
이미지를 불러오는 행위는 네트워크, 메모리, 성능, 시간 등의 여러 비용을 지불해야 하기 때문입니다.
그런 이유에서 앞서 ‘같은 비율의 다양한 크기를 가지는 동일 이미지들’이란 표현을 사용했고요.
세 번째, 다른 비율의 다양한 크기의 다른 이미지들을 사용하고 싶다면,
IMG 요소의 srcset 속성이 아닌 CSS의 @media(미디어쿼리 혹은 미디어 규칙) 사용을 권장합니다.
개발자가 원하는 해상도에 맞게 출력할 결과를 정확히 명시할 수 있기 때문이죠.
기타 이유는 ‘두 번째’ 설명과 같습니다.
네 번째, x와 w 디스크립터는 개발자가 브라우저에 이미지의 크기를 알려주는 용도의 단위입니다.
‘두 번째’ 설명에서 말씀드린대로 이미지 로드는 지불할 비용이 크기 때문에,
브라우저가 비용 지불 없이도 이미지의 크기를 알 수 있도록 개발자가 x 혹은 w 디스크립터로 이미지 크기를 명시하는 것입니다.
따라서 이미지의 정확한 크기를 확인하고 입력하는 것이 중요합니다.
다섯 번째, Mac에서는 많은 경우 디스플레이 해상도로 ‘스케일링’을 사용합니다.
쉽게 말씀드리면, 디스플레이 확대/축소 비율이 100%가 아니고 120%, 150% 같은 확대된 해상도라는 겁니다.
Windows도 같은 기능이 있습니다만 기본 옵션이 아닌 경우가 많아 말씀드리고자 하는 현상이 덜합니다.
모두 OS 디스플레이 옵션에서 해당 내용을 확인할 수 있는데요.
특히 Mac의 경우 정확한 해상도 수치로 옵션 선택이 안되다 보니 문제 해결과 이해에 어려움을 겪는 경우가 많은 듯합니다.
그래서 Mac에서는 RDM(https://github.com/avibrazil/RDM) 같은 프로그램을 사용하시는 것도 좋습니다.
아무튼 디스플레이가 확대/축소된 경우, 이미지도 그에 맞게 확대/축소된 크기로 렌더링을 해야 하는데요.
그러다 보면 확대/축소 일부 구간에서 이미지가 흐려지는 현상이 발생합니다.
대부분의 이미지는 비트맵 방식(jpg, png, gif 등)이고 픽셀 단위로 렌더링 되다 보니 발생하는 현상입니다.
그런데 일부 브라우저는 이 현상을 해결하기 위해 이미지 비율을 임의로 조정합니다.
예를 들어, 141% 확대된 이미지라면 150%로 출력한다는 것이죠.
그래서 해당 뷰포트 크기에서 원하는 이미지가 나오지 않을 수 있는 겁니다.
그 외 ‘두 번째’ 내용도 같이 발생할 수 있고요.
여섯 번째, x와 w 디스크립터는 필요에 맞게 사용하는 것이지, 더 좋고 나쁨의 단위는 아닙니다.
제가 아는 바로는 w 디스크립터가 비교적 더 최신 기술이고, 그 전에 많이 사용된 x 디스크립터에 관련된 정보가 훨씬 많습니다.
아이폰이 3에서 4로 넘어가면서 3과 4를 동시에 지원해야 하니 iOS 개발에 필요한 이미지를 특정 배수 크기로 요구하기 시작했고,
(예를 들어 image.png와 image@2x.png를 동시에 관리해야 했죠)
이후 수많은 모바일 개발에서 배수 방식을 사용하면서 x 디스크립터가 유용해졌죠.
그리고 그것을 API로 요구하는 경우도 있고요.
그래서 x와 w 디스크립터 사용에 대한 입장이 일부 나뉘는 듯한데요, 저의 생각은 이렇습니다.
‘일반적인 웹 개발 경우에 꼭 배수(x)로 작성할 필요 없이 그냥 w 디스크립터로 다양한 이미지를 제공하면, 브라우저가 이미지를 선택할 권한이 있으니 알아서 필요한 이미지를 사용하지 않을까?! 단, 개발 요구사항이 x 디스크립터라면 필수로 작성해야지!’
수많은 사용자 환경이 동일한 배수 이미지를 요구하는 것이 아니기 때문에 개발자는 모든 환경에 대응한 이미지를 준비할 수 없고 그만큼 w 디스크립터가 중요해졌다고 생각합니다.
그리고 w는 ‘Width’를 의미하는데요, 그러면 ‘Height’를 의미하는 h 디스크립터는 없느냐?
실제 h 디스크립터 도입을 논의하긴 했지만, 여러 문제로 폐기되었는데요, 그 문제 중 하나가 바로 사용과 인지의 복잡성입니다.
결론적으로 개발자는 w 디스크립터를 사용해 이미지의 가로 너비만 명확하게 명시하면, 수많은 사용자 환경에 대한 대응은 브라우저가 알아서 할 것이니 고민을 덜 해도 된다는 겁니다.
