s0rr0w

p { margin: 0px; }

Скопировать код с приведенной страницы

Правила форума гласят, что это не место, где на халяву пишут скрипты. Поэтому или вы планы на счет JS меняете и приступаете к самостоятельному изучению, или я переношу тему в раздел коммерческих услуг.

Подводные камни При всей кажущейся простоте интерфейсов, сложностей в сборке там гораздо больше. Возьмем простой пример. Изначально дизайнер набросал вот такой простой вариант: А потом его расширил до вот такого: Ничего сложного, скажете вы. Это верно, сложного тут ничего нет. Как я уже писал выше, первым делом изучаем дизайн с целью нахождения зависимостей, исключительных ситуаций и прочего. Именно с изучения объекта порезки должен начинать любой уважающий себя верстальщик. Для начала стоит классифицировать все объекты, чтобы проще было определять зависимости. Итак, что мы видим? 1. Плашка. Самый корневой элемент нашего дизайна, это плашка. Плашка состоит из множества других логических элементов дизайна. На что стоит обратить внимание? * Закругленные углы. Их можно реализовывать множеством способов, но нам нужно будет выбрать тот, который позволил бы максимально быстро добавлять дополнительные элементы без особых проблем. * Ширина плашки. В интерфейсных решениях лучше не использовать фиксированные размеры элементов, поэтому по умолчанию выбираем "резиновую" ширину плашки. Исключения, конечно же бывают, но лучше предусматривать максимум сразу и облегчать вариант потом, чем предусмотреть упрощенную версию изначально, а потом все переделывать. Исходя из дизайна, перед верстальщиком должны возникнуть два вопроса: а) Входит ли в ширину плашки загогулина в заголовке, или нет. б) Как должны позиционироваться другие плашки без загогулины относительно данного дизайна плашки. Верстка еще не началась, а у нас уже есть два вопроса к дизайнеру. Чем раньше они решатся, тем меньше переделок и проблем будет в конце. 2. Заголовок плашки. Тут возникает целый ворох проблем. Дизайнер поленился, и нарисовал самый идеальный вариант, но мы умеем смотреть в будущее и добавляем вопросы. * Длинный текст заголовка. Что будет, если текст заголовка будет в две строки? * Загогулина. Принадлежит ли загогулина логически заголовку, или же всей плашке? * Тень под заголовком. Этот вопрос будем рассматривать ниже, так как решение лежит за пределами компетенции дизайнера. 3. Панель кнопок и кнопки. * Дизайн состояний кнопок. Кнопки имеют несколько состояний, нужны варианты всех доступных состояний: hover, active, usual. * Расположение кнопок. Кнопка в данном дизайне одна, и важно знать, как будет выглядеть наш макет при двух и более кнопках. * Позиция панели кнопок. Может ли панель кнопок на других макетах быть не только справа, но и слева? 5. Панель табов. Тут все более-менее понятно, за исключением пары вопросов * Много табов. Как должен вести себя макет, если будет очень много табов? Выделение активного таба визуально привязывает его к контенту, поэтому перенос табов на новую строку категорически противопоказан. Если же делать скроллируемые переключатели табов, то как минимум не хватает дизайна с управляющими элементами. * Дизайн состояний активаторов табов. На дизайне не показано, как будет выглядеть hover-состояние на неактивном и активном активаторе таба. 6. Контентная область. Тут нужно скрупулезно полазить с линейкой, чтобы определить отступы от границы блока. Визуально первый пункт меню расположен вровень с заголовком справа, но бокс начинается гораздо выше. С контентной областью особых проблем не должно быть. 7. Две колонки. Это тоже логический блок, наравне со всеми остальными. Добавляем в общую копилку вопросов к дизайнеру еще парочку. * Пропорции колонок. Пропорции колонок должны быть резиновыми или левая часть должна быть статической? Какие еще пропорции могут встречаться? * Зеркальные колонки. Могут ли колонки быть в зеркальном отображении? Это важно при выборе вариантов кода для решении данной задачи. 8. Дерево Я думаю, что все уже догадались, что в данном блоке есть проблемы с различными состояниями элементов дерева, есть недостача графического оформления - не указан вид свернутого дерева с подкатегориями и так далее. Я намеренно оставляю парочку неописанных логических элементов, чтобы вы самостоятельно изучили дизайн и научились предвидеть проблемы, которые могут возникнуть при сборке. После определения логических элементов и решения вопросов с дизайнером можно приступать к следующей фазе продумывания: поиску закономерностей и выбору вариантов реализации. Но это будет в следующей статье.

