s0rr0w

Исли рассматривать сложные интерфейсы, то я вам приведу ряд факторов, которые влияют на ваш код. 1. Любой код (HTML, JS, CSS) должен быть собран в едином логическом месте. Это значит, что для редактировании кода не потребуется править десятки файлов. 2. Код должен быть написан таким образом, что добавление или убирание кода или куска кода (больше касается HTML) не должно влиять на работоспособность всей системы. 3. Код должен быть как можно более простым, чтобы упростить понимание другими разработчиками принципов работы. 4. По умолчанию брать вариант, когда любой код не статичен, количество данных и их структура не константа, все может быть упрощено или усложнено, но это не должно влиять на работоспособность системы в целом. 5. С одним и тем же кодом может работать не один компонент. 6. Каждый компонент должен иметь API по взаимодействию с другими компонентами. Вот и найдите для этого золотую середину.

В какое чувство? Человек указывает на какие-то проблемы, которые проблемами то не могут считаться. Это скорее особенности кода, чем баги. Я не же указываю вам на то, что именование JS переменных должно происходить по правилам JS, а именно первая должна быть буква. Переменные типа "_" и "$" хоть и работают, но являются синтаксическими ошибками. Но я понимаю, что это особенности кода. На это я и указывал во многих своих постах. Что все привыкают делать сферических коней в вакууме. Решать задачу в лоб, не задумываясь про повторное использование кода, про масштабируемость систем, про организацию гибких структур.

Проблему? Да нет проблемы, проблема снова же сугубо в вашем воображении. Я уже написал, что достаточно кодеру дать пояснения по поводу именования классов и не заморачиваться. Да, кстати, а где ваш "супер-беспроблемный" код? Не надо меня отсылать куда-то там... Код, Штирлиц, код! Право же, не перестаете меня умилять. Да, вызов getElementsByClassName непосредственно в inline-обработчике будет приводить к перекрытию вызова. Но никто не мешает написать window.getElementsByClassName. Да и покажите мне человека, который собирается писать javascript-опусы непосредственно в inline-обработчиках? Вызывая любую кастом-функцию внутри тела можно спокойно обращаться через getElementByClassName без указания window. Так я не понял, в чем проблема то? В перекрытии функций в очень специфических случаях? Так эта проблема есть всегда и с любым кодом. Да вполне. Так, кажется я пользовался старыми данными по JS-интерпретатору. Цикл в современных браузерах уже работает на уровне do-while и while. Можно смело переписывать код. а) зачем вам вообще познания в JS, если вы все равно пишете трэш-код? б) после моего увольнения из одной команды разработчиков, на мое место до сих пор не могут найти человека. я не считаю себя космо-кодером, но количество багов в моих кодах до сих пор минимально. В отличие от моих сокоммандников. в) это к вам относится в аналогичной мере.

:cool: Именно этого ответа я ждал. Итак, была предложена структура, структура обработана. Задача выполнена! А то, что это сферический конь в вакууме, никого не интересует. Одно из самых простых требований к нормальному программисту - умение смотреть хотя бы на шаг вперед, а не механически выполнять задачу. Нет простых задач по определению. Вечно кроется какое-то западло в самом тривиальном месте. Именно поэтому для меня скрипт для табов куда сложнее задача, чем многим кажется.

AKS, прокомментируйте следующее, пожалуйста. 1. DT, DD нельзя использовать без DL. Последствия переноса части кода в другую ветку дерева может привести к потенциальному багу с отображением. 2. В вашем JS коде жестко закреплена структура. Что будет, если после H будет стоять что-то другое? Например еще один H. Вполне реальная ситуация. 3. Ссылки создаются скриптом. Что делать, если понадобится уникальные коды для каждой закладки, где не только CSS будет изменен, но и отличаться HTML? 4. Таблицу нельзя использовать после H, так как присваивается display: block. 5. Что делать, если надо будет между контентом табов и самим переключателем вставить еще какие-то теги? 6. Что будет, если контент таба будет удален или перемещен? Ответьте на эти вопросы, только спокойно, рассудительно, без эмоций.

