Pull to refresh

Почти таргетинг

Reading time5 min
Views694
Original author: Eric Meyer
Позвольте рассказать вам одну историю, случившуюся в 2002 году. (Точная дата подзабыта, но год именно этот.) Как и множество других историй — она длинновата, но, в отличие от некоторых историй — правдива.

Пока разработчики Нетскейпа готовили новый релиз Мозиллы, браузера, от которого мы «отбранчили» Навигатор, мы в группе Technology Evangelism/Developer Support (TEDS) проверяли его на популярных и партнерских сайтах. На некоторых из них верстка расползалась. В одном случае — очень серьезно.

Достаточно быстро выяснилось, что проблема в нарезанных картинках, заверстанных в таблицу. По какой-то причине на некоторых сайтах между этими картинками появились промежутки. Покопавшись, причину нашли — движок Гекко поменял механизм работы со строками на более совместимый со спецификацией CSS. Теперь картинки всегда «сидели» на базовой линии (если не указано иное) и нижняя часть строки (та что для нижних выносных элементов шрифта — прим. пер.) всегда присутствовала.

Это было в новинку для мира браузеров, потому что все браузеры поступали так, как все браузеры всегда поступали — уменьшали ячейку таблицы до размеров картинки, если кроме нее там ничего не было. Проблема только в том, что такое поведение было некорректным. Исправив ошибки имплементации CSS Гекко «поломал» верстку у таких сайтов. То есть, он ломал ее в стандартном режиме. В нестандартном (quirks) Гекко вел себя по-старому и выполнял фокус с уменьшением ячеек.

Мы связались с разработчиками одного из проблемных сайтов, достаточно известной на то время социальной сетью (вроде того), и объяснили ситуацию. Мы уже знали, что они не могут поменять доктайп, чтобы уйти в нестандартный режим, потому что это поломало бы им другие вещи. Предложить им простой CSS фикс вида td img {vertical-align: bottom;} мы им тоже не могли, потому что вся верстка у них была табличная и таким образом мы бы сместили все картинки, а не только порезанные. Все что мы могли предложить — объяснение ситуации, рекомендацию задать всем нарезанным картинкам CSS класс, «прижимающий» картинки, и уверения в том, что на другие браузеры это влияния не окажет.

Их ответ: «Нет. Это ваша проблема. Все браузеры делают все правильно, и мы не собираемся возиться со своими темплейтами и добавлять классы только потому, что вы что-то сломали.»

Истина же состояла в том, что мы вовсе даже чинили это что-то — это все остальные браузеры вели себя неправильно. Но эта истина проблему нашу не решала. Получалось, что мы стоим перед выбором: откатить наши улучшения CSS движка или поломать этот сайт и все ему подобные, которых было тогда достаточно много. Ни то, ни другое радости не вызывало. И поговаривали, что без решения проблемы — апдейтом сайта ли или браузера, — продукт не выйдет. Так обстояли дела.

Позвольте резюмировать существовавшее положение. Мы:

1. Улучшили поддержку стандартов в браузере.

2. Обнаружили, что это портит верстку на определенных сайтах.

3. Их разработчики наотрез отказались менять что-либо на своей стороне.

4. Решать проблему должны были мы.

Откатить улучшение было нельзя — это влияло на отображение текста и задевало кучу других вещей. Убедить разработчиков сайта нам не удавалось, сколько бы мы им не объясняли, что это часть развития веб-стандартов и более правильного поведения браузеров. Перед нами две дороги, и ни по одной из них мы пойти не могли.

И мы нашли третий вариант: «почти стандартный» режим, в дополнение к обычным стандартному и нестандартному. Да, именно поэтому «почти стандартный» режим и существует. Если я правильно помню обсуждение, в его существовании по большей части виновен я; так что, простите меня все те, кто был вынужден иметь дело с «почти стандартным» режимом в негекковских браузерах.

