Pull to refresh

Comments 108

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

С одной стороны, всё замечательно и текст теперь, как в книгах, но почему-то глаз дёглается и разрывает слово. Быть может, привычка.

Классно было бы, если бы у нах был, к примеру, плагин для Вордпресс.
Вообще у Qlikworld BV очень много продуктов, которые заслуживают пристального внимания. Очень весомые. я писал о них тут: fima.habrahabr.ru/blog/28425/ и так же посмотрите тут:http://fima.habrahabr.ru/blog/28894/
весьма интересная программулина сделана для нас. скачать программулю можно тут: download.qlikworld.com/downloads/rssreader/814/setup.exe
чего только не содержит в себе. 78 каналов ведущего радио, переводчики, калькулятор валют, энциклопедии и много другого.
;) а вы все текст и текст. только сейчас заметили про текст… поковырять поближе, так там много чего вообще у компании. разработок море…
Да это полный идиотизм — в компьютерных текстах делать переносы. Они нужны чтобы бумагу экономить, а в интернете абсолютно неприменимы для ПРАВИЛЬНОГО оформления текста НИ justify, НИ переносы.
UFO landed and left these words here
Даже если брать за предположение, что текст могут напечатать, переносы показываются всегда — на экране они только мешают нормально читать. И даже если речь идет про «жесткую» копию.

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

А любой сервис или автоматический «расставлятель» делает это так, что переносы вставляются там где не надо (например, здесь описано), забивают HTML-код, остаются в буфере при копировании, и идут подряд по несколько (что совершенно неверно — больше двух переносов в строках подряд воспринимается как «лес» палочек).

Есть, кстати, два плагина для Вордпресса, но ссылок давать не буду, потому что это неправильно :)
Если у вас не очень широкая колонка и довольн длинные слова, то текст у вас будет либо с сильно рваным правым краем, либо (при выравнивании по обеим сторонам) с жуткими растянутыми пробелами. В этом случае, переносы могут спасти ситуацию.
В английском языке с его более короткими словами эта ситуация не так заметна — собственно поэтому производители браузеров не сильно чешутся насчет поддержки переносов.
я один не догнал? как это «Эта статья уже со­дер­жит рас­став­лен­ные пе­ре­но­сы.» а в исходном коде все чисто. Как оно работает? Прошу прощения если затупил.
Попробуй изменить размер окна своего броузера и следи за переносами.
эффект я пронаблюдал — все работает, это и настораживало так как исходный код чистый, уже сам выяснил & shy; скрывает Firefox при показе Ctrl+U
он многое скрывает. и этим порой плох для разработки.
Да нифига он не скрывает! Не надо ля-ля. В тексте статьи НЕТ никаких ­ — супер-пупер-руки-поотрывать-парсер хабра превращает ­ в U+00AD — а этот символ и не должен быть виден! Скопируйте в текстовый файл — сразу увидите все символы (по крайней мере у меня в Ubuntu так).
Я не на Хабре код смотрел, а на указанном сайте. Парсер здесь ни при чём.
А что кривой код теперь могут только создатели Хабрахабра писать?

Посмотрите на следующий текст в исходниках хабрастраницы (надуюсь я смогу обмануть хабрапарсер):
От­­ дель­­ ный ин­­ те­­ рес сис­­ те­­ ма пред­­ став­­ ля­­ ет тем, что уме­­ ет пра­­ виль­­ но рас­­ став­­ лять пе­­ ре­­ но­­ сы на се­­ ми язы­­ ках. При этом са­­ ми язы­­ ки меж­­ ду со­­ бой не пе­­ ре­­ ме­­ ши­­ ва­­ ют­­ ся, т.е., если рас­­ став­­ лять пе­­ ре­­ но­­ сы в рус­­ ском тек­­ с­­ те, ко­­ то­­ рый со­­ дер­­ жит ино­­ стран­­ ные сло­­ ва, то сис­­ те­­ ма рас­­ ста­­ вит пе­­ ре­­ но­­ сы толь­­ ко в рус­­ ских сло­­ вах, а ино­­ стран­­ ные оста­­ вит без из­­ ме­­ не­­ ний.
Хабр не причем, все зависит от браузера, через который исходный код смотреть, у меня опера и фф под виндовс ничего не показывают, но если открыть в дримвьювере или блокноте, то сразу все становится видно
Хабр ОЧЕНЬ ДАЖЕ ПРИЧЁМ. Откройте файл с ­, посмотрите исходный код страницы и… о мегасуперчудо — вы увидите все ваши ­, откройте файл где ­ превращено в U+00AD — и будет так, как вы описали.

