Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 95
Microsoft считает, что это небезопасная операция, поэтому даёт нам по рукам. Поэтому нормально стилизовать файл-инпут в Internet Explorer не получится.Включаете этому элементу прозрачность, растягиваете кнопку (установкой шрифта), уменьшаете поле (шириной), сверху кладёте слой со своей стилизованной кнопкой.
Которому элементу, инпуту? Так она не работает, только сегодня проверял. Правда, работает
visibility: hidden — но при нём не кликнешь. Касаемо же «сверху» — вообще сомневаюсь. Если положить сверху что-то с бОльшим z-index, то клик не проходит. В Опере точно такое было, пока я не узнал, что можно click() делать просто.
Всё работает. Только как раз input поверх кнопки, а не кнопка поверх input-а. Этот «трюк» ранее использовался повсеместно.
Да, вы правы, прошу прощения. Моя версия IE8 битая, она не работает с прозрачностью никак (переустановка не помогает). Способ вполне рабочий
… еще можно инпут файл положить внутрь лейбла. И тогда никакие трюки с прозрачностью не потребуются.
У меня не сработало это. Инпут остался видимым. Может, вы что-то не уточнили?
Ну так инпут скрыть надо, а label стилизировать как вам нужно.
Трюк в том, что input внутри label перехватывает получает все клики на label без паники системы защиты (label for= тоже работает).
Трюк в том, что input внутри label перехватывает получает все клики на label без паники системы защиты (label for= тоже работает).
В Firefox ниже 23-й версии был баг, из-за которого для file-полей это не работало.
А смысл в label? То есть это позволит сделать
display: none, при этом не используя прозрачность? Но я так понял, label обязательно должна быть привязана к инпуту через for, или нет?
Жду картинку по троллейбус из буханки.
PS inline-block для IE 6-7 существует:
PS inline-block для IE 6-7 существует:
*display: inline;
*zoom: 1;
Для IE7
zoom: 1 вроде не нужен. А для IE6 — на скриншоте видно, что происходит. При том, что вёрстка самая обычная (центрированный контейнер с заданным max-width, внутри него разбивка на две колонки, и левой ещё на две секции — всё абсолютным позиционированием, у контейнера position: relative).Для IE7 zoom: 1 нужен, иначе это будет обычный display: inline. А у IE6 столько болезней, что дело может быть не только в этом.
IE6 не поддерживает max-width, в его случае нужны танцы с бубном и expressions.
IE6 не поддерживает max-width, в его случае нужны танцы с бубном и expressions.
Позвольте не согласиться всё-таки. Обычный, да не совсем. Смотрим официальную спецификацию (кстати, Opera 11.64 ведёт себя согласно ей при задании
Это с HTML Academy.
Теперь смотрите на скрины)
Как видите — работает абсолютно как inline-block. Работает padding, работает задание ширины. Вы же не хотите сказать, что это глюк режима эмуляции, и в IE7 под виртуалкой я увижу что-то другое?
Касаемо margin — он работает и в режиме
display: inline):Особенности блочно-строчных элементов:
- им можно задавать размеры, рамки и отступы, как и блочным элементам;
- их ширина по умолчанию зависит от содержания, а не растягивается на всю ширину контейнера;
- они не порождают принудительных переносов строк, поэтому могут располагаться на одной строке, пока помещаются в родительский контейнер;
- элементы в одной строке выравниваются вертикально подобно строчным элементам.
Это с HTML Academy.
Теперь смотрите на скрины)
Показать
Как видите — работает абсолютно как inline-block. Работает padding, работает задание ширины. Вы же не хотите сказать, что это глюк режима эмуляции, и в IE7 под виртуалкой я увижу что-то другое?
Касаемо margin — он работает и в режиме
inline, тут моя ошибка, да. Внутренние отступы, недоступные в inline, мне в случае с иконками и кнопками были совершенно не нужны, но в случае реального inline у них бы высота и ширина схлопнулись до нуля, и они бы исчезли с экрана (потому как пустой контент). И я только что это в Опере проверил. Здесь же однако всё совсем не так. И под виртуалкой в IE7 ничего не исчезло :)Почитайте про hasLayout — он включается в том числе и при заданном width (как в вашем случае) и тогда zoom уже не нужен. Код выше (display: inline; zoom: 1;) это минимально необходимый код для inline-block на старых IE. Вы же утверждаете что обычный display: inline в IE ведет себя как dispaly: inline-block, а это не так.
Я так подумал по косвенным признакам) Спасибо за разъяснения. Но зачем zoom, если есть width? Я так понял, в моём случае всё-таки можно без него?
hasLayout можно включить разными способами, и каждый работает чуть по-своему. По моему опыту, самый «пуленепробиваемый» —
Если hasLayout уже включён, например, с помощью ширины, то
height: 1px (или любая другая явно заданная ширина или высота в пикселах) (именно px, т. к. % в определённых ситуациях к желаемому результату не приводил) для IE6 и min-height: 0 для IE7.Если hasLayout уже включён, например, с помощью ширины, то
zoom для этой цели, разумеется, уже не нужен. Кстати, с zoom в контексте включения hasLayout были определённые проблемы, поэтому я его для этой цели не использовал.За IE6 не скажу, но в IE7 ширина в процентах работает (без указания высоты), при этом
inline работает как inline-block. Пример (блоки с кнопками, по 2 штуки в двух контейнерах с display: block)На первый взгляд, процентные значения размеров элемента (я, кстати, говорил о фиктивных значениях, близких к нулю и используемых только для включения hasLayout) тоже включают hasLayout, но потом, по мере усложнения вёрстки, вид или поведение страницы могли (хотя и не обязательно) неожиданно стать неправильными.
Эм, после кодировки CP1251 перестал читать. Аффтар, ты в каком веке живёшь? UTF-8 жешь.
Если проект нацелен исключительно на Россию — зачем гонять для русского текста в два раза больше байтов? Траффик жешь :)
Чтобы не иметь проблем со спецсимволами и их вставкой с помощью подстановок (entities)? ;-)
Про Gzip тоже забывать не стОит.
Про Gzip тоже забывать не стОит.
Приведите пожалуйста пример спецсимволов, которые люди могут использовать в мессенджере общего назначения, и которых нет в однобайтовой кодировке)
Gzip и так работает, на самом деле. Просто не вижу смысла в юникоде, когда в сообщениях только русский и латиница. И кстати — ВК для российских пользователей использует CP1251, насколько я знаю.
Gzip и так работает, на самом деле. Просто не вижу смысла в юникоде, когда в сообщениях только русский и латиница. И кстати — ВК для российских пользователей использует CP1251, насколько я знаю.
Приведите пожалуйста пример спецсимволов, которые люди могут использовать в мессенджере общего назначения, и которых нет в однобайтовой кодировке)Не уверен, что вы подразумеваете под мессенджером общего назначения, а на сайтах вполне могут использоваться, например, такие символы:
→ ← ↓ ↑ μ × − ² ³
Просто не вижу смысла в юникоде, когда в сообщениях только русский и латиница. И кстати — ВК для российских пользователей использует CP1251, насколько я знаю.Подобные доводы, равно как и упоминание CP1251 вместо Windows-1251 пробуждает во мне впечатляющие воспоминания об одном человеке, который писал движок сайта на Delphi. :-)
Не думаю, что в мессенджере кто-то будет часто использовать квадрат или куб)
Тем более эти стрелки, которые вообще непонятно для чего. Кстати, квадрат у меня прошёл… Странно. Кодировка передачи до PHP — windows-1251, кодировка соединения с БД — тоже. Не очень экзотические символы попались похоже =)
UPD: оказывается, перед отправкой символы преобразуются к виду &#nnn; (μ для μ например). Видимо, заслуга браузера…
Тем более эти стрелки, которые вообще непонятно для чего. Кстати, квадрат у меня прошёл… Странно. Кодировка передачи до PHP — windows-1251, кодировка соединения с БД — тоже. Не очень экзотические символы попались похоже =)
UPD: оказывается, перед отправкой символы преобразуются к виду &#nnn; (μ для μ например). Видимо, заслуга браузера…
Да, современные браузеры при отправке форм вынужденно экранируют символы, отсутствующие в наборе символов используемой на странице кодировки. Эти коды — и есть подстановки (entities), с которыми в общем случае лучше не связываться без реальной необходимости. А реальная необходимость одна — экранирование служебных символов HTML (
И даже в «мессенджере» пользователь может вставить фрагмент текста, откуда-то его скопировав. ;-)
<, >, &, ") в текстовых узлах и значениях атрибутов.И даже в «мессенджере» пользователь может вставить фрагмент текста, откуда-то его скопировав. ;-)
Чем плохи подстановки? Тем, что символов 6 вместо одного?) А если это происходит раз в 100-200 сообщений? Вроде как, практические соображения перевешивают.
Тем, что один реальный символ представлен более чем одним символом на уровне кода. Если есть универсальная кодировка, где все символы, кроме 4-х спецсимволов HTML, можно хранить непосредственно (UTF-8), нет смысла использовать другую кодировку. Экономия трафика путём использования ограниченной 8-битной кодировки вместо универсальной UTF-8 — это, пожалуй, экономия на спичках.
Согласен, в некоторых приложениях это может быть критично. К счастью, у меня задача намного проще, там нет особой работы с разбиением текста и обработкой фрагментов. Более того — сама идеология системы End-to-End шифрования подразумевает, что сервер ничего «не знает» и хранящихся текстах (даже в тех переписках, где они не зашифрованы). Ему должно быть пофиг, сколькими символами там закодировался редкий символ. Главное — чтобы обратное декодирование прошло без проблем и вернуло тот же результат.
Насчёт экранирования тех символов, что вы написали — ну можно хранить так, а замену делать на этапе вывода, например. Мне кажется, такой подход гибче, хотя и потребует лишнего процессорного времени. Более того, современные браузеры вообще прощают такие не экранированные символы в текстовых узлах (хотя это конечно не означает, что не нужно делать по правилам).
Насчёт экранирования тех символов, что вы написали — ну можно хранить так, а замену делать на этапе вывода, например. Мне кажется, такой подход гибче, хотя и потребует лишнего процессорного времени. Более того, современные браузеры вообще прощают такие не экранированные символы в текстовых узлах (хотя это конечно не означает, что не нужно делать по правилам).
можно хранить так, а замену делать на этапе вывода, например. Мне кажется, такой подход гибче, хотя и потребует лишнего процессорного времени.Можно, просто в общем случае нецелесообразно. Хотя, конечно, решение за разработчиком конкретного сайта или приложения.
современные браузеры вообще прощают такие не экранированные символы в текстовых узлахТолько когда очевидно, что спецсимвол использован как текстовый (например, если непосредственно за открывающей угловой скобкой следует пробел). Но код при этом не перестаёт быть синтаксически некорректным («невалидным»).
Да, точно — валидацию разметка после такого не проходила, поправлял. Вы правы.
Про целесообразность — ну так экономия места в базе. Пока база маленькая, это не принципиально, но вот когда разрастётся… Впрочем, поскольку этих символов мало — можно не заморачиваться с этим. Но всё-таки этих символов больше, мне думается, чем тех, для которых придётся использовать entities. Так что мой подход тоже имеет право на жизнь
Про целесообразность — ну так экономия места в базе. Пока база маленькая, это не принципиально, но вот когда разрастётся… Впрочем, поскольку этих символов мало — можно не заморачиваться с этим. Но всё-таки этих символов больше, мне думается, чем тех, для которых придётся использовать entities. Так что мой подход тоже имеет право на жизнь
Нет, ну конкретный символ из только что перечисленных может и нечасто нужен. Вот только это просто пример, а символов тысячи, и любым из них «российский пользователь» может попытаться воспользоваться.
Вы не представляете, как раздражает, когда на каком-нибудь кривом сайте во время общения по привычке вводишь специальный символ, а тот либо шлет какую-то кашу (в Quora есть такая проблема), либо выдает что-нибудь вроде «Ошибка записи в базу данных» (такая проблема на сайте МТИ).
Вы не представляете, как раздражает, когда на каком-нибудь кривом сайте во время общения по привычке вводишь специальный символ, а тот либо шлет какую-то кашу (в Quora есть такая проблема), либо выдает что-нибудь вроде «Ошибка записи в базу данных» (такая проблема на сайте МТИ).
И да, к слову, даже если говорить только о перечисленных символах — стрелка «→» нередко бывает нужна, когда кому-нибудь по чату объясняешь последовательность действий, например в какие меню зайти в программе, и куда нажать.
Просто не вижу смысла в юникоде, когда в сообщениях только русский и латиница.Правильнее исходить из обратных побуждений. Нужно искать смысл НЕ использовать unicode. И в 21 веке такая причина должна быть веской.
И кстати — ВК для российских пользователей использует CP1251, насколько я знаю.А хабрахабр до сих пор не умеет HTTPS. Впрочем, если мне не изменяет память, VK тоже далеко не сразу ему научился.
Блин, а ведь и правда не умеет. А мне казалось, что умел(
Зачем тогда они HabraStorage на HTTPS перевели, да ещё так, что в старых Операх картинки не грузятся? Вот где загадка…
Честно говоря, в HTTPS не вижу особого смысла. Если для ВК это ещё можно обосновать логинами через бесплатный Wi-Fi, то вот на Хабр заходят как правило из дома (ну по крайней мере статьи пишут точно оттуда). А уж шифровать картинки статей… Мда. Даже у Википедии больше причин работать по SSL, на мой взгляд.
Но главное — насчёт «не сразу» Вы не правы. ВК был создан в 2006 году, тогда UTF-8 очень даже был. И раньше был. Это их сознательный выбор, а не «не умеют». Я думаю, экономят траффик (даже с учётом сжатия будет меньше, тем более в ВК очень много текстов), плюс функции работы с обычными строками в PHP должны работать намного быстрее, чем те, что с префиксом mb_.
На самом деле, даже между разными серверами гонять меньше данных приходится — если соединение с SQL сервером в однобайтовой кодировке делать. Не знаю, как делает вк, но что у них сервера баз данных на отдельных кластерах, это без сомнений.
Зачем тогда они HabraStorage на HTTPS перевели, да ещё так, что в старых Операх картинки не грузятся? Вот где загадка…
Впрочем, если мне не изменяет память, VK тоже далеко не сразу ему научился
Честно говоря, в HTTPS не вижу особого смысла. Если для ВК это ещё можно обосновать логинами через бесплатный Wi-Fi, то вот на Хабр заходят как правило из дома (ну по крайней мере статьи пишут точно оттуда). А уж шифровать картинки статей… Мда. Даже у Википедии больше причин работать по SSL, на мой взгляд.
Но главное — насчёт «не сразу» Вы не правы. ВК был создан в 2006 году, тогда UTF-8 очень даже был. И раньше был. Это их сознательный выбор, а не «не умеют». Я думаю, экономят траффик (даже с учётом сжатия будет меньше, тем более в ВК очень много текстов), плюс функции работы с обычными строками в PHP должны работать намного быстрее, чем те, что с префиксом mb_.
На самом деле, даже между разными серверами гонять меньше данных приходится — если соединение с SQL сервером в однобайтовой кодировке делать. Не знаю, как делает вк, но что у них сервера баз данных на отдельных кластерах, это без сомнений.
Кстати, VK вы, вероятно, переоцениваете. Например, они уже три месяца (после сообщения от автора этих строк) не могут «исправить» тривиальную ошибку типа «тёплое с мягким», из-за которой пользователя современного браузера перенаправляют на страницу «Вы используете устаревший браузер» лишь на основании отключённого JavaScript:
Дополнительно впечатляет, что баг-трекер у них тоже есть, но там, судя по всему, почему-то доступен только поиск без возможности добавления новых баг-репортов, поэтому приходится действовать приватно через раздел «Помощь».
<noscript><meta http-equiv="refresh" content="0; URL=/badbrowser.php"></noscript>
Дополнительно впечатляет, что баг-трекер у них тоже есть, но там, судя по всему, почему-то доступен только поиск без возможности добавления новых баг-репортов, поэтому приходится действовать приватно через раздел «Помощь».
Ну баг-трекер у них всегда был чем-то фиктивным, сколько я его помню, если мы с вами говорим об одном. А вот про JS вы зря. Это нормально, ВК без JS не работает, потому что не может работать — это не какой-то там мессенджер, а целая соцсеть. Так всегда было, насколько я помню — минимум года 4 или больше. То есть стоит отключить JS — и тебя кидает на эту страничку :)
Проблема не в том, что без JS сайт не работает, а в ложном предположении, что отключённый JS говорит об устаревшем браузере (иначе говоря, божий дар с яичницей):
1. пользователь вводится в заблуждение не соответствующим действительности сообщением об устаревшем браузере, хотя браузер у него самый свежий;
2. вместо вывода уведомления непосредственно на запрошенной странице происходит принудительное перенаправление на другую страницу без возможности вернуться назад. Поэтому перейдя на страницу, например, с помощью браузерной закладки, не имеешь возможности, временно включив JS, просто обновить страницу — приходится снова искать страницу в закладках.
Т. е. имеем не только ошибочную увязку не связанных вещей (отлючённый JS и устаревший браузер), но и технически безграмотное решение, снижающее удобство пользователя, а также нежелание со стороны их веб-разработчиков пошевелиться и элементарным образом решить этот тривиальнейший вопрос. Какой там UTF-8, что вы. ;-)
1. пользователь вводится в заблуждение не соответствующим действительности сообщением об устаревшем браузере, хотя браузер у него самый свежий;
2. вместо вывода уведомления непосредственно на запрошенной странице происходит принудительное перенаправление на другую страницу без возможности вернуться назад. Поэтому перейдя на страницу, например, с помощью браузерной закладки, не имеешь возможности, временно включив JS, просто обновить страницу — приходится снова искать страницу в закладках.
Т. е. имеем не только ошибочную увязку не связанных вещей (отлючённый JS и устаревший браузер), но и технически безграмотное решение, снижающее удобство пользователя, а также нежелание со стороны их веб-разработчиков пошевелиться и элементарным образом решить этот тривиальнейший вопрос. Какой там UTF-8, что вы. ;-)
Да, и правда фигово сделано.
Насчёт UTF-8 — так он был. Помните, статусы задом-наперёд с помощью специальных символов? От него намеренно отказались — и я думаю, на то были причины. Мне кажется, вы плохо знаете вк))
Кстати — как вам вот такое? Это всё на тему издержек.
А ещё тут писали про GZIP — так вот всё равно размер словаря будет больше. Я знаю, что там не просто дерево Хаффмана строится, а всё гораздо сложнее при ZIP сжатии, и используется несколько техник — но всё равно словарь вырастет. Примерно вдвое
Насчёт UTF-8 — так он был. Помните, статусы задом-наперёд с помощью специальных символов? От него намеренно отказались — и я думаю, на то были причины. Мне кажется, вы плохо знаете вк))
Кстати — как вам вот такое? Это всё на тему издержек.
А ещё тут писали про GZIP — так вот всё равно размер словаря будет больше. Я знаю, что там не просто дерево Хаффмана строится, а всё гораздо сложнее при ZIP сжатии, и используется несколько техник — но всё равно словарь вырастет. Примерно вдвое
У вас всё так органично получается. Windows XP, no-HTTPS, no-Unicode + win1251, экономия на спичках (избегание mb_), Opera 12-. Пожалуй в этот ряд ещё отлично впишутся FTP и phpMyAdmin. Перечислил бы ещё пару пунктов, но адепты этих инструментов съедят с потрохами :D
Настоящая прогулка с динозаврами. Каноническая :)
Настоящая прогулка с динозаврами. Каноническая :)
FTP и phpMyAdmin
С этими динозаврами порой приходится гулять не от хорошей жизни…
Ну в целом ваш посыл уловил, спорить не буду, всё так)
Вот только про XP зря вы — лёгкая и удобная ОС, без лишнего, и с чётким нормальным рендерингом шрифтов. Я кстати из-за бледного вывода шрифтов даже новым Chrome пользоваться нормально не могу.
no-HTTPS не потому, что я считаю, что так нужно (мессенджер этот как раз для безопасности общения сделан), а потому, что проект пока «не взлетел», прибыли не приносит, а сертификат хороший — стоит денег.
А про phpMyAdmin — вот тут я правда удивлён. Вы таки знаете более удобные аналоги?) Я думал, это стандарт де-факто. Причём, он не только с MySQL работает, а с многими СУБД. Ну и в любом случае, у меня к нему претензий нет особых.
Если интересно, почему Опера не новой версии — могу объяснить) Не 15+, потому что это уже не Опера в строгом смысле. И куча функций утеряно, и дизайн совсем не тот, со шрифтами те же грабли. А почему не 12.х — потому что тормозная и глючная до безобразия. Глюков тележку можно наперечислять в ней, если вспомнить =)
Вот только про XP зря вы — лёгкая и удобная ОС, без лишнего, и с чётким нормальным рендерингом шрифтов. Я кстати из-за бледного вывода шрифтов даже новым Chrome пользоваться нормально не могу.
no-HTTPS не потому, что я считаю, что так нужно (мессенджер этот как раз для безопасности общения сделан), а потому, что проект пока «не взлетел», прибыли не приносит, а сертификат хороший — стоит денег.
А про phpMyAdmin — вот тут я правда удивлён. Вы таки знаете более удобные аналоги?) Я думал, это стандарт де-факто. Причём, он не только с MySQL работает, а с многими СУБД. Ну и в любом случае, у меня к нему претензий нет особых.
Если интересно, почему Опера не новой версии — могу объяснить) Не 15+, потому что это уже не Опера в строгом смысле. И куча функций утеряно, и дизайн совсем не тот, со шрифтами те же грабли. А почему не 12.х — потому что тормозная и глючная до безобразия. Глюков тележку можно наперечислять в ней, если вспомнить =)
Это называется создать себе проблему, а потом её героически решать. До сих пор встречаюсь с проблемами кодировок… на Windows. В любой *nix системе уже давно забили на все альтернативные кодировки и повсеместно используют UTF-8. Я раньше такое даже на FreeBSD практиковал, хотя там в консоли, вроде, до сих пор проблемы (буду рад, что ошибаюсь, давно в консоли голой не был).
А не поделитесь, какие именно проблемы? У меня последние проблемы закончились ещё в середине нулевых, когда пересел на нормальный браузер (который делал автодетект без ошибок). Даже ещё раньше — уже IE7 почти не ошибался при определении. А при работе локально — так вообще никаких проблем, в Windows одна кодировка всего, там не может быть никаких вариантов. То есть есть ещё две двухбайтовых и UTF-8, но по дефолту всё в ANSI.
Единственное, когда плохо — это когда на Mac OS X пакуют файлы макета в архив (обычно дизайнеры), потом пересылают мне… А там все имена битые. Именно из-за того, что кодировка на Маке другая, похоже.
Единственное, когда плохо — это когда на Mac OS X пакуют файлы макета в архив (обычно дизайнеры), потом пересылают мне… А там все имена битые. Именно из-за того, что кодировка на Маке другая, похоже.
Да бывает на работе обращаются с разными хитрыми файлами. Открываешь стандартными средствами, копируешь текст, а получаешь кракоряблики или просто знаки вопроса вместо русских букв. И ещё, такая же беда с файлами из 1C, вроде.
А не поделитесь, какие именно проблемы?Пресловутый Bush hid the facts в разнообразных вариациях. Ниже вы приводите разнообразные её вариации, приговаривая при этом «да всё ж работает… кроме этого, вот этого и ещё того».
Во всех системах, кроме Windows про эти проблемы все уже давно забыли: UTF-8 везде — и не нужно никаких автоопределений.
because Notepad prepends a byte order mark as a non-standard UTF-8 flag
Ну вот, то есть для Windows маркером кодировки является BOM (который так все ругают постоянно), а если его нет — она пытается анализировать содержимое эвристически.
Протестил кстати примеры из статьи, работают =) У меня как раз WinXP SP3.
Но всё равно не понимаю, при чём тут веб. Если проект не планирует международного развития, хранит базу в любой кодировке, но движок интерпретирует её всегда как известную однобайтовую кодировку (и никуда не конвертирует) — такого казуса не произойдёт. У меня всё ещё лучше — данные сохраняются в UTF-8 (на уровне СУБД), то есть в базе может быть любой контент, на любом языке. И в тот момент, когда проекту понадобится перейти на UTF-8 — это будет сделано буквально в две строки в заголовочном файле. И никаких кракозябр, и ничего конвертировать не нужно.
данные сохраняются в UTF-8 (на уровне СУБД)Это правильно. Хотя тогда тем более нет смысла заниматься перекодировкой туда-сюда, а лучше просто использовать UTF-8 везде. Унификация, единообразие, предсказуемость.
Не соглашусь всё-таки. Понимаете, чтобы было везде — надо файлы тоже в UTF-8 хранить. Хотя бы шаблоны (а у меня местами в одном файле код и контент, то есть по сути все PHP скрипты надо перекодировать в UTF-8).
А теперь внимание — вы не знали, что ISP Manager имеет серьёзные баги при работе с файлами в UTF-8, содержащими русский текст? Сейчас не уверен, может уже и исправили, а вот как минимум весной-летом 2013-ого такой файл в панели было не открыть на редактирование (у меня другой проект в UTF-8 целиком). А редактировать каждый раз локально, а потом заливать кнопкой «Загрузить файл» (а правки я делаю по 3-4 раза в минуту) — увольте, я не мазохист.
А теперь внимание — вы не знали, что ISP Manager имеет серьёзные баги при работе с файлами в UTF-8, содержащими русский текст? Сейчас не уверен, может уже и исправили, а вот как минимум весной-летом 2013-ого такой файл в панели было не открыть на редактирование (у меня другой проект в UTF-8 целиком). А редактировать каждый раз локально, а потом заливать кнопкой «Загрузить файл» (а правки я делаю по 3-4 раза в минуту) — увольте, я не мазохист.
вы не знали, что ISP ManagerНе просто не знал, но и никогда не пользовался ISP Manager. :-) С другой стороны, вполне могу понять вынужденное ограничение на уровне используемой платформы. Приходилось иметь дело с «движком», поддерживавшим только Windows-1251.
А с cPanel работали?) Вот интересно, вы правда не разрабатывали никакой сайт для обычного хостинга? Даже в молодости?)
Мне казалось, почти каждый через это прошёл из здесь присутствующих. Естественно, в более крупных проектах уже правила игры другие. Но даже там часто покупают недешёвую лицензию — и таки да, ставят ISP Manager. Поскольку он и правда удобен и много чего может.
Мне казалось, почти каждый через это прошёл из здесь присутствующих. Естественно, в более крупных проектах уже правила игры другие. Но даже там часто покупают недешёвую лицензию — и таки да, ставят ISP Manager. Поскольку он и правда удобен и много чего может.
Кстати, а у вас не было проблем c отображением отдельных букв кириллицы? Обычно вылезает проблема если пользователи сами могут сообщения оставлять на сайте.
Просто вспомнился один форум несколько лет назад где я был постоянным посетителем. Админ того форума никак не мог эту проблему исправить.
Кстати, тут нашёл свои слова возмущения от 1 февраля 2007 года. Неожиданно обнаружил, что свой личный сайт до сих пор в cp1251 :) Тут же переделал всё в UTF-8.
Просто вспомнился один форум несколько лет назад где я был постоянным посетителем. Админ того форума никак не мог эту проблему исправить.
Кстати, тут нашёл свои слова возмущения от 1 февраля 2007 года. Неожиданно обнаружил, что свой личный сайт до сих пор в cp1251 :) Тут же переделал всё в UTF-8.
Нет, никогда не было) По идее, такого вообще никогда не должно быть. Разве что, прогон через iconv() иногда даёт баги (но обычно не из UTF-8 а из более редких кодировок вроде UTF-16, сталкивался с подобным, когда парсил ID3-тэги в MP3 файлах самописной функцией).
Оффтопик
iconv() вообще зло. в одном проекте было нужно парсить каналы на YouTube, и сначала это было реализовано не используя API (потом перешли на него, правда). Так вот iconv() плох тем, что когда он встречает в UTF-8 некоторые экзотические составные символы — он не выбрасывает их, а делает аварийный выход, и вся часть строки после проблемного символа — отбрасывается. Это доставляло массу проблем: например, «плохой» символ мог попасться в названии или описании канала — но из-за его присутствия мы не могли получить данные, расположенные дальше.
Точнее, могли, но для этого нужно было предварительно разбить весь HTML код на фрагменты. Задача реальная, но трудоёмкая, плюс это делало нас сильно зависимыми от разметки YouTube — в любой момент она могла поменяться, и разбиение стало бы работать неправильно.
Точнее, могли, но для этого нужно было предварительно разбить весь HTML код на фрагменты. Задача реальная, но трудоёмкая, плюс это делало нас сильно зависимыми от разметки YouTube — в любой момент она могла поменяться, и разбиение стало бы работать неправильно.
Вы, наве́рное, не пове́рите, но да́же кири́ллица иногда́ не помеща́ется в оди́н байт.
> У меня как раз WinXP SP3.
Яснопонятно, откуда у вас такое отторжение юникода и прочего. Это ж слишком новое все, непроверенное и от лукавого!
А на сервере у вас, дайте угадаю, Server 2003, MSSQL и Apache 1.3?
Яснопонятно, откуда у вас такое отторжение юникода и прочего. Это ж слишком новое все, непроверенное и от лукавого!
А на сервере у вас, дайте угадаю, Server 2003, MSSQL и Apache 1.3?
Это обычный недорогой хостинг, там Apache 2.x и CloudLinux. На домашнем сервере у меня Apache 2.0 стоял ещё в 2009-ом году, так что тут тоже не угадали (правда, и сейчас стоит он же, поскольку сервер этот мне особо не нужен, крутится там домашняя страничка, работает — и ладно). =)
И — стыд и срам — там стоит WinXP SP2 (SP3 уже не влазит на встроенный накопитель), причём изначально — она была Home Edition, то есть там даже управления политиками нет. Зато лицензионная =)
Серверной Windows у меня никогда не было, не качать же её для такой ерунды. Кроме того — нетбук её не факт, что потянет.
И — стыд и срам — там стоит WinXP SP2 (SP3 уже не влазит на встроенный накопитель), причём изначально — она была Home Edition, то есть там даже управления политиками нет. Зато лицензионная =)
Серверной Windows у меня никогда не было, не качать же её для такой ерунды. Кроме того — нетбук её не факт, что потянет.
Я не знаю, какой у вас опыт в веб-разработке, и какой у вас сайт — тоже не знаю, но РАДИ ВСЕГО СВЯТОГО, используйте UTF. Причин вам накидали уже миллион, но самая главная — вы без серьезного на то повода ограничиваете как себя, так и ваших пользователей, ограничиваете преусловутыми 255 символами, половина из которых — английские и технические символы. Это все равно, что прыгать на одной ноге, вместо того, что бы бежать на двух, аргументируя «ну так одна нога меньше места занимает».
Не существует никакой необходимости не использовать юникод. Как вам уже написали, серьезной разницы по траффику нет — gzip сжатие поможет в любом случае). Вы считаете, что приложение русскоязычное, а что если завтра оно выстрелит и вам срочно нужно будет сделать мультиязычность?
А что, если ваши «исключительно русскоязычные» пользователи захотят написать/скопировать текст на эстонском, туркменском, китайском? Что если они скопируют спец-символы из блокнота? Что если они захотят написать иностранное имя, оригинальное название фильма, или название анимe на японском?
А что если вы захотите подключить внешний виджет, сграбить данные с API, подключить внешнюю базу которая в UTF? Парам-пам-пам — вам прийдется лепить костыли и подключать конвертацию. Или не вам, а разработчику, который за вас будет сайт доделывать/поддерживать (а теперь представьте, сколько проклятий в ваш адрес уйдет).
Я не знаю, сколько еще привести причин использовать UTF.
Тоже самое с HTTPS. Единственная причина не использовать его — это отсутствие денег на сертификат (и то, эта проблема уже решаема и скорее всего ее не будет в будущем).
HTTPs — это не только защита для «логинов через бесплатный Wi-Fi», как вы говорите. Это защита данных впринципе. Даже если на вашем сайте нету сессии (в чем я сомневаюсь), если через ваш сайт люди будут отправлять хоть какую-то информацию, ее имеет смысл шифровать.
Я понимаю, что домохозяйки этого понимать не могут, но уж вы-то как разработчик обязаны осознавать, что большинство людей не «фильтруют», что они пишут в интернете. Телефоны, номера кредитных карт… если ваше приложение — веб-мессенжер, то тут все еще хуже.
Не вижу смысла приводить миллион причин, т.к. в гугле есть миллион статей на эту тему. Просто почитайте.
Не существует никакой необходимости не использовать юникод. Как вам уже написали, серьезной разницы по траффику нет — gzip сжатие поможет в любом случае). Вы считаете, что приложение русскоязычное, а что если завтра оно выстрелит и вам срочно нужно будет сделать мультиязычность?
А что, если ваши «исключительно русскоязычные» пользователи захотят написать/скопировать текст на эстонском, туркменском, китайском? Что если они скопируют спец-символы из блокнота? Что если они захотят написать иностранное имя, оригинальное название фильма, или название анимe на японском?
А что если вы захотите подключить внешний виджет, сграбить данные с API, подключить внешнюю базу которая в UTF? Парам-пам-пам — вам прийдется лепить костыли и подключать конвертацию. Или не вам, а разработчику, который за вас будет сайт доделывать/поддерживать (а теперь представьте, сколько проклятий в ваш адрес уйдет).
Я не знаю, сколько еще привести причин использовать UTF.
Тоже самое с HTTPS. Единственная причина не использовать его — это отсутствие денег на сертификат (и то, эта проблема уже решаема и скорее всего ее не будет в будущем).
HTTPs — это не только защита для «логинов через бесплатный Wi-Fi», как вы говорите. Это защита данных впринципе. Даже если на вашем сайте нету сессии (в чем я сомневаюсь), если через ваш сайт люди будут отправлять хоть какую-то информацию, ее имеет смысл шифровать.
Я понимаю, что домохозяйки этого понимать не могут, но уж вы-то как разработчик обязаны осознавать, что большинство людей не «фильтруют», что они пишут в интернете. Телефоны, номера кредитных карт… если ваше приложение — веб-мессенжер, то тут все еще хуже.
Не вижу смысла приводить миллион причин, т.к. в гугле есть миллион статей на эту тему. Просто почитайте.
Да нет у меня неприятия UTF-8, как кто-то написал выше. Мне, очевидно, приписывают то, чего я нигде не писал. Просто в некоторых случаях он, на мой взгляд, избыточен (это моя личная позиция, и она может казаться вам неверной, это нормально).
Давайте по пунктам:
Ну да, и что? В 90% случаев русскоговорящему пользователю достаточно русского и английского алфавита, цифр, знаков препинания и некоторых спецсимволов. То есть всех тех символов, которые есть на клавиатуре.
Будет надо — сделаем. Я или кто-то другой)
Да, всё так, это как раз и есть те оставшиеся 10 процентов. Но в этом случае браузер закодирует всё это в entites, и побиться ничего не должно.
Если этот виджет будет настолько важен (обычно виджеты — это что-то второстепенное), то перейдём конечно. Но я не считаю правильным из-за какого-то виджета, который выдаёт символы в UTF-8, менять кодировку целого сайта. Если там всего 1-3 таких символа, которые нельзя сконвертировать в текущую кодировку — проще написать костыль, который подменит их перед конвертацией.
Защита при передаче по каналу связи, не более. Обычный проводной канал имеет меньше шансов быть прослушанным (да, про СОРМ я знаю, но это особый случай и особые полномочия). Главное же — HTTPS не поможет обезопасить данные от владельцев/админов сервера.
И поэтому — тадам! — проект имеет свой алгоритм шифрования, который можно активировать при создании комнаты (работает независимо от того, есть ли HTTPS). Причём он шифрует данные насовсем, так что их не прочитает в том числе и администратор сервера. Общий чат не шифруется, конечно — смысла нет. Но если человек напишет в общий чат номер своей кредитки или полный список паролей — ну это, извините, диагноз, с этим ничего не поделать =)
Давайте по пунктам:
вы без серьезного на то повода ограничиваете как себя, так и ваших пользователей, ограничиваете преусловутыми 255 символами, половина из которых — английские и технические символы
Ну да, и что? В 90% случаев русскоговорящему пользователю достаточно русского и английского алфавита, цифр, знаков препинания и некоторых спецсимволов. То есть всех тех символов, которые есть на клавиатуре.
Вы считаете, что приложение русскоязычное, а что если завтра оно выстрелит и вам срочно нужно будет сделать мультиязычность
Будет надо — сделаем. Я или кто-то другой)
А что, если ваши «исключительно русскоязычные» пользователи захотят написать/скопировать текст на эстонском, туркменском, китайском? Что если они скопируют спец-символы из блокнота? Что если они захотят написать иностранное имя, оригинальное название фильма, или название анимe на японском?
Да, всё так, это как раз и есть те оставшиеся 10 процентов. Но в этом случае браузер закодирует всё это в entites, и побиться ничего не должно.
А что если вы захотите подключить внешний виджет, сграбить данные с API, подключить внешнюю базу которая в UTF? Парам-пам-пам — вам придется лепить костыли и подключать конвертацию.
Если этот виджет будет настолько важен (обычно виджеты — это что-то второстепенное), то перейдём конечно. Но я не считаю правильным из-за какого-то виджета, который выдаёт символы в UTF-8, менять кодировку целого сайта. Если там всего 1-3 таких символа, которые нельзя сконвертировать в текущую кодировку — проще написать костыль, который подменит их перед конвертацией.
HTTPs — это не только защита для «логинов через бесплатный Wi-Fi», как вы говорите. Это защита данных впринципе.
Защита при передаче по каналу связи, не более. Обычный проводной канал имеет меньше шансов быть прослушанным (да, про СОРМ я знаю, но это особый случай и особые полномочия). Главное же — HTTPS не поможет обезопасить данные от владельцев/админов сервера.
Я понимаю, что домохозяйки этого понимать не могут, но уж вы-то как разработчик обязаны осознавать, что большинство людей не «фильтруют», что они пишут в интернете. Телефоны, номера кредитных карт… если ваше приложение — веб-мессенжер, то тут все еще хуже.
И поэтому — тадам! — проект имеет свой алгоритм шифрования, который можно активировать при создании комнаты (работает независимо от того, есть ли HTTPS). Причём он шифрует данные насовсем, так что их не прочитает в том числе и администратор сервера. Общий чат не шифруется, конечно — смысла нет. Но если человек напишет в общий чат номер своей кредитки или полный список паролей — ну это, извините, диагноз, с этим ничего не поделать =)
в этом случае браузер закодирует всё это в entites, и побиться ничего не должно.Зато, кстати, entities попадут в базу данных (и останутся там, скорее всего, навсегда), даже если сама она в UTF-8, если, конечно, перед записью в БД их не раскодировать (что в общем случае маловероятно).
Ну да, а что поделать. Но ведь благодаря этому на выводе пользователь не увидит квадратики — я вот сильно сомневаюсь, что в обратную сторону браузер тоже заменит. Точнее, уверен, что нет, если данные приходят «сразу». Если через XHR — не знаю, надо смотреть.
При «переезде» на UTF-8 можно написать небольшую функцию, которая сделает замену. Это пишется в несколько строк — если, конечно, подготовить заранее базу этих самых кодов замены… Они кстати случайно не равны Unicode кодам?
При «переезде» на UTF-8 можно написать небольшую функцию, которая сделает замену. Это пишется в несколько строк — если, конечно, подготовить заранее базу этих самых кодов замены… Они кстати случайно не равны Unicode кодам?
Да, проверил. Вручную поправил в базе сообщение. Если бы не заменялось — был бы знак вопроса вместо символа. Что в принципе логично. Причём не важно, каким образом этот символ придёт, через XHR или нет — он приходит из СУБД уже в однобайтовой кодировке, и на этом этапе с ним ничего не сделать.
либо прописать нужным блокам (например, вторым в контейнере) особый класс во всех местах в HTML, либо написать одну JavaScript функцию, и в ней назначить нужные стили через style.Можно ещё добавлять классы средствами JS.
IE7 (и IE8 в режиме эмуляции) добавляет слева от всех пунктов отступТакого бага уже не припомню (давно IE9+, а задолго до этого — IE8+), но включение так называемого hasLayout с помощью
min-height: 0 для IE7 и height: 1px для IE6 решало большинство абсурдных проблем, свойственных IE 6/7. У списков была другая проблема — увеличенный относительно номинального line-height даже при list-style: none для списка, обходилась с помощью vertical-align: top для LI.А что насчёт IE6?IE6 (0,05%) уже давно нет. Как и IE7 (0,2%) и, в общем-то, IE8 (0,6%). Для них достаточно использовать подход с унифицированной упрощённой таблицей стилей, основанной на семантике.
IE7 (и IE8 в режиме эмуляции) добавляет слева от всех пунктов отступ.
это лечилось с помощью list-style-position: outside;
стилизовать input типа file
Его не нужно скрывать. Поместите его в div с position: relative и oveflow: hidden, сделайте position: absolute, растяните по размеру контейнера и сделайте прозрачным (filter: alpha(opacity=0)).
После этого стилизуйте div как вам надо.
Ностальгии коммент :)
Здесь должно быть полно старичков, для которых подобные танцы были простой рутиной.
Очень многое решалось zoom:1; и position:relative; Ну и знать всякую «магию». Например IE6 при float:left; margin-left:10px; удваивал значение margin. То есть он считал margin-left:20px; Настоящая боль это скругленные уголки и прозрачность )
Здесь должно быть полно старичков, для которых подобные танцы были простой рутиной.
Очень многое решалось zoom:1; и position:relative; Ну и знать всякую «магию». Например IE6 при float:left; margin-left:10px; удваивал значение margin. То есть он считал margin-left:20px; Настоящая боль это скругленные уголки и прозрачность )
Нужна помощь по этим динозварам (только JS я тогда не знал), пишите в личку. Не проподать же знаниям )
ну, скруглённые углы довольно успешно решаются тупо большим количеством разметки… Как вспомню этот код — брррр, ужас.
Потому во всех текущих проектах просто тупо забил на поддержку любых устаревших браузеров, а IE начинается с 9. Как только наберёт популярность Win 10 и EDGE — так сразу нафиг все устаревшие браузеры.
Пора переходить на современный JS… Как только пойму необходимость =)
PS смотрю код на «хардкорных» js-прогеров, удивляюсь обилию костылей и полифиллов. Это было необходимо 10 лет назад, сейчас — уже нет. Старый веб должен погибнуть вместе с поддержкой от программистов. Иначе так и будем из десятилетия в десятилетие таскать весь этот мусор.
Потому во всех текущих проектах просто тупо забил на поддержку любых устаревших браузеров, а IE начинается с 9. Как только наберёт популярность Win 10 и EDGE — так сразу нафиг все устаревшие браузеры.
Пора переходить на современный JS… Как только пойму необходимость =)
PS смотрю код на «хардкорных» js-прогеров, удивляюсь обилию костылей и полифиллов. Это было необходимо 10 лет назад, сейчас — уже нет. Старый веб должен погибнуть вместе с поддержкой от программистов. Иначе так и будем из десятилетия в десятилетие таскать весь этот мусор.
Как я вас понимаю) А с меня вот начальник спрашивает, почему я отключил доступ на сайт для IE8 и ниже (очень сильно ехала вёрстка). Мир был бы намного лучше, если бы IE9 выпустили под XP и на восьмёрку можно было забить.
Начальнику полезно озвучить, какова текущая доля IE8 в России. :-)
Начальник может быть и не неправ. Если в конторе все работают на windows XP и везде IE8. А админ (если есть) занят чем-то более важным. Так часто бывает.
Это доля IE8 в интернет, а внутри сети предприятия скорее всего IE тотален. Админы не приветствуют сторонний софт на рабочих станциях, тем более не управляющийся групповыми политиками.
Старый веб, к сожалению, может погибнуть только вместе с РЖД, Сбербанком и иже с ними. А до тех пор поддержка от программистов, неизбежна.
Наконец-то хоть кто-то озаботился динозаврами. А то надоело вносить в блэклисты сайты, требующие «обновить браузер», имхо ибо всё должно быть совместимо. Катаетесь же на великах по ДОП, ибо вам удобно и мерс не нужен, почему юзеру тогда нужно браузер менять из-за прихотей программеров?
Это Вы велозадротов не видели. Светодиодные фары, настолько яркие, что гаишники принимают их за ксенонки — практически норма. Сабвуферов не видел, но мощная акустика встречается. 250 км/ч — это трудно, но учитывая малую массу велека (даже вместе со всем, что на него повесили) электромотор сотню выдаёт без перегрева.
почему юзеру тогда нужно браузер менять из-за прихотей программеров?Интересная у вас логика. Инопланетная. Разработчик выполняет свою работу из альтруистических побуждений? Или ему всё таки платят зарплату? Зарплату платят исходя из кол-ва труда, которое обычно выражается в трудочасах. Соотвественно каждое действие в проекте, совершённое разработчиком стоит работодателю денег.
Теперь будем работодателей винить, что они игнорирует 0.02% пользователей, потому что стоимость разработки под них увеличит стоимость продукта на 20-30%? Почему юзер должен менять браузер из-за прихотей бизнесменов? Так? :-)
Если ваша лень в обновлении браузеров безмерна, то вы можете тратить свои собственные деньги на допилку тех проектов, которые у вас покривились. Это будет довольно честно, правда?
Моя логика основана на обязательности совместимости. Если программеры таковой не озабочены, то да, это не моя планета, согласен. Просто не забываем о частой необходимости использования систем искаропки, в которые тупо запрещено вносить изменения и использовать сторонние программы. А также понимаем, что все «новинки», вносимые в стандарт — обычные свистомигалки, без которых в большинстве случаев можно и обойтись.
Моя логика основана на обязательности совместимости.Кто обязал? Кого обязал? Кому обязал? Куда мне засунуть купленную лет так 12 назад VHS-кассету и как мне позвонить с купленного тогда же D-AMPS телефона? XP, так, для справки, тогда уже была в ходу.
Если программеры таковой не озабочены, то да, это не моя планета, согласен.Значит вам нужно на другую планету. Ту, где всё ещё в ходу патефоны и диафильмы. А программисты — совместимостью озабочены, да. Но… в меру. Как только что-то отживает свой срок — оно перестаёт поддерживаться. Когда конкретно это происходит — вопрос сложный и в каждом случае решаемый индувидуально, но всё, что связано с техникой рано или поздно отживает свой срок. Да, иногда на то, чтобы полностью изжить какой-нибудь устаревший стандарт уходят годы — но это вовсе не значит что все вокруг должны всё это время их поддерживать.
Просто не забываем о частой необходимости использования систем искаропки, в которые тупо запрещено вносить изменения и использовать сторонние программы.Ну вот тот, кто «тупо запретил» их менять — пусть с ними и разбирается. NASA покупает процессоры и дисководы на eBay — вам тоже никто не запрещает это делать. Но остальные-то разработчики тут причём?
А также понимаем, что все «новинки», вносимые в стандарт — обычные свистомигалки, без которых в большинстве случаев можно и обойтись.А вот это уж предоставьте решать тем, кто их разрабатывает.
Да я не против всяких нововведений, как Вы не понимаете..., только не надо насильно заставлять ими пользоваться.
То есть когда поддержка WiMAX или теж же эдиссононовких сетей на 200V постоянного тока прекращается — это нормально, а когда вас просят браузер обновить — то это катастрофа?! Где логика?
Как и чем вы будете ими пользоваться — это ваши проблемы. Но так же, как с какого-то момента оборудование с поддержкой цепей постоянного тока стало не так-то просто купить, так и здесь: хотите поддерживать старые браузеры — сами думайте как вы это сделать. Можете proxy какой-нибудь поставить, можете вообще глазками на исходный код смотреть. Но разработчики вам ничем не обязаны.
Как и чем вы будете ими пользоваться — это ваши проблемы. Но так же, как с какого-то момента оборудование с поддержкой цепей постоянного тока стало не так-то просто купить, так и здесь: хотите поддерживать старые браузеры — сами думайте как вы это сделать. Можете proxy какой-нибудь поставить, можете вообще глазками на исходный код смотреть. Но разработчики вам ничем не обязаны.
Вы когда-нибудь на JavaScript писали?
Zenitchik, он не писал, но я очень много пишу, и без всяких наворотов обхожусь (раз обеспечиваю полную поддержку Opera 11-12). Процентов 80 вещей можно реализовать с нуля на чистом JS, даже если браузер их не умеет, от остального обычно можно просто отказаться.
Я с этим и не спорю. Но когда наконец отпадает необходимость в каком-то древнем костыле — это чертовски приятно. Скажем, мы перестали поддерживать ИЕ6 — гора с плеч. Урезали функционал, доступный в ИЕ7 — сильно полегчало.
С нетерпением жду момента, когда, наконец, можно будет забыть о том, что методов JS1.6 в массиве может не быть…
С нетерпением жду момента, когда, наконец, можно будет забыть о том, что методов JS1.6 в массиве может не быть…
Вообще отчасти товарищ прав: HTML5 внёс очень много полезного, как и CSS3. Но всё, что вводилось года с 2012-ого — преимущественно и правда свистомигалки. Процентов на 90 :)
Можете попытаться меня переубедить, приведя примеры реально незамениммых нововведений, появившихся в стандартах в последние года два.
Можете попытаться меня переубедить, приведя примеры реально незамениммых нововведений, появившихся в стандартах в последние года два.
Если программеры таковой не озабочены, то да, это не моя планета, согласенТочно не ваша. Разработчики озабочены тем, за что им платят. А тем, за что им не платят, они не озабочены. Вы ожидали чего-то иного?
Просто не забываем о частой необходимости использования систем искаропки, в которые тупо запрещено вносить изменения и использовать сторонние программыПолагаю, речь идёт об программном обеспечении для истребителей, да? Почему вы применяете эту логику к веб-сайтам? Какое они имеют отношения «имутабельным к системам из коробки»?
А также понимаем, что все «новинки», вносимые в стандарт — обычные свистомигалки, без которых в большинстве случаев можно и обойтись.В этом, наверное, тоже разработчики «виноваты»?
В общем я не вижу в этих ваших комментариях никакой логики, кроме оголтелого ретроградства и брюзжания. Поверьте, всем плевать на проблемы 0.02% пользователей, в особенности тем, кто платит за разработку. В следующий раз когда вы что-нибудь у кого-нибудь закажете, и потребуете мелочную опцию, от которой не будет никакого толку, но из-за которой вам повысят стоимость услуги эдак раза в полтора, вы едва ли будете мыслить в том же духе.
Что интересно — протоколы шифрования в настройках у IE7 и IE8 одни и те же: SSL 2.0 (не отмечен), SSL 3.0 и TLS 1.0. И длина ключа в окне «О программе» и там и там равна 128 бит. Но почему-то IE7 сервер отшивает. Если кто знает причину такого явления — пишите в комментарии.
Протоколы SSL и TLS ≠ наборы шифров.
IE для HTTPS использует системный SChannel, который в XP не умеет SNI, а почти все поддерживаемые шифры считаются слабыми. Если вы настраивали веб-сервер по рекомендациям Mozilla, то он скорее всего не будет работать с любой версией IE на XP, но будет работать на Vista и выше.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Прогулка с динозаврами: как я адаптировал веб-приложение под IE 7