Вот какой странный вопрос по поводу интерфейсов для веб-сервисов образовался.
К примеру, есть некий сервис, в котором пользователь (несколько типов пользователей) заполняет какие-то данные (несколько типов данных). Каждая запись, любого типа у любого пользователя имеет “имя” и “дескрипшин”, которые в интерфейсе выводятся как в табличных формах, в разных списках, так и в формах, которые можно было бы назвать профайлом записи.
К примеру, речь идёт о фиксированном размере интерфеса, хотя на самом деле даже это не суть важно.
И, к примеру, пользователь в качестве имени (а сейчас даже более актуально в качестве описания) вводит неразрывное слово; не существующее в словаре, но каким-то образом отмечающее именно эту запись. Вот так вот 120 неразрывных букв “W” в дескрипшине. Естественно, при публикации этой записи на экране в обычных условиях этот экран разъезжается на всю ширину неразрывного слова. Какие приняты в цивилизованном сообществе разработчиков интерфейсов стандартные решения такой задачи?
- И пусть с ним. Растягивается интерфейс (или сам интерфейс не растягивается, но запись “выезжает” за правый край интерфейса). Как бы ни было свёрстано, первым методом или вторым, экран смотрится в любом случае некрасиво, но можно сказать, к примеру, что юзер сам себе даун, если делает такие записи, и пусть теперь смотрит на то, что сам ввёл, не нравится – отредактирует запись.
- “Обрезать” запись в соответствии с общем стилем интерфейса. Здесь есть несколько разных методов, которые можно было бы использовать:
- С помощью html/css, задавая размер блоку, где публикуется дескрипшин и указывая свойство overflow:hidden; Такая беспробельная запись обрежется по правому краю вполне благополучно, в хинте же (title) можно выводить полный текст записи. Плюс этого метода в том, что те записи, которые содержат адекватные дескрипшины с пробелами между словами, будут отображаться нормально. Минус – для каждой такой записи необходимо указывать фиксированный размер, а ширину в некоторых блоках важно было бы оставить динамическую. А если рассматривать программные методы?
- к примеру, просто обрезая дескрипшин после какого-то символа, как угораздило сделать нашим программером на текущем проекте. Недопустимый минус – он обрезает и валидные дескрипшины по тому же количеству символов и показывает в одной строке, хотя допустим перенос текста дескрипшина на три строки.
- Можно было бы писать сложнее, вставляя что-то типа
<wbr />после какого-то количества символов. Но тогда в валидных дескрипшинах тоже будут переноситься слова, и причём в самых неожиданных местах, тоже недопустимо. - Каким-то образом определять неадекватные дескрипшины? Есть ли для этого стандартные решения? И на каком этапе их нужно определять? Уже после того, как юзер что-то ввёл и показывается экран со списком введённых данных? Или на этапе заполнения формы, хитрыми валидаторами не давая возможности ввести юзеру неадекватный текст?
Кажется, отдел маркетинга и сам уже видит, что преимущества интерфейса с фиксированной шириной с лихвой перекрываются недостатками, и прошлый, резиновый “дизайн” был уместнее для такого проекта, но даже резина концептуально вопрос с неадекватными дескрипшинами не решает. Кто что может посоветовать?
> Можно было бы писать сложнее, вставляя что-то типа
<wbr>после какого-то количества символов. Но тогда в валидных дескрипшинах тоже будут переноситься слова, и причём в самых неожиданных местах, тоже недопустимо.Если вставлять
<wbr>после символов эдак 20, то на практике почти нереально встретить нормальное слово, которому бы это помешало.А еще можно вставлять
­вместо<wbr>. IE6+ и FF3+ умеют его отображать. Про остальных не знаю.Про
&Да, третий умеет, а FF2 нет.В общем, пока решили верстальщицким методом обрезать неадекват: просто по ширине с overflow:hidden
Как по мне, то 3 метод логичный. Только нужно вставлять не после определенного количества символов, а внутри каждого неразрывного слова, тогда валидные резаться не будут вообще.
По-моему, есть готовые решения на JavaScript (задается максимальное значение длины слова и скрипт уже сам все делает “на лету”).
Сложный вопрос. Когда подобная проблема встала у нас, решение было крайне тупое. Дело осложнялось резиной (у нас именно осложнялось, с фиксированной шириной было бы проще). Что мы сделали:
1. Подсчитали, сколько букв w влезает в строку минимальной ширины, пусть будет N.
2. При сохранении искали “слова” (часть строки, ограниченная пробельными и переносимыми символами) и вставляли пробел после каждых N символов. Получилось ужасно. А вот с ­ должно выйти хорошо!
Из символов переноса самый красивый результат у ­, но FF2 его не понимает… А wbr не работает в Safari (по крайней мере, под win).
Из чисто html/css решений еще можно попробовать overflow:scroll. Но в подписях к полям, скорее всего, не получится либо будет выглядеть ужасно.
Скроллы как раз и были решением проблемы, пока отдел маркетинга “это” не увидел. Однозначно сказано: найти решение без скроллов.
А с не-резиной дополнительная трабла следующая: используется несколько юзерс контролов, с какой-то, скажем, повторяющейся формой. И эта форма вставляется в несколько разных экранов. В одном экране есть “колонка” с деревом данных, слева, т.е. размер для формы = экран минус 200 пикселей дерева и минус 16 пикселей полей.
А в другом, к примеру, экране, этого дерева нет и форма – на всю ширину интерфейса. И здесь надо было бы выводить дескрипшины разной ширины, а объект – один, этот юзерский контрол.
Сейчас ловим все такие размеры, и в контроле программер будет менять имя класса с предзаданной шириной в зависимости от того, куда контрол сс этой формой попал. Кшмр.
А нельзя ли искать пробельный символ среди первых n символов (определив n в зависимости от макета, конечно) и если такого нет – вот тогда вставлять разрыв?
Т.е. считать первые, скажем, 20, если в них нет пробела, дефиса или другого разделительного символа, то вставлять разрыв. Так?
Да, примерно так. Можно вообще это делать по всей длине фразы. То есть строку на 255 символов поделить на 11 частей и проверять на наличие разрыва каждый кусок.
Когда я работал в Артиксе, у нас была необходимость решения подобной задачи, но там нельзя было обрезать текст, нужно было переносить про shy еще никто и не знал в принципе, т.к. он был не применим в половине браузеров. Так вот программер родил идею. Внимание! После каждого символа вставляется блок span с точкой, он скрывается через CSS и программер с помощью всей этой фигни, каких-то хитроумных подсчетов делал перенос. А программер у нас был офигенный мужик, очень веселый, как видите! =)
Паш, такой метод недопустим. В некоторых (теоретически — во всех) случаях эти “длинные строки” юзер может или ДОЛЖЕН копировать и куда-то вставлять.
К примеру в нескольких местах по сценарию он получает линки на свой продукт, простые и криптованные, и ясно, что текст с точками ему отдавать бессмысленно.
да я знаю, просто вспомнил смешную историю =)
я бы рекомендовал вариант №1, но с изменением алгоритма расчет длины строки на стороне сервера. иначе говоря, перед отдачей текста он проверяется на соотвествие этой длине и если там попадается неразрывное слово, длинее лимита, текст обрезается на -3 символа от лимита и туда вставляем “…”. вобщем-то примерно так сделано у нас.
собственно можно это сделать как на серверной стороне, так и на клиентской, но ИМХО задача сервера отдать форматированный текст.
Вариант 2.1 – Поправка. Необходим заданный размер, а не фиксированный. Другими словами, вы не обязаны задавать его в пикселях.
Попробовал: происходит достаточно адекватное поведение контента.
Татьяна, так что, нашли подходящее решение? Пробовали методом 2.1 задавать процентную ширину блока?
Дима, так сложилось, что у нас несколько мест, где есть проблема с длинными строками, и там разные ситуации, поэтому пришлось использовать и разные решения.
К примеру в интерфейсах, где длинные дескрипшины выводятся в табличной форме в две колонки, там я урезаю html+css, свойством overflow, в блоке, где генерится длинна