а как в таком случае задавать стили для общих элементов типа strong, a, code, ul, ol, pre, h1-h6, blockquote и тд, которые могут встречаться внутри разных независимых блоков(например внутри статьи на сайте или внутри комментария)? что-то не уловил этот момент, может вы проясните..
Немного исправлю: каждый блок в visual composer'e является обычным шорткодом, собственно так в базу и сохраняется, поэтому меняя темплейт шорткода базу данных трогать не нужно. По сути, принцип работы гутенберга аналогичный.
aslanovich: писал этот код для одного из своих старых проектов и в процессе разработки также пробовал сделать по такому принципу. В общем, не помню уже почему, но данный подход тогда для меня был неприемлем. В связи с этим получилось более громоздкое, но, на мой взгляд, более гибкое решение.
про отрицательный margin-top тоже думал, но от шрифта к шрифту разные значения нужны, а при наличии опции смены шрифта такой прикол не прокатит. кстати, при line-height = 1 небольшие отступы тоже есть..
Maa-Kut: не то, чтобы они плохи, но держаться за них я бы не стал(имея fetch api, например). В вопросе я не имел ввиду какой-то конкретный кейс, но вот представим обычный сайт: есть common элементы, которые нужно обрабатывать на каждой странице, а есть специфичные для каких-либо страниц вещи, которые тоже надо бы обрабатывать. Но грузить разные JS файлы для разных страниц накладно и не решает проблему целиком(например страницы, созданные в page builder каком-нибудь, где ты не всегда можешь знать какие элементы на какой странице будут использованы).
Итак. Как мы поступим, чтобы не засорять глобальную область видимости лишними функциями и коллбэками? Можем ли мы инкапсулировать код каждого элемента, чтобы не допустить перемешивания и возникновения этой каши, когда всё в кучу? Затем представим, что проект растёт и в него а) добавляются новые разработчики и б) элементов становится на порядки больше. Я даже не представляю, что за ужас начнётся.
Поэтому и был задан вопрос по поводу фреймворков - возможно, это может спасти от подобной ситуации. Ищу решения, короче говоря)
Rou1997: суть как раз в том, что не нужно внутри фреймворка работать с DOM, там по-другому устроено. Ajax функции jquery достаточно скудны в сравнении со специализированными библиотеками которые легко можно прикрутить в свой проект при надобности.
А связь между масштабностью проекта и инструментами, которые в нем используются как раз-таки прямая. Чем больше проект, тем сложнее вести его используя jquery-way. Чтобы это понять нужен опыт, я не смогу сейчас рассказать про все возможные проблемы, но поверьте мне, их реально много и вопрос мой был вообще не о том, что тут лучше.
Rou1997: я работал с jQuery достаточно долгое время и могу сказать, что для мелких проектов он подойдет, но на более-менее больших это уже превращается в реальную проблему.
Rou1997: валидация форм, обработка событий, ajax и тд. все то, что делает обычный JS для одной конкретно взятой страницы. Странный у вас вопрос какой-то.
Так это поисковые движки, как они мне помогут, если у меня есть текст на 300 символов, скажем, и заголовок вопроса, который может даже не соответствовать теме? Нужно как-то разобрать этот текст прежде, чем выполнять поиск по базе сайта. Об этом и вопрос.
vsuhachev: мне нужно посчитать количество обращений к странице, но при этом не замедляя страницу(её быстродействие, скажем так, очень принципиально), поэтому и ищу решения..
anyd3v: да, но почему нельзя выполнять это действие после того как запрос выполнен и ответ сформирован? тогда снаружи никаких изменений видно не будет.
