반응형
우리는 최근에 Elad Shechter와 그의 새로운 CSS 리셋에 대해 이야기했고, 그 직후 Josh Comau는 그의 블로그에 글을 올렸습니다.
지금은 CSS 리셋의 새로운 시대에 와 있습니다. CSS 리셋이 필요하지 않으신가요? 기본 스타일링에 대한 브라우저 간의 큰 차이는 많지 않으며, 스타일링을 끄고 실행할 때쯤이면 스팀롤을 사용하여 제자리에 배치했을 것입니다. 따라서 "현대적" CSS 리셋은 모든 새 프로젝트에서 유용한 작업을 수행하는 의견화된 기본 스타일 모음에 가깝습니다. 왜냐하면, 그게 바로 여러분이 원하는 방식이기 때문입니다.
Josh의 선택들을 살펴본 결과, 저에게는 그렇게 보입니다: 디자인에 대해 특별히 의견이 정해져 있지 않지만, 거의 모든 프로젝트가 원하는 것이 되어 디자인을 보조합니다.
의 뜨거운 의견을 쏟아낼 거야
*, *::before, *::after {
box-sizing: border-box;
}*, *::before, *::after {
box-sizing: border-box;
}Heck yes. We used to consider this a global holiday ’round here. Although, with more and more layout being handled by grid and flexbox, I’m feeling like this is slightly less useful these days. When you’re setting up a layout with `fr` units and flexin’ stuff, the `box-sizing` model doesn’t come into play all that much, even when `padding` and `border` are involved. But hey, I still prefer it to be in place. I do think if it goes into a CSS reset it should use the inheritance model though, as it’s easier to undo on a component that way.* {
margin: 0;
}* {
margin: 0;
}This is basically why the CSS-Tricks logo “star” exists. I used to love this little snippet in my CSS resets. There was a period where it started to feel heavy-handed, but I think I’m back to liking it. I like how explicit you have to be when applying any margin at all. Personally, I’d rock `padding: 0;` too, as list elements tend to have some padding pushing them around. If you’re nuking spacing stuff, may as well nuke it all.html, body {
height: 100%;
}html, body {
height: 100%;
}아마 좋은 계획일 거야 Josh는 "어플리케이션에서 백분율 기반 높이를 허용"이라고 말하는데, 저는 이것이 요즘 제 하루 일과에서 많이 나오지는 않지만, 신체 배경과 같은 것들이 여러분이 예상할 수 있는 공간을 채우지 못하는 것입니다.
Too bad `body { height: 100vh; }` isn’t enough here, but I feel like that’s not as reliable for some reason I can’t think of right now. Maybe something to do with the footer navigation in iOS Safari?body {
line-height: 1.5;
-webkit-font-smoothing: antialiased;
}body {
line-height: 1.5;
-webkit-font-smoothing: antialiased;
}I can’t get into the `-webkit-font-smoothing: antialiased;` thing. I think it tends to make type dramatically thin and I don’t love it. I don’t mind it as a tool, but I wouldn’t globally apply it on all my projects.I also generally like to put global typographic sizing stuff on the `html` selector instead, just because the “root” part of `rem` implies the `<html>` element — not the `<body>` — and I like sizing stuff in `rem` and then adjusting the root `font-size` at the root level in media queries.That `1.5` value feels like a good default `line-height` (more of a 1.4 guy myself, but I’d rather go up than down). But as soon as it’s set, I feel magnetically pulled into reducing it for heading elements where it’s always too much. That could happen via `h1, h2, h3` kinda selectors (maybe `h4`–`h6` don’t need it), but Josh has some CSS trickery at work with this snippet that didn’t make it into the final reset:* {
line-height: calc(1em + 0.5rem);
}* {
line-height: calc(1em + 0.5rem);
}That’s clever in how the `0.5rem` goes a long way for small type, but isn’t as big of an influence for large type. I could see trying that on a greenfield project. Prior art here is by Jesús Ricarte in “Using calc to figure out optimal line-height.”img, picture, video, canvas, svg {
display: block;
max-width: 100%;
}img, picture, video, canvas, svg {
display: block;
max-width: 100%;
}Good move for a CSS reset. The `block` display type there prevents those annoying `line-height` gaps that always kill me. And you almost never want any of these media blocks to be wider than the parent. I somehow don’t think `picture` is necessary, though, as it’s not really a style-able block? Could be wrong. I’d probably toss `iframe` and `object` in there as well.p, h1, h2, h3, h4, h5, h6 {
overflow-wrap: break-word;
}p, h1, h2, h3, h4, h5, h6 {
overflow-wrap: break-word;
}Good move for sure. It’s bad news when a long word (like a URL) forces an element wide and borks a layout. I tend to chuck this on something — like `article` or `.text-content` or something — and let it cascade into that whole area (which would also catch text that happens to be contained in an improper element), but I don’t mind seeing it on specific text elements.If doing that, you probably wanna chuck `li, dl, dt, blockquote` on that chain. Despite having attempted to research this several times (here’s a playground), I still don’t 100% know what the right cocktail of line-wrapping properties is best to use. There is `word-break: break-word;` that I think is basically the same thing. And I think it’s generally best to use `hyphens: auto;` too… right??#root, #__next {
isolation: isolate;
}#root, #__next {
isolation: isolate;
}여기서 무슨 일이 벌어지는지 잘 모르겠어요. 앱을 이러한 루트에 마운트하는 리액트/넥스트(Response/Next)라는 것은 이해합니다. 그리고 스택 컨텍스트를 만드는 것은 이러한 레벨에서 스택 컨텍스트를 만드는 것이 왜 특별히 유용한지 모르겠습니다. 동시에, 저 역시 특별한 문제는 없는 것 같습니다.
전반적으로, 꽤 멋져! 저는 항상 다른 사람들이 CSS 리셋을 위해 무엇을 사용하는지 보는 것을 즐깁니다.
'css' 카테고리의 다른 글
| CSS를 사용하여 클레이모피즘 만들기 (0) | 2022.01.13 |
|---|---|
| JavaScript 페이지 스크롤 진행률 표시줄 (0) | 2022.01.13 |
| 새 컨테이너 쿼리 폴리필(Polyfill)만 작동합니다. (0) | 2022.01.10 |
| 레인보우() 사용 (0) | 2022.01.10 |
| 애덤 아가일의 병든 마우스 아웃 CSS 호버 효과 (0) | 2022.01.10 |
댓글