в общем, ладно, спасибо вам, в целом то я больше хотел по классу этому узнать кто пробовал и как он, ибо в будущем возможно его будем использовать для нормального проекта и в нормальных условиях. я пока еще подержу вопрос, вдруг кто ответит еще чего, а потом вам засчитаю ответ за решение ;)
еще раз говорю, я это понимаю. стоит задача, ее надо выполнить, мои доводы против - не сработали. Надо, так надо, потому пытаюсь хоть как-то улучшить ситуацию (по моему мнению, это хотя бы отдавать оба варианта поровну). Ну и на самом деле там принцип какой - лэндинг суточной распродажи доменов, периодически будет запускаться, холивар, да даже не холивар, а просто желание маркетолога - посмотреть влияет ли на восприятие одна незначительная мелочь. Вести клиентов будут не с контекста и не с директа, а из соц. сетей преимущественно (под это заточен лэндинг, реклама в социалках). Но в целом... задача стоит, ничего не поделаешь. А на "оть*бись" ее делать не хочу.
Ну... нет, я то полностью с вами согласен и знаю эти базовые принципы прекрасно!)
Но таков случай - срез мал (и ничего не поделаешь), исходя из этого (естественно мерить будем по конверсии), считаем нужно делить хотя бы поровну, так сказать уравнивать оба варианта.
нет, ну вы конечно можете еще предложить работодателю решение на массивах и циклах, если есть какие-то предрассудки относительно предложенно встроенной функции
@tuxx ну "вы" было не конкретно к вам, извините если не так выразился. Вы же правильно сомневаетесь, и даже не сомневайтесь - я вам выше объяснил почему. Да и к тому же, хоть они (корп-ии зла Яндекс и Гугль) и обладают такими вычислительными мощностями, но я не думаю что целесообразно было бы их тратить на анализ верстки (в том смысле как вы выше описали). Да и к чему... Я же говорю, содержимое - да, разметка - только микроразметка и семантика.
@morozovdenis почему, после извлечения из базы данных результат можно вернуть в какую угодно переменную @Taraflex ну я хоть и недавно тут, но периодически поражаюсь и впадаю в недоумение от подобных вопросов - сарказм или нет)
Ну... да, кроссбраузерность/поддержка старых браузеров в том числе...
Нагрузка (как основной, не учитывая поддержку), надеюсь вы понимаете, что .has-submenu более быстродественен и менее трудозатратен , нежели ul.menu li a:not(:only-child) (по ссылке выше хорошо описан процесс рендеринга). На крупных проектах конечно в основном это влияет, но всё же
Во-вторых, одна из основных задач/возможностей javascript'а как раз в том и состоит(-яла) чтобы изменять и путешествовать по дереву DOM. Котлеты отдельно, мухи отдельно)
Третье, тоже немаловажное - подстраиваться в таком случае под разметку, (как в приведенном выше примере), меньшая гибкость
Ну и в целом куда проще использовать какой нибудь .parent() или вовсе просто указать один класс/класс-модификатор который будет за это отвечать, и понятней это будет (особенно в командной разработке), нежели например разбираться в css-хитросплетениях
Как то тоже столкнулся с недостатком отсутствия подобного селектора:
надо было в зависимости от дочернего, родителю менять фон, решил за счет :before в дочернем с картинкой и позиционированием.
Ну и да, в sass/scss еще можно подобное делать насколько помню
Не за что) Опишу как я понял задачу и поясню решение:
имеем меню ul.menu > li > a / a + ul. Для него написать на чистом css селектор для выделения пункта меню, имеющего/не имеющего подменю.
Если перевесить с li на дочерний a стили (хотя бы визуальные) то описанный мною выше селектор будет как раз то, что вам надо: «выбираем все a, которые при этом не единственные(:not(:only-child)) в ul.menu li». Визуально вы выделите соответствующий пункт, но не элемент родителя.
Если же вам хотелось знать возможно ли через css путешествовать вверх по дереву - то нет)
Конкретно по селектору по родителю : web-standards.ru/articles/parent-selector хорошая статья, а так еще посерчите - давно идут споры по поводу реализации этого в будущем, может еще будет)