Тогда мне непонятно, почему вам непонятно. Вот я и сомневался, что вы достаточно хорошо изучили принципы работы моего кода. Не надо меня отсылать куда-то там. Приведите код. Это добавит вам уважение как к человеку, который умеет доказать свои слова делом. Смысла в этом не вижу. Есть IE, который для меня существует всего в 2-х версиях, есть DOM-ориентированные браузеры. Зачем что-то придумывать, если можно спокойно ограничиться такой проверкой? Люди, которые сознательно идут на подмену юзерагента пусть также сознательно и сталкиваются со всеми вытекающими последствиями. Мало того, это редко распространенная практика в корпоративном секторе. Итак, я задал вопрос, какой самый быстрый цикл. В ответ я получаю про разницу в скорости. Использование конструкции как раз к месту, так как это самая быстрая конструкция. Да, немного неудобная, но зато выполняет возложенную на нее фукнцию. И какие же заблуждения мои должны были рассеяться? Я скачаль альфу оперы, запустил код. Граблей не нашел вообще. Они находятся сугубо в вашем воображении. Моя функция является методом объекта window, встроенная - document'a. Где грабли? В том, что две фунции имеют одинаковое название? Это смешно. И в чем проблемы с inline-обработчиками, поясните мне темному, может я чего пропустил. Ах, какие высокопарные слова. Если вы делаете по другому, то это не значит, что мой код не содержит идей. Например, я использую обращение к элементам по имени классов. Это куда лучше обращения по ID. Я использую HTML темплейтирование, вместо создания нод при помощи createElement, и не видеть выгоду от этого считаю узостью мышления. Активация по эмуляции клика - тоже не считаю архаикой, а как раз наоборот. Да, я согласен, что на первый взгляд код кажется именно таковым, каким вы описали. Но не видел вашего супер-кода, а поэтому вообще сомневаюсь в ваших способностях. Говорить красивые слова каждый умеет

Dimitry Wolotko, я и не пытался даже.

Метод какого интерфейса? window?

Перечитайте то, что было написано мной про искусственное ограничения количества платформ. Речь идет не про сайты, а про бэк-энд системы. Ничего не занято. В DOM будет использован в качестве интерфейса документ или нода. Но никак не window. Например? Давайте все познавать на примерах. Ваш вариант ограничителя? Докажете, что do-while не самый быстрый, перепишу код на самый быстрый. Текущее положение ноды не является константой. Если привязывать данные к какому-то паренту, то при изменении структуры может быть потеряна связь. Или же наоборот, нужно принудительно терять связь у данной ноды с ее парентом. Как вариант - перемещение таба в другое место, в другой табулятор. Внимательно изучите код. Там уж более чем понятно все расписано. А какой из них был дописан? Вы код смотрели? У меня там как раз для этого случая сделан пример Это их карма Суть изложите. В моей практике пока что не было серьезных проблем. Хоть один пример в студию. Чтобы вызвать функцию переключения таба, нужно будет передать все необходимые параметры, а эти параметры нужно будет привязать к опшинам. Не проще ли хранить параметры в одном месте? Вы код вообще изучали? Однажды меня лишили премии как раз за то, что выдавалась ошибка. Мне детально пояснили, почему я не прав. И я согласился с аргументами. Выполнение по онлоаду ничем не отличается от данного метода. Все равно запуск функций будет стековым с идентичными последствиями. Напишите метод сильного сочетания. В любом случае за отдельный кусочек кода будет отвечать какой-то компонент. Чтобы привязаться к обработчику onclick данного компонента все равно придется выполнить передачу параметра. Нет разницы как это будет сделано, или же через идентификацию + листенер, или же прямой записью функции в тело onclick обработчика. Например? Давайте ваш пример кода, как модерновый, неархаичный, с чистой и прозрачной логикой и с великолепным результатом в конце. Или все так и будет на уровне светских бесед? На практике все куда хуже. Табы требуют очень сильной абстракции, куда более высокой, чем в моем примере. Потому как вариантов реализации масса.