Нечего на зеркало пенять если рожа крива!
Эй, поосторожнее! Рожа крива у парсера.
Об чём и речь. Но мне тут пытаются доказать что, типа, это в Firefox глюк и он ­ не показывает. Конечно показывает! Если это самое ­ там есть! А если его кто-то скушал до того, как текст в Firefox попал, то с какой стати он должен что-то показывать? U+00AD не должен отображаться там, где переносы не случаются (моноширинный шрифт — отдельная песня).
Я посмотрел как отображается shy в лисе по ctrl+u — со статическим текстом отображается как пять символов.

Но так как на той странице тот кусок с шаями генерится динамически, то проверить без спецсредств трудно. Но в целом, пока что вы выигрываете :)) Показываются шаи как есть. Что, правда, не отменяет другие подмены html-кода на один-единственный символ.
Покажите пример где HTML-код показывается как один-единственный символ. Во всех случаях что я видел он съедался кем-нибудь «по дороге» до попадания в Firefox…
Ага! Понял в чём разница — «view selection source» мне не нравится, с ctrl+u всё в порядке. Пример:

zencd.spb.ru/tmp/eaten.html

А v.s.s. от себя много добавляет. Но чертовски удобен. Но добавляет :)
Я бы сказал что он удаляет, а не добавляет :-) Я внизу описал — почему…
добавляет пропущенные [html] [body]
сам закрывает теги
(ну и сам сворачивает энитити до одного символа)

это не то что внизу описано
С динамическим текстом проблемы: там как бы нет исходного кода. Показывается содержимое DOM-дерева. А в DOM-дереве разница между "&#65;" и "A" уже пропадает — все entities превращаются просто в буквы… Когда вы делаете «View Selection Source» три символа ("<"," >" и "&") превращаются обратно в entities (по понятным причинам). Остальные символы не трогаются…

P.S. Вообще на Хабре почти нереально про такие вещи рассказывать: он по разному интерпретирует entities в разных случаях, так что увидеть что ты пишешь нельзя (кнопка «предпросмотр» показывает не тот текст, который ты увидишь после того, как нажмёшь на кнопку «написать»). А без примеров — тяжело и писать и воспринимать.
Блин! То это, то. Всё, вопрос закрыт.

