Данияр Кудайбергенов: смешно читать такой бред. На дриббле постят крутые дизайнеры, половина из которых работает в гуглах и компаниях подобного уровня. Добрые 70% концептов там потом без проблем появляются в передовых проектах, пока всякие васяны из колхоза продолжают это все надменно осуждать, думая что они в чем то разбираются.
Создаешь стримовый поток, от клиента к серверу. Посылаешь туда аудио-чанки или что-нибудь подобное, что ты можешь отсылать. Пока стрим открыт, все это дело сохраняется в какой-нибудь условный массив. По закрытии стрима энкодишь все это дело и сохраняешь как аудиофайл например.
Подробную инструкцию не осилю, но гугл тебе поможет.
Если что, то юзкейсы блок__элемент__элемент бывают, и это не запрещено законом и чем либо еще. Так что видел подобные вещи в исполнении весьма авторитетных людей. Но использовать такое надо весьма обдуманно, где без дополнительной вложенности будет не полная картина.
ummahusla: То есть вы на полном серьезе сможете копаться вот в таких исходниках? i.imgur.com/zYTh7Yp.png
Ибо изначальные названия переменных анминифаеры вам не вернут. А без них код канваса представляет из себя ад и израиль.
Banny_Boom: когда высота неизвестна, лучшие варианты выравнивания текста это либо flexbox, либо табличка (то что вы и написали в уточнении). Попробовал сейчас другие способы - везде проблемы.
Banny_Boom: С выравниваем все не так просто. Если бы высота каждого блока продукта известно - можно выравнивать через line-height равный высоте блока (за вычетом паддинга). Если высота неизвестна, то самый простой способ это использование табличного выравнивания, потому-что вариант с transform: translateY(-50%) сделает текст размазанным.
Еще как вариант можно задавать top: 50% и делать margin-top: -font-size/2 - padding-bottom/2 но это весьма жуткий вариант, и если названия будут длинными и займут 2 строчки, то этот вариант развалится (а вот табличный будет работать).
Маленькое замечание - помещение всего скроллинг контента внутрь контейнера, слегка проигрывает по производительности варианту, когда контент расположен напрямую внутри body. Связано это с тем, что в браузерах (как минимум в хроме точно) имеется встроенная оптимизация скроллинга для контента внутри body. В большинстве случаев на это конечно можно забить, но если когда-нибудь будете делать сайт, загруженный анимацией при скроллинге, то возможно этот совет вам поможет :)
Сергей: игрался с этим. И еще с кучей свойств. Я убил часа 3-4 на очень интенсивный гуглинг и проверки. И хром/сафари на макОс все равно продолжали увеличивать элементы по своему усмотрению. И только потом решил попробовать удвоение font-size.
Павел Кизернис: топорный ответ - потому что rem образно говоря является теми же px, только с возможностью их скейлинга, а вьюпорт еденицы это именно вьюпорт еденицы, и они не привязаны к каким-то реальным статичным значениям из макетов. То есть стоит у вас допустим font-size: 62.5% и вам необходимо сделать блок 300х200px. Вы пишите width: 30rem; height: 20rem;
А затем вам например необходимо чтобы на экранах с шириной выше 1600px весь контент стал на 25% больше, включая этот блок, то есть он должен быть 360х240 в итоге. И вы тогда пишите media (blahblah) font-size: 78.125% и блок невероятным образом становится 360x240px. А верстка в стартовом разрешении остается все такой же, заточенной под пиксели из макета.
Единственный минус rem - скейлинг шрифтов вместе со всем остальным, и при особо сильном снижении некоторые вещи будет тяжело читать. То есть это не минус, а как бы логичное следствие. Лечится либо кастомным допиливанием отдельных элементов через media-query, либо какой-нибудь простой приблудой с препроцессорами.