Мы сделали так, что «почти стандартный» режим применялся для доктайпа проблемного сайта — это был XHTML DOCTYPE, должен заметить. Попутно мы выпустили специальный DTD для IBM. Они использовали его для валидации своего сайта, где были много всякого HTML-невалидного, и у них тоже была описываемая проблема. Так появился третий режим отображения. А все потому, что некоторые сайты были некорректно устроены и отказались меняться, чтобы соответствовать нашими улучшениям. Мы поступили так чтобы не попортить небольшую (но популярную) часть веба и одновременно улучшить поддержку стандартов.

(Кстати, этот же случай стал причиной появления статьи “Images, Tables, and Mysterious Gaps“.)

А теперь возьмите увеличьте эту ситуацию на несколько порядков — вы получите представление о том, с чем приходится иметь дело людям из IE. Ровно как было у нас в Нетскейпе: с одной стороны  — свои собственные прошлые ошибки, с другой — отказ сайтов идти навстречу нашему желанию лучше поддерживать стандарты.

Кто-то сказал, что Майкрософт находится в уникальном положении, которое может позволить ему «встать во главе», пропагандировать среди своих клиентов улучшенные стандарты и корректировку старых сайтов. Все верно. Но что если партнерская корпорация-мультимиллиардер откажется от корректировок и потребует, в соответствий с длиннющим контрактом и его пунктами о серьезных неустойках, сделать так, чтобы новая версия IE не ломала (понимайте «ломала», как хотите) их корпоративный интранет или коммерческий веб-сайт. Один такой случай — достаточное препятствие.

Все наши публикации на DevEdge, активная помощь сайтам в апдейтах их кода, CSS и JS для работы с Гекко (так чтобы в других браузерах ничего не ломалось) и помощь в процессе улучшения поддержки стандартов в Гекко не смогли помочь нам преодолеть это препятствие. Пришлось идти в обход.

Оглядываясь назад, могу предположить, что этот опыт подсознательно повлиял на мое согласие с предложением браузерного таргетинга, потому что в определенном смысле это именно то, что мы сделали с Мозиллой в схожих условиях. Просто мы это сделали более неявным и ненадежным способом, привязав все к определенному доктайпу вместо какого-нибудь надежного якоря. Если бы мы могли предложить тому сайту (и всем подобным) простой способ попросить «отрисовать как Мозилла 0.9» (или как что угодно еще) вверху страницы или в заголовках сервера — они могли бы и согласиться.

А что если бы мы предложили, а они бы отказались и опять поставили бы нас перед выбором откатить улучшения или исправить браузер — настроили бы мы все под какую-то одну определенную версию Мозиллы вместо последней и лучшей? Мой внутренний идеалист хочет думать, что нет. Внутренний прагматик кивает, что да. А что еще мы могли бы сделать в этих обстоятельствах? Выпустить браузер, который сломал бы сайт, входящий в десятку популярнейших, в надежде, что они там смирятся с тем, что таки уже выпущено на свободу? Зная, что это заметным образом, а иногда и очень серьезно испортит процесс веб-серфинга для наших юзеров? Нет. Мы бы выпустили продукт без улучшений по части CSS или мы бы использовали установили по умолчанию плохой таргетинг. У нас не было тогда таргетинга версий, но мы сделали все то же самое, просто повесили все на доктайп.

Кратковременное решение кратковременной проблемы? Да. Но если бы мы этого не сделали, сколько еще продолжалась бы плохая поддержка стандартов Нетскейпом/Мозиллой в ожидании того дня, когда можно будет вернуть это улучшение, не ломая кучу сайтов на глазах многочисленных пользователей? Возможно годы. Потому мы и применили слабое подобие таргетинга версий, чтобы иметь возможность улучшить поддержку стандартов побыстрее. И было это более пяти лет назад.

Так что, может быть я сильнее сочувствую затруднениям IE и предложенному ими решению, потому что сам прошел через подобное. Не в такой степени, но дилемма казалась не менее удручающей, несмотря на разность масштабов. Это стоит учитывать, оценивая что я сказал и скажу по данной теме.
Tags:
Hubs:
+37
Comments48

Articles