Смелое заявление. Теория тем и хороша, что только теория. Практика требует куда больших уровней абстракций при работе с кодом. Что есть HTML? Всего лишь контейнер. Контейнер для данных. Количество тегов строго ограничено. А вот названия классов - нет. Именно поэтому абстракция кода на уровне классов - более масштабируемое решение по причинам отсутствия ограничивающих факторов. Это не помойка, это просто альтернативный вариант.

Ваш код как раз показывает, почему я ее отверг. Итак, стоит задача сделать табы разноцветными. Что нужно сделать в вашем коде? Написать новый обработчик. Нужно сделать табы в табах. Что надо сделать? Написать новый обработчик? Переписать код? Нужно усложнить HTML структуру закладки, как того требует дизайн. Что надо сделать в вашем коде? Снова написать новый обработчик. Через пару месяцев интеграции вашего кода в какой-либо интерфейс у вас будет десятка два абсолютно бесполезных обработчиков, разобраться в логике работы которых будет ой как сложно. Вот и получился выигрыш в одном месте, но это пиррова победа. Задели личное самолюбие? Ну извини тогда. На личности я переходить не люблю, поэтому пропускаю мимо ушей попытки втянуть в дискуссии такого характера.

Я сильно упростил решение в JS части, но в HTML - вполне себе нормальная идеология, построенная на идентификации функциональной принадлежности по классам. HTML продиктован сугубо минимизацией затрат на темплейтирование и создание более сложных вариаций и комбинаций.

Кроссбраузерность играет роль сугубо только для сайтов. Для корпоративных интранет и интернет систем - кроссбраузерность почти не играет роль. Попробуйте в государственный сектор продвинуть как стандарт FF. Монополия приносит MS огромный успех. И даже если есть хитрые, быстрые, умные, то это им мало помогает. FF как платформа в десятки раз лучше IE, но, увы, монополия делает "успех" IE. А это вообще зачем? Показать разницу мышления при работе над конечной задачей. И, как результат, абсолютно разный код. Основная задача, которая преследовалась, показать, что ради лучшей масштабируемости и простоты в работе над кодом можно пренебрегать логической разметкой HTML, перенеся логику на CSS-классы. Кстати, с удивлением обнаружил в коде MS POPFLY аналогичный моему подход.

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

Любой из предложенных кодов можно спокойно применить в навигации по сайту. Или я не понимаю сути понятия "навигация по сайту"?