Впрочем, технически понятно почему так происходит. Однако в смущение вводит.
все, простите, вопрос снят,
*задумался, почему у него FF не показывает в исходном коде & shy;*
Сложно найти черную кошку в темной комнате, особенно, если ее там нет. В статье уже нет никакх &shy. Хабрахабр преобразовал их в честный юникодный символ U+00AD — а он и не должен быть виден в тексте (если только шрифт не моноширинный).
Отличный сервис! Теперь можно красиво текст вписать в страницу.
Сервис, в принципе, полезный.
Но один важный вопрос: как скажется такая обработка текста на индексации поисковиками?
& shy; — мягкий перенос, в исходном коде не отображается, следовательно, на индексацию и выдачу поисковиков влиять не должен.
UFO landed and left these words here
Действительно есть, попробовал открыть в блокноте, а Opera и Firefox не показывают
Делаем из неуникального контента — уникальный ))
Сейчас поисковики (я про двух основных игроков рынка говорю) не считают за пробельный символ мягкого переноса, точно так же, как игнорируют символ ударения (а вот Rambler, кстати, не игнорит). А вот nbsp и thinsp — да, делаются пробельными.
Это Вы проверяли, или «общие соображения»?
Только, что связывался с разработчиками сервиса в германии, гугл и яху & shy; не воспринимают, яндекс и рамблер они не тестировали.
Что значит не воспринимают? Игнорируют или понимают неправильно (как пробел)?
Т. е. как раз воспринимают как положено :)
яндекс давно склеивает, рамблер вроде тож.
Вообще начал использовать года три назад, ещё никто не жаловался. А если уж жалоба, то пройтись автозаменой по документу — дело пяти секунд.
Не привычно читать в браузере текст с переносами, проще явно не становится. Нужны ли они в интернете… ведь браузер сам выравнивает текст на строке. Зачем?
не знаю, я только на последнем абзаце заметил, что в статье расставлены переносы :)
давным-давно писал скрипт на регулярках для расстановки мягких переносов. потом убрал, когда начали жаловаться на глюки толи в ИЕ, толи еще где-то (когда меняешь размер окна, переносы превращались в дефисы)
Тоже заметил переносы только когда автор об этом написал. Заметил и ужаснулся рваному правому краю статьи. Все-таки считаю что переносы в печатном тексте излишество. Гораздо лучше смотрится и читается текст, выровненный по ширине без всяких разрывов слов. Переносы возможны в рукописном тексте, когда не хватает места для окончания слова, а писать уже начал. Как исключение может быть только печатный текст с длинными словами в узкой колонке.
Вот и я об этом говорю, зачем тянуть в вэб то, что для него не предназначено. Хотя есть некоторые случаи, когда это будет полезно.
UFO landed and left these words here
о, не заметил сразу ваш коммент. 100% согласен.
Переносы иного и в экранном варианте все же нужны, особенно если у вас встречаются длинные слова и тогда правая линия обзаца становится «рваной». А если узкие колонки то это один из действенных способ уравновесить ширину строки
Откуда взялся этот миф, мол легче читать текст, выровненный по левому краю? Меня всегда ужасно раздражал текст, выровненный по левому краю — когда его много, трудно перебегать с глазами со строчки на строчку, особенно если ширина строки большая.
UFO landed and left these words here
Это не миф. Легче читать текст, в котором не только слова в строке имеют одинаковую плотность, но и буквы в слове (решается кернингом, лигатурами). Тогда и эффектней любые выделения текста (шрифтом, жирностью, наклоном) смотрятся.

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

В газетах к слову узкие столбцы не просто так сделаны, а из рассчёта на быстрое «деловое» чтение.

Идеальный для чтения текст:
а) равномерная плотность строк, букв, межбуквенного, межстрочного пространства, абзацев.
б) равнение по обеим сторонам страницы, переносов как можно меньше и резать слова наиболее читаемым способом (#comment_1130805)
в) гарнитура соответствует эпохе и стилю повествования, желаемому типу восприятия.
г) переносы слов на следующую строку делаются предпочтительно по смысловым блокам (никаких союзов и предлогов в конце строки)
д) знаки пунктуации, особенно неплотные, в конце и начале строки выходят за пределы строки (« — достаточно плотный, как буква знак, а вот запятые, тире, кавычки-лапки — слишком лёгкие и образовываю дырку)

Это знаю я. Уверен, хороший типограф знает гораздо больше. Попробуйте почитать хорошо свёрстанные книги. Там не спотыкаешься о дырки, опечатки, провисшие союзы, не рябит от шрифта в глазах. Там передаётся смысл.
У меня книга повестей Лескова за 1929 год была, даже с неудобными ер и ять, куда приятнее читать, чем современные книжицы.
Наверное я ошибаюсь. Но, как я уже сказал, текст, выровненный по левому краю для меня как был, так и остаётся неудобным для чтения. Наверное мой случай уникален.
Хм. Тогда вопрос: нравится, когда по правому равнение идёт или по центру? Или я чего-то не догоняю и равнение jystify не включает в себя равнение по левому краю? Случай действительно редкий.
Ну ещё, если justify, то получается, что нерегулярные дырки посреди текста напрягают меньше, чем правый рваный край?
Нравится, когда равнение идёт по ширине (justify). Да, как-то нерегулярные дырки посреди текста напрягают меньше, ведь посреди текста я не перескакиваю вдруг на следующую строчку.
так совмещайте ­ во всех слогах и justify — будет и красиво и дырки в строках минимально отличаться будут. (длина максимального слога делить на количество пробелов)

Я к Вам в блог зашёл и уяснил в чём дело. Когда строки длинные и текст мелкий, то дырки в тексте особо не заметны, особенно если не привязывать союзы к словам и позволять им обвисать.
Но удобочитаемая строка — это не 15 слов, а всего 6—8 (два—три смысловых блока). И вот как раз в короткой строке дыры будут отвратительные.

