s0rr0w

Flash? Этот умеет сам на все окно разворачиваться.

Строго определенный элемент? Ключевое слово не строго, а определенный. Т.е. с конкретным именем. Не Вася, Петя, Маша, а только все Пети.

Зачем понадобилось такое окно?

Да

А зачем?

1. Использовать якоря. Нажал на кнопарик - страница не просто перезагружается, но еще и передается имя якоря. 2. Использовать AJAX и другие новомодные технологии.

Что не понятно? У тебя есть одноуровневый список элементов. Неважно каких. :nth-child выберет любой элемент из этого списка по формуле an+b и присвоит ему нужный стиль. Например, твоя формула 4n, итерация начинается с 0, то 4*0 = 0. Такого элемента нет в списке, поэтому применять стили не к чему. Следующий элемент - 4й, потом 8й и так далее. Если твоя формула 2n+1, то на 0й итерации применять нужно к 1-му элементу, на 1й к 2*1+1 = 3-му элементу и так далее. :nth-child от :nth-of-type отличается тем, что последний применяет формулу только для строго определенного элемента, а не для всех подряд.

Я сюда почти не заглядываю, поэтому не отвечаю особо. Сильные стороны оракла не привлекательны с точки зрения простых решений, но весьма удобны и продуманны в корпоративном применении. Допустим, взять ту же фичу, что Oracle достаточно правильно работает с XML, и мало того, он еще умеет индексировать содержимое этого XML и обращаться к нему как к таблице. Разбивка данных на партиции, горизонтальное и вертикальное компрессирование партиций позволяет серьезно ускорить работу вашего софта, используя при этом меньше места. При правильном дроблении информации можно достигать многократного прироста производительности. Криптование данных сделано достаточно толково и серъезно не нагружает систему. Real Application Cluster - вот эта фича достойна похвалы. Кастеризация продукта позволяет наращивать производительность системы без особых проблем. Чтобы нормально использовать кластерное ПО, желательно устанавливать Automatic Storage Management. Эта фича позволяет управлять множеством типов дисковых хранилищ, эффективно работать с базами, оптимизировать производительность всей дисковой подсистемы. Ну и особой похвалы достоин PL/SQL. Хоть он и дубовый в некоторых вещах, но позволяет сделать самое главное - перенести логику из приложения в базу. Что это дает на практике? Вам не нужно делать 10 запросов, достаточно сделать один. Компиляция кода позволяет ускорять выполнение кода на стороне сервера. Порадовал мониторинг системы. Можно достаточно быстро проанализировать состояние всей базы, состояние оракла, как выполняются запросы, сколько памяти требуется и так далее. Тюнингом можно заниматься практически вечно. Глобальность оракла уже такова, что появилось разделение на DBA (администраторы) и DBP (программисты). Администраторы следят за производительностью и занимаются тюнингом, программеры пишут код. Для оракла не проблема отдавать данные в виде json. Что это значит на практике, думаю, пояснять не стоит. Это с наскока что первое в голову пришло.

Ага, сейчас, так прямо и разбежались писать готовый код. Держи карман шире. Могу рассказать, чего нужно, чтобы это работало. Нужно сначала указать обработчик onload для документа фрейма, по которому он будет смотреть свойство offsetHeight, и данное свойство указывать тегу iframe через style

Говорю, обращение к $("#randomPost") идет до того, как этот элемент <li id="randomPost"> будет загружен на странице

