s0rr0w

1. Опера какая версия? 2. Попробуй разделить строку на два действия var node = document.getElementById('fotoimg_'+img_num); alert( node.arr_num + " " + start_pos); node.arr_num = start_pos;

Полезные знания

Главное, чтобы одна пядь была, но не блонди, и тогда с полупинка ставится Денвер.

OMG! Приемчики 90-х годов... http://astoria-n.ru/spacer.gif Где картинка?

Ключевое слово - фоновое изображение. У фонового изображения есть замечательное свойство - background-position Изучите вот это http://www.w3.org/TR/CSS21/colors.html#pro...ground-position Там даже картинки есть для лучшей усвояемости.

А для чего вообще это свойство используется? Может там можно без clip обойтись?

А должен брать? Что по этому поводу спецификация говорит?

Почему мучиться? Вполне себе работоспособная система. А когда приходит время, и ты понимаешь одну простую истину, что основа всей системы - файл, то становится легко и непринужденно. Для веба Linux больше подходит, чем Win. В целях обучения хочу на старенький и мало используемый компьютер поставить Linux. В связи с чем прошу дать первые наставления и ЦУ. Наставление первое. Нужно забыть про окошки и прочую лабудень Windows. Наставление второе. Основа *nix систем - файлы. Наставление третье. Сначала нужно запастить терпением и мануалами.

Вот скажите, какой смысл пытаться помещать блочный элемент внутрь инлайн-элемента? Есть коробка. В коробку можно засунуть кошку. Но зачем коробку засовывать в кошку? Может я и не совсем правильное слово подобрал (валидный), но факт остается фактом - невозможно вставить блочный элемент внутри строчного. Это запрещено на уровне правил рендеринга, но есть способ это отобразить (workaround так сказать) > "Как это проигнорировать?" Вы где-то прочитали другое? Поделитесь ссылочкой на точное место, как браузер должен понимать инстукцию <!ENTITY>. A то я вижу в спецификации XML1.0 (4th edition) для декларации типа другую инструкцию Да в той же спеке все и написано. http://www.w3.org/TR/2006/REC-xml-20060816/#sec-external-ent Почитайте еще вот это http://www.w3.org/TR/REC-xml/#dt-doctype XML может состоять из множества разрозненных кусков. DTD используется для того, чтобы указать какие элементы есть в определенной структуре, какие атрибуты и так далее, а также указывает на их отношения - вложенность, обязательные параметры и т.д. Без DTD XML может быть well-formated, но невалиден. >То есть там однозначно написано, что для декларации типа документа используется инструкция <!DOCTYPE>, a не <!ENTITY>. А для декларации типа документа как XHTML далеко недостаточно только инструкции <!ENTITY>. В вашем коде однозначно написано, что вы определили параметрическую сущность, контент которой подчиняется законам, описанным в указанной DTD. Имя сущности - html. В контексте какого типа документа? Любого. Это же команда

Резонный вопрос, зачем нужны замыкания, если негатив от них перекрывает весь позитив?

Это решается примитивным префиксом перед именем функции. Для пейджера PGR_foo, для таббера TAB_foo и так далее.

Например, два байта на символ.

Если ты собирал правильно, то у тебя вся страница представляет слоеный пирог. Отключить футер, хэдер и меню, да пару блоков - это не составит труда. Для более уникальный блоков я использую class="unprintable" Как показывает статистика, на странице всего 5-10 блоков, которые "лишние".

В больших - наврядли. В маленьких - да. Большие имеют лишние деньги, чтобы не спешить и не смешить потом людей, а малениким приходится работать на скорость.

А эффективнее, это как? Кто мерял эту самую эффективность? > Причем не в плане производительности кода, а в плане скорости разработки. Везде присутствует мифическая скорость разработки... Но покажите мне хоть один отчет компании, которая бы показала эффективность данного подхода. В частности если в гугле работают такие глупые программисты, а вы такие умные, почему вы еще не там? Вы могли бы легко доказать свое превосходство ;-) (Вопрос саркастический, ответа не требует). Я не говорил что в гугле работают глупые программисты. Но их творения не представляют для меня никакой сложности. И не несут ничего интересного. И я не собираюсь доказывать кому-то свое превосходство, глупо это. Вот, например, zeroglif, он собаку съел на JS. Мне далеко до него, но я туда и не стремлюсь, это не мой путь. Что касается фирм, не занимающихся непосредственно веб-технологиями, то, возможно, вы в чем-то правы. Я не видел опровержения своих слов, и я бы сменил све мнение на противоположное, если бы имел успешную историю применения фреймворков для создания веб-приложений. Завтра я постараюсь дописать доку и выложить ту надстройку, которую написал, сделать пару уроков и показать, что есть альтернативы текущим фреймворкам в том виде, в котором они существуют на данный момент времени. Кстати, zeroglif, есть тема для обсуждения. http://forum.htmlbook.ru/index.php?showtopic=12183

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

