Тег <img> и проблемы с атрибутом alt

true.True?TRUE! · January 8, 2012

Таков желаемый результат в идеале.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title>Изображение</title>
</head>
<body>
<p><img src="images/aresna.png" alt="Винни-Пух в гостях у Кролика" width="100" height="111" hspace="4" vspace="4" border="1"></p>
</body>
</html>

Красным выделил осознанную ошибку в названии файла. arena.png- то как он сохранен у меня. А опечатку добавил чтобы проверить что из этого выйдет. и вышло вот что:

1. В Опере текст уходит за границу.

2. В Мазиле тексту грубо говоря, плевать на заданные параметры ширины и высоты рисунка.

3. А вот в Редакторе все четко, как и должно быть. И хочется, чтобы так было и в браузерах.

Вопросы:

1) Как этого добиться?

2) Такого рода неожиданности ведь могут весь дизайн сломать в будущем. Могут ведь?-))

3) В чем, собственно, проблема. Почему везде так по разному? Где ошибка?

Arantir · January 9, 2012

Ошибка, там где и всегда во все века - в заднице у разработчиков баузеров баузерах. Такие вот системные элементы у всех по разному отображаются и их практически никогда нельзя поменять. Поля для ввода текста, скроллбары и так далее - все это у всех браузеров свое.

"Выкрутится" то можно почти всегда... Но эти усилия не стоят результата.

В данном случае можно картинку сделать div'ом, где картинка - это background, текст поставить на задний план в такой же по ширине div, а background-color на transparent.

Тогда без картинки у всех будет абсолютно одинаково - квадратик с текстом и текст не вылазит никуда.

Но, по-моему, легче просто следить, чтобы адрес картинки на вашем сайте был правильным. А если у кого-то из посетителей сайта руки из мягкого места растут, то это не вина веб-мастера =)

2) Такого рода неожиданности ведь могут весь дизайн сломать в будущем. Могут ведь?-))

А вот чтобы такого не случалось, надо правильно верстать... Попробуйте совет с div'oм. Пихать текст на заний план не надо, а вот картинку в виде фонового рисунка div'а сделать вполне можно... div всегда им и останется, даже без картинки структура сайта не нарушится.

Верстка слоями называется, когда почти все на div'ах и CSS построено.

Вот та же главная страница этого сайта - http://htmlbook.ru . Там нет ни одной таблицы и только логотип тегом img сделан. При этом, если отключить картинки в браузере, то на сайте ничего не поломается им можно будет пользоваться как и раньше.

Конечно пропадет половина пиктограмм, которые несут важную информацию пользователю. Так что отключение картинок - это уже проблемы пользователя.

Edited January 9, 2012 by Arantir

SelenIT · January 9, 2012

Для FF проблема решается через display:inline-block для img (и, имхо, это надо бы вообще внести во все ресеты, т.к. сам по себе img по дефолту ведет себя именно как инлайн-блок, а вовсе не как инлайн). Опера чуть упрямее, но ей (по крайней мере последним версиям, в старых не проверял) вправляет мозги немножко JS. Но вот Хром, зараза...

P.S. Транзишнл-доктайпам, вызывающим у браузеров когнитивный диссонанс limited quirks mode, уже лет 8 как пора на свалку. Они были нужны исключительно для временной поддержки проектов, изначально завязанных на "фичи" HTML3.2, а в эпоху HTML5 они вообще ни для чего не нужны.

psywalker · January 9, 2012

Для FF проблема решается через display:inline-block для img (и, имхо, это надо бы вообще внести во все ресеты, т.к. сам по себе img по дефолту ведет себя именно как инлайн-блок, а вовсе не как инлайн). Опера чуть упрямее, но ей (по крайней мере последним версиям, в старых не проверял) вправляет мозги немножко JS. Но вот Хром, зараза...
P.S. Транзишнл-доктайпам, вызывающим у браузеров когнитивный диссонанс limited quirks mode, уже лет 8 как пора на свалку. Они были нужны исключительно для временной поддержки проектов, изначально завязанных на "фичи" HTML3.2, а в эпоху HTML5 они вообще ни для чего не нужны.

Илюх, слушай, а скажи плз, почему инлайн-блок помогает в данной ситуации в фф?

true.True?TRUE! · January 9, 2012

Арантира я понял...

SelenIT, думаю, через недельку другую и вас пойму

Ребята, спасибо за ответы, в принципе я понял суть проблемы. А Транзишнл,это просто в примере было. Я просто вставил,посмотрел.Правда была мысля перевести в стрикт.

А ссылка оказалась очень и очень полезной.Пойду грызть гранит.

Еще раз спасибо.

Илюх, слушай, а скажи плз, почему инлайн-блок помогает в данной ситуации в фф?

наверное потому что ставит определенные ограничения,которые по сути и нужны,нет?

SelenIT · January 9, 2012

почему инлайн-блок помогает в данной ситуации в фф?

Насколько я понимаю, он заставляет браузер учитывать указанные ширину и высоту. Поскольку у картинки дефолтный display:inline, высота и ширина применяются к ней только благодаря наличию intrinsic dimensions ("внутренне присущих" размеров). В других браузерах поведение картинки изначально ближе к inline-block (имхо, именно его и логично бы сделать по умолчанию), поэтому указанные размеры держатся без подпорок.

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

psywalker · January 9, 2012

Илюх, слушай, а скажи плз, почему инлайн-блок помогает в данной ситуации в фф?
наверное потому что ставит определенные ограничения,которые по сути и нужны,нет?

Да, это-то понятно)) Но, меня интересовала сама суть, как именно это работает.

почему инлайн-блок помогает в данной ситуации в фф?
Насколько я понимаю, он заставляет браузер учитывать указанные ширину и высоту. Поскольку у картинки дефолтный display:inline, высота и ширина применяются к ней только благодаря наличию intrinsic dimensions ("внутренне присущих" размеров). В других браузерах поведение картинки изначально ближе к inline-block (имхо, именно его и логично бы сделать по умолчанию), поэтому указанные размеры держатся без подпорок.
Вообще ситуация с недогрузившимися картинками для браузера так или иначе нештатная, и последнее слово так или иначе за разработчиками. У Мозиллы есть логика в том, что, раз уж картинка недоступна, чтобы хотя бы текстовый эквивалент был доступен в максимально читабельном виде -- без обрезки и скукоживания ("дизайн — ничто, содержание — всё"). У Хрома логики нет, это тупо баг . Опера, видимо, пытается усидеть на двух стульях (и дизайн не развалить, и текст худо-бедно показать, обычно тексты короткие). И задача унификации этого разнобоя не так уж тривиальна. Для критичных участков оформления (не иллюстраций и т.п.) есть резон использовать приемы типа такого...

Понял. Спасибо, Илюх

Ты имеешь ввиду вот этот приём?

.nir {
   height:100px; /* height of replacement image */
   padding:0;
   margin:0;
   overflow:hidden;
}

.nir:before {
   content:url(image.gif);
   display:block;
}

SelenIT · January 9, 2012

Да, этот. И всякие вариации на эту тему.

Sign In

Тег <img> и проблемы с атрибутом alt

Question

true.True?TRUE!

Link to comment

Share on other sites

7 answers to this question

Recommended Posts

Arantir

Link to comment

Share on other sites

SelenIT

Link to comment

Share on other sites

psywalker

Link to comment

Share on other sites

true.True?TRUE!

Link to comment

Share on other sites

SelenIT

Link to comment

Share on other sites

psywalker

Link to comment

Share on other sites

SelenIT

Link to comment

Share on other sites

Join the conversation

Обсуждения

Forums

Important Information