Ну да, конечно, ничего сложного. Так и надо было сразу: .A * { border-color: inherit }
А класс B ничего не знает и не хочет знать про класс А и цвет рамки. Тем более класс может меняться быть А, а может быть A2, A3, каждый со своей рамкой Тем более этих вложенных дивов целая куча и классов у них там: B1, B2,... B22. Всем прописывать рамку — совсем неправильно.
Спасибо. Не совсем то. Дело в том, что у внешнего дива класс А может быть, а может и не быть, или может быть класс C, с третьим цветом рамки, который должен спуститься до внутреннего дива.
В тоже время по логике приложения и его вёрстки класс B не интересно знать про цвет рамки вообще, какая к нему "придёт" сверху каскада, такой и быть. И я не хочу всем внутренним классам писать цвет рамки: есть так, то цвет такой, если иначе, то другой. Тем более я упростил вопрос. Реально там много разных вложенных элементов разных типов, а не только B, и всем им надо отдать общий цвет рамки, определяемый во внешнем диве классом А.
Я почему использовал селектор по id? Класс — это не индивидуальная характеристика этого модального окна, а вполне может быть всех модальных объектов, поэтому я взял по id. Но можно и по классу отбирать.
Насчёт библиотек не скажу, но это несложно сделать меньше чем в десяток строчек. Пишу с телефона, поэтому не удобно. Если до понедельника не забуду, или кто-нибудь здесь не напишет раньше, то сделаю.
А зачем вам отдельное окно? Можно Яндексу тоже аяксом отправить, чтобы текущая страница не терялась. А результат можно отразить не в отдельной вкладке браузера, а в том же окне в отдельном слое поверх.
1. Действительно поддержка должны быть отдельно, т.к. иначе получается не совсем понятный договор (вернее его сложно сделать таким).
2. Хотелось бы сделать договор, в рамках которого будет не одно ТЗ, а несколько. Т.е. ПО будет развиваться, и функционал будет наращиваться постепенно.
3. Это внутренний договор внутри группы компаний. Т.е. вроде бы "все свои", но договор надо сделать юридически грамотный. Делается для того, чтобы навести порядок, правильно разнести затраты и выделить разработку ПО (которая является непрофильной деятельностью, но которую мы ведём сами). Это необходимо для правильной структуры бизнеса, и для того, чтобы принять ПО на баланс и его аммортизировать.
Мне кажется, что это нетривиальная задача. Причём даже с точки зрения сценария. Допустим я еле-еле кручу колесо (по одному тику) , соответственно содержимое скоролируется хоть и мгновенно, но медленно. Потом перестаю медленно крутить, "накат" должен тоже завершиться медленной скоростью. Если я кручу колесо быстро, я "разгоняю" скрол, и он должен тормозить с большой скорости. Опять-таки, что значит "перестаю", какая должна быть пауза между тиками, чтобы это означало "перестал крутить").
Прежде чем начать думать над кодом, надо бы сначала продумать эту механику с точки зрения пользования.
