Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 108
Спасибо, очень интересно. В последнее время интересуюсь правильным оформлением текста.
С одной стороны, всё замечательно и текст теперь, как в книгах, но почему-то глаз дёглается и разрывает слово. Быть может, привычка.
Классно было бы, если бы у нах был, к примеру, плагин для Вордпресс.
С одной стороны, всё замечательно и текст теперь, как в книгах, но почему-то глаз дёглается и разрывает слово. Быть может, привычка.
Классно было бы, если бы у нах был, к примеру, плагин для Вордпресс.
Вообще у Qlikworld BV очень много продуктов, которые заслуживают пристального внимания. Очень весомые. я писал о них тут: fima.habrahabr.ru/blog/28425/ и так же посмотрите тут:http://fima.habrahabr.ru/blog/28894/
весьма интересная программулина сделана для нас. скачать программулю можно тут: download.qlikworld.com/downloads/rssreader/814/setup.exe
чего только не содержит в себе. 78 каналов ведущего радио, переводчики, калькулятор валют, энциклопедии и много другого.
;) а вы все текст и текст. только сейчас заметили про текст… поковырять поближе, так там много чего вообще у компании. разработок море…
весьма интересная программулина сделана для нас. скачать программулю можно тут: download.qlikworld.com/downloads/rssreader/814/setup.exe
чего только не содержит в себе. 78 каналов ведущего радио, переводчики, калькулятор валют, энциклопедии и много другого.
;) а вы все текст и текст. только сейчас заметили про текст… поковырять поближе, так там много чего вообще у компании. разработок море…
Да это полный идиотизм — в компьютерных текстах делать переносы. Они нужны чтобы бумагу экономить, а в интернете абсолютно неприменимы для ПРАВИЛЬНОГО оформления текста НИ justify, НИ переносы.
Даже если брать за предположение, что текст могут напечатать, переносы показываются всегда — на экране они только мешают нормально читать. И даже если речь идет про «жесткую» копию.
Кстати, переносы придуманы не для экономии бумаги (хотя и для этого тоже), а чтобы как раз уменьшить «зияющие провалы» между словами при полной выключке (выравнивании по ширине). Проблема в том, что расставляет их редактор, знающий правила.
А любой сервис или автоматический «расставлятель» делает это так, что переносы вставляются там где не надо (например, здесь описано), забивают HTML-код, остаются в буфере при копировании, и идут подряд по несколько (что совершенно неверно — больше двух переносов в строках подряд воспринимается как «лес» палочек).
Есть, кстати, два плагина для Вордпресса, но ссылок давать не буду, потому что это неправильно :)
Кстати, переносы придуманы не для экономии бумаги (хотя и для этого тоже), а чтобы как раз уменьшить «зияющие провалы» между словами при полной выключке (выравнивании по ширине). Проблема в том, что расставляет их редактор, знающий правила.
А любой сервис или автоматический «расставлятель» делает это так, что переносы вставляются там где не надо (например, здесь описано), забивают HTML-код, остаются в буфере при копировании, и идут подряд по несколько (что совершенно неверно — больше двух переносов в строках подряд воспринимается как «лес» палочек).
Есть, кстати, два плагина для Вордпресса, но ссылок давать не буду, потому что это неправильно :)
Если у вас не очень широкая колонка и довольн длинные слова, то текст у вас будет либо с сильно рваным правым краем, либо (при выравнивании по обеим сторонам) с жуткими растянутыми пробелами. В этом случае, переносы могут спасти ситуацию.
В английском языке с его более короткими словами эта ситуация не так заметна — собственно поэтому производители браузеров не сильно чешутся насчет поддержки переносов.
В английском языке с его более короткими словами эта ситуация не так заметна — собственно поэтому производители браузеров не сильно чешутся насчет поддержки переносов.
я один не догнал? как это «Эта статья уже содержит расставленные переносы.» а в исходном коде все чисто. Как оно работает? Прошу прощения если затупил.
Попробуй изменить размер окна своего броузера и следи за переносами.
эффект я пронаблюдал — все работает, это и настораживало так как исходный код чистый, уже сам выяснил & shy; скрывает Firefox при показе Ctrl+U
он многое скрывает. и этим порой плох для разработки.
Да нифига он не скрывает! Не надо ля-ля. В тексте статьи НЕТ никаких ­ — супер-пупер-руки-поотрывать-парсер хабра превращает ­ в U+00AD — а этот символ и не должен быть виден! Скопируйте в текстовый файл — сразу увидите все символы (по крайней мере у меня в Ubuntu так).
Я не на Хабре код смотрел, а на указанном сайте. Парсер здесь ни при чём.
А что кривой код теперь могут только создатели Хабрахабра писать?
Посмотрите на следующий текст в исходниках хабрастраницы (надуюсь я смогу обмануть хабрапарсер):
От дель ный ин те рес сис те ма пред став ля ет тем, что уме ет пра виль но рас став лять пе ре но сы на се ми язы ках. При этом са ми язы ки меж ду со бой не пе ре ме ши ва ют ся, т.е., если рас став лять пе ре но сы в рус ском тек с те, ко то рый со дер жит ино стран ные сло ва, то сис те ма рас ста вит пе ре но сы толь ко в рус ских сло вах, а ино стран ные оста вит без из ме не ний.
Посмотрите на следующий текст в исходниках хабрастраницы (надуюсь я смогу обмануть хабрапарсер):
От дель ный ин те рес сис те ма пред став ля ет тем, что уме ет пра виль но рас став лять пе ре но сы на се ми язы ках. При этом са ми язы ки меж ду со бой не пе ре ме ши ва ют ся, т.е., если рас став лять пе ре но сы в рус ском тек с те, ко то рый со дер жит ино стран ные сло ва, то сис те ма рас ста вит пе ре но сы толь ко в рус ских сло вах, а ино стран ные оста вит без из ме не ний.
Хабр не причем, все зависит от браузера, через который исходный код смотреть, у меня опера и фф под виндовс ничего не показывают, но если открыть в дримвьювере или блокноте, то сразу все становится видно
Хабр ОЧЕНЬ ДАЖЕ ПРИЧЁМ. Откройте файл с ­, посмотрите исходный код страницы и… о мегасуперчудо — вы увидите все ваши ­, откройте файл где ­ превращено в U+00AD — и будет так, как вы описали.
Нечего на зеркало пенять если рожа крива!
Нечего на зеркало пенять если рожа крива!
Эй, поосторожнее! Рожа крива у парсера.
Об чём и речь. Но мне тут пытаются доказать что, типа, это в Firefox глюк и он ­ не показывает. Конечно показывает! Если это самое ­ там есть! А если его кто-то скушал до того, как текст в Firefox попал, то с какой стати он должен что-то показывать? U+00AD не должен отображаться там, где переносы не случаются (моноширинный шрифт — отдельная песня).
Я посмотрел как отображается shy в лисе по ctrl+u — со статическим текстом отображается как пять символов.
Но так как на той странице тот кусок с шаями генерится динамически, то проверить без спецсредств трудно. Но в целом, пока что вы выигрываете :)) Показываются шаи как есть. Что, правда, не отменяет другие подмены html-кода на один-единственный символ.
Но так как на той странице тот кусок с шаями генерится динамически, то проверить без спецсредств трудно. Но в целом, пока что вы выигрываете :)) Показываются шаи как есть. Что, правда, не отменяет другие подмены html-кода на один-единственный символ.
Покажите пример где HTML-код показывается как один-единственный символ. Во всех случаях что я видел он съедался кем-нибудь «по дороге» до попадания в Firefox…
Ага! Понял в чём разница — «view selection source» мне не нравится, с ctrl+u всё в порядке. Пример:
zencd.spb.ru/tmp/eaten.html
А v.s.s. от себя много добавляет. Но чертовски удобен. Но добавляет :)
zencd.spb.ru/tmp/eaten.html
А v.s.s. от себя много добавляет. Но чертовски удобен. Но добавляет :)
С динамическим текстом проблемы: там как бы нет исходного кода. Показывается содержимое DOM-дерева. А в DOM-дереве разница между "A" и "A" уже пропадает — все entities превращаются просто в буквы… Когда вы делаете «View Selection Source» три символа ("<"," >" и "&") превращаются обратно в entities (по понятным причинам). Остальные символы не трогаются…
P.S. Вообще на Хабре почти нереально про такие вещи рассказывать: он по разному интерпретирует entities в разных случаях, так что увидеть что ты пишешь нельзя (кнопка «предпросмотр» показывает не тот текст, который ты увидишь после того, как нажмёшь на кнопку «написать»). А без примеров — тяжело и писать и воспринимать.
P.S. Вообще на Хабре почти нереально про такие вещи рассказывать: он по разному интерпретирует entities в разных случаях, так что увидеть что ты пишешь нельзя (кнопка «предпросмотр» показывает не тот текст, который ты увидишь после того, как нажмёшь на кнопку «написать»). А без примеров — тяжело и писать и воспринимать.
Тут есть некий www.plazoo.com/images/hypho.gif.
все, простите, вопрос снят,
*задумался, почему у него FF не показывает в исходном коде & shy;*
*задумался, почему у него FF не показывает в исходном коде & shy;*
Отличный сервис! Теперь можно красиво текст вписать в страницу.
Сервис, в принципе, полезный.
Но один важный вопрос: как скажется такая обработка текста на индексации поисковиками?
Но один важный вопрос: как скажется такая обработка текста на индексации поисковиками?
& shy; — мягкий перенос, в исходном коде не отображается, следовательно, на индексацию и выдачу поисковиков влиять не должен.
Действительно есть, попробовал открыть в блокноте, а Opera и Firefox не показывают
Делаем из неуникального контента — уникальный ))
Сейчас поисковики (я про двух основных игроков рынка говорю) не считают за пробельный символ мягкого переноса, точно так же, как игнорируют символ ударения (а вот Rambler, кстати, не игнорит). А вот nbsp и thinsp — да, делаются пробельными.
Это Вы проверяли, или «общие соображения»?
Только, что связывался с разработчиками сервиса в германии, гугл и яху & shy; не воспринимают, яндекс и рамблер они не тестировали.
Что значит не воспринимают? Игнорируют или понимают неправильно (как пробел)?
Игнорируют, склеивая слоги
яндекс давно склеивает, рамблер вроде тож.
Вообще начал использовать года три назад, ещё никто не жаловался. А если уж жалоба, то пройтись автозаменой по документу — дело пяти секунд.
Вообще начал использовать года три назад, ещё никто не жаловался. А если уж жалоба, то пройтись автозаменой по документу — дело пяти секунд.
не знаю, я только на последнем абзаце заметил, что в статье расставлены переносы :)
давным-давно писал скрипт на регулярках для расстановки мягких переносов. потом убрал, когда начали жаловаться на глюки толи в ИЕ, толи еще где-то (когда меняешь размер окна, переносы превращались в дефисы)
давным-давно писал скрипт на регулярках для расстановки мягких переносов. потом убрал, когда начали жаловаться на глюки толи в ИЕ, толи еще где-то (когда меняешь размер окна, переносы превращались в дефисы)
Тоже заметил переносы только когда автор об этом написал. Заметил и ужаснулся рваному правому краю статьи. Все-таки считаю что переносы в печатном тексте излишество. Гораздо лучше смотрится и читается текст, выровненный по ширине без всяких разрывов слов. Переносы возможны в рукописном тексте, когда не хватает места для окончания слова, а писать уже начал. Как исключение может быть только печатный текст с длинными словами в узкой колонке.
о, не заметил сразу ваш коммент. 100% согласен.
Переносы иного и в экранном варианте все же нужны, особенно если у вас встречаются длинные слова и тогда правая линия обзаца становится «рваной». А если узкие колонки то это один из действенных способ уравновесить ширину строки
Откуда взялся этот миф, мол легче читать текст, выровненный по левому краю? Меня всегда ужасно раздражал текст, выровненный по левому краю — когда его много, трудно перебегать с глазами со строчки на строчку, особенно если ширина строки большая.
Это не миф. Легче читать текст, в котором не только слова в строке имеют одинаковую плотность, но и буквы в слове (решается кернингом, лигатурами). Тогда и эффектней любые выделения текста (шрифтом, жирностью, наклоном) смотрятся.
Равнение по левому краю обязательно почти везде, потому что легче каждый раз начинать читать с одной вертикали. Исключение делается лишь для газетной вёрстки.
В газетах к слову узкие столбцы не просто так сделаны, а из рассчёта на быстрое «деловое» чтение.
Идеальный для чтения текст:
а) равномерная плотность строк, букв, межбуквенного, межстрочного пространства, абзацев.
б) равнение по обеим сторонам страницы, переносов как можно меньше и резать слова наиболее читаемым способом (#comment_1130805)
в) гарнитура соответствует эпохе и стилю повествования, желаемому типу восприятия.
г) переносы слов на следующую строку делаются предпочтительно по смысловым блокам (никаких союзов и предлогов в конце строки)
д) знаки пунктуации, особенно неплотные, в конце и начале строки выходят за пределы строки (« — достаточно плотный, как буква знак, а вот запятые, тире, кавычки-лапки — слишком лёгкие и образовываю дырку)
Это знаю я. Уверен, хороший типограф знает гораздо больше. Попробуйте почитать хорошо свёрстанные книги. Там не спотыкаешься о дырки, опечатки, провисшие союзы, не рябит от шрифта в глазах. Там передаётся смысл.
У меня книга повестей Лескова за 1929 год была, даже с неудобными ер и ять, куда приятнее читать, чем современные книжицы.
Равнение по левому краю обязательно почти везде, потому что легче каждый раз начинать читать с одной вертикали. Исключение делается лишь для газетной вёрстки.
В газетах к слову узкие столбцы не просто так сделаны, а из рассчёта на быстрое «деловое» чтение.
Идеальный для чтения текст:
а) равномерная плотность строк, букв, межбуквенного, межстрочного пространства, абзацев.
б) равнение по обеим сторонам страницы, переносов как можно меньше и резать слова наиболее читаемым способом (#comment_1130805)
в) гарнитура соответствует эпохе и стилю повествования, желаемому типу восприятия.
г) переносы слов на следующую строку делаются предпочтительно по смысловым блокам (никаких союзов и предлогов в конце строки)
д) знаки пунктуации, особенно неплотные, в конце и начале строки выходят за пределы строки (« — достаточно плотный, как буква знак, а вот запятые, тире, кавычки-лапки — слишком лёгкие и образовываю дырку)
Это знаю я. Уверен, хороший типограф знает гораздо больше. Попробуйте почитать хорошо свёрстанные книги. Там не спотыкаешься о дырки, опечатки, провисшие союзы, не рябит от шрифта в глазах. Там передаётся смысл.
У меня книга повестей Лескова за 1929 год была, даже с неудобными ер и ять, куда приятнее читать, чем современные книжицы.
Наверное я ошибаюсь. Но, как я уже сказал, текст, выровненный по левому краю для меня как был, так и остаётся неудобным для чтения. Наверное мой случай уникален.
Хм. Тогда вопрос: нравится, когда по правому равнение идёт или по центру? Или я чего-то не догоняю и равнение jystify не включает в себя равнение по левому краю? Случай действительно редкий.
Ну ещё, если justify, то получается, что нерегулярные дырки посреди текста напрягают меньше, чем правый рваный край?
Ну ещё, если justify, то получается, что нерегулярные дырки посреди текста напрягают меньше, чем правый рваный край?
Нравится, когда равнение идёт по ширине (justify). Да, как-то нерегулярные дырки посреди текста напрягают меньше, ведь посреди текста я не перескакиваю вдруг на следующую строчку.
так совмещайте во всех слогах и justify — будет и красиво и дырки в строках минимально отличаться будут. (длина максимального слога делить на количество пробелов)
Я к Вам в блог зашёл и уяснил в чём дело. Когда строки длинные и текст мелкий, то дырки в тексте особо не заметны, особенно если не привязывать союзы к словам и позволять им обвисать.
Но удобочитаемая строка — это не 15 слов, а всего 6—8 (два—три смысловых блока). И вот как раз в короткой строке дыры будут отвратительные.
На примере блога соглашусь: лучше длинная но аккуратная строка, чем много рваных коротких.
Я к Вам в блог зашёл и уяснил в чём дело. Когда строки длинные и текст мелкий, то дырки в тексте особо не заметны, особенно если не привязывать союзы к словам и позволять им обвисать.
Но удобочитаемая строка — это не 15 слов, а всего 6—8 (два—три смысловых блока). И вот как раз в короткой строке дыры будут отвратительные.
На примере блога соглашусь: лучше длинная но аккуратная строка, чем много рваных коротких.
1. а в экранном тексте сохранять плотность не нужно? (с пристрастием атремийлебедев-ориентированных веб-дизайнеров к резиновым макетам — особенно)
2. какая связь между бОльшей легкостью чтения текста, выровненного по левому краю (не только с экрана, но и вообще, в целом) и отсутствием необходимости переносов?
2. какая связь между бОльшей легкостью чтения текста, выровненного по левому краю (не только с экрана, но и вообще, в целом) и отсутствием необходимости переносов?
Эээ… В печтаном-то тексте они как раз и нужны! Чтобы текстовые блоки включённые по ширине выглядели более однородно и плотно. Ну, и при вёрстке флагом был бы более ровный правый край. Посмотрите в журналы, ей-богу.
замечательно :) Джастифай теперь будет рулить!
У Рината (боюсь не правильно написать фамилию, Nasibullin Rinat) есть замечательный пак php-функций для обработки текста в кодировке UTF-8. Так вот там есть функция hyphen_words().
Отказался от идеи расстановки переносов, когда попробовал скопипастить его в блокнот…
А в чём проблема? Сейчас скопипастил, сохранились только переносы, которые сделал браузер. Если нужен целый текст, где каждый абзац идёт одной строкой — сорц->копипаст->преобразовать в текст.
Более того сейчас сохранил как текст оперой статью, где есть и nbsp и условные переносы — всё хорошо, на абзацы поделено с шириной строки, взятой из CSS, заголовки отдельно.
Объясните, в чём проблема? Если каличный блокнот/браузер, то это не проблема технологии и не проблема веб-стандартов. В качестве блокнота обычный виндовый пользовал…
Более того сейчас сохранил как текст оперой статью, где есть и nbsp и условные переносы — всё хорошо, на абзацы поделено с шириной строки, взятой из CSS, заголовки отдельно.
Объясните, в чём проблема? Если каличный блокнот/браузер, то это не проблема технологии и не проблема веб-стандартов. В качестве блокнота обычный виндовый пользовал…
Хм… WinXP, стандартный блокнот. Дефисы только в тех местах, где были показаны браузером Opera 9.27.
А вот Firefox и ИЕ6 выдали мне кошмарное говно, о котором Вы говорите. Блокнот не виноват.
При нажатии «сохранить как текст» и ИЕ и Файрфокс повторили извращения.
Ну шо я могу сказать… ИЕ уже не вылечить, а в багрепорт файрфокса надо писать. А вам или юзать Оперу или копипастить сорц и преобразовывать в текст (насколько я помню такая мгическая кнопка есть в Gridinsoft Notepad)
А вот Firefox и ИЕ6 выдали мне кошмарное говно, о котором Вы говорите. Блокнот не виноват.
При нажатии «сохранить как текст» и ИЕ и Файрфокс повторили извращения.
Ну шо я могу сказать… ИЕ уже не вылечить, а в багрепорт файрфокса надо писать. А вам или юзать Оперу или копипастить сорц и преобразовывать в текст (насколько я помню такая мгическая кнопка есть в Gridinsoft Notepad)
Дефисы только в тех местах, где были показаны браузером Opera 9.27.
Есть что-то общее между фанатами Apple и браузера Opera: желание выдавать недостатки своих любимцев, за достоинства.
То, что Opera теряет мягкие переносы чести ей не делает, а Notepad ведёт себя так, как и должен вести.
ИЕ уже не вылечить, а в багрепорт файрфокса надо писать.Вообще-то багрепорт нужно писать создателям Opera ибо только этот браузер портит текст при копировании в буфер обмена. Firefox и MS IE (в виде исключения, не иначе) всё делают правильно.
Судя по всему, особенности отображения именно блокнотом.Не только блокнотом: многие «программистские» редакторы (работающие на принципе: один симво — одно знакоместо) так себя ведут.
В Gedit и OOo 3 всё нормально :)
Хотя и там и там символы мягкого переноса остались и даже, кажется, работают.
Хотя и там и там символы мягкого переноса остались и даже, кажется, работают.
У Рината (боюсь не правильно написать фамилию, Nasibullin Rinat) есть замечательный пак php-функций для обработки текста в кодировке UTF-8. Так вот там есть функция hyphen_words().
Млин, плюсаните ему в карму за такой презент )))
+) богатая идея +) плюсанул +)
Я думал-гадал как средствами CSS организовать «книжные» переносы, а оказывается такой спецсимвол уже существует :))
Ага, читал я об этом. Но прирост объёма кода нифига не радует. Впрочем как и от расставленного после каждого слога shy. Ручками надо )) тогда например в первых словах абзаца вообще не требуется.
> Вы когда-нибудь обращали внимание на то, что практически на всех сайтах в тексте отсутствуют переносы и
> из-за этого статьи, новости и другой контент выглядят не строгой симпатичной колонкой, а неровным блоком
> c кривым правым краем?
Своеобразная ирония в том, что этот текст сверстан с align=justify. :-)
> из-за этого статьи, новости и другой контент выглядят не строгой симпатичной колонкой, а неровным блоком
> c кривым правым краем?
Своеобразная ирония в том, что этот текст сверстан с align=justify. :-)
ИМХО вставлят разметку переносов в текст статьи — сплошное извращение. Надо доверить эту работу JavaScript'у :)
Вот будут у нас 100GHz процы — тогда и JavaScript пригодится. Библиотечка, в принципе, есть. Но пока — не стоит. Расстановка переносов — весьма ресурсоёмкая операция.
да, но если переносы обрабатывать на сервере, при этом формирируя массив для яваскрипта с указанием только координат для вставки переносов, это может здорово увеличить производительность скрипта
А вот это хорошая мысль. Остаётся вопрос точного прицеливания )
Маразм. Кому это облегчит жизнь? Если уж и вставлять переносы — то так как это сейчас сделано: с помощью специально для этого предназначенного символа. Получите по два байта на перенос (это в UTF-8). Координаты больше займут плюс ещё лишняя обработка в браузере.
Если нужно почитать свободно — почитайте в браузере. А если разметку делать — разметьте тэгами и только в конце расставьте. Ни капли не мешает. А читать тексты в сорс-коде особого смысла нет (тогда уж и тэги порубать надо).
Ну и если совсем по-хорошему, то самый вариант делать на стороне сервера. Переносы расставляются при загрузке статьи на сервер, убираются для правки её кода, расставляются только в отредактированных абзацах при исправлении и заливке.
Что касается расставления переносов после каждого слога — это в любом случае извращение и перегрузка кода. Хотя при аппаратном сжатии не так страшно, ведь символ везде повторяется.
Ну и если совсем по-хорошему, то самый вариант делать на стороне сервера. Переносы расставляются при загрузке статьи на сервер, убираются для правки её кода, расставляются только в отредактированных абзацах при исправлении и заливке.
Что касается расставления переносов после каждого слога — это в любом случае извращение и перегрузка кода. Хотя при аппаратном сжатии не так страшно, ведь символ везде повторяется.
застра-хуй
Я попробую высказаться кратко.
Читать интернет-тексты с переносами — непривычно и неудобно.
Уж лучше обычная гребенка или «justy» (тем более что данный скрипт от «гребенки» не избавляет.)
Читать интернет-тексты с переносами — непривычно и неудобно.
Уж лучше обычная гребенка или «justy» (тем более что данный скрипт от «гребенки» не избавляет.)
А если выравнивание по двум сторонам и эти переносы, то получится текст как в книжке. Для чтения с компьютера литературы)
Я, например, обратил внимание на то что в тексте стоят переносы только после того как дочитал до этого момента в тексте.
тем то и прекрасен сервис МЯГКОГО ПЕРЕНОСА. для того и работает, чтоб не заметно было. так полагаю — для копирайтеров сервис просто супер.
Копирайтеры, гоп до кучки на www.plazoo.com!!!
Копирайтеры, гоп до кучки на www.plazoo.com!!!
Я по сей день вручную расставляю. Дело в том, что не везде, где можно делать перенос, его делать нужно. Точнее есть более удачные места переноса и менее удачные. Например:
была раз-
ница
и была разни-
ца
Во втором случае недочитав слово мы его достроим сами и перенесёмся на следующуу строку легче проскочив оторваный кусочек.
То же самое с неразрывными пробелами и запретом на перенос слов через дефис. Где-то можно сделать это без ущерба для смысла, а где-то нельзя.
Впрочем если сравнить justify и просто shy, то выбор очевиден. Более того расставленные везде где можно переносы позволяют испольщовать нам justify без ущерба для вида и плотности строки.
была раз-
ница
и была разни-
ца
Во втором случае недочитав слово мы его достроим сами и перенесёмся на следующуу строку легче проскочив оторваный кусочек.
То же самое с неразрывными пробелами и запретом на перенос слов через дефис. Где-то можно сделать это без ущерба для смысла, а где-то нельзя.
Впрочем если сравнить justify и просто shy, то выбор очевиден. Более того расставленные везде где можно переносы позволяют испольщовать нам justify без ущерба для вида и плотности строки.
Плагин для WordPress, делает примерно тоже самое, но интереснее:
kingdesk.com/projects/wp-hyphenate/
…русский язык в комплекте.
kingdesk.com/projects/wp-hyphenate/
…русский язык в комплекте.
Тема с переносами витает давно и обсуждалась на проекте www.typograf.ru пару тройку лет назад. Мягкие переносы не внедрены до сих пор только по пречине разночтений в браузерах www.quirksmode.org/oddsandends/wbr.html
Полезность переносов оспаривать глупо, ибо пока будут фиксированные колонки идлинныеслова :) необходимость в них не исчезнет. Во всех остальных случаях — это плохо. Особенно в джастифай выравнивании.
По поводу поисковиков думаю следающее: как только появятся переносы, поисковики научатся с ними работать :)
Полезность переносов оспаривать глупо, ибо пока будут фиксированные колонки идлинныеслова :) необходимость в них не исчезнет. Во всех остальных случаях — это плохо. Особенно в джастифай выравнивании.
По поводу поисковиков думаю следающее: как только появятся переносы, поисковики научатся с ними работать :)
Проблема разночтений в браузерах решена. ­ работает во всех современных браузерах, так что пора…
P.S. В Firefox 2.0 оно не работает, но катастрофы не происходит: просто переносы не работают и всё. Пробелов лишних не появляется…
P.S. В Firefox 2.0 оно не работает, но катастрофы не происходит: просто переносы не работают и всё. Пробелов лишних не появляется…
Есть плагин на jQuery для расстановки переносов в тексте: http://htmler.ru/2013/12/07/jquery-perenosy-russkogo-teksta/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сервис расстановки переносов