С удовольствием дам пояснения по каждому пункту. > для отсечения IE используется банальный navigator.userAgent.indexOf("MSIE"), то есть любители по-spoof-ить свои юзерагенты заранее идут лесом; Обычно для интерфейсов поддерживать не более 2-х браузеров. Это существенно удешевляет разработку. В требованиях к клиентам фронта серьезных продуктов всегда указывается, какими именно версиями каких именно продуктов нужно пользоваться. > метод getElementsByTagName('*') предполагает, что IE ниже шестой версии отдыхает; И отлично. Сама MS не поддерживает данные версии продуктов. Зачем поддерживать старье? >метасимвол b в регулярном предполагает, что имена классов с дефисами внутри прид?тся выбирать более внимательно; Решается на уровне проектной документации для разработчиков. > do-while предполагает, что при начальном индексе (i), равном нулю, мы можем уплыть в светлую даль вечного loop-a, и почему именно do, и почему снизу; Верно. Запишем как багу. Do-while самый быстрый цикл в JS. > ноды засоряются ненужными данными, которые легко можно держать снаружи Не очень удобно. Особенно если потребуется других компонент доступ к этим данным. Могу пояснить на примере, если надо. > там прилинкован зачем-то свой же родитель, Потому что прописка ноды меняется. А значит и меняется родитель. > имя собственного же класса Потому что никому не запрещено дописать еще классы. И как потом искать? > да болтающийся текст activeTab Не константа. Разные компоненты могут использовать разные классы. > и т.д.) что чревато конфликтами в IE (возможное совпадение им?н в глобальном констексте) Очень серьезная проблема Никто не мешает стоить именование объектов так, как кому нравится. В больших проектах замечательно работает правило именования функций префиксами и наиболее полным отражением сути функций в ее названии. > очень сомнительна необходимость в нетривиальных и бажных dispatchEvent/fireEvent для такой примитивной задачи, как клик по табу; В чем нетривиальность и бажность? Клик - это как раз отправная точка для действий над табами. Поэтому лучше эмулировать клик по табу, проходя стандартную функцию переключения, чем городить огород с дополнительными и универсальными функциями переключения, которым потребуется куча параметров. > повсюду натыканы try-catch, но реальная проверка чего-либо вообще не производится; Нужно сугубо для успокоения клиентов, дабы не раздражать их JS-error'ами, а свести все к банальному "не работает". Инценденты были. А проверку производить собственно не требуется, так как пользователю незачем видеть сообщения об ошибках. >один кусок скрипта во внешнем файле, другой в html Если внимательно посмотреть, то внешний файл - универсальная библиотека. > первоначальная инициализация не по загрузке, а по месту скрипта в потоке, Раздробите файл на куски, как это сделано во всех крупных проектах, и вы поймете, что ничего плохого в этом нет. > обработчики заведены архаично в тегах... И в чем плохость данного метода? А, наверное лучше городить сверху систему идентификаторов для всех тегов, чтобы присваивать нужным тегам банальные обработчики. > общую логику даже не беру в расч?т... Предложите ваш, самый лучший, самый идеальный вариант. А мы посидим и подумаем, чем он хорош, а чем - нет. Если стояла задача написать качественный/reuse-ный/командный/кроссбраузерный/масштабируемый код, то вряд ли. А если ещ? и предположить, что это код коммерческий, то тут пахнет выговором от босса, как минимум... Я сам себе выговор делать не буду. В данном примере ( на компонент это явно не тянет ) стояла задача написать простой в использовании и несложный код. Идеальный код нельзя написать в принципе, только по одной причине - всех вариантов не предусмотреть. Да и не надо это, в самом совершенном коде очень тяжело что-либо понять.

1. Привязка к количеству элементов. Что нужно сделать чтобы было не 3 а 4 вкладки? А если надо будет одну убрать? 2. Код закладок и контента находятся в разных местах. Если нужно будет, чтобы разные компоненты наполняли вкладки, то придется городить дополнительные параметры, чтобы все реализовать красиво. Весь HTML код для вкладки лучше все же хранить в одном месте. 3. Управление через параметр display. Не для всех элементов можно сделать display: block. Это существенно ограничивает гибкость кода. Советую все же разобраться, как работает вариант AKS и как работает мой. Много хороших идей можно вынести.

Dimitry Wolotko, у меня нет холи-вора Я давно уже ни с кем не воюю. Ветряные мельницы давно уже ушли в прошлое. AKS, итак, командный работник - этот тот работник, который заботится не о том, как выполнить свою работу хорошо, а тот, кто решает задачу так, чтобы было хорошо команде. В чем это выражается? В логике работы компонент, в API, в масштабируемости кода. Возьмем к примеру наши два кода. Мой код намного больше в JS части, но он позволяет делать те вещи, которые не предусмотрены в вашем. Например, я могу повесить на закладку собственный обработчик, не напрягаясь всего лишь дописав нужный JS-код. Как разработчик компоненты ( части ) я не привязан ни к каким тегам, мне достаточно указать имя класса и придерживаться всего лишь одного условия - заголовок таба должнен быть прямым потомком контейнера с содержимым таба. На инициализацию можно повесить любой обработчик, что позволило достаточно просто сделать селект с аналогичными свойствами. Опять же, селект уже является частью кода, поэму его просто стилизировать и работать с ним. А теперь посмотрите на свой код? Оцените его гибкость и масштабируемость? А где реализация второй части задания? Я ведь в задании присал "Задача: Сделать табулятор, который помимо обычных табов может переключаться селектом" Именно поэтому я задачу выполнил на 100%, сделав и табулятор, и селект. Кстати, одно из ценных свойств истинно командного разработчика - внимательно и до конца читать задачу. И на 100% ее реализовывать.

