По личному опыту могу сказать, что так иногда поступают после тестирования сайта на разных платформах.
В отличие от мака, где скролл смотрится минималистично, на винде и линуксе по дефолту он немного несуразный.
Так и получается, что какой-нибудь менджер проекта заворачивает эту мелочь и просит сделать кастомный скролл, который бы вписывался в дизайн сайта.
rodigy, Уже давно. Вероятнее, речь идет о каких-то небольших проектах, для которых разворачивать сборку нет смысла. В целом, можно обойтись и без отдельных сборщиков. IDE от JetBrains предлагают всю функциональность этих штук из коробки.
Aitd, Если убрать отступы, пустот не будет. Так как вы написали - не получится. Или юзать либу, что написали выше, либо masonry. Что в целом одно и то же.
Можно попробовать подобное, но на флексах. С помощью Order получится изменить положение блоков. Но это тоже так себе вариант.
Рикко, полагаю, что все зависит от того, что далее будет происходить с этой разметкой. Если вы оставите это так и менять контент там не придется (или того, кто будет редактировать текст вперемешку с html это не будет смущать), то нормально.
Но если редактировать не нужно, то код можно просто вставить в файл шаблона.
А чтобы работать только с контентом, минуя перетягивание разметки в админку, то лучше воспользоваться плагинами для кастомных полей. Например ACF. Можно сделать очень лаконично и просто для редактирования.
По поводу специальных плагинов для html, не знаю, звучит странно.
Главное различие:
props - свойства, которые доступны в компонентах после того, как какие-либо значения были переданы в качестве атрибутов. К слову, в качестве свойств могут быть переданы значения из State.
Props не могут быть изменены напрямую. На то они и свойства.
State - состояние. Они могут и должны обновляться. Не только потому, что это данные хоть как то нужно обновлять (например, чтобы изменять данные после взаимодействия пользователя с интерфейсом), но также и из за того, что при обновлении State происходит перерендеринг компонента.
Теперь представим такую ситуацию: из родительского компонента со State отправляем в дочерний значения с атрибутами из State, который тот принимает их в качестве props. Дочерний компонент может быть просто функциональным (без возможности хранить State).
Так, при обновлении State родительского компонента будут изменяться и props дочернего.
Лобстер: Где то видел clip-path генератор. Можете легко найти кучу таких в гугле. Но как вы говорили выше - это не поддерживается в IE и Edge.
Если подсмотреть логику рисования таких фигур, то, думаю, не составит труда сделать что то свое.
Артём Петренков: Тут больше интересна сама структура шаблона, чтобы поковырять и понять логику взаимодействия модулей, разграничения скриптов для разработки, продакшена и тестирования скажем.
Наверняка же кто то уже написал свой велосипед, минуя create-react-app и прочие буллетпруфные шаблоны.
Влад: Объяснение Денис Инешин не противоречит этому. Вызывать jQuery можно двумя способами.
Но если у вас подключены библиотеки (или по какой то причине несколько версий jQuery), которые используют $, то для избежания конфликтов не остается ничего, кроме как использовать jQuery вместо $.
При этом некоторые CMS (например, Wordpress), загружают jQuery в режиме noconflict для минимизации возможных конфликтов со сторонними библиотеками.
Это функциональность Wordpress "из коробки". Не понимаю в чем заключается неудобство. Или вы имеете в виду, что не хочется все складировать в стандартный блог, то можно сделать Custom Post Type. Но не думаю, что можно как то более удобным способом реализовать категоризацию в вашем случае.
В общем, я не вижу смысла заморачиваться. Если бы у вас была более сложная структура записей, где нужно было бы учитывать несколько кастомных taxonomy то да, иногда бывает все не так очевидно. Но, в конце концов, это же Wordpress, ничего особо нового тут не придумаешь, особенно когда речь идет о блоге.