3. Думаем как машина. Это может звучать странно, но умение думать как машина может спасать шкуру хорошего кодера не один раз. В первой статье я акцентировал внимание на том факте, что при сборке интерфейсов недопустимо использовать приемы, которые можно использовать в сайтах. Пришло время рассмотреть некоторые из них. Это не полный список, но достаточная пища для размышления. Разумная уникальность Дизайнеры очень любят рисовать то, что красиво выглядит. Работа у них такая. А вот кодер должен быть тем Цербером, который не дает дизайнеру интерфейса слишком разгуляться. Потому что нарисовать изменения, зачастую, требует получаса работы, а внести изменения в код всего продукта, протестировать, внести все исправления и удалить недочеты - две недели. Почему так долго? Да потому что нельзя вносить слишком много уникальных правок в код. Это сильно фрагментирует его и приводит к трудноуловимым ошибкам. Возьмем простой пример. В одном модуле дизайнер сделал кнопки без иконок, но во тридцать втором понадобилось сделать меню именно с иконками. Решать данную проблему можно многими способами. 1. Сделать новый стиль и структуру кода для данного дизайна, старый код и стиль оставить как есть. 2. Сделать новую структуру и новый стиль, но внести изменения во все участки кода. Для вебсайтов вполне подойдет и первый пункт. Для интерфейсов только второй. Какая разница? Сайт обновляется в разы медленнее чем интерфейс. Главное на обычном сайте - контент, а в интерфейсе - сам интерфейс. Поэтому наиболее дешевый вариант будет внесение изменение кода не только в один модуль, но и во все последующие. Потом изменение оформления будет идти в несколько раз проще, потому что будет один код для всех меню во всем проекте. Однако, бывают случаи перегиба палки. Попытка все менюподобные компоненты загнать в одну структуру кода и дизайна приводят к прямо противоположному эффекту. Код не упрощается, а неимоверно усложняется, и, примерно, на 80% начинает состоять из исключений. Про быстрое исправление ошибок в таком коде не может быть и речи. Итеративность кода Код, который делает кодер, используется в дальнейшем во всевозможных темплейтах системы. И часть логики кода должна быть продиктована данными и способом вывода этих данных. На практике это значит, что если какой-то блок кода повторить несколько раз, то ничего не должно поехать и не должно посыпаться. По возможности, нужно избегать вариантов, когда определенный стиль назначается последнему элементу. Лучше, если уникальный стиль будет назначаться первому элементу, а еще лучше - вообще не делать уникальных стилей. Любые повторяющиеся элементы должны иметь такую структуру и такое стилевое оформление, чтобы без проблем переноситься в разные участки кода. Возьмем простой пример, который изображен на скриншотах выше. Нам необходимо сделать тень для плашки заголовка, тень для бокса меню, и тень для самой плашки с контентом. Как это лучше всего собрать? Первое, что приходит в голову, это тень от заголовка поместить к самому заголовку. Тень от меню - в контейнер к меню. С этим вариантом есть проблемы, так как под заголовком может быть как меню, так и просто контент. Первое, что приходит в голову, это сделать два разных стиля с тенью под плашкой с заголовком. Но это очень плохое решение. Заголовок может не "знать", какой именно блок находится после него. Перекладывать это на программную часть очень плохо. Зато можно изменить условия задачи, и перенести уголки и тень в блок, который "знает", какого цвета его фон. Т.е. плашка под заголовком будет иметь ровную линию внизу, а уголки и тень будет формировать тот блок, который находится под заголовком, ему достаточно иметь отрицательное смещение margin-top. Вуаля! Таким простым изменением поведения блока мы серьезно облегчили задачу программисту, ведь теперь ему не нужно думать про логику вывода блока, а достаточно просто выводить его. Мы облегчили задачу серверу, потому что ему не не нужно обрабатывать дополнительный код. Мы сделали код чище и понятнее, а это самое главное. Модификаторы вместо глобальных конструкций Многие любят глобальные конструкции в коде. Что это значит? Это значит, что стиль задается некому контейнеру, который всем своим подчиненным элементам рассказывает, как они выглядят и какое их поведение. Это вполне себя оправдывает для сайтов, но губительно для интерфейсов. Все дело в том, что решения в интерфейсе очень часто повторяются, наследуются и перекрываются. Если вы определили стиль, например вот такого плана .menuBlock UL LI { color: green } то добавить модификатор к LI в этом стиле потребует указания полного пути, чтобы сохранить специфичность. Как итог - километровые, запутанные, тяжелые для отладки, css-файлы. Пусть лучше пользователь получит чуть больше текста, но ваш код будет работать без ошибок, и вы не будете тратить время на исправление хитромудрых зависимостей в стилях.

Скрипт вызывается до того, как контейнер будет вставлен в DOM-дерево?

Тут спецов скорее всего нет. Они есть на sql.ru (кажется правильно написал). С ораклом все гораздо сложнее, чем с тем же мускулем. Он очень глобальный. Некоторые вещи там продиктованы именно этой самой глобальностью. Читать следует то, что больше всего нужно в работе или каком-либо проекте. По мере роста количества знаний будут расти и потребности в этих самых знаниях. Самое главное, с чего следует начать, так это с курсоров. Это сугубо мои ощущения. На мускуле писать мегасерьезные и глобальные вещи - себя не уважать. Мускуль был, есть и будет базой для простых веб-страничек и средненьких систем. Если интересно, могу более подробно рассказать про возможности оракла.

Вам очень хочется найти скрипт? Так кто мешает искать? Ищите, мы разрешаем!

Картинкой можно сделать. Одной большой картинкой. Как и приведено в примере.

Про метод я имел в виду данный подход, когда берется именно innerHTML. Советую попробовать сделать вот так <option value="1"><!-- Comments here -->opt 1</option> И выбрать его. А потом заменить innerHTML на text.

Потому что это не очень хороший метод. Содержит текст, который написан в теге: <option>вот этот текст</option>

Оставлять прозрачные края.

А в чем трудности с таким дизайном? Главное сделать следующее: 1. Исследовать, отличаются ли по цвету градиент верхней кнопки от нижней. Если отличаются, то сделать все виды кнопок в одном файле. 2. Распологать все кнопки абсолютно отпозиционированно, с заданной шириной и высотой 3. Padding кнопки выставить минимальным, чтобы по вертикали и по горизонтали он был примерно одинаковым. 4. Текст внутри кнопки центрировать относительно блока кнопки 5. Картинки для конопок положить в виде фона для того же span'a

От селекта подымаемся по дереву вверх на одну ноду, потом в этом контейнере ищем элементы с именем "input", берем нулевой элемент по списку, его полю "value" присваиваем текст того опшина селекта, который на данный момент выбран. Уточнение. Брать innerHTML у опшина жестоко. Для этого есть свойство text.

А что в этом файле на первой строке стоит?

Так низзя. Это не полиграфия.

Установите FireBug или ему подобные виджеты, выберите картинку, посмотрите весь css, который присваивается данной картинке.

В вашем незнании матчасти. В CSS это свойство было переопределено.

Можно всевозможными способами. Какая цель?