IT story

CSS가 음수 패딩을 지원하지 않는 이유는 무엇입니까?

hot-time 2020. 7. 19. 09:14
반응형

CSS가 음수 패딩을 지원하지 않는 이유는 무엇입니까?


나는 부정적인 패딩의 전망이 특정 페이지 요소의 CSS 개발이 더 쉽고 쉬워지는 데 도움이 될 수 있다고 여러 번 보았습니다. 그러나 W3C CSS에는 네거티브 패딩이 제공되지 않습니다. 이것의 이유는 무엇입니까? 재산 사용에 방해가되는 재산이 있습니까? 답변 주셔서 감사합니다.

업데이트

예를 들어, 20px의 세로 간격이있는 글꼴을 사용하고 글꼴 하단에 점선 테두리를 적용하려는 경우 (예 : 하이퍼 링크가 나타나는 경우). 이 경우 점선 테두리가 지정된 단어 아래 20px 아래에 나타나기 때문에 스타일이 너무 초라하다는 것을 알 수 있습니다. 음수 여백을 사용하면 여백이 경계 외부 영역을 변경하므로 작동하지 않습니다. 이러한 상황에서는 부정적인 패딩이 도움이 될 수 있습니다.


나는 최근 박스 모델이 왜 그런지대해 토론했던 다른 질문대답 했습니다.

박스 모델의 각 부분에는 특별한 이유가 있습니다. 패딩은 내용을 넘어 배경을 확장하기위한 것입니다. 컨테이너의 배경 축소 해야하는 경우 상위 컨테이너를 올바른 크기로 만들고 하위 요소에 음수 여백을 지정해야합니다. 이 경우 내용이 채워 지지 않고 넘칩니다.


정의에 의한 패딩은 양의 정수 (0 포함)입니다.

음수 패딩으로 인해 테두리가 내용으로 축소 될 수 있습니다 ( w3 상자 모델 페이지 참조). 이렇게하면 내용 영역이 내용보다 작게 만들어 지므로 의미가 없습니다.


negative padding유용하고 굉장한 이유에 대한 아주 좋은 예를 설명하고 싶습니다 .

CSS 개발자 모두 알고 있듯이 동적 크기 조정 div를 다른 크기로 세로로 정렬하는 것은 번거롭고 대부분 CSS를 사용하는 것만으로는 불가능한 것으로 간주됩니다. 통합으로이를 negative padding변경할 수 있습니다.

다음 HTML을 검토하십시오.

<div style="height:600px; width:100%;">
    <div class="vertical-align" style="width:100%;height:auto;" >
        This DIV's height will change based the width of the screen.
    </div>
</div>

다음 CSS를 사용하면 div외부 의 내부 내용을 세로로 가운데에 맞출 수 있습니다 div.

.vertical-align {
    position: absolute;
    top:50%;
    padding-top:-50%;
    overflow: visible;
}

설명해 줄게 ...

내부 div의 상단을 50 %로 절대적으로 배치하면 내부 div의 상단 가장자리가 외부 div의 중앙에 배치됩니다. 꽤 간단합니다. 백분율 기반 위치는 상위 요소의 내부 치수를 기준으로하기 때문 입니다.

반면 백분율 기반 패딩 은 대상 요소의 내부 크기를 기반으로합니다 . 따라서 속성을 적용하여 padding-top: -50%;내부 div의 내용을 내부 div의 내용 높이의 50 % 거리만큼 위로 이동 시켰으므로, 내부 div의 내용을 외부 div의 중앙 에 위치시키고 내부 div는 역동적입니다!

OP를 요청하면 이것이 가장 좋은 유스 케이스 일 것입니다.이 해킹을 수행 할 수 있도록 구현해야한다고 생각합니다. lol. 또는 기능을 수정하고 모든 요소에서 작동 vertical-align하는 버전을 제공 vertical-align해야합니다.


이것은 도움이 될 수 있습니다.

상자 크기 조정 CSS 속성은 계산 너비와 요소의 높이에 사용되는 기본 CSS 박스 모델을 변경하는 데 사용됩니다.

http://www.w3.org/TR/css3-ui/#box-sizing
https://developer.mozilla.org/En/CSS/Box-sizing


속이는 법이 아니라 왜 물었다.

일반적으로 초기 구현의 프로그래머의 게으름 때문에 이미 다른 기능에 더 많은 노력을 기울여 플로트와 같은 더 이상한 부작용을 제공했기 때문에 디자이너가 더 많은 요청을 받았지만 시간이 걸리지 않았습니다. 이를 허용하기 위해 FOUR 속성을 사용하여 이웃 요소에 대해 요소를 푸시 / 풀할 수 있습니다 (이제 4 개의 푸시 만, 2 개의 풀만 가져옵니다).

