Вот что изменилось на сайте за сегодня:

• сделано несколько тупых оптимизаций, чтобы не так часто Мастерхост испытывал «Capacity problems»;
• ЦСС стал выдаваться одним файлом, а не тремя;
• цвета посещённых и непосещённых ссылок стали лучше отличаться;
• иконка кинофильма отодвинута подальше от поля поиска, чтобы не казаться кнопкой «Найти»;
• к сожалению, пришлось перейти с Гельветики на Ариал (Гельветика подглючивала на Виндоусе);
• специально для браузеров-калек, которым чтобы искать по сайту нужны костыли (т. е. для не-Оперы), добавился Опенсёрч;
• сильно всё улучшено в ИЕ;
• прижимающаяся к верху шапка заработала в Опере (хотя я не до конца ей доволен пока);
• исправлена корявость, из-за которой линия, отделяющая шапку от контента, стиралась не до конца на самом верху страницы (внимательные ребята её видели, и им не нравилось);
• подпись снизу немного изменена, чтобы было понятнее, что это за правила;
• ссылка на меня оставлена только на главной странице сайта, как положено;
• в мгновенных результатах поиска убрана подпись снизу, а то она прыгала туда-сюда;
• если у вас где-то не работала ctrl-навигация вправо, должна была заработать;
• новая фавыконка, говорят, должна лучше смотреться на тёмном фоне;
• если в правилах ничего не найдено, то ссылка на Яндекс.Словари теперь сразу ищет введённое слово в словарях.

Спасибо всем, кто вчера и сегодня вместе с обнаруживаемыми проблемами присылал сразу решения. Дмитрий Зимин, например, прислал готовое решение для прикручивания Опенсёрча, Эндрю Маркус и Макс Шальнов — некоторые правки для ИЕ; Калан (ах, как я не люблю клички!) — улучшенную иконку, а Анатолий Рр — исправление ошибки с навигацией и корявости с тонкой линией.

Всё же лучше всего сайт работает в Вебките. Потому что Вебкит — рай для веб-разработчика. В Опере тоже всё работает нормально. Потому что Оперой пользуюсь я. Проблемы остались в Фаерфоксе и в ИЕ. Ещё есть проблема с Айпадом, из-за которой на нём сайт смотрится огромным (как будто Айфон растянули пропорционально). Это из-за того, что я не знаю, как прописать тег meta viewport раздельно для Айпада и Айфона.

Если кто-то из вас будет столь любезен, что пришлёт мне решения (которые я пойму, и которые не сломают сайт там, где он и так работает), будет очень-очень круто.

В четвёртом выпуске «говорильного подкаста» говорим с техдиректором «Аймобилки» Сергеем Чикуёнком про ХТМЛ 5, Флеш, ИЕ6 и веб-разработку вообще.

Среди затронутых тем:

• ХТМЛ 5 — круто ли это? Почему так долго? Как стандарты отстают от жизни.
• Валидность и чистота кода. Ценность валидного кода против ценности хорошего сайта. Как донести до любителя валидности, что это не важно? А может быть невалидный код — признак неряшливости разработчика? Как спецификация и валидатор по-разному понимают стандарты. Закрывать ли теги, брать ли атрибуты в кавычки — не технический вопрос, а дело вкуса. Когда валидность и функциональность вступают в противоречие.
• Флеш, какова его роль в вебе? Флеш и видео, кодеки, в чём природа спора, и почему не получается уже договориться. Обсуждаем появившиеся в последнее время весёлые демки, когда видео взаимодействует с остальной страницей.
• Аджакс и ИЕ, история вопроса. Сергей рассказывает о том, какой крутой браузер ИЕ6 (не шутка). Куча всего появилась в ИЕ6 раньше, чем где-либо, а через годы это записали в стандарты, но по-другому. Виноват ли в этом ИЕ?
• Гугль и все другие крутые компании перестали поддерживать ИЕ6. Правда ли это? Оказывается, нет, но плохие веб-разработчики используют непонимание людьми этих анонсов, чтобы не поддерживать ИЕ6. Подавляющее большинство пользователей ИЕ6 не меняют браузер, потому что не могут, а не потому, что не хотят. Одно из достижений ИЕ6 — победа над идиотской бокс-моделью В3Ц. Пользователи ИЕ6 охотнее расстаются с деньгами, поэтому не поддерживать ИЕ6 невыгодно.
• Мы как разработчики очень любим Вебкит!

Слушать прямо тут

