HTML+CSS+JavaScript

Что можно сделать, чтобы открытый тег (к примеру <b>) в одном диве, не выделял текст в другом?

<div><b>12345</div> <div>54321</div>

Кроме как помещения дивов в таблицу.

<table> <tr><td><div><b>12345</div></td></tr> <tr><td><div>54321</div></td></tr> </table>

Закройте тег

<div><b>12345</b></div>  <div>54321</div>

>Что можно сделать, чтобы открытый тег (к примеру <b>) в одном диве, не выделял текст в другом?

Закрыть его.

Хороший совет, конечно. :))
Но суть моего вопроса именно в том, что делать, если закрывающего тега нет?

Ну где-то же в коде HTML он (закрывающий </b>) должен быть :-), хотя бы из-за того, что это оговорено в стандартах W3C http://www.w3schools.com/tags/tag_font_style.asp.

Да я понимаю, что стандарт W3C предполагает наличие закрывающего тега.
НО. Данные, которые отображаются в дивах, вводит пользователь. И, естественно, он может случайно или умышленно, оставить тег не закрытым. А фильтрация данных не делается. Так задумано.

Вот я и хочу узнать, как еще, кроме как помещения в таблицу, можно ограничить отрытый тег (к примеру <b>), чтобы он не "портил" другие елементы страницы?

div      {font-weight: normal;}

Не совсем то. Если по аналогии делать для тегов <i> и <u>, т.е.

div       {      font-weight: normal;      font-style: normal;      text-decoration: none;      }

То курсив не будет работать, а вот подчеркивание по прежнему "залазит" в другой див.

>Данные, которые отображаются в дивах, вводит пользователь. И, естественно, он может случайно или умышленно... А фильтрация данных не делается. Так задумано.

Интересная задумка, а чего вы тогда хотите? Когда-то посмеялся про свобоный стиль, а он оказывается существует!

На счет свободного стиля, ничего сказать не могу.

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

Пытаясь найти наиболее рациональное решение, я стараюсь перебирать все возможные варианты. И если проблему не удается решить в месте ее появления, то это делается, где-то, "выше" в решении.

Это, похоже, именно такой случай. Выходит, чтобы не мудрить какую-то, особо извращенную защиту от не закрытого тега, мне проще использовать таблицу.

Вот и все. Спасибо всем, кто пытался помочь. :)

Можно не фильтровать, а просто проставить после (или прямо перед) каждого </DIV> набор закрывающих тегов </b></i></u></s>... (ну и все прочие, которые клиент может открыть в ДИВ'е и забыть закрыть). Неоткрытые браузером проигнорируются; те, что забыли закрыть - закроются.

К сожалению, данное решение теряет смысл, если в первом диве будет несколько одинаковых открывающих тегов.

Тогда делайте радикально: включайте свой DIV внутрь ячейки таблицы - конец таблицы автоматически закрывает все незакрытые теги.

<table width="100%" cellpadding="0" cellspacing="0"><tr><td><div> normal <b>bold <b>bold2 <u>bold_underline <u>bold_underline2 <i>bold_underline_italic <i>bold_underline_italic2 <big>bold_underline_italic_big <big>bold_underline_italic_big2 <code>bold_underline_italic_big_code <code>bold_underline_italic_big_code2 <samp>bold_underline_italic_big_code_samp <samp>bold_underline_italic_big_code_samp2 <small>bold_underline_italic_big_code_samp_small <small>bold_underline_italic_big_code_samp_small2 <sub>bold_underline_italic_big_code_samp_small_sub <sub>bold_underline_italic_big_code_samp_small_sub2 <sup>bold_underline_italic_big_code_samp_small_sup <sup>bold_underline_italic_big_code_samp_small_sup2 <tt>bold_underline_italic_big_code_samp_small_sup_monospace <tt>bold_underline_italic_big_code_samp_small_sup_monospace2 + аналогично <s>, <strike>, <var>, <kbd>, <ins>, <strong>, <pre>... </div></td></tr></table> <table width="100%" cellpadding="0" cellspacing="0"><tr><td><div> normal </div></td></tr></table>

Для противников "табличного дизайна" отмечу, что наличие любого количества таблиц с единственной ячейкой и заданной шириной никак не будет тормозить рендеринг страницы.

Собственно, про таблицы я еще в первом посте написал. И так же решил к ним прибегнуть.
Только теперь, хочу уточнить один момент.

>наличие любого количества таблиц с единственной ячейкой и заданной шириной никак не будет тормозить рендеринг страницы.

А если таблица будет одна, а в ней любое количество строк\ячеек, это будет тормозить рендеринг страницы?

Разумеется.

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

И, кстати, в локале это можно легко проверить.
Делаете таблицу из 1000 строк по одной ячейке, с одинаковым содержанием ячеек.
И делаете второй вариант - тысячу таблиц с той же одной ячейкой каждая.

В хедере запускаете таймер и по onload тела документа определяете время, необходимое на загрузку и формирование DOM-модели страницы и выводите его алертом.
Второй вариант (1000 таблиц по 1 ячейке каждая) по объёму кода будет значительно больше, чем первый (1 таблица с тысячью ячеек), однако таймер во втором случае покажет меньшее время.

Благодарю за развернутый ответ. Теперь, все понятно.

Беседа ушла немного в сторону от заголовка темы, тем не мение, хочу спросить еще вот что:
Поскольку, создание большого количества таблиц, ведет к увеличение кода, а весь этот процесс происходит при помощи js, то есть в браузере пользователя, будет ли большой объем информации влиять на производительность компьютера? Особенно на слабых машинах?

Сам, конечно, полагаю, что будет. А вот, на сколько сильно? И будет ли решением проблемы, скрывать таблицы при помощи display = 'none'? Или нужно будет применять другие подходы?

Не думаю, что компы настолько слабые..

Смотря сколько получится таблиц.
Могу привести несколько отвлеченный пример:
генерация на JS ~ 65000 div`ов + задание им атрибутов и обработчиков onmouseover/onmouseout/onclick (таблица цветов) -
на машине Celeron 2.66 GHz, 256Mb RAM занимает около полутора минут
на машине P4 3.0 GHz, 512Mb RAM - около 30 сек
тестировалось в Firefox 2.0, Opera 9.20

Сокрытие таблиц скорее всего не поможет, т.к. ресурсы все-равно будут расходоваться на создание DOM-узлов.

65000 для меня уже перебор. Хотя... Чем черт не шутит? (с)
Спасибо за приведенную статистику.