На примере блога соглашусь: лучше длинная но аккуратная строка, чем много рваных коротких.
1. а в экранном тексте сохранять плотность не нужно? (с пристрастием атремийлебедев-ориентированных веб-дизайнеров к резиновым макетам — особенно)
2. какая связь между бОльшей легкостью чтения текста, выровненного по левому краю (не только с экрана, но и вообще, в целом) и отсутствием необходимости переносов?
Эээ… В печтаном-то тексте они как раз и нужны! Чтобы текстовые блоки включённые по ширине выглядели более однородно и плотно. Ну, и при вёрстке флагом был бы более ровный правый край. Посмотрите в журналы, ей-богу.
UFO landed and left these words here
Опера начала поддерживать shy в 2003м. Мозилла — только с выпуском ff3.
Возможно для очень узких колонок будет полезно. Или если очень уж хочется выровнять текст по ширине.
замечательно :) Джастифай теперь будет рулить!
UFO landed and left these words here
Странно, я наоборот постоянно «соскакиваю», когда текст выровнен по левому краю. А когда выровнен по ширине, дочитав строку до конца, перевожу взгляд на конец следующей строки (который буквально тут же), и по ней уже веду взгляд на начало строки.
UFO landed and left these words here
Отказался от идеи расстановки переносов, когда попробовал скопипастить его в блокнот…
UFO landed and left these words here
А в чём проблема? Сейчас скопипастил, сохранились только переносы, которые сделал браузер. Если нужен целый текст, где каждый абзац идёт одной строкой — сорц->копипаст->преобразовать в текст.

Более того сейчас сохранил как текст оперой статью, где есть и nbsp и условные переносы — всё хорошо, на абзацы поделено с шириной строки, взятой из CSS, заголовки отдельно.

Объясните, в чём проблема? Если каличный блокнот/браузер, то это не проблема технологии и не проблема веб-стандартов. В качестве блокнота обычный виндовый пользовал…
UFO landed and left these words here
Хм… WinXP, стандартный блокнот. Дефисы только в тех местах, где были показаны браузером Opera 9.27.

А вот Firefox и ИЕ6 выдали мне кошмарное говно, о котором Вы говорите. Блокнот не виноват.

При нажатии «сохранить как текст» и ИЕ и Файрфокс повторили извращения.

Ну шо я могу сказать… ИЕ уже не вылечить, а в багрепорт файрфокса надо писать. А вам или юзать Оперу или копипастить сорц и преобразовывать в текст (насколько я помню такая мгическая кнопка есть в Gridinsoft Notepad)
Дефисы только в тех местах, где были показаны браузером Opera 9.27.

Есть что-то общее между фанатами Apple и браузера Opera: желание выдавать недостатки своих любимцев, за достоинства.

То, что Opera теряет мягкие переносы чести ей не делает, а Notepad ведёт себя так, как и должен вести.

ИЕ уже не вылечить, а в багрепорт файрфокса надо писать.
Вообще-то багрепорт нужно писать создателям Opera ибо только этот браузер портит текст при копировании в буфер обмена. Firefox и MS IE (в виде исключения, не иначе) всё делают правильно.
Возможно Вы и правы. Опера копирует по принципу WYSsiWYG. Для меня это не недостаток. Однако про копирование в вордпэд тоже важно.

Ведь никто не сказал как нужно правильно копировать текст. Большинство юзеров скопируют его просто на память, а не для последующей вёрстки ворде.
Судя по всему, особенности отображения именно блокнотом.
Не только блокнотом: многие «программистские» редакторы (работающие на принципе: один симво — одно знакоместо) так себя ведут.
В Gedit и OOo 3 всё нормально :)
Хотя и там и там символы мягкого переноса остались и даже, кажется, работают.
Хотя и там и там символы мягкого переноса остались и даже, кажется, работают.
Конечно остались и работают — это как раз нормально.

Млин, плюсаните ему в карму за такой презент )))
плюсанул… тему подкинул братан.
Я думал-гадал как средствами CSS организовать «книжные» переносы, а оказывается такой спецсимвол уже существует :))
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
Ага, читал я об этом. Но прирост объёма кода нифига не радует. Впрочем как и от расставленного после каждого слога shy. Ручками надо )) тогда например в первых словах абзаца вообще не требуется.
Такое точно поисковиками индексироваться не будет :)
UFO landed and left these words here
Тогда, конечно, проблем не будет.