Самый кроссбраузерный способ.

"Навешивание" происходит сразу после присвоения функции. Контекст у этих функций один, поэтому обработчик находит i в контексте той функции, которая присваивала этот самый обработчик. При замыкании функция не вызывает сама себя. Она просто сохраняет контекст. И не факт, что обращение к свойствам будет дольше. Есть бенчмарк, который это подтвердит?

Дизайн нужен. Потому что приведенный пример не учитывает 1. Как ведет себя бокс, когда ему не хватает места справа? 2. Минимальная и максимальная ширина бокса? 3. Как ведет себя бокс, когда ему не хватает места снизу? 4. Минимальная и максимальная высота бокса? 5. Какие элементы кроме маленького кружочка с буковкой могут служить активатором данного попапа? Без ответов на данные вопросы я даже и пальцем не пошевелю в сборке.

Вы все не теми категориями мыслите. Поведение элемента и его дизайн определеяет структуру HTML.

100$ в час - разжевывание и....

Потому что происходит схлопывание отступов

По заказу веб-трудящихся, решил написать ряд статей о том, какие задачи и трудности возникают перед веб-разработчиком при работе над интерфейсами. Я постараюсь приводить практические примеры, но в большинстве своем это будет теоретический материал с минимумом готовых решений. Это не потому, что мне жалко поделиться готовыми решениями, это делаю намеренно, чтобы любой читатель задумался над проблематикой и попытался прийти к некому решению самостоятельно. Мне не нужны последователи, мне нужны конкуренты. Для начала хотелось бы составить список отличий подходов и приемов, а также уровень решаемых задач для простых сайтов (пусть даже и порталов), и веб-интерфейсов. Целью практически любого сайта является донесение контента до пользователя. Контент может быть как текстовым, так и графическим, имиджевым. Цель любого интерфейса - удобство пользования, предсказуемость, быть интуитивно понятным. Дизайн тут играет вспомогательную роль, а не основную. Особые отличия возникают и в интеграции веб-интерфейса с серверной частью, и то, что допустимо при сборке сайтов, может быть вообще недопустимо для сборки интерфейсов. Мы обязательно разберем это на примерах, но это будет позже. Особое внимание хочу акцентировать на том, что при разработке сайта кодер может допускать больше вольностей в сборке, иногда прибивая что-то "гвоздиком". Такая тактика при сборке интерфейса не только пагубна, но еще и экономически неэффективна. Экономическая эффективность должна быть поставлена во главу всей сборки. Если на сайт можно потратить пол года, то на интерфейс достаточно большой системы нужно потратить гораздо больше. Если сайт в будущем может долгое время не переделываться, то интерфейсы переделываются постоянно. В процессе создания какого-то продукта возникают новые, более удобные решения, которые в последующем распространяются на остальные части интерфейса. Постоянные переделки должны выполняться с минимальными трудозатратами, иначе продукт может никогда не выйти из состояния глубокой альфа-версии. Чтобы минимизировать эти затраты, кодер должен выработать стратегию разработки. Стратегия разработки - это набор неких условий и договоренностей, которые принимают разработчики в процессе работы над проектом. Сюда включаются типы документов, правила форматирования кода, именования классов, структурирования документа, правила именования переменных и файлов и так далее. Это должен быть свод правил, которых должны придерживаться все в команде. В противном случае продукт превратится в кашеобразное нечто, поддерживать которое будет просто экономически невыгодно. Продукт будет сыпать багами, исправление которых будет порождать новые и новые баги. Пользователи будут не в восторге от вашей работы, и если в сайтах недочет может никто и не заметить, то в интерфейсе на него будут постоянно натыкаться. Стратегии разработки будет посвящено несколько статей. Еще одну проблему стоит затронуть - это универсализация кода. Любую задачу можно решать разными способами. Наример, человеку нужно почистить картошку, и ему нужен для этого инструмент. Вы можете дать ему специальный нож для чистки картофеля, а можете дать завод по чистке любых овощей и фруктов, а не только картофеля. Нож является решением в лоб, завод - универсальным решением. Задача кодера - балансировать между этим двумя крайностями в виде самого простого решения и самого универсального. Так как интерфейсы постоянно переделываются, то хранение для каждого типа овощей своего ножа может быть выгодно только на первых порах разработки. Дальше потребуются более универсальные решения, еще дальше - еще более абстрактные и универсальные. Только с опытом придет понимание, какое решение применять в каждом конкретном случае, чтобы не закапываться в самом начале в суперуниверсальные решения. Универсализация может сыграть злую шутку с любым разработчиком. Еще одна проблема в любой разработке - недостаток информационных потоков между разработчиками. Затрагивать эту тему мы будем потому, что она напрямую влияет на качество кода. Очень часто проблемы вызывает то, что кодер считает себя конечным звеном разработки: дали задание, собрал и забыл. Это пагубная практика. Перед любой сборкой нужно думать. Много думать, моделировать в голове будущую сборку. Если кодеру что-то не нравится в дизайне, нужно садиться с дизайнером и оговаривать все ньюансы перед сборкой. Многие проблемы можно обходить еще до начала сборки, ведь проще перерисовать пару элементов, чем переверстывать тонны кода потом. Аналогично обстоят дела и с другой стороной медали - программистами. Если вы сделали что-то эдакое, которое требует от программера дополнительных переменных или условий, вы должны идти к нему и обсуждать эту проблему. Если это не сделать сразу - потом вы будете переделывать работу по несколько раз за свой счет, срывая сроки и недосыпая ночами. Мы плавно подошли к тому, что перед любой сборкой нужно внимательно изучать то, что нарисовано. Нет ничего страшного, если вы будете час переставлять линейки в графическом редакторе, изучать прошлые дизайны, код, который был уже сделан. Если этого не сделать на начальном этапе, то ваша работа может быть напрасной. Думать, думать, и еще раз думать. Вот девиз настоящего кодера. Вот краткий перечень вопросов, над которыми я обычно думал: * Какие первые потенциальные проблемы могут возникнуть при сборке? * Какие закономерности можно выявить в дизайне, и как их можно систематизировать? * Какие исключения из закономерностей есть, можно ли ими пренебречь? * Достаточно ли информации представлено на рисунке, чтобы выполнить все задание? * Какое поведение должно быть у каждого из элементов? На последнем вопросе остановлюсь чуть поподробнее. Поведение элементов диктует код. Например, есть некий элемент, который может иметь резиновую ширину. Но в дизайне все сделано так, что при больших или малых разрешениях, элемент может вести себя совершенно не так, как ожидается. С другой стороны, есть вещи, которые очень трудно сделать без ухищрений или совершенно злобных хаков. Проще отказаться от хитромудрого поведения, чем собирать нечто монстроидальное, которое будет рассыпаться при первом же изменении базовых условий. Это не все, что будет рассмотрено в будущих статьях, развивать тему будем по мере проявления интереса к определенным моментам.

