Недостатки Safari

Недостатки SafariНекоторое время назад я произвёл попытку отказаться от использования для повседневных нужд всех браузеров, кроме Safari. До этого момента я в течении долгого времени использовал в качестве дефолтного браузера Firefox, но в какой-то момент его медлительность и аппетиты относительно системных ресурсов меня окончательно расстроили, и волевым усилием я сделал дефолтным Safari. Прошло около 4-х месяцев, и настало время подвести некоторые итоги, а также сделать определённые выводы. В этой статье я приведу те причины, по которым мне пришлось отказаться от идеи использовать встроенный в систему Mac OS X браузер в качестве основного.

Отсутствие поддержки XML

Так уж сложилось, что по работе мне часто приходится работать с XML данными. И в первый же день моего перехода на Safari, этот браузер обескуражил меня отсутствием полноценного отображения XML. Впоследствии мне удалось найти плагин, позволяющий выводить XML в виде нормальной древовидной структуры, но осадок остался: современный браузер, содержащий в себе инструменты для web-разработки/отладки, по моему мнению, должен поддерживать отображение XML.

Невозможность выбора сертификата

Не помню уже, когда и почему это случилось, но у меня два кошелька в системе Webmoney, и оба они зарегистрированы для работы с Light-интерфейсом. Но оказалось, что Safari, в отличии от упомянутого ранее Firefox, не позволяет, при входе в систему Webmoney, выбрать, какаой именно сертификат необходимо использовать в данный момент для авторизации: браузер, вероятно, просто берёт тот, который стоит первым в «Связке ключей» по какому-то из критериев, и авторизуется при помощи него. Поэтому для нормальной работы с Webmoney мне приходится использовать Firefox.

Читайте также  Разговоры об iPhone

Отсутствие поддержки плагинов

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

Невозможность посмотреть свойства объекта

Вроде бы и мелочь, а всё ж таки довольно неприятная: во всех популярных браузерах, кроме Safari, я могу очень быстро выяснить свойства объекта на какой-либо странице (размер и тип изображения, например).

Недоработанные инструменты разработки

В Safari изначально присутствуют неплохие средства для отладки веб-приложений на стороне клиента (это как Firebug для Firefox, только встроенный в браузер изначально). Но средства эти местами довольно сырые и непродуманные. В доказательство, приведу пару примеров «сырости»:

Отладка JS и breakpoints

В Safari, если в одной из вкладок вы выставили breakpoint на какой-либо из строк JS, и он сработал (выполнение скрипта приостановилось), то вы не сможете открывать страницы в других вкладках этого же окна, пока не пройдёте точку остановки и не закончите выполнение скрипта на отлаживаемой странице. Т.е. остановка скрипта в одной из вкладок нейтрализует работу всех открытых ранее вкладок того же окна (в новом окне или новой вкладке всё будет работать). В том же Firebug для Firefox такого не наблюдается.

Анализ элементов страниц

С помощью упомянутых выше средств разработки можно проанализировать любой элемент отображаемой страницы, что очень удобно: щёлкнул правой кнопкой мыши на объекте, выбрал «Проверить объект» и получил всю необходимую информацию о нём в открывшейся панели с исходным кодом. Интересное начинается позже, когда выясняется, что в этой самой панели вновь можно кликнуть по любому элементу, буть то тег или текст, и снова его «проверить», а потом проверить элемент той панели, которая откроется для отображения кода, а затем ещё и ещё раз повторить эти действия: в общем, разработчики позволили вызывать проверку элемента из любой панели (даже если вы просматриваете исходник JS или диаграмму загрузки элементов сайта). Это происходит по той простой причине, что сама панель отладки представляет из себя HTML-документ, все элементы которого хранятся по адресу /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Resources/, а Safari знает, что для HTML- документов нужно отображать пункт контекстного меню «Проверить объект».

Читайте также  Из адресной строки Safari — в поиск Google

Сохранение файлов

Очень серьёзной недоработкой в Safari я считаю автоматическую загрузку файлов в указанную в настройках директорию. Разумеется, можно кликнуть по ссылке на файл правой кнопкой мыши и выбрать пункт «Загрузить файл по ссылке как …», но, во-первых, почему нельзя сделать этот выбор по умолчанию, а во-вторых, далеко не всегда ссылка ведёт сразу на объект, который я хочу загрузить; бывает, что файл на загрузку отдаётся серверным скриптом, так что сложно узнать, что за ним прячется: .mp3, .doc, .pdf или ещё что-то, а Safari услужливо подставляет в строку имени файла, к примеру, download.php, а дальше предоставляет разбираться вам, что скрывается за этой маской.

Невозможность поиска из адресной строки

В прошлой заметке я уже указывал на это неудобство и предлагал кустарный способ его частичного исправления. К сожалению, этот способ работает довольно криво, и не даёт использовать столь удобный функционал, как поиск из адресной строки, в полной мере.


Список этот, возможно, мог бы продолжаться и дальше, если бы я поставил себе целью собрать воедино все претензии пользователей (а не только мои) к Safari. Но я описал лишь те, что привели меня к следующему выводу: Safari, увы, пока что не может претендовать на роль основного браузера на моих компьютерах. При своей легковесности и нетребовательности к ресурсам, он, к сожалению, имеет ряд серьёзных недочётов, благодаря которым проигрывает Firefox.

Mac OS X Hints
Adblock
detector