Вообще автору имело смысл вместо того, чтобы жаловаться на Хабре (да, конечно, это проще), сообщить о проблеме в юзабилити в багтрекере Мозиллы. В принципе проблема разрешается примерно так же, как с сайтами с просроченным/самоподписанным SSL-сертификатом: две кнопочки «Уходим отсюда» и «Я понимаю риск/Добавить исключение». Тогда пользователь получит более дружелюбную возможность для решения проблемы. Конечно, придётся вежливо и грамотно сформулировать проблему на английском, правильно классифицировать её и быть готовым к дополнительным вопросам, но зато это конструктивный подход :-)
Ещё лучше скачать сорцы Файрфокса, исправить проблему, собрать патч и приложить к забиси в багтрекере ;-)
Первая мысль — промэпить порт через локальный ssh-сервер:
ssh -L 80:<router_address>:6000 localhost
После чего можно заходить в файрфоксе на localhost:80
Может, есть способ проще :-)
А ещё он понимал теги на всех языках, включая китайский и японский (чего не умеет моя Нокия, выпущенная на четыре года позже!), и к песне можно было приаттачить караоке-код. В общем, раньше люди старались :-)
Мой долго работал, потом по наследству перешёл младшему брату и у него тоже долго работал. Кажется, в прошлом году брат ещё с ним ходил. Видимо, мне повезло :-)
Интересно. Можно ссылку на мануал к какому-нибудь из таких устройств? Те гарнитуры, что я держал в руках, предоставляли не больше, чем те самые пять кнопок.
Всё, что вы написали, действительно очевидно. Неочевидным, на мой взгляд, является тот факт, что при компиляции звёздочка разворачивается в полный список колонок. Вполне мог бы существовать байт-кодовый вариант, семантически эквивалентный выбору всех колонок.
Такое поведение можно понять (хотя я бы не сказал, что оно очевидное), однако явных упоминаний этого я на сайте MySQL не нашёл. Например, тут про подобное поведение не сказано. Возможно, я плохо искал. Вы можете показать, где сказано, что prepare запоминает список колонок на момент создания statement?
Почитываю нередко блог Реймонда Чена, изредка заглядываю к Ларри Остерману, немало интересного нашёл у Дженсена Харриса. Будет приятно здесь увидеть статьи в том же ключе, что и у них =)
А ещё я давно хочу где-нибудь высказать всё, что я думаю о саппорте Майкрософт в России! Так что жду топика об организации работы нашего саппорта — сколько там людей, много ли обращений (в том числе от физлиц) и какого характера эти обращения, много ли остаётся нерешённых проблем, что делают с нерадивыми саппортерами и т. д. Думаю, в комментариях к такому топику я и вылью всё, что накопилось =)
<body>
</body>
<script>
var a;
a = "http://example.org/get.php?test";
a += "&ok";
a += "&wonderful";
alert(a);
</script>
Во всех браузерах результат одинаковый: выдаётся сообщение http://example.org/get.php?test&ok&wonderful
Дело не в парсинге JS-скрипта, а в том, что этот скрипт криво модифицирует DOM-модель.
Если я неправ, приведите, пожалуйста, полный текст исправленного документа с использованием CDATA, который будет давать одинаковый результат в разных браузерах.
Вообще, во-первых, следует помнить, что innerHTML — это не просто поле, а свойство. То есть записав туда что-то и тут же считав, мы можем не получить то, что записали. То есть += действует примерно как setInnerHTML(getInnerHTML()+"...").
Чтение из innerHTML всегда должно возвращать well-formed HTML (исходя из здравого смысла, а не из стандарта, которого нет). Так как на вход ему подсовывают не well-formed, то браузеры пытаются интерпретировать его по-разному. Моё предположение, что Firefox интерпретирует &ok как ошибочно незаэкранированный амперсанд и добавляет экранирование сам, а Chrome интерпретирует, как незакрытый character-entity, мысленно дописывает в конец точку с запятой, после чего замечает, что character-entity &ok; не существует вообще и выкидывает его из результата.
Ещё лучше скачать сорцы Файрфокса, исправить проблему, собрать патч и приложить к забиси в багтрекере ;-)
ssh -L 80:<router_address>:6000 localhost
После чего можно заходить в файрфоксе на localhost:80
Может, есть способ проще :-)
> где «satsub» вычисляет разницу насыщенности между двумя значениями.
следует писать «насыщенную разность» или «разность с насыщением».
www.fightnews.ru/content/nikolay-valuev-posle-poezdki-v-metro-prishlos-pit-uspokoitelnoe
А ещё я давно хочу где-нибудь высказать всё, что я думаю о саппорте Майкрософт в России! Так что жду топика об организации работы нашего саппорта — сколько там людей, много ли обращений (в том числе от физлиц) и какого характера эти обращения, много ли остаётся нерешённых проблем, что делают с нерадивыми саппортерами и т. д. Думаю, в комментариях к такому топику я и вылью всё, что накопилось =)
Во всех браузерах результат одинаковый: выдаётся сообщение
http://example.org/get.php?test&ok&wonderfulДело не в парсинге JS-скрипта, а в том, что этот скрипт криво модифицирует DOM-модель.
Если я неправ, приведите, пожалуйста, полный текст исправленного документа с использованием CDATA, который будет давать одинаковый результат в разных браузерах.
Чтение из innerHTML всегда должно возвращать well-formed HTML (исходя из здравого смысла, а не из стандарта, которого нет). Так как на вход ему подсовывают не well-formed, то браузеры пытаются интерпретировать его по-разному. Моё предположение, что Firefox интерпретирует &ok как ошибочно незаэкранированный амперсанд и добавляет экранирование сам, а Chrome интерпретирует, как незакрытый character-entity, мысленно дописывает в конец точку с запятой, после чего замечает, что character-entity &ok; не существует вообще и выкидывает его из результата.