Фотошоп и формат psd сокращают время сборки примерно на 5-10%. Знание этого инструмента добавляют еще от 5 до 10% скорости работы.

Надо начинать с изучения инструментария. Серьезно сокращает время работы.

Вы просто не умеете считать свою прибыль.

Нет, чтобы модуль был подключен, нужно рестартить апач. Если дуракам дать такую возможность, то они положат все хостинги.

Только psd и cpt. Остальное в мусорку сразу.

По идее да, можно. Как именно - я не в курсе. Лучше проконсультироваться с хостером. Нужно всего две строчки extension=php_xsl.dll extension=php_mbstring.dll

Баг у вас в голове. Вы выдаете желаемое за действительное. Реалии совершенно другие. Ссылка - inline элемент, картинка - replaced inline элемент. Размер бокса под ссылку определяется высотой шрифта. Размер бокса под картинку - высотой самой картинки. Бокс ссылки не растягивается! Картинка выравнивается внутри бокса ссылки относительно vertical-align. По умолчанию этот параметр равен base-line. Базовая линия проходит под буквой п, л, но есть еще буквы р, у, хвостики которых опускаются ниже базовой линии. Отсюда и отступ. Итак, первая проблема - миф, вторая лечится разными свойствами, и "таблетку" я уже приводил на этом форуме.

На этом хостинге стоит php 5.2, без поддержки xsl и mbstring На моем - php5.3 с поддержкой перечисленного Вывод - сменить хостера или попросить переключить на новую версию php

Документация рулит! http://ua2.php.net/manual/en/function.mb-strtoupper.php Говорить то он говорит, только читать нужно внимательно то, что он говорит. Fatal error: Class 'xsltprocessor' not found Такого класса нет, есть XSLTProcessor.

Сделать функцию с приведенным кодом. Вызывать функцию через getURL("java script:foo()")

Зато удобный и быстрый браузер

IE принципиально не умеет хранить более чем одной области выделения.

Используйте FireFox. Он умеет выделять колонки.

Вариантов два - удалять весь путь или оставлять мусор