html이 디자인되었을 때, 잡지는 당시 이미지 주변에서 텍스트 리플 로우를 좋아했지만, 오늘날 우리는 터치 트렌드를 가지고 있기 때문에 싫어하고 공간이 많고 읽을 거리가없는 스 쿼리를 좋아합니다. 그들이 중심보다는 수레에 더 압력을 넣어 이유, 또는 그들이 같은 것을 디자인 한 수 margin-top: fill;또는 margin: average 0;단순히 아래로 내용을 정렬하거나 주위의 여분의 공간을 배포합니다.

이 경우 CSS에 :parent의사 선택기 가 부족한 동일한 이유 때문에 루프 평가를 방지하기 위해 구현되지 않았다고 생각합니다 .

엔지니어가 아닌 지금은 CSS가 요소를 한 번만 페인트하고 미래의 요소를 페인트하기 위해 몇 가지 속성을 기억하지만 이미 페인트 된 요소로 돌아 가지 않는다는 것을 알 수 있습니다.

그것이 패딩이 너비에서 계산되는 이유입니다. 페인팅을 시작할 때 사용할 수 있었던 값이기 때문입니다.

패딩에 음수 값이있는 경우 여백이 이미 설정되어있을 때 이미 정의 된 외부 한계에 영향을줍니다. 나는 아직 아무것도 칠해지지 않았지만 90 년대 기술로 천재가 만든 그림 과정이 어떻게 진행되는지 읽었을 때 바보 같은 질문을하고 "감사합니다"라고 말합니다.

웹 페이지의 요구 사항 중 하나는 웹 페이지를 표시하기 전에 시간이 걸리고 모든 것을 올바르게하기 위해 컴퓨터 리소스를 먹는 앱과 달리 빠르게 사용할 수 있어야한다는 것입니다. 웹 페이지는 적은 리소스를 사용해야하므로 모든 장치에 적합해야합니다. 가능) 바람에 스크롤됩니다.

If you see applications with complex reflowing and positioning, like InDesign, you can't scroll that fast! It takes a big effort both from processors and graphic card to jump to next pages!

So painting and calculating forward and forgetting about an element once drawn, for now it seems to be a MUST.


Fitting an Iframe inside containers will not match the size of the container. It adds about 20px of padding. Currently there is no easy way to fix this. You need javascript (http://css-tricks.com/snippets/jquery/fit-iframe-to-content/)

Negative margins would be an easy solution.


Because the designers of CSS didn't have the foresight to imagine the flexibility this would bring. There are plenty of reasons to expand the content area of a box without affecting its relationship to neighbouring elements. If you think it's not possible, put some long nowrap'd text in a box, set a width on the box, and watch how the overflowed content does nothing to the layout.

Yes, this is still relevant with CSS3 in 2019; case in point: flexbox layouts. Flexbox items' margins do not collapse, so in order to space them evenly and align them with the visual edge of the container, one must subtract the items' margins from their container's padding. If any result is < 0, you must use a negative margin on the container, or sum that negative with the existing margin. I.e. the content of the element effects how one defines the margins for it, which is backwards. Summing doesn't work cleanly when flex elements' content have margins defined in different units or are affected by a different font-size, etc.

The example below should, ideally have aligned and evenly spaced grey boxes but, sadly they aren't.

body {
  font-family: sans-serif;
  margin: 2rem;
}
body > * {
  margin: 2rem 0 0;
}
body > :first-child {
  margin-top: 0;
}
h1,
li,
p {
  padding: 10px;
  background: lightgray;
}
ul {
  list-style: none;
  display: flex;
  flex-wrap: wrap;
  padding: 0;/* just to reset */
  padding: -5px;/* would allow correct alignment */
}
li {
  flex: 1 1 auto;
  margin: 5px;
}
<h1>Cras facilisis orci ligula</h1>

<ul>
  <li>a lacinia purus porttitor eget</li>
  <li>donec ut nunc lorem</li>
  <li>duis in est dictum</li>
  <li>tempor metus non</li>
  <li>dapibus sapien</li>
  <li>phasellus bibendum tincidunt</li>
  <li>quam vitae accumsan</li>
  <li>ut interdum eget nisl in eleifend</li>
  <li>maecenas sodales interdum quam sed accumsan</li>
</ul>

<p>Fusce convallis, arcu vel elementum pulvinar, diam arcu tempus dolor, nec venenatis sapien diam non dui. Nulla mollis velit dapibus magna pellentesque, at tempor sapien blandit. Sed consectetur nec orci ac lobortis.</p>

<p>Integer nibh purus, convallis eget tincidunt id, eleifend id lectus. Vivamus tristique orci finibus, feugiat eros id, semper augue.</p>

I have encountered enough of these little issues over the years where a little negative padding would have gone a long way, but instead I'm forced to add non-semantic markup, use calc(), or CSS preprocessors which only work when the units are the same, etc.

참고URL : https://stackoverflow.com/questions/4973988/why-does-css-not-support-negative-padding

반응형