SelenIT

Еще лучше, если бы это было text-fill-image (по аналогии с text-fill-color, который уже работает там за префиксом же наряду с text-stroke-*, и подсвойствами background-а). Всё-таки путать разные типы значений для свойства с именем *-color едва ли лучше, чем путать логику фона и фигуры...

точнее, был бы он действительно частью стандарта, а не отсебятиной одного конкретного движка (ладно, полутора движков) А по сабжу — всё-таки не получается, видимо, без явного задания размеров. SVG-то идет как внедренный элемент а-ля айфрейм или канвас, по умолчанию берет ширину 300px (почему эта дефолтная ширина не растягивает предка в Fx — загадка, явно баг, но если убрать width: 100% у SVG, текст появится... снаружи кнопки). С явной попиксельной подгонкой, вроде, всё приемлемо во всех браузерах, включая IE9 (http://jsfiddle.net/QFSSc/4/). Может, оно и нормально — это ведь графика, по сути-то?

Вдобавок http://habrahabr.ru/post/136622/#surprise (конкретно про этот случай). По спецификации, «желаемая ширина» флоата рассчитывается по контенту, размещенному в одну строку везде, где только можно. Но вот включать ли в эту ширину вложенные флоаты или нет — браузеры расходятся во мнениях. Fx и Вебкит/Блинк впихивают вложенный флоат в уже рассчитанный внешний, отчего текст перестает вмещаться и переносится, IE и старая Опера (на Престо) добавляют ширину флоата к контейнеру, текст при этом не переносится. Насколько я понимаю спецификацию, ее букве и духу лучше отвечает поведение IE (как ни странно), а поведение Fx и хромиумов является багом.

Хм, у меня все последние блинковые — Хром 30.0.1599.101 m, Я-Б 13.10.1500.9151, Опера 17.0.1241.53 — рисуют пример из той статьи адекватно, четко обрезают по кругу. И даже совсем не последний iOS 6.1.3 Safari на айпаде рисует нормально. Только старая Опера на Престо выбивается (причем при любом position).

А что за баг с ними? Я, похоже, не в курсе...

«В любой непонятной ситуации фигачь -webkit-backface-visibility: hidden» (©) Это один из самых безопасных способов одновременно изолировать проблемный элемент в отдельный «RenderLayer» (нечто, до боли напоминающее старый добрый IEшный hasLayout на новом витке развития) и иногда, заодно, случайно включить для него аппаратное ускорение отрисовки. А еще говорят, что в наше время, мол, хаки больше не нужны...

Для Windows даже они уже не поддерживают.

Но запуск действия в ответ на простой запрос урла GET-ом — изначально ведь как-то неправильно, разве нет?

Не достаточно ли отправлять форму методом POST?

Сорри, что-то я теперь запутался, что и где тут должно центрироваться…

Это максимальное число (2-байтное целое со знаком), которое старая Опера принимала для размеров. Т.е. максимальный запас, который можно было для нее задать. Сейчас, в связи с переходом Оперы на движок Хрома, про этот хак вполне безопасно не вспоминать. Баг, с которым он борется, сам по себе не такой уж критичный.

Float-нутый элемент по определению не предполагает центрирования, это взаимоисключающие условия. Если нужно центрирование, не нужен float (а если при этом нужно сжать ширину эл-та по содержимому — можно применить display: inline-block или display: table, и центрировать с помощью text-align родителя и margin: auto самого эл-та, соответственно). Оптимальное решение зависит от конкретной задачи. Можно взглянуть на проблемную страницу?

то с огромной вероятностью где-то что-то не так с постановкой задачи. В данном случае, по-моему, определенно лучше

Потому что синтаксис языка JavaScript не допускает незаэкранированных переносов строк в строковых значениях. К сожалению, никак, в HTML нет такого понятия. Но можно запрашивать HTML-файлы аяксом и вставлять их целиком в нужное место DOM страницы (напр. как в 3-м примере здесь).

100% из-за него.

Мне новый нравится гораздо больше!

Для меня не вариант. У меня старый ноут 1280x800, и то катастрофически не хватает именно высоты. 1400-1600x900 — еще бы куда ни шло, но fullHD лучше (можно тестировать верстку во всем доступном диапазоне, в редакторе просто шрифт поставить покрупнее, а системные кнопки я и так узнаю), поскольку для меня ноут — долговременная покупка, устаревающий экран меня не прельщает. Лучше уж на диске/оперативе сэкономлю, потом доставлю. А планшеты сейчас есть с экранами непосредственно от третьего айпада еще дешевле (напр.), но у меня была задача не «тестировать на планшете», а, увы, «тестировать на айпаде» . Поэтому пришлось брать миник, безретиновый, да. Но как раз к нему я уже привык

Хакинтош — не то, имхо. Для меня главное преимущество, из-за которого я вообще стал рассматривать маки как потенциальный вариант для работы — именно в железе, а конкретно в экране, то бишь в ретине. Ось (для меня по-прежнему чуждая и непривычная, но, говорят, с большим кол-вом специфично фронтендерских удобняшек) — не более чем бесплатное (маверик же!) приложение

Псевдоэлементы ::before/::after работают для элементов, у которых есть контент, перед и после которого, соответственно, они могут вставляться. Select — замещаемый элемент, он не выводит свой контент, а замещает его фактически системным элементом управления (выстроенным на основе контента элемента). Вообще история с псевдоэлементами для замещаемых элементов сложна и запутана (иногда они работают там, где по теории не должны, напр. для <hr>), но общий вывод из нее по сути сводится к предыдущему ответу

Для вхождения, чтобы «почувствовать, что такое веб вообще», он неплох, пожалуй. Но он очень сильно ограничивает, прежде всего технически (нельзя поставить в код правильный доктайп, что позволит использовать по максимуму новые возможности браузеров, мешает назойливая и несуразная реклама и т.п.). Если подходить к вебу как к серьезному хобби, а то и как к будущей профессиональной деятельности, надо будет перейти на следующий этап, с более полным контролем над хостингом. Я сам не спец в дизайне, поэтому советовать не берусь. Всё-таки дизайн — хоть и прикладное, но искусство. Поэтому общие основы композиции, цветоведения и т.п. художественных дисциплин к нему вполне применимы, есть смысл просто почитать соотв. учебники (сейчас их издают совсем нескучными). Ну и есть смысл почитать советы профессионалов, например, здесь. Он аляповат. Он выглядит неаккуратно. Он рябит в глазах неестественными полосами. Он не монтируется со строгостью и лаконичностью основного оформления форума (кстати, на мой взгляд, неплохого, хоть и не выделяющегося среди стандартных тем оформления основных форумных движков). Он не ассоциируется ни с лесом, ни с лунным светом (по крайней мере, у меня), ни с романтикой сказочной волчьей стаи — в общем, не только не помогает создать антураж, атмосферу ролевой игры, но наоборот, явно выбивается из нее (опять же, на мой взгляд — но, судя по реакции других форумчан, я в этом не одинок). В принципе, для форума фон — не главное, его задача, как правильно отметили выше — не отвлекать от содержания. По-моему, вот на этом форуме фон с этой задачей справляется А вообще посмотрите, какие темы для форумов выбирают дизайнеры-профессионалы — например, здесь и здесь (первое, что нашлось в Гугле по запросу «best forum theme» — «лучшая тема [оформления] для форума»). Да, усиленно учите английский! Так сложилось, что большинство качественных ресурсов по дизайну, веб- и не только — англоязычные. Да и вообще без знания английского в современном мире никуда. Не ругаться при детях, даже завуалированно!

Не жалуются — значит, можно считать, что всё ОК («не сломалось — не чини»)

Сложно сказать, но этот кусок скрипта 1) судя по всему, ошибочен логически, 2) содержит потенциально слабое звено в лице gethostbyaddr. Лучше таких вещей по возможности избегать. Видимо, да (хотя неплохо бы еще значение error_reporting проверить).

Тогда не вижу другого пути узнать правду, кроме как перенастроить error_reporting и display_errors для отладки. Но в любом случае не вижу смысла анализировать тут HTTP_X_FORWARDED_FOR и подобное. Я бы прикладывал к письму один лишь «честный» айпишник отправителя (т.е. обычный REMOTE_ADDR), если понадобится узнать, чей он и прочее — это может сделать и тот, кто разбирает заявки, слишком автоматизировать это (к тому же усложняя и замедляя скрипт рассылки лишним для дела обращением к DNS). Кстати, в мане PHP 3-й коммент — возможно, как раз про эту ошибку. Если в настройках PHP стоит display_errors = off, то при падении скрипта с ошибкой сообщение сервера останется пустым, с обычным статусом 200. Для отладки, имхо, лучше врубить display_errors и вызывать скрипт напрямую.

А что сказал error.log сервера? Теоретически, скрипт мог нормально дорабатывать до ошибки, а на ней валиться намертво...

Почти наверняка бяка зарыта здесь. В HTTP_X_FORWARDED_FOR с огромной вероятностью сидит айпишник в локальной сети, навроде 192.168.x.x. По которому, естественно, никакой хост не разрезолвится.