WingedFox

И что? Для эффектов -- самое то, что надо. Это утверждение относится и к HTML/JS. =)

А пользовать flash не судьба?

А, ну тогда пеняйте на качество той библиотеки. IE работает с VML достаточно шустро.

IceBars Звиняйте, а когда в IE включили поддержку canvas? =)

Спасибо. За стрелочку будет тягаться чуть позжее =) Модуль с выбранным цветом и печатью разных цифровых значений уже почти готов. Может какие другие цветовые пространства? Наборы цветов из библиотек (пантоны)? Ps: собственно он уже готов и установлен, на очереди, пожалуй, сохранение выбранных цветов в куках =)

в конечном сч?те это делается либо на уровне прямого доступа к видеопамяти, либо посредством вызова спец. функций графического ускорителя. Но никак не через использование тормозного DOM из интерпретируемого языка. Ага-ага. Более быстрые платформы ещ? поискать надо. Если бы IE не был заброшен почти на 4 года, всякие FF с Операми и рядом бы не лежали. Сравните скорость отрисовки достаточно простой тулзы в разных браузерах: http://debugger.ru/demo/projects/colorpicker/

uefa Другой вариант while (el.lastChild) el.removeChild(el.lastChild);

Electra Смотря что они из себя представляют.

Доброго времени суток, Потребовалось тут поиграться с различными цветовыми пространствами, в результате чего получился модульный инструмент для подбора цвета. Сейчас поддерживается HSL, HSV, RGB, CMYK. Интересуют комментарии и пожелания по доработке. =) Дема: http://debugger.ru/demo/projects/colorpicker/

Ребяты, обломитесь с "управлением каждым пикселем"... Я тут поигрался с подобной генерацией картинок: 1) это дичайшие тормоза (Athlon64 X2 6000/4Gb) 2) некоторые браузеры поддерживают от 32767 до 65535 узлов Я даже сомневаюсь, что canvas выдержит подобное издевательство. Не говоря уже о проблемах производительности. Пожалейте интерпретируемые языки, пишите подобные вещи на компилируемых =)

Нет.

Можно посмотреть, как работают готовые решения. Например http://cms.debugger.ru/test Обычно это делается через relative/absolute позиционирование вложенных блоков.

try..catch

Картинка отда?тся динамически: http://images.brookeskye.com/mypics/iloveit24.jpg Серверный скрипт определить не удастся, т.к. он никаких данных не показывает =) Вот весь ответ: HTTP/1.1 200 OK Date: Wed, 07 Nov 2007 19:21:20 GMT Content-Type: image/jpeg Connection: close

http://svn.debugger.ru/wsvn/JS%20libraries...ns/trunk/dom.js getComputedStyle

Мне вс? равно, сколько человек потратил сил и времени на то, чтобы начистить свой значок "знатока стандарта Х". Если эти знания не подтверждаются практическим опытом -- они бесполезны. Вот и вс?. Специалисты с шишками куда как ценнее -- они понимают, что вс? в мире относительно. Это да?т им значительно бОльшую гибкость и умение подстроиться под любые задачи/ограничения, в отличие от деревянных стандартоносцев... А я, между прочим, вижу это иначе, чем MS vs стандарты. Для меня есть стандарт MS, есть и другие (не буду перечислять). А предложение было совсем не в том, чтобы с умным видом сказать про "стандарт MS и другие". Я предлагал сравнить подходы в разработке определ?нных механизмов, на примере вполне конкретной реализации вполне конкретного свойства.

А как ситуация может улучшится, если никто не желает следовать стандартам, еще при этом учат других: "делай, как я"? Естественным отбором улучшится, через пару тысяч лет. Когда-то и религия была юна. И духовные практики. Да и холодильники сначала делали кто во что горазд. Индустрия должна повзрослеть. Это бывает ничуть не хуже - смотря от кого исходит информация, и чьи это умозаключения. Так стандарты -- это уже и есть умозаключения, продвигаемые некими профессионалами, в качестве пропаганды своего вИдения мира. И не более того. Как пример в разнице опоры на опыт и умозаключения -- сравните event.button в реализации MS и "стандартном".