Так так так, я весь во внимании... Но там нигде не сказано, что низя (ну никак низя) поместить в inline box block box. В спецификации ясно написано, как элементы внутри этих блоков могут размещаться. Обратимся к разъяснениям того что такое inline box и block box Ага, ясно написано. Есть блок - делай блок. Помещай в блоки другие блоки и лайн боксы. Есть лайн бокс - внутри могут быть другие инлайн элементы. Итак, что произойдет, если попытаться поместить болочный элемент внутрь строчного. DIV станет строчным, значит будет создан анонимный блок, в который будет помещен line-box, но содержимое его будет нулевым, так как следующий элемент не является строчным элементом. Раз содержимое нулевое, то высота данного блока будет нулевой. Нужно создать блочный элемент за line-box-ом. Внутри него создать line-box и поместить текст ссылки. Итак, мы никак не можем засунуть блок внутрь инлайн блока. Можем создать только новый блок. Похвально что вы прочитали спеку, но, к сожалению, не до конца. > Другой момент, что я намерено ввожу браузер в заблуждение. Ведь в dtd описана еще и структура элементов. Он должен такие инструкции описания проигнорировать. Как это проигнорировать? Где вы такое прочитали? DTD создан для того, чтобы описывать элементы и их структуру. > Браузер будет рисовать мне в "тегах <B> жирным даже в XML документах". Для этого надо сделать всего одну вещь - в /etc/mime.types подправить одну строчку "text/html html htm xml", чтобы сервер в заголовке отправлял text/html, а не text/xml. Этим вы только скажете браузеру, что ему стоит подгрузить дефолтные значения CSS для тегов. > Давайте, я возьму на себя смелость расширить для Вас, понятие команды применительно к тегу. Тег - с точки зрения программного продукта, это команда/инструкция в контексте какой-либо модели документа. И что должен сделать браузер при виде тега <COLLAPSE>? Какую команду выполнить? > стоп. стоп. не так быстро. я ни сколько не упираюсь, что спецификации не должны совершенствоваться. наоборот. я только за. я лишь вам обосновываю свою точку зрения (выражаясь иносказательно): что напильник должен быть применен именно там и именно так, где он нужен. Разработчики спецификаций тоже люди. И им свойственно что-то упускать, что-то забывать.

Аааааа... Вот вы про что. Кто делал сайты для всех этих компаний? Это к тому, что сама компания не использует фреймворки, это кто-то разработал продукт с использованием фреймворков. И врядли DELL настаивал на том, что нужно обязательно их использовать. Вы пользовались gmail? сделайте проект такого же масштаба без фреймворка -- продолжим беседу. Легко! В Гмейл нет ничего сложного. Ещё что? ( я проигнорировал те фразы, в которых не нашел смысла) Конечно, особенно меня порадовал пропуск вопроса про то, каким местом фреймворки ускоряют разработку. Нет смысла в данном вопросе, ага... Верю, ибо нелепо!

OMG.. Вы случайно не сетевой администратор? Если нет, то идите прямиком к нему.

