it-swarm-ru.tech

Почему CSS не поддерживает отрицательный отступ?

Я много раз видел, что перспектива негативного заполнения может помочь разработке CSS определенных элементов страницы стать лучше и проще. Тем не менее, в W3C CSS нет положения для отрицательного заполнения. В чем причина этого? Есть ли какие-либо препятствия для собственности, которые препятствуют ее использованию как таковой? Спасибо за ваши ответы.

ОБНОВЛЕНИЕ

Как я вижу, например, если вы используете шрифт, который имеет что-то, скажем, 20 пикселей по вертикали, и вы хотите применить пунктирную границу к нижней части шрифта, например, при появлении гиперссылки. В таких случаях стиль будет слишком потертым, поскольку пунктирная граница появится на 20 пикселей ниже указанного Word. если вы используете отрицательное поле, оно не будет работать, так как поле изменяет область за пределами границ. Отрицательный отступ может помочь в таких ситуациях.

116
ikartik90

Я недавно ответил на другой вопрос где я обсуждал почему модель бокса такая, какая она есть.

Есть конкретные причины для каждой части блочной модели. Padding предназначен для расширения фона за пределы его содержимого. Если вам нужно уменьшить фон контейнера, вы должны сделать родительский контейнер правильного размера и дать дочернему элементу некоторые отрицательные поля. В этом случае содержимое не padded, оно переполнено.

77
zzzzBov

Заполнение по определению является положительным целым числом (включая 0).

Отрицательное заполнение может привести к тому, что граница будет свернута в контент (см. box-model page на w3) - это сделает область контента меньше контента, что не имеет смысла.

5
Oded

Я хотел бы описать очень хороший пример того, почему 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;
}

Позвольте мне объяснить ...

Абсолютное расположение верхней части внутреннего блока на 50% помещает верхний край внутреннего блока в центр внешнего блока. Довольно просто Это потому, что процентное позиционирование относительно внутренних размеров родительского элемента .

Процентное заполнение , с другой стороны, основано на внутренних размерах целевого элемента . Таким образом, применяя свойство padding-top: -50%;, мы сместили содержимое внутреннего элемента div вверх на 50% высоты содержимого внутреннего элемента div, поэтому центрировали содержимое внутреннего элемента div во внешнем элементе div и все еще позволяя высоту размерность внутреннего div должна быть динамичной!

Если вы спросите меня «OP», это будет лучший вариант использования, и я думаю, что он должен быть реализован именно так, чтобы я мог сделать этот взлом. лол. Или они должны просто исправить функциональность vertical-align и предоставить нам версию vertical-align, которая работает со всеми элементами.

3
WebWanderer

Это может помочь, кстати:

Свойство CSS box-sizing используется для изменения блочной модели CSS по умолчанию, используемой для вычисления ширины и высоты элементов.

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

1
Rolf

Вы спросили, ПОЧЕМУ, а не как его обмануть

Обычно из-за лени программистов начальной реализации, потому что они уже приложили больше усилий в других функциях, предоставляя более странные побочные эффекты, такие как float, потому что они были более востребованы дизайнерами в то время, и все же они не потратили время чтобы разрешить это, мы можем использовать свойства FOUR для перемещения/вытягивания элемента против его соседей (теперь у нас есть только четыре для Push и только 2 для pull).

Когда разрабатывался html, журналам тогда нравился текст, перерисованный вокруг изображений, а теперь ненавидимый, потому что сегодня у нас есть сенсорные тренды, и нам нравятся мелкие вещи с большим количеством места и нечего читать. Вот почему они оказывают большее давление на поплавки, чем на центрирование, или они могли бы создать что-то вроде margin-top: fill; или margin: average 0;, чтобы просто выровнять контент по дну или распределить его дополнительное пространство вокруг.

В этом случае я думаю, что он не был реализован по той же причине, по которой в CSS отсутствует псевдо-селектор :parent: для предотвращения зацикливания вычислений.

Не будучи инженером, я могу видеть, что CSS прямо сейчас создан для рисования элементов один раз, помня некоторые свойства для будущих элементов, которые будут нарисованы, но НИКОГДА не возвращаясь к уже нарисованным элементам.

Вот почему (я думаю) отступы рассчитываются по ширине, потому что это значение было доступно на момент начала его рисования.

Если бы у вас было отрицательное значение для отступа, это повлияло бы на внешние пределы, которые уже были определены, когда маржа уже была установлена. Я знаю, еще ничего не нарисовано, но когда вы читаете, как проходит процесс рисования, созданный гениями с технологией 90-х, я чувствую, что задаю глупые вопросы и просто говорю «спасибо», хе-хе.

Одним из требований к веб-страницам является то, что они быстро доступны, в отличие от приложения, которое может не торопиться и использовать ресурсы компьютера, чтобы получить все правильно, прежде чем отображать его, веб-страницы должны использовать небольшие ресурсы (поэтому они подходят для каждого устройства возможно) и прокручиваться на ветру.

Если вы видите приложения со сложными перекомпоновками и позиционированием, например, InDesign, вы не сможете прокрутить так быстро! Чтобы перейти на следующие страницы, нужно много усилий как от процессоров, так и от графических карт!

Таким образом, рисование и расчет вперед и забывание об элементе, который был нарисован, сейчас кажется, что это ОБЯЗАТЕЛЬНО.

1
sergio

Потому что у разработчиков CSS не было предвидения представить гибкость, которую это принесло бы. Существует множество причин для расширения области содержимого блока, не влияя на его отношение к соседним элементам. Если вы считаете, что это невозможно, поместите длинный текст nowrapd в блок, установите ширину блока и посмотрите, как переполненное содержимое не влияет на макет.

Да, это все еще актуально для CSS3 в 2019 году; Показательный пример: макеты flexbox. Поля элементов Flexbox не сворачиваются, поэтому, чтобы расположить их равномерно и выровнять по визуальному краю контейнера, необходимо вычесть поля элементов из отступов их контейнера. Если какой-либо результат <0, вы должны использовать отрицательную маржу для контейнера или суммировать эту отрицательную маржу с существующей маржей. То есть содержимое элемента влияет на то, как для него определяются поля, то есть наоборот. Суммирование не работает должным образом, когда содержимое элементов Flex имеет поля, определенные в разных единицах, или зависит от размера шрифта и т.д.

В приведенном ниже примере в идеале должны быть выровненные и равномерно расположенные серые поля, но, к сожалению, это не так.

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>

За эти годы я столкнулся с достаточным количеством этих небольших проблем, когда небольшое отрицательное заполнение прошло бы долгий путь, но вместо этого я вынужден добавить несемантическую разметку, использовать calc() или CSS-препроцессоры, которые работают, только когда единицы являются то же самое и т. д.

0
Walf

Установка Iframe внутри контейнеров не будет соответствовать размеру контейнера. Это добавляет около 20px отступов. В настоящее время нет простого способа исправить это. Вам нужен JavaScript ( http://css-tricks.com/snippets/jquery/fit-iframe-to-content/ )

Отрицательные поля будут легким решением.

0
john ktejik