Если у карточки уже есть position отличный от static, у child элемента уже опорные координаты будут в левом верхнем углу карточки, этого должно быть достаточно. Если есть возможность - css карточки помог бы
я бы посоветовал воспроизвести конечно всё же через тень, но тут хозяин-барин.
Решений два
1. договориться с дизайнером и всё же тень бросить
2. делаем карточке псевдоэлемент, родителю позишн релейтив, з-индекс 2, псевдоэлементу индекс 1, чтобы отступы по бокам были всегда по 10 px - псевдоэлементу left, right, top 10px, высоту 100%. Может где немного напутал, но общий смысл такой. Блюр всегда блюрит всё что внутри, потому выносим на псевдоэлемент. Можно попробовать так же и с тенью сработать, блюр (хотя и тень там же рядом), если я не ошибаюсь, более энергозатратная операция.
Вы уверены, что надо именно фильтр блюр на доп блок? Очень похоже на просто бокс шедоу, у которого можно управлять размером, смещением, цветом и степенью размытия. Может тут поиграться?
Ссылку на сайт - куда можно зайти посмотреть как это работает в данный момент. Можно на чужой, лишь бы увидеть этот чат. Но если это вызывает затруднение, как вы правки собираетесь вносить?
Yustas Alexu, вот тут вы не правы. Это называется ошибка выжившего.
То что в ваших проектах "на практике" ни на что не влияет - просто частный случай. И упирать на это, рассказывая, что "не пригодилось" - на ресурсе где люди спрашивают как правильно - не гут.
По стрелочным функциям - я вовсе не топлю за useCallback. Я только против их вызова внутри события onClick.
useCallback, мемоизация - не есть самоцель, иногда они просто вредны, иногда бесполезны, тут вступает в дело как раз ваш случай - решение по месту.
А просто отвергать - вы тогда собеседование не пройдете в какую-нибудь серьезную контору, где попросят написать на хуках банальную авторизацию с просьбой убрать лишние ререндеры :)
Вообще - работая с данными и натыкаясь на "непреодолимые преграды" обкладывайте каждый шаг console.log()
Так вы будете понимать что к вам пришло, в каком виде и почему не срабатывает map от строки :)
всё зависит от находящейся под рукой документации )
Специализируясь во фронтэнде, я такое сам с лёта не осилю. Но обложившись документацией - вполне всё можно преодолеть.
Всё зависит от того, где результат Вашей работы будет применяться. Если потрениться на кошках - многие условности можно не реализовывать, чтобы просто понять суть происходящего.
Если же правка нужна на боевом сайте - лучше специалиста привлечь.
Нужно выполнить несколько требований и соответственно подготовить код
1. создать эндпойнт на стороне сайта - (пишем код на пхп), урл, в который можно со страницы асинхронным запросом с помощью ajax отправить Ваши данные и который дальше отправит эти данные в базу.
2. написать асинхронный запрос на отправку данных на стороне js.
3. подготовить поля в базе данных, куда эти данные будут складываться.
Обычно такой объем работы выполняет fullstack специалист, который должен хорошо разбираться в написании бэкенда (безопасно, устойчиво ко взломам, с валидацией, сообщениями об успехе/неуспехе отправки данных), уметь подготовить изменения в бд, плюс к этому - уметь писать код на фронте.
kovtann, нужна ссылка где на это чат в рабочем состоянии можно глянуть. Хотя бы на чужом сайте но именно этот виджет, тогда можно будет понять причины.
Ссылка на сервис, который его предоставляет, требует авторизации, чего, понятное дело, никому не интересно.
Ivan765 ой ли всё так просто? )
Я не увидел примера для анимации дропдауна. А зная, что анимация стилей для неизвестной высоты не особо-то реализуется, становится оченно интересно увидеть именно пример в песочнице.
Если это адаптив, есть несколько шагов:
1. определить список для каких разрешений вообще работать должно
2. выбить из дизайнера всё.. информацию, как должна вести себя картинка на таких-то разрешениях - вы вполне можете указывать для разрешений менее условных 2к высоту картинки max-height: 400, а на больших разрешениях - другое значение, либо max-height: auto, а на мелких разрешениях width: 100%, чтоб картинка разделяла текст, не давала обтекать.
3. определить переломные разрешения
4. написать медиазапросы для всех перегибов
Вообще говоря - обсуждать частное решение необходимо в условиях наличия полной информации, где, как, в какой четверти луны вы собираетесь это использовать.
Может бэкенд вам возвращает набор полей и вы генерите разметку на фронте, может разметка собирается на php на бэкенде и там можно весь гемморой переложить на плечи бэкенд программиста... Надо ли вам делать адаптив, надо ли делать изменяемые размеры у иконок, надо ли делать ховер со сменой картинки, либо ховер со сменой цвета, монохромные ли у вас иконки, векторные или нарезка из пнг..., собраны ли они в спрайты...
Сейчас все предложения высосаны из пальца "как бы сделал я для себя".
А еще можно дизайнера и заказчика уговорить на верстку универсальными компонентами, чтобы уникальных вещей было как можно меньше, и наверняка окажется, что стили для них хорошо если 10% от общего объема окажутся. Тогда и огород городить не возникнет причин.
Soul1 если Вы хотите чтобы меню привязывалось к родителю - родителю нужно добавить position: relative. И внезапно.. пабам! выпадающее меню будет срезано overflow, т.к. меню уже окажется внутри контейнера. То как у вас ведет себя меню говорит о том, что стоит подтянуть CSS
