Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 11
Есть мнение, что сами переносы — атавизм, который стоит оставить позади.
Аргументы вкратце следующие:
1. В вебе нет ограничения на число строк, поэтому нет острой потребности заполнять площадь по максимуму.
2. Раздробленные слова затрудняют чтение сильнее, чем «рваный край».
Изначально потребность в переносах возникла как попытка сэкономить площадь носителя. Количество строк в бумажном издании ограничено, влияет на стоимость тиража. В вебе этой проблемы нет, поэтому нет и функциональной причины для переносов.
Рваный край становится проблемой только в том случае, если неудачно подобрана ширина колонки. Для сплошного текста оптимальна длина строки в ~6—9 слов (и слегка варьируется для разных языков). В такой колонке колебания рваного края составляют от силы процентов пять-десять ширины, это смотрится вполне нормально и живо. Если же колонка выглядит рваной, это как раз сигнал о том, что есть проблема с пропорциями шрифта и строки — тогда лучше по возможности подрихтовать дизайн, а не лечить симптомы.
В идеале, при ручной верстке, строки вообще лучше переносить по смыслу, а не по количеству символов. Так, чтобы сохранялись семантические и логические связи между словами и словосочетаниями. Сравните:
С точки зрения функциональности, скорочтения и восприятия смысла, рваный край лучше, чем дробные слова. В этом плане переносы — ненужный костыль, который мы тянем в веб из книжной типографики по привычке.
Что касается эстетики, тут тоже не всё однозначно. Избыточно ровные текстовые блоки сродни симметричной композиции и т.п. Обычно человеку изначально нравятся симметрия, яркие цвета и простые геометрические формы. Но по мере развития вкуса, предпочтение отдается асимметрии, полутонам и сложным пятным. (Не в смысле ханжества; просто естественная закономерность из культурологии, основывается на изучении народных искусств на разных стадиях развития).
Так что, на мой взгляд, переносы в вебе не нужны. Как не нужен, например, text-indent для отбивки абзацев или п р о б е л ь н а я р а з р я д к а для выделения текста. Это пережитки бумажных изданий, вынужденные костыли, обусловленные несовершенством технологий верстки. По мере развития технологии их желательно изживать из массового оборота.
P.S. Кстати, есть вероятность, что сами принципы чтения постепенно изменятся. Вот интересный эксперимент (англ.), например. Вместо вывода целого текста выводится одно поле, которое показывает текст пословно — скорость чтения получается выше обычной. Это не полноценная замена тексту, конечно, их сложно всерьез сравнивать, но сама попытка переосмыслить процесс чтения о многом говорит.
Тем не менее, статью прочел с интересом, спасибо!
Аргументы вкратце следующие:
1. В вебе нет ограничения на число строк, поэтому нет острой потребности заполнять площадь по максимуму.
2. Раздробленные слова затрудняют чтение сильнее, чем «рваный край».
Изначально потребность в переносах возникла как попытка сэкономить площадь носителя. Количество строк в бумажном издании ограничено, влияет на стоимость тиража. В вебе этой проблемы нет, поэтому нет и функциональной причины для переносов.
Рваный край становится проблемой только в том случае, если неудачно подобрана ширина колонки. Для сплошного текста оптимальна длина строки в ~6—9 слов (и слегка варьируется для разных языков). В такой колонке колебания рваного края составляют от силы процентов пять-десять ширины, это смотрится вполне нормально и живо. Если же колонка выглядит рваной, это как раз сигнал о том, что есть проблема с пропорциями шрифта и строки — тогда лучше по возможности подрихтовать дизайн, а не лечить симптомы.
В идеале, при ручной верстке, строки вообще лучше переносить по смыслу, а не по количеству символов. Так, чтобы сохранялись семантические и логические связи между словами и словосочетаниями. Сравните:
У меня есть примерно 10
причин не делать пере-
носы при сплошном набо-
ре текста в вебе.
У меня есть
примерно 10 причин
не делать переносы
при сплошном наборе
текста в вебе.
С точки зрения функциональности, скорочтения и восприятия смысла, рваный край лучше, чем дробные слова. В этом плане переносы — ненужный костыль, который мы тянем в веб из книжной типографики по привычке.
Что касается эстетики, тут тоже не всё однозначно. Избыточно ровные текстовые блоки сродни симметричной композиции и т.п. Обычно человеку изначально нравятся симметрия, яркие цвета и простые геометрические формы. Но по мере развития вкуса, предпочтение отдается асимметрии, полутонам и сложным пятным. (Не в смысле ханжества; просто естественная закономерность из культурологии, основывается на изучении народных искусств на разных стадиях развития).
Так что, на мой взгляд, переносы в вебе не нужны. Как не нужен, например, text-indent для отбивки абзацев или п р о б е л ь н а я р а з р я д к а для выделения текста. Это пережитки бумажных изданий, вынужденные костыли, обусловленные несовершенством технологий верстки. По мере развития технологии их желательно изживать из массового оборота.
P.S. Кстати, есть вероятность, что сами принципы чтения постепенно изменятся. Вот интересный эксперимент (англ.), например. Вместо вывода целого текста выводится одно поле, которое показывает текст пословно — скорость чтения получается выше обычной. Это не полноценная замена тексту, конечно, их сложно всерьез сравнивать, но сама попытка переосмыслить процесс чтения о многом говорит.
Тем не менее, статью прочел с интересом, спасибо!
Если же колонка выглядит рваной, это как раз сигнал о том, что есть проблема с пропорциями шрифта и строки — тогда лучше по возможности подрихтовать дизайн, а не лечить симптомы.
и что делать на телефоне с текстом на немецком (пример слова есть в статье)?
Возможно, есть смысл использовать сжатые гарнитуры (condensed) и кегль чуть скромнее. Что немцы частенько и делают, собственно.
К сожалению, я не знаю немецкого (переносы тоже от балды расставлены), поэтому адекватно протестить не могу. Чисто визуально, несмотря на сжатие, глазу проще выхватить из контекста слово, когда оно не дробится:
А вообще, надо брать да проверять. Практика — критерий истины) Дизайнеры часто судят о мнимой читабельности визуально, по размеру букв и т.п. Но на практике не раз убеждался, что больше зависит именно от компоновки текста в колонке: длина строки, выключка, интерлиньяж и др. Поэтому в сложных случаях надо брать и тестить.
Ну и держим в голове, что ваш пример довольно специфичен: википодобный немецкий текст в ширине 304px, без редактуры. Мы всё-таки по большей части работаем с русскоязычными или на крайняк англоязычными текстами. В быту всё проще. Рядовой текст без переносов выглядит вполне нормально даже без изменения кегля и гарнитуры. Читается легче, чем с переносами.
Вообще, если слова длиной под 30 знаков — исключения, то в идеале хотелось бы лечить их индивидуально. Мягкими переносами (­) или принудительно дробить. Тривиальная задача для типографа, в общем-то. Если такой возможности нет, лучше уж просто оставлять свободно висеть в отдельной строчке, нет в этом ничего особо страшного. Одна визуально некрасивая строчка вряд ли стоит сотни переносов по всей простыне.
К сожалению, я не знаю немецкого (переносы тоже от балды расставлены), поэтому адекватно протестить не могу. Чисто визуально, несмотря на сжатие, глазу проще выхватить из контекста слово, когда оно не дробится:
А вообще, надо брать да проверять. Практика — критерий истины) Дизайнеры часто судят о мнимой читабельности визуально, по размеру букв и т.п. Но на практике не раз убеждался, что больше зависит именно от компоновки текста в колонке: длина строки, выключка, интерлиньяж и др. Поэтому в сложных случаях надо брать и тестить.
Ну и держим в голове, что ваш пример довольно специфичен: википодобный немецкий текст в ширине 304px, без редактуры. Мы всё-таки по большей части работаем с русскоязычными или на крайняк англоязычными текстами. В быту всё проще. Рядовой текст без переносов выглядит вполне нормально даже без изменения кегля и гарнитуры. Читается легче, чем с переносами.
Вообще, если слова длиной под 30 знаков — исключения, то в идеале хотелось бы лечить их индивидуально. Мягкими переносами (­) или принудительно дробить. Тривиальная задача для типографа, в общем-то. Если такой возможности нет, лучше уж просто оставлять свободно висеть в отдельной строчке, нет в этом ничего особо страшного. Одна визуально некрасивая строчка вряд ли стоит сотни переносов по всей простыне.
С точки зрения… скорочтения… рваный край лучше, чем дробные слова.
По каким исследованиям? Мне кажется, что с дробными словами есть профит когда предугадывается окончание и фактически чтение начинается со второго слова на новой строке.
Вряд ли существует фундаментальное исследование, не тот масштаб проблемы. Есть много мнений на этот счёт, есть рекомендация избегать переносов в самых разных Style Guides.
Гайд «Википедии»:
Чикагский гайд (платный, но есть trial), на который ссылается гайд MS:
Это не исследования, конечно. Но рекомендации. Каждый руководствуется субъективным опытом. Я описываю свои наблюдения, которые основаны на довольно плотной работе с текстом в течение нескольких лет (копирайтинг, редактура и т.п.). Их не обязательно принимать на веру, но можно принять как пищу для размышлений.
Так вот, личное мнение:
1. Техника чтения такова, что мы идентифицируем слова отнюдь не последовательно. Наиболее значимы для распознавания первые и последние символы. (Здесь чуть глубже, с отсылками и примерами). Когда слово дробится, мы сразу теряем часть опорных символов, число вариантов вырастает, распознание затрудняется.
2. Чтение со второго слова равносильно центральной или правосторонней выключке, потому что глаз вынужден нащупывать начало каждой новой строки. (Опять же, не могу сослаться на классическое исследование, но это входит в любой сборник «плохих практик» по типографике и полностью подтверждается моим личным опытом).
3. При послоговом переносе возникает многовариантность из-за общих приставок и корней. «Мама, я принёс тебе теле-...» — телефон? телевизор? телескоп? телеграмму? Это постоянный микроподбор вариантов на основе контекста.
Предугадывание (нечеткий поиск) кажется мне по определению более ресурсоёмкой операцией, чем прямое и однозначное считывание. Косвенно это подтверждается тем, насколько сложнее на глаз найти все вхождения определенного слова в длинном тексте, если оно местами дробится переносами.
Учитывать моё мнение или нет — тут уж целиком на ваше усмотрение :)
P.S. Прошу прощения, дальше углубляться не готов, итак слишком увлёкся)
Гайд «Википедии»:
Use of soft hyphens should be limited to special cases, usually involving very long words or narrow spaces (such as captions in infoboxes or other tight page layouts, or column labels in narrow tables). Widespread use of soft hyphens is strongly discouraged, because it makes the wikitext very difficult to read and to edit.
Чикагский гайд (платный, но есть trial), на который ссылается гайд MS:
The hyphenation function on your word processor should be turned off. The only hyphens that should appear in the manuscript are hyphens that would appear regardless of where they appeared on the page (e.g., in compound forms). Do not worry if such a hyphen happens to fall at the end of a line or if the right-hand margin is extremely ragged. By the same token, do not attempt to manually break excessively long words (e.g., long URLs) with a hyphen. See also 2.96.
Это не исследования, конечно. Но рекомендации. Каждый руководствуется субъективным опытом. Я описываю свои наблюдения, которые основаны на довольно плотной работе с текстом в течение нескольких лет (копирайтинг, редактура и т.п.). Их не обязательно принимать на веру, но можно принять как пищу для размышлений.
Так вот, личное мнение:
1. Техника чтения такова, что мы идентифицируем слова отнюдь не последовательно. Наиболее значимы для распознавания первые и последние символы. (Здесь чуть глубже, с отсылками и примерами). Когда слово дробится, мы сразу теряем часть опорных символов, число вариантов вырастает, распознание затрудняется.
2. Чтение со второго слова равносильно центральной или правосторонней выключке, потому что глаз вынужден нащупывать начало каждой новой строки. (Опять же, не могу сослаться на классическое исследование, но это входит в любой сборник «плохих практик» по типографике и полностью подтверждается моим личным опытом).
3. При послоговом переносе возникает многовариантность из-за общих приставок и корней. «Мама, я принёс тебе теле-...» — телефон? телевизор? телескоп? телеграмму? Это постоянный микроподбор вариантов на основе контекста.
Предугадывание (нечеткий поиск) кажется мне по определению более ресурсоёмкой операцией, чем прямое и однозначное считывание. Косвенно это подтверждается тем, насколько сложнее на глаз найти все вхождения определенного слова в длинном тексте, если оно местами дробится переносами.
Учитывать моё мнение или нет — тут уж целиком на ваше усмотрение :)
P.S. Прошу прощения, дальше углубляться не готов, итак слишком увлёкся)
Рваный край мне в любом случае кажется некрасивым; поэтому я всегда прописываю text-align: justify; (в этом я перфекционист: ставлю перед тире и использую кавычки-ёлочки). Да, на значительной части строк можно обойтись без переносов. Но существуют длинные слова (гиппопотомонстросесквипедалиофобия — боязнь длинных слов :-) ).
А что касается подбора ширины колонки — страницу читают на разных устройствах с разными экранами.
А что касается подбора ширины колонки — страницу читают на разных устройствах с разными экранами.
-moz-hyphenate-limit-chars: 6 3 2; /* not yet supported */пихать эту строку в стили бессмысленно. браузеры уже давно отказались (к счастью) от префиксов. если Firefox добавит поддержку переносов, то уже без префиксов.
Пока Chrome не станет нормально поддерживать переносы, то пока смысла мало в них, к сожалению.
Прочитал с интересом, благодарю (поставил плюс).
Хочу заметить, что язык лучше всего указывать в трёх местах.
Во-первых, в HTTP-заголовках:
Nginx:
Во-вторых и в третьих, в HTML:
Предвижу вопрос: зачем дублирование.
Хочу заметить, что язык лучше всего указывать в трёх местах.
Во-первых, в HTTP-заголовках:
Nginx:
add_header Content-Language ru;DefaultLanguage ruВо-вторых и в третьих, в HTML:
<html dir="ltr" lang="ru"><meta http-equiv="content-language" content="ru">Предвижу вопрос: зачем дублирование.
Отвечаю: для поисковых систем на основе опыта работы с ними.
Решил я прописать description на двух языках:
<meta name="description" lang="ru" content="Здесь было описание">
<meta name="description" lang="en" content="The description was here">Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Всё, что нужно знать об автоматических переносах в CSS