Несовместимость с img { max-width:100%; }

Наши селекторы всегда по классам, типа .YMaps img

Любой селектор по id, например #content img перебьёт наши правила. Поэтому смысла защищаться нет.

Первое и основное: благодарю Вас за проявленное внимание к проблеме. Не многие разработчики способны, а ещё меньше - готовы и имеют желание общаться с "потребителями" их API и обсуждать возникающие сложности. Посему ещё раз - спасибо за уделённое время и проявленное внимание.

По сути вопроса: я несколько иное имел в виду. Вместо .YMaps img использовать .YMaps img.YMapsMap например, или просто - img.YMapsMap. В этом случае Ваше правило будет более специфичным, нежели img или #id img.

Я понимаю, что в этом случае размер html кода несколько подрастёт (придётся дорисовывать class="YMapsMap" во все img самой карты), но может быть оно того стоит? Кстати - класс можно ведь и на стороне клиента дорисовывать через JScript.

"Лёгкий" вариант .YMaps img действительно не вариант защиты...

Может всё-таки имеет смысл рассмотреть предлагаемый вариант защиты, хотя бы опционально - при подъёме определённого флага через JScript, скажем. Поймите, зачастую карту приходится вставлять в сайт, где разработчик темы работал давно, за деньги, css совсем не маленький. А тогда ("давно") в ТЗ размещение Яндекс.Карт не предусматривалось.

P.S. Возможно, можно было бы и проще обойтись: не могли бы Вы предложить некое средство online тестирования html+css кода конкретной страницы (то есть вводим url в Ваш сервис, он делает запрос по типу браузера, ищет и указывает на несовместимости в css /  html). Если такое средство будет, тогда, как минимум, не придётся тратить сутки на выявление сути проблемы, лишь озаботиться workaround под эту проблему, что уже проще.

> По сути вопроса: я несколько иное имел в виду. Вместо .YMaps img использовать .YMaps img.YMapsMap например, или просто - img.YMapsMap. В этом случае Ваше правило будет более специфичным, нежели img или #id img.

Нет, это не так. Любой селектор с # перебивает любой селектор без #, см. спецификацию: http://www.w3.org/TR/CSS2/cascade.html#specificity

Защититься от сторонних css мы можем, таким образом, только записывая все стили непосредствено в style, а это превратит html-код в нечитабельную кашу.

Прошу прощения - был неправ. Указанная Вами статья стандарта говорит лишь о том, что img#id всегда будет более специфичным, нежели img.class. Мы же с Вами обсуждали иные правила #id img и .class img.class, посему и допустил ошибку в логике.

В style писать безусловно - ужас да и только.

Большинство, кстати, вполне устроит решение для размещения одной карты на странице, так что можно в css просто дописать правила для #YMapsSingletonMap img, и давать рекомендацию при размещении одной карты на странице использовать контейнер с указанным Id. И у 99% (имхо) потребителей проблема со стилями была бы решена. И уже только 1% (имхо) с множеством карт на одной странице пришлось бы лопатить свой css. Такое решение не вариант?

> P.S. Возможно, можно было бы и проще обойтись: не могли бы Вы предложить
некое средство online тестирования html+css кода конкретной страницы
(то есть вводим url в Ваш сервис, он делает запрос по типу браузера,
ищет и указывает на несовместимости в css /  html). Если такое средство
будет, тогда, как минимум, не придётся тратить сутки на выявление сути
проблемы, лишь озаботиться workaround под эту проблему, что уже проще.

Очень сложно достоверно выяснить, повлияет ли сторонний CSS на нашу верстку. Обычно конфликты вёрстки тривиально находятся глазами в firebug-е.

Речь идёт, по сути, о загрузке указанного пользователем url в некий объект (как ms-любител - activeX того же IE использовал, доступны и open source решения), который обеспечит интерфейсы, через которые мы получим результирующие стили интересующего нас контейнера (пользователь должен нам указать id контейнера). И уже после этого сообщить, есть там "криминальные" стили или нет. В идеале, безусловно, следовало бы указать файл css номер строки в нём и правило, генерирующее "запрещённые" стили для нашего контейнера.

Вот отличить криминальные стили от некриминальных и есть проблема.

Даже банальный font-size в каких-то условиях может быть криминальным.

А каким образом тогда действовать потребителям API? Как минимум, в этом случае напрашивается некая wiki с указанием допустимых / недопустимых правил, которую уже с подачи тестеров Вы сможете наполнять данными.

Прошу потому, что данный клуб нашёл, по сути, случайно, информацию в нём по поиску найти даже в Яндексе далеко не просто...

Очень просто: не писать правила, распространяющиеся на все img, a, table и пр. в документе.

Кажется, что хорошая верстка таких правил и так не содержит :)

ещё бы все дизайнеры были программистами, и не начинающими, а знакомыми с правилами хорошего тона... Но это уже лирика.