Относительное «лишь» относится не к сравнению долей Хрома и ИЕ, а к динамике изменения ситуации.
Другими словами, по сравнению с тем, что было год, два, три назад, сейчас доля ИЕ — лишь 36%, а доля Хрома — целых 36%.
Если вы доверяете другу, то он пароли смотреть не будет.
Если не доверяете, то инкогнито не спасёт от кейлоггера и банально от просмотра ваших документов на рабочем столе и папки «наши эро-фото».
Если доверяете, но не хотите, чтобы случайно пароли мешались, да, режим гостя в операционной системе. На всех трёх занимает до 10 секунд.
А если и это не подходит, просто другой профиль Хрома.
Если можно включить вашего пользователя на вашем компьютере, то можно и любой кейлоггер поставить, так что ваши пароли всё равно под угрозой.
Попробуйте поставить пароль на пользователя. Желательно и домашний каталог зашифровать.
В чём тогда преимущество перед простой запоминалкой паролей? В том, что указанные адреса открываются с любого компьютера за пару секунд.
Достать базу паролей из дома — сложнее. :)
Я написал его не давно, и, мне кажется, он объективно качественнее варианта Матиаза. Впрочем, я не отрицаю, что вдохновлён именно Матиазом, мы с ним переписывались. :)
Этот баг — это баг. Т.е. разработчики допустили оплошность и потом исправили.
Баги с расширением прототипов — это неправильные архитектурные решения. Их исправить сложно.
К примеру, случилась такая проблема, как у prototype.js — что делать? Старый код зависим от старого поведения, а новый код (особенно, внешний) — от нового.
Как догадаться, какой метод нужен вызывающему коду?
jQuery имеет обратную несовместимость с самим собой, это нормально. Вы контралируете обновление jQuery.
А насчёт «ломается в новых браузерах» я бы хотел цитату.
И даже если и правда иногда ломается, разумеется, расширение прототипов является дополнительным риском и меняет эту вероятность в большую сторону.
Скоро попимо блокировки плагинов и скриптов, для того, чтобы можно было читать статьи, как спокойные статьи, надо будет блокировать и CSS. А то всё бегает и прыгает. =7
Конечно, это не идеально удобные решения.
Но разве не очевидно, что слой с Javascript конечно нужен, только он добавляется сверху.
Таким образом, если вдруг у вас или на стороне клиента сломался Javascript, всё равно всё будет работать.
Таким образом, параноики и эстеты с отключенными скриптами получают замечательные условия и довольные радуются сайту.
А если ещё вспомним, что параноики и эстеты без скриптов практически однозначно являются технически образованной публикой, рекомендательной базой для окружающих, то снанет понятно, что эти 7%–17% Хабра-юзеров очень даже важны для проекта.
Другими словами, по сравнению с тем, что было год, два, три назад, сейчас доля ИЕ — лишь 36%, а доля Хрома — целых 36%.
Будете качать на него базу и KeePassX? :)
Компьютер может быть Chrome OS, например.
KeePassX там не запустится.
В принципе, это справедливо. Любая программа может и кейлоггер поставить.
Если не доверяете, то инкогнито не спасёт от кейлоггера и банально от просмотра ваших документов на рабочем столе и папки «наши эро-фото».
Если доверяете, но не хотите, чтобы случайно пароли мешались, да, режим гостя в операционной системе. На всех трёх занимает до 10 секунд.
А если и это не подходит, просто другой профиль Хрома.
Попробуйте поставить пароль на пользователя. Желательно и домашний каталог зашифровать.
В чём тогда преимущество перед простой запоминалкой паролей? В том, что указанные адреса открываются с любого компьютера за пару секунд.
Достать базу паролей из дома — сложнее. :)
Он навешивается с помощью условных комментариев:
Однако, в любом случае, это медленный CSS, который вынужденны хавать все браузеры. Я предпочитаю просто подключать отдельный CSS для IE.
Таг
<details>совсем новый и плагин Матиза самый первый. Вряд ли он сразу написал всё хорошо, правда? :)Я написал его не давно, и, мне кажется, он объективно качественнее варианта Матиаза. Впрочем, я не отрицаю, что вдохновлён именно Матиазом, мы с ним переписывались. :)
$life = 0не вернёт0, т.е. всегдаfalse?</зануда>Этот баг — это баг. Т.е. разработчики допустили оплошность и потом исправили.
Баги с расширением прототипов — это неправильные архитектурные решения. Их исправить сложно.
К примеру, случилась такая проблема, как у prototype.js — что делать? Старый код зависим от старого поведения, а новый код (особенно, внешний) — от нового.
Как догадаться, какой метод нужен вызывающему коду?
А насчёт «ломается в новых браузерах» я бы хотел цитату.
И даже если и правда иногда ломается, разумеется, расширение прототипов является дополнительным риском и меняет эту вероятность в большую сторону.
Наверняка к вёрстке своих комментариев вы подходите с меньшей заботой, чем к вёрстке статей, не правда ли?
Т.е. и на 50 килобайт вашего кода он выдаст 80 килобайт Javascript (50+30).
Разумеется, этот пример ненормален.
А вот основной выигрыш в удобстве разработки и поддержки.
Конечно, это не идеально удобные решения.
Но разве не очевидно, что слой с Javascript конечно нужен, только он добавляется сверху.
Таким образом, если вдруг у вас или на стороне клиента сломался Javascript, всё равно всё будет работать.
Таким образом, параноики и эстеты с отключенными скриптами получают замечательные условия и довольные радуются сайту.
А если ещё вспомним, что параноики и эстеты без скриптов практически однозначно являются технически образованной публикой, рекомендательной базой для окружающих, то снанет понятно, что эти 7%–17% Хабра-юзеров очень даже важны для проекта.