Скачать выпуск можно на Арподе (или по прямой ссылке), там же можно подписаться на подкаст. Разговаривали мы часа два, но я оставил от этого традиционные 50 с небольшим минут.

Кстати, с кем и про что, на ваш взгляд, ещё нужно поговорить?

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

слов<img class="suffix" src="i/suffix.gif" />ечко

Но что написать в стилях?

.suffix {
  position: ???
  width: 1.5em; /* на три буквы чтоб */
  bottom: -1em;
}

Относительно позиционированный элемент занимает собой места в нормал-флоу столько же, сколько непозиционированный, а потом может быть сдвинут относительно этого места так, что нормал-флоу этого не заметит. В нашем случае это не подходит, потому что будет разрыв между «слов» и «ечко» шириной в картинку.

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

Поэтому всё время приходится делать так:

слов<span class="suffix"><img src="i/suffix.gif" /></span>ечко

.suffix { position: relative }
.suffix img {
  position: absolute;
  width: 1em;
  bottom: -1em;
}

Спан, конечно, красивее было бы закрыть после «ечк», но это не про семантику заметка. Так вот, весь этот спан, получается, существует только для того, чтобы задать «систему координат» для картинки. Но ведь она уже задана тем, куда вы воткнули эту картинку в разметке!

Так почему было не придумать какой-нибудь position: anchored, который бы участвовал в нормал-флоу, но с точки зрения нормал-флоу имел бы размеры 0 на 0? Можно было бы развить идею, введя anchored-x и anchored-y, чтобы, допустим, сделать сноски на поля, висящие на уровне того места, откуда на них ссылаются. Атрибут position: anchored-y означал бы, что left / right для этого элемента имеют смысл по принципу position: absolute; а top / bottom — по принципу position: anchored, т.е. относительно точки, где элемент встретился в разметке. Тогда текст, снесённый на поля, можно было бы размечать так:

Пушкин писал<sup>1</sup><div class="sidenote"><sup>1</sup> В «Капитанской дочке»</div>: «Береги честь смолоду».

.sidenote {
  position: anchored-y;
  left: 110%; /* чтобы отступить от самого текста 10% его ширины */
  top: 0;
}

Почему создатели стандартов придумывают всякую хрень (вроде box-shadow или анимации) раньше, чем решают базовые задачи вёрстки?

Добавлено несколько позже: Оказывается, я ничего не понимаю в вёрстке. Спасибо комментаторам за прояснение ситуации.

Шестнадцатеричные цифры a, b, c, d, e и f нужно писать исключительно в нижнем регистре. Читателю совершенно необязательно проводить время с лупой перед монитором, пытаясь различить 8 и B, 0 и D. Вывод различными программами этих цифр в верхнем регистре следует считать багом.

Разыскивается хороший скрипт автодополнения с выпадайкой в текстовом поле. Скрипт должен брать перечень вариантов откуда-нибудь (аджакс не нужен, варианты могут идти сразу в исходном ХТМЛе) и автодополнять ими при вводе. Ещё должна выпадать выпадайка с подходящими вариантами.

Главное, что мне нужно, и чего нет в скриптах, которые я нахожу — это поддержка ввода через запятую нескольких элементов, для каждого из которых должно работать своё автодополнение со своей выпадайкой, причём выпадайка должна выпадать именно под тем местом, где вводится вводимое слово.

Должно работать под всеми браузерами. Может использовать jQuery.js. Не должно тормозить.

Помогайте, пожалуйста.

Недавно у меня на «Вотсоуэвере» стали спамить в комментариях. До этого у меня такой проблемы не было — от спама спасал запрет на комментирование старых заметок (пока роботы успевали найти заметки, к ним уже закрывались комментарии).

Я считаю капчу недопустимым издевательством над посетителями, и я не буду её делать частью формы комментирования ни при каких обстоятельствах.

Самое первое, что я захотел проверить — это разница во времени между моментом получения роботом формы и отправкой комментария. Я думал, что если это делается подряд, то это по-любому спам, ведь живому человеку нужно время, чтобы что-то написать. Оказалось, «умный» робот ждёт 5 секунд перед отправкой формы — это довольно много, за это время человек может вставить комментарий, написанный в Ворде в соседнем окне. Следовательно, таким образом отрубить спам не получится.

Я обнаружил, что все айпи-адреса, с которых был спам, есть в базе на сайте stopforumspam.com, так что можно иметь под рукой эту базу, и считать спамом все комментарии с этих адресов. Но ведь спам может прийти и с адреса, который вчера принадлежал зомби с Виндоусом Экс-пи, а сегодня принадлежит безобидному Маку.