С какой же тогда целью Вы, уходя от темы, акцентируете внимание на фактах моей творческой биографии? Да они ведь Вам не были известны, не известны до сих пор, и станут известными никогда! Так что нечего упоминать свои "заслуги перед отечеством", противопостовляя их отсутствию таковых у меня. Пишите по существу! Я не акцентировал внимание, я констатировал факт. Можно хоть всю жизнь проработать в команде, но не быть командным работником. Можно всю жизнь наступать на одни и те же грабли, но так и не понять, почему так происходит. Чем больше опыта - тем больше приоритеты смещаются в совершенно другое русло. Это я и указал. Все остальные домыслы - плод воображения. А теперь вернемся к нашим "баранам" main.css body { font-size: 8pt; font-family: tahoma; } .hiddenBlock { display: none; } .tabContent { background: #f5f5f5; border: 1px solid #ccc; padding: 10px; } .tabSwitch { text-decoration: none; border: 1px solid #ccc; border-bottom-width: 0px; background: #e5e5e5; padding: 0px 5px; margin-right: 3px; } .superTab { background: #f5f5cc; } .activeTab { font-weight: bold; background: #ccc; } lib.js IE = (navigator.userAgent.indexOf("MSIE") != -1); matchClassName = function (node, className){ try { var re = new RegExp ("b" + className + "b", "gi"); return ( node.className.match(re)); } catch ( e ) { return } } applyClassName = function (node, className, state ){ try { var re = new RegExp ("b" + className + "b", "gi"); if ( state ) { if ( !node.className.match(re) ) node.className += (" " + className); }else{ node.className = node.className.replace(re, ""); node.className = node.className.replace(/s+/gi, " "); } } catch ( e ) {} } dispatchEventForElement = function ( node, eventType ) { try { if(!IE){ var evt = document.createEvent("MouseEvents"); evt.initMouseEvent(eventType, true, true, window, 0, 0, 0, 0, 0, false, false, false, false, 0, null); node.dispatchEvent(evt) }else{ node.fireEvent("on"+eventType); } } catch ( e ) {} } getElementsByClassName = function ( container, className ) { var tmpArr = []; try { var nodeList = container.getElementsByTagName( "*" ); var i = nodeList.length; do { if ( matchClassName( nodeList.item( i-1 ), className ) ) tmpArr.push( nodeList.item( i-1 ) ); } while ( --i ); } catch ( e ) {}; return tmpArr; } getInnerText = function ( node ) { try { if ( IE ) return node.innerText; else { var range = document.createRange( ); range.selectNodeContents ( node ); return range.toString();; } } catch ( e ) { } } И сам код <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> <html> <head> <title>Demo</title> <script type="text/javascript" src="lib.js"></script> <link rel="stylesheet" type="text/css" href="main.css"> </head> <body> <div id="tabBox"> <div id="tabSwitchContainer"></div> <div class="tabContent"> <a href="#" onclick="switchTab( this ); return false;" class="tabSwitch superTab"><i>Tab</i> 1</a> Tab 1 Content </div> <div class="tabContent"> <a href="#" onclick="switchTab( this ); return false;" class="tabSwitch activeTab">Tab 2</a> Tab 2 Content </div> </div> <p><select id="linkedSelect" onchange="dispatchEventForElement( this.options[ this.value ].linkedNode, 'click')"><option> </option></select></p> <script type="text/javascript"> <script type="text/javascript"> tabInit = function ( tabBoxID, tabSwitchContainerID, switchID, activityID, initHandler ) { try { var tabBoxNode = document.getElementById( tabBoxID ); var tabSwitchContainer = document.getElementById( tabSwitchContainerID ); var switchNodesList = getElementsByClassName ( tabBoxNode, switchID ); var activeTab = switchNodesList[ 0 ]; for ( var i = switchNodesList.length; i--; ) { switchNodesList[ i ].options = { linkedNode: switchNodesList[ i ].parentNode, tabSwitchContainer: tabSwitchContainer, switchID: switchID, activityID: activityID } tabSwitchContainer.appendChild ( switchNodesList[ i ] ); if ( matchClassName ( switchNodesList[ i ], activityID ) ) activeTab = switchNodesList[ i ]; } dispatchEventForElement ( activeTab, "click" ); if ( initHandler ) initHandler ( switchNodesList ) } catch ( e ) { alert( "Sorry, an error occured." ) } } switchTab = function ( node ) { try { if ( !node.options ) { do{ node = node.parentNode; } while ( !node.options ) } var opts = node.options; var tabSwitchList = getElementsByClassName( opts.tabSwitchContainer, opts.switchID ); for ( var i=tabSwitchList.length; i--; ) { applyClassName ( tabSwitchList[ i ], opts.activityID, tabSwitchList[ i ] == node ); applyClassName ( tabSwitchList[ i ].options.linkedNode, "hiddenBlock", tabSwitchList[ i ] != node ); } } catch ( e ) { alert( "Sorry, an error occured." ) }; } fillInLinkedSelect = function ( nodeList ) { var selNode = document.getElementById ( "linkedSelect" ); selNode.options.length = 0; for ( var i = nodeList.length; i--; ) { var tmpOption = new Option( getInnerText ( nodeList[ i ] ) , nodeList.length - i - 1 ) tmpOption.linkedNode = nodeList[ i ]; selNode.options [ selNode.options.length ] = tmpOption; } } tabInit ( "tabBox", "tabSwitchContainer", "tabSwitch", "activeTab", fillInLinkedSelect ); </script> </body> </html> P.S. Я реализовал задачу на 100%. Мало того, в моем варианте абсолютно все равно, какие теги будут использоваться.

Стандартная "форумная возня". Один говорит о правильном структурировании данных, другой - совсем о другом, о дешевизне и простоте в разработке (ох уж эта меркантильность!). Что есть правильное структурирование данных? Логичесткое представление в HTML? У меня логическое представление перенесено на классы. Смотришь на классы и видишь истинное предназначение данного блока. Чем не правильное структурирование? Ах да, я забыл, правильно списки делать только при помощи UL, OL, DL, и ни-ни использовать что-то другое. 1. Я тебе не затыкал рот. 2. Аргументов у меня хватит, но вот будут ли мои аргументы для тебя значимы? Или будем и дальше повторять стандартные фразы из стандартных книжек? Очень просто. Сделать два варианта - один ортодоксальный, при помощи DL, а второй - с полным нарушением принципов HTML. Потом сравнить оба варианта. Я свой выложу последним, чтобы не было копирования идей.

Не понял вопроса. Удалять нужно хотя бы потому, чтобы уменьшить количество обрабатываемых нод до минимума. Это влияет на скорость работы. А в моем случае используется почти любой контейнер и самая примитивная функция appendChild. Выигрыш как раз нулевой. И чем больше проект, тем минимальнее становится эффект логической разметки. Хочешь проверить? Уже на одной задаче будет усложнение. А если задач несколько, и все они работают с данным кодом, то усложнение будет расти в неприличной прогрессии. Чем проще код - тем дешевле. Про разбирательство знающими людьми: ты явно не работал над реально сложными проектами. Особенно над теми, где работало несколько человек. Для интерфейсов важно не well-formated, а дешевизна в разработке. Иногда приходится использовать свои атрибуты, которые не проходят валидацию, но с ними проще работать. Дабы не быть голословным и дальше, предлагаю провести мааленькое соревнование. Задача: Сделать табулятор, который помимо обычных табов может переключаться селектом. Красивости не нужны. Сугубо функционал. Принимаешь участие в соревновании?

> Наличие портфолио. Не факт, что человек его сделал сам. > Умение принимать решение. Я принял решение не связываться с вами. > Умение делать не только сайт, но и часть. Что существенно удорожает разработку. > Умение писать не только в Web 2.0, но и в предыдущей версии. Да кому нужны такие продукты? > Умение сочетать версии на одном сайте (чувство стиля). Странное требование. > Желание заработать, а не хапнуть. Мое желание заработать вам будет очень дорого стоить. Ведь я не как новичек оцениваю стоимость работы. > Понимание обязательности соблюдения сроков сдачи работы. Но куда лучше просто умение соблюдать сроки. А то, что человек это просто понимает не улучшает качество и количество. Итак, самый главный вопрос, а чем же собственно должен заниматься тот, кому интересна разовая удаленная работа?

2 из 10 Тупо две сардельки посреди монитора.

Через много лет программирования под HTML я пришел к одной очень простой истине. Все то многообразие тегов практически невостребовано в интерфейсах. Поясню почему. Порой сложность конструкции требует многократного вложения элементов. Порой требуется перенос содержимого с одной части дерева в другую. Все это нивелирует важность логического оформления кода, и банально начинает сводиться к нескольким тегам: DIV, SPAN, A, TABLE (и все запчасти), IMG. Логическая же часть перекладывается на классы. AKS, в твоем варианте потребуется удалять лишние DT, а вместо них создавать A. Перенести же куском можно только в аналогичный DL. В моем варианте ничего удалять не требуется. Ты выиграешь на логике кода, зато проиграешь в скриптовой части, что создаст усложнение кода. А разбираться в нем через определенное время становится все сложнее и сложнее. Так что готов поспорить, что предложенные варианты - лучше, удобнее для разработчика.

Как бы это делал я. Самое первое правило - код одного таба должен быть описан в одном месте. Это улучшает восприятие и уменьшает количество будущих багов. Что это значит? Рассмотрим пример <div id="tabBox"> <div id="tabSwitchContainer"></div> <!-- <= в этот контейнере будут закладки --> <div class="tabContent"> <a href="#" onclick="switchTab(); return false;" class="tabSwitch">Tab 1</a> Tab 1 Content </div> <div class="tabContent"> <a href="#" onclick="switchTab(); return false;" class="tabSwitch">Tab 2</a> Tab 2 Content </div> </div> Потом создаем простую функцию инициализации нашего таба. 1. Найти контейнер с id="tabBox" 2. Найти контейнер для закладок ( id="tabSwitchContainer"); 3. Найти все элементы, у которых среди имени класса встречается tabSwitch (/btabSwitchb/gi) 4. Каждой найденной ссылке присвоить параметр linkedNode, который равен parentNode ссылки. Это нужно для того, чтобы установить связь переключателя с блоком с контентом. 5. Перенести ссылку в контейнер для закладок (appendChild) 6. Функция switchTab находит все элементы, которые имеют в имени класса строку tabContent и присваивают класс hiddenBlock ( display: none ) Для элемента, который равен linkedNode, класс hiddenBlock удаляется. В чем преимущества данного варианта - блок монолитный, спокойно навешивается дополнительная логика в одном месте, а не в нескольких. - не требуется сложные схемы идентификации разлычных блоков. Переключатель работает через присвоенный параметр linkedNode. Код не привожу специально.