Отбросить-то не мешает, но не факт, что они туда пробелов не навставляют.
> Вы когда-нибудь обращали внимание на то, что практически на всех сайтах в тексте отсутствуют переносы и
> из-за этого статьи, новости и другой контент выглядят не строгой симпатичной колонкой, а неровным блоком
> c кривым правым краем?

Своеобразная ирония в том, что этот текст сверстан с align=justify. :-)
ИМХО вставлят разметку переносов в текст статьи — сплошное извращение. Надо доверить эту работу JavaScript'у :)
Вот будут у нас 100GHz процы — тогда и JavaScript пригодится. Библиотечка, в принципе, есть. Но пока — не стоит. Расстановка переносов — весьма ресурсоёмкая операция.
да, но если переносы обрабатывать на сервере, при этом формирируя массив для яваскрипта с указанием только координат для вставки переносов, это может здорово увеличить производительность скрипта
А вот это хорошая мысль. Остаётся вопрос точного прицеливания )
Маразм. Кому это облегчит жизнь? Если уж и вставлять переносы — то так как это сейчас сделано: с помощью специально для этого предназначенного символа. Получите по два байта на перенос (это в UTF-8). Координаты больше займут плюс ещё лишняя обработка в браузере.
Если нужно почитать свободно — почитайте в браузере. А если разметку делать — разметьте тэгами и только в конце ­ расставьте. Ни капли не мешает. А читать тексты в сорс-коде особого смысла нет (тогда уж и тэги порубать надо).

Ну и если совсем по-хорошему, то самый вариант делать на стороне сервера. Переносы расставляются при загрузке статьи на сервер, убираются для правки её кода, расставляются только в отредактированных абзацах при исправлении и заливке.

Что касается расставления переносов после каждого слога — это в любом случае извращение и перегрузка кода. Хотя при аппаратном сжатии не так страшно, ведь символ везде повторяется.
Я попробую высказаться кратко.
Читать интернет-тексты с переносами — непривычно и неудобно.

Уж лучше обычная гребенка или «justy» (тем более что данный скрипт от «гребенки» не избавляет.)
А если выравнивание по двум сторонам и эти переносы, то получится текст как в книжке. Для чтения с компьютера литературы)
Я, например, обратил внимание на то что в тексте стоят переносы только после того как дочитал до этого момента в тексте.
тем то и прекрасен сервис МЯГКОГО ПЕРЕНОСА. для того и работает, чтоб не заметно было. так полагаю — для копирайтеров сервис просто супер.

Копирайтеры, гоп до кучки на www.plazoo.com!!!
Я по сей день вручную расставляю. Дело в том, что не везде, где можно делать перенос, его делать нужно. Точнее есть более удачные места переноса и менее удачные. Например:

была раз-
ница

и была разни-
ца

Во втором случае недочитав слово мы его достроим сами и перенесёмся на следующуу строку легче проскочив оторваный кусочек.

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

Впрочем если сравнить justify и просто shy, то выбор очевиден. Более того расставленные везде где можно переносы позволяют испольщовать нам justify без ущерба для вида и плотности строки.

дабы не быть голословным — duxlab.com/puti/prochee/vizitki/vi.zip
Тема с переносами витает давно и обсуждалась на проекте www.typograf.ru пару тройку лет назад. Мягкие переносы не внедрены до сих пор только по пречине разночтений в браузерах www.quirksmode.org/oddsandends/wbr.html

Полезность переносов оспаривать глупо, ибо пока будут фиксированные колонки идлинныеслова :) необходимость в них не исчезнет. Во всех остальных случаях — это плохо. Особенно в джастифай выравнивании.

По поводу поисковиков думаю следающее: как только появятся переносы, поисковики научатся с ними работать :)
Проблема разночтений в браузерах решена. &shy; работает во всех современных браузерах, так что пора…

P.S. В Firefox 2.0 оно не работает, но катастрофы не происходит: просто переносы не работают и всё. Пробелов лишних не появляется…
Значит скоро Тёма © объявит что он придумал переносы :)
Only those users with full accounts are able to leave comments. Log in, please.