Получается, что подозреваемый в спаме комментарий нельзя просто отметать. Может быть, как раз в таком случае показывать капчу, типа «наш глупый компьютер решил, что вы робот, но вы введите капчу, чтобы переубедить его». Тогда нужно быть уверенным, что такие случаи будут крайне редки.

Следующее над чем я думаю — это использовать Джаваскрипт, который бы делал что-то хитрое в форме, чего бы не смог сделать робот. Но я пока не знаю, вдруг роботы и Джаваскрипт выполнять умеют?

Если у вас есть какой-то опыт в этой области, поделитесь, пожалуйста.

Да, ещё про сайты разных веб-студий.

На странице работы никогда не сказано, собственно, в чём состояло «комплексное интернет-решение». «Сайт компании Пумпурум-лимитед» — и скриншот. Что за компания, чем занимается, зачем ей делали сайт? Этого не написано. Потому, что этими вопросами реально не задавались разработчики. У них было ТЗ, где было сказано, какие нужны разделы, «график» нарисовал что-то в Фотошопе, верстальщик сверстал, вот и сайт, вот скриншот. Что ещё сказать? Не писать же вату из ТЗ, что сайт поддерживает такие-то браузеры и минимальное разрешение такое-то.

Всё это как-то очень уныло.

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

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

Продолжим тему нормальных урлов. Некоторые ребята думают, что хороший урл получается, если бездумно заменить в адресе всю служебную хрень на прямые слеши. Эти идиотские урлы видны невооружённым глазом. Например, вместо site.ru/?article=4972304 делают site.ru/article/4972304/.

Такой «красивый» урл ничем не лучше исходного. Он даже хуже: он показывает нам древовидность там, где её нет. Кажется, будто текущая страница — дочерняя для страницы site.ru/article/, на которой 404 или вообще какая-нибудь ошибка ПХП отображается.

Вместо article должно быть написано articles, а по адресу site.ru/acticles/ должен быть список статей. А если он и так показывается на главной, то страница отдельной статьи должна быть дочерней по отношению к главной: site.ru/4972304/. Если уж очень хочется запихать слово article в адрес, то нужно писать: site.ru/article-4972304/.

Урлы с бессмысленным набором слов и чисел, разделённых слешами, являются следствием бездумной конвертации внутренней логики веб-приложения в формат, «похожий на урл». Есть какой-нибудь класс Article, или файл article.php, или функция article (), и в урл его название и попадает.

Конечно, структура сайта чаще всего не является строго древовидной. Частое отклонение — главная страница сайта одновременно и корневая, и соседняя для страниц второго уровня. Но беды в этом никакой нет: на уровне урла всё равно всегда можно решить, к какому из двух уровней относить страницу. В большинстве случаев решение стоит принимать в пользу более короткого урла, потому, что иначе появится ненастоящий промежуточный уровень иерархии. В тех же редких случаях, когда промежуточный уровень появляется, он должен просто тихо редиректить на «настоящую» страницу.

В западном интернете постепенно тоже начинают понимать, что пользоватям не интересен .aspx и прочий?мусор=в&урлах, и переходить на более короткие и чистые урлы. Однако уже в нескольких местах я заметил кретинистические псевдочеловекопонятные урлы, которые нужно истребить. ПЧПУ — это урлы, в которые наряду с бессмысленной технической шелухой запихивается ещё и человеческая часть. Например, такие урлы сейчас делают на Дискогсе:

• http://discogs.com/Руки-Вверх-Дышите-равномерно/release/1193791

Кроме того, что в урле по-прежнему содержится шелуха (1193791), даже человеческая его часть — это обман:

• http://www.discogs.com/The-Beatles-Let-It-Be/release/1193791

По этому адресу оскорбительно (по отношению к Битлам) лежат «Руки вверх». А если часть, начинающуюся со слова release, стереть, то получим 404. Зачем вводить людей в заблуждение, имитируя нормальные урлы, когда система всё равно кривая и калечная?

Человекопонятный урл — это не просто такой урл, в котором понятно, что написано; должен быть понятен принцип, система формирования урлов, чтобы я мог написать адрес и попасть на нужную страницу, как я это с лёгкостью делаю на Википедии. Если слабо сделать как на Википедии (когда и урлы человеческие, и возможные наложения разрешаются дисамбигуационными страницами), то лучше не заниматься ерундой, а сделать урл хотя бы коротким и оставить просто /1193791.