Николай В., почитайте про каскад в CSS.
Таблица стилей должна быть примерно такой:
li a {color:#F00; font-size:15px;}li ul li a {color:#000; font-size:14px;}
А в HTML либо так (вполне семантично, но не всегда удобно):
<ul> <li> <a href="#">Item</a> <ul> <li><a href="#">Subitem</a></li> </ul> </li></ul>
Либо вот так - бывает полезно при более сложных стилях, т.к. позволяет отдельно прописывать стиль для LI верхнего уровня.
<ul> <li> <a href="#">Item</a> </li> <li class="sublevel"> <ul> <li><a href="#">Subitem</a></li> </ul> </li></ul>
http://www.w3.org/TR/html40/struct/lists.html#edef-UL
ХЗ, пример к изречению "Lists may also be nested" помечен как DEPRECATED.
Способы хранения деревьев в базах данных в вики на phpclub.ru - весьма рекомендую.
Сам в основном использую Adjacency List (т.е. сохранение parent id), в основном из-за простоты и стабильности. У Nested Sets основная беда случается, когда вставляешь узел куда-нибудь в середину дерева, т.к. приходится переписывать смещения у всех узлов правее нового узла, а при больших базах это о-о-о-очень долго.
Сейчас пытаюсь (очень аккуратно, и, пока, безрезультатно) комбинировать Adjacency List и Nested Sets. Есть мысли в двух направлениях.
Во-первых, можно на Nested Sets организовать только часто доставаемую иерархию, а прочие объекты присоединять по parent id. Например, если речь идет о магазине, структура разделов (которых редко бывает больше двух сотен) выстраивается на Nested Sets, т.к. ее часто нужно выводить целиком, а товары присоединяются паренту (т.к. чаще всего одним запросом достаются товары определенной категории). Но при этом, например, теряется преимущество Nested Sets на удалении, товары придется удалять в несколько запросов.
Во-вторых, в некоторых случаях бывает нужно работать с достаточно глубокой структурой, которая, при этом, постоянна. Для таких случаев я пытаюсь сделать возможность хранения отдельных ветвей дерева на Nested Sets. Правда, послднее время склоняюсь к тому, что это не очень нужно и не очень выполнимо =)
Кстати говоря, пара замечаний насчет рекурсии при подходе Adjacency List. Во-первых, в рекурсивных запросах нет ничего страшного. Как правило, запросы идут довольно простые запросы, и редко их бывает очень много. Во-вторых, в критических ситуациях проблема решается кешированием (если ваша система поддерживает помодульное кеширование). В-третьих, где-то на форуме Котерова (во, нашел топик, он живет здесь) предлагали довольно оригинальное решение. Суть такая, что для каждого узла можно сохранять уровень вложенности. Тогда, например, чтобы вытащить всех родителей узла, достаточно level раз приджойнить табличку со структурой саму к себе по полу parent. Сам не тестил, но идея занятная.
PS. Справедливости ради, стоит заметить, что есть еще подход Materialized Path. Мне он показался кривым и неэффективным, однако, возмжно натолкнет кого-нибудь на правильные мысли =)
Сам сайт не смотрел. У четырех случайно взятых морд в бэках сидят линкаторы. Еще у одной - pagerank сомнительного происхождения. Может в этом дело? =) Смотрите внимательнее, откуда морда берет показатели.
PS. Топик в мемориз, за рекордное количество грамматических вариаций на тему слова "пессимизация" =)
Про переколдовку аля "что такое" euhenio еще год назад писал (см. коммент в конце). Правда, у него "фиговина" определена э... несколько более конкретно =)
ХренРедькиНеСлаще, е-мае, Вы серьезно что-ли? Люди в поисковую строку яндекса адреса сайтов вбивают, потому что не знают, что его можно прямо в браузер вбить. И так еще долго будет. А Вы им хотите про переколдовку рассказать, про мягкость, да? Спуститесь на землю =)
P.S. Че-то с этим апдейтом все с ума посходили. Ну нафиг, спать пойду.
ХренРедькиНеСлаще, кондиционеры да окна не мы ищем, а простые пользователи. Где им научиться? Разве что Игорь Минович начнет бесплатные лекции на стадионах читать, о пользе поисковых операторов Яндекса =)
Кроме того, последние месяца 3 на основе расширяющих операторов (&&) можно буквально делать новый сервис - поиск по дорам (с). Уж не знаю, доров ли стало больше, или Я работать стал хуже.
Ну, вообще неплохо было бы взглянуть вот на эту расшифровку - подробно объясняется, кого когда и за что "забанили". На самом деле эти романы изымались в отдельных учреждениях отдельных штатов в разные годы 20 века. Так что не вижу повода для столь глобальных обобщений.
wilelf, поглядите
вот это, вот это, и особенно вот это. Списочек довольно забавный, а его составление было, по сути, авантюрой с коммерческой подоплекой. Кстати, в результате этого мероприятия, америкосы массово бросились скупать этот списочек, (включая, (о Боже!) 42 banned and / or challenged titles, которые фашиствующие либералы читать строго-настрого запретили). Говорят, за 2 дня был распродан годовой запас Улисса =)
Кстати, предложите свой списочек, это модно =) Да, речь идет только об англоязычной литературе.
www.google.com за 420 баксов - тоже неплохо =)
Хотя, посравнивал с ценами на нескольких линкброкерах, по большей части похоже на правду.
На самом деле, мне кажется, было бы правильнее сделать возможность расстановки коэфициентов вручную, через какой-то GUI. Это ж не формула философского камня, верно?
Буду следить за развитием. Жду учета яки =)
P.S. Грин, с посещаемостью 2 проблемы. Во-первых, одна и та же цифра может быть и "очень много", и "очень мало", в зависимости от тематики. По всяким некоммерческим темам бывают сайты с очень хорошими показателями, кучей настоящих бэклинков, и 10 хостами в сутки - потому что в сети просто мало народа интересуется вопросом. И, во-вторых, не всегда понятно, как эту посещаемость выдирать, много где счетчики без циферок.
Провалился один пациент. Не очень конкурентный запрос, сайт долго сидел на 3 месте. Вчера прикупил 2 средненьких морды. Сегодня обе проиндексированы, а сайт на 14 месте =) У сайтов впереди бэки явно слабее, вылезло несколько почти "голых" новичков.
Есть подозрения, что Я крутит параметр минимального передаваемого веса ссылки. Т.е. помоечные (обменные, каталожные) ссылки перестают рулить. Война бюжетов плавно перетекает в войну ресурсов =)
СКОРПИОН, тот же код, но в несколько раз короче. Хвала тернарному оператору =)
function $(node) {return document.getElementById(node);} function showInput(sel) { $('__file').style.display = (sel.value == 'video') ? 'block' : 'none'; $('__text').style.display = (sel.value == 'video') ? 'none' : 'block'; }
Ну и вызывать так: onchange="showInput(this);"
Обычно с таким кодом проблем меньше, хотя, конечно, кому как удобнее =)