Людей, набивших шишки на подобных вещах куда проще научить хорошему, нежели студентов, вооруж?нных сверкающей брон?й "идеального знания". Просто из опыта. Ну, защищал-то я именно позицию. Не далее, как в 14:30:01 Иногда кровь вскипает и хочется ввязаться в новый крестовый поход. =) В общем, по чесноку.

AKS Могу Вас уверить, что следование стандартам ничуть не улучшает ситуацию. Просто обмен опытом заменяется на цитаты... и виртуальные умозаключения. Веб слишком молод и слишком бурно развивается, чтобы было на что опираться.

Вспомнил тут, в каком я был шоке, когда посмотрел на код интерфейсов, генерируемый Bindows, Zimbra, Tibco и прочими крупными движками для RIA (rich internet application). Сейчас я точно могу сказать, что для RIA, к которым, несомненно, относится интерфейс управляемый табами, семантически корректная разметка совершенно не важна. Все 4 пункта полностью корректны.

Я пишу об ограниченном решении, к которому вообще незачем возвращаться в будущем. Если только править баги, которых полно у тех, кто учится на собственных "шишках", выдавая их за опыт. Вы представляете себе, что существуют проекты, которые в неизменном виде живут годами? Не понял. Это что за фраза? Хотите оскорбить? Ни в коем разе, это к вопросу что человек сам себе выбирает окружение. Мне, например, нравится жить совсем в другом мире, без помоек =) Здесь речь не об этом. Мой оппонент изначально отверг вариант с использованием стандартной разметки и логики. Противопоставил этому он свои "шишки" и "костыли" (иных аргументов я не увидел). Так вот давайте с самого начала. В этом Вы с ним согласны? C самого начала я с ним согласен, что нет никакой разницы, какие теги использовать. За исключением тех, внешний вид которых не может контролироваться. Другое дело, что я предпочитаю логически верную разметку. Но в любом случае, для меня куда более ценным является мнение человека, имеющего практический опыт. Даже если его опыт ид?т в разрез с моим. Кстати, мо? решение табов точно так же выложено в этой теме, т.ч. есть возможность сравнить и подходы.

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

s0rr0w, поддерживаю Ваши аргументы в полной мере. Правда, я до подобной прагматичности ещ? не дош?л, да и не сильно хочется =) То что крупные корпоративщики сами стараются максимально сузить рабочую платформу -- непреложный факт. Просто потому, что каждая точка в версии платформы обозначает сотни рабочих часов программистов и тестеров, которые выливаются в сотни тысяч долларов затрат, и миллионы долларов упущенной выгоды. Как пример, последний проект, в котором я принимал участие, имел требования: Windows 2000/SP4, IE6/SP2 и было запрещено даже просто тестировать в других браузерах/OS. В общем, командная игра заключается в том, чтобы сделать наиболее эффективное по затратам/масштабируемости/реюзабельности решение, которое да?т максимальные возможности по повторному использованию кода. Что вед?т к элементарному облегчению условий труда себе и коллегам и увеличению заработков. Что мне не сильно нравится в коде -- отсутствие идеологии, я предпочитаю красивые решения. По результатам публикации кода -- пальму первенства отдам s0rr0w, за наиболее практичное решение, идущее из опыта (очень похоже на код человека, учившегося на шишках, а не умных теоретизированиях).

Самое рабочее решение -- указывать в .em все величины, даже размеры картинок. Тогда и разъезжаться ничего не будет.

Возьмите готовый и отлаженный шаблон: http://debugger.ru/demo/other/pagetemplate/PageTemplate.html http://debugger.ru/demo/other/pagetemplate...Template.v3.zip