Почему странное? Очень даже не странное. > 1. фреймворки упрощают жизнь и ускоряют разработку. Каким местом? Я эту фразу слышал триста раз уже. Но я не видел реальных подтверждений того, что это таким является. > 2. фреумворки в пределах своих ограничений помогают забыть о кроссбраузерности Иногда в ущерб скорости. Мало того, с выпуском все новых и новых браузеров код фреймворка разрастается, так как в разных версиях одного и того же браузера реализация некоторых вещей может серьезно отличаться. И как только выходит новый браузер, с отличиями от предыдущих, сразу начинаются проблемы с функциональностью. И исправить ошибки зачастую очень дорого. > 3. фреймворки не надо поддерживать -- этим занимаются другие, весьма неглупые люди, а мы пользуемся (совершенно бесплатно) Не забывайте про временной лаг. Иногда от возникновения ошибки до ее исправления может пройти пол года. Потому что этим занимаются другие люди. Хоть и весьма неглупые. 4. Если чего не хватает, можно фреймворк доделать и прислать свои труды разработчикам А зачем? Смысл в наращивани в фреймворке фич, которые будут востребованы один раз из тысячи? Если Вы считаете, что "Умные люди" (мыслящие не шаблонно ))) не используют фреймворки -- то Вы считаете глупыми такие фирмы, как Google, w3c, DELL, Intel. Подробнее с этого места... (запасся попкорном) пишите предметно, не собирайте бред. Ясен перец, что есть то, чего фреймворк не может, но это не значит, что нужно от него отказаться совсем и не использовать даже то, что он может (имхо). Да, давайте начнем писать предметно. И начнем с вас. Покажите мне пример продукта, написанного на одном из фреймворков, который сложнее чем лайтбокс.

http://www.google.com/search?hl=ru&q=п...G=Пошук&lr=

Гуглим "картинка над flash"

Я просил ссылку на спецификацию, а не на ваше резюме. Первоисточник я читал, и в нем я не нашел ни одного упоминания что делать, если в инлайн блоке вдруг кто-то захочет поместить блочный элемент. Вариантов интерпретации масса. Сделать два инлайн блока и один обычный в середине. Проигнорировать блочный элемент вообще. Переместить блочный элемент за пределы строчного элемента. Но никогда блочный элемент не будет помещен внутрь строчного. > В моем коде не сказано, что DTD указывает на структуру документа HTML. В этом коде сказано, что в данном документе XML будут применены сущности соответствующие типу и именам указанным в публичном стандарте //W3C//DTD XHTML 1.0 Transitional//EN. Указано из какого источника браузер должен загрузить эти имена сущностей. Как не сказано? <!ENTITY % html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" < это что такое? Это описание структуры контента html элемента. > s0rr0w, поробуйте написать свой парсер. тогда Вам наверно станет понятна и моя точка зрения. Парсер - сам лично не имеет мозгов. Программист-человек в него вкладывает алгоритм как "действовать" в той или иной ситуации, как "понимать" тот или иной набор символов. Потому парсер как собака понимает только команды и инструкции. Но я принимаю вашу точку зрения. Ибо она достаточно широка, но не конкретна. Понимание алгоритма визуализации может быть и без написания собственного парсера. Еще раз повторю, если бы теги были командами, то "собака"-браузер выделял бы текст в тегах <B> жирным даже в XML документах. Парсер занимается обработкой потока. Ему все равно, какие теги, сколько их, какой у них уровень вложенности. Задача парсера - построить DOM дерево. Безликое дерево. > Итак, я до сих пор придерживаюст мнения, что создавая новые теги и атрибуты и пространства имен там где это не предусмотрено (HTML/XHTML) вы тем самым не только нарушаете спецификации, но и вставляете палки в колеса другим разработчикам ПО и устройств. Если конечно, s0rr0w, вы хотите придерживаться такой философии, присоединяйтесь к Мелкософту. Я лично благодарен W3C. Эти ребята делают нужную работу по унификации и стандартизации. Когда каждый пишет как хочет, возникает слишком много абсурда. Вас никто не запрещает придерживаться этого мнения. Но оно ошибочно. Спецификации имеют ряд неточностей, коллизий и ошибок. Именно поэтому их постоянно уточняют и дополняют. Я придерживаюсь философии, что если что-то было описано в спецификации - того и надо придерживаться. Спецификация XML главнее спецификации HTML в XHTML. > Все понятно, Вы просто не можете пояснить. Легко сказать - трудно сделать. Ну что ж Вы видимо еще молоды, Вам простительно. Я поясняю на протяжении многих постов, но вот пояснения ничего не дают. Может потому что вы молоды? Максимализм и все такое... К чему все это? Пофилософствовать и я могу... Давайте ближе к теме.

Непонятно.

http://www.google.com/search?hl=ru&q=c...0mov%20to%20swf