Yarik Voronov

К слову о замыканиях. Если мы используем замыкания, как способ программирования. (Замыкания) Нам всегда надо держать в уме три вещи: область действия переменных, время их жизни, смысл того где мы делаем замыкание. Например function createMyObject () { var localVariable = "local"; this.alert = function () {return localVariable} } MyObject = new createMyObject (); По сути дела память под конструктор не освободиться после создания объекта. Потому что мы использовали замыкание со ссылкой на переменную вне области действия анонимной функции. Все в порядке когда таких конструкторов мало. Но если их 1000 или более? то уже начинаются проблемы с памятью, выделяемой под приложение. Может наступить момент переполнения. Нам надо четко предствавлять как долго должен "жить" (занимать активную память) объект: до конца сеанса или до того как вернет результат операции. В данном примере конструктор будет жить до конца сеанса (пока пользователь не уйдет со страницы). Так как сборщик мусора Java Script не может его "прибить" пока хоть один объект ссылается на его переменные. В моем примере следует пояснить , что значит "прибить" - перевести из фактического состояния в формальное, без выделения динамической памяти, грубо говоря в текст. Более правильный код первого примера function createMyObject () { this.localVariable = "local"; this.alert = function () {return this.localVariable} } MyObject = new createMyObject ();

>Есть блок - делай блок. Помещай в блоки другие блоки и лайн боксы. Есть лайн бокс - внутри могут быть другие инлайн элементы. Итак, что произойдет, если попытаться поместить болочный элемент внутрь строчного. DIV станет строчным, значит будет создан анонимный блок, в который будет помещен line-box, но содержимое его будет нулевым, так как следующий элемент не является строчным элементом. Раз содержимое нулевое, то высота данного блока будет нулевой. Нужно создать блочный элемент за line-box-ом. Внутри него создать line-box и поместить текст ссылки. Итак, мы никак не можем засунуть блок внутрь инлайн блока. Можем создать только новый блок. Похвально что вы прочитали спеку, но, к сожалению, не до конца. Да, здесь я с Вами согласен - будет огранизован анонимный блочный элемент вокруг строчного, содержащий блочный. А строчный блок будет разорван. Блочный и строчный станут потомками анонимного block-box. Так где здесь противоречие? Договариваете. А то останавливаетель на середине. Сделайте, пожалуйста, выводы в контексте своего тезиса: >> Другой момент, что я намерено ввожу браузер в заблуждение. Ведь в dtd описана еще и структура элементов. Он должен такие инструкции описания проигнорировать. >Как это проигнорировать? Где вы такое прочитали? DTD создан для того, чтобы описывать элементы и их структуру. "Как это проигнорировать?" Вы где-то прочитали другое? Поделитесь ссылочкой на точное место, как браузер должен понимать инстукцию <!ENTITY>. A то я вижу в спецификации XML1.0 (4th edition) для декларации типа другую инструкцию То есть там однозначно написано, что для декларации типа документа используется инструкция <!DOCTYPE>, a не <!ENTITY>. А для декларации типа документа как XHTML далеко недостаточно только инструкции <!ENTITY>. >> Давайте, я возьму на себя смелость расширить для Вас, понятие команды применительно к тегу. Тег - с точки зрения программного продукта, это команда/инструкция в контексте какой-либо модели документа. >И что должен сделать браузер при виде тега <COLLAPSE>? Какую команду выполнить? В контексте какого типа документа?

2 Mike-Eci, попробуйте привязаться к словам NAT (Network Address Translation) и DNAT (Destination Network Address Translation). Вам надо проложить маршрут пакетов от роутера к локальному компьютеру и обратно. от компа/роутера с внешним IP к компу с внутренним IP

Да ладно... "Не будет"... Вы сами несколько постов назад приводили такой пример. А в спецификации достаточно ясно описана модель блочного форматирования и визуального предствления. И там (9 Visual formatting model) достаточно ясно дается понимание того что display относится к положению самого элемента, и его потомков. Но там нигде не сказано, что низя (ну никак низя) поместить в inline box block box. В спецификации ясно написано, как элементы внутри этих блоков могут размещаться. Обратимся к разъяснениям того что такое inline box и block box Это элементы которые не формируют вокруг себя нового блока (переноса строки, грубо выражаясь) Это те элементы которые наоборот генерируют вокруг себя блок, т.е перенос строки. Они (такие элементы, но не их потомки) визуализируюся как блок. Заметьте с пецификации не указано через запятую какие теги строчные а какие блочные. Итак, определяя inline box Вы задаете положение самого этого блока и его потомков, относительно родителя этого inline box. block box внутри inline box будет генерировать перенос строки. Но будет отображаться inline относительно родителя inline box'а и не будет выходить за его пределы. Никакого противоречия не вижу. Заодно посмотрите раздел 9.2.1.1 Anonymous block boxes, там есть хороший пример. Еще раз повторюсь, что то что вы говорите по поводу точно строчных и точно блочных элементов - это закодировано как by default. для тех кто не хочет увеличивать объем кода дополнительными таблицами стилей по тем или иным причинам. и это совместимость и приемственность стандартов. на мой взляд - довольно удобно. В точку. Если брать только эту строчку кода. Инструкцией <!ENTITY> я задаю браузеру взять только сущности, а не структуру. 4.1 Character and Entity References Другой момент, что я намерено ввожу браузер в заблуждение. Ведь в dtd описана еще и структура элементов. Он должен такие инструкции описания проигнорировать. А вот это уже зависит от того что написано в коде парсера (в 3 из 4 что-то логичное). Если вы уберете из моего кода шапку DOCTYPE. вы получите такой же результат (естественно удалив из кода и сущности). Вернусь немного к прошлым постам. "Браузер не грузит DTD сторонних разработчиков". Примерно так это звучало. Оpera 9.63 будет загружать, если разрешить в конфигах XML: External Entities FireFox < 3 к сожалению не сможет. по соображениям безопасности. в FF3 я не смог найти опцию включения/выключения Load external data file in XML FF won't parse my xml DTD's external general entities >Понимание алгоритма визуализации может быть и без написания собственного парсера. Еще раз повторю, если бы теги были командами, то "собака"-браузер выделял бы текст в тегах <B> жирным даже в XML документах. Парсер занимается обработкой потока. Ему все равно, какие теги, сколько их, какой у них уровень вложенности. Задача парсера - построить DOM дерево. Безликое дерево. Браузер будет рисовать мне в "тегах <B> жирным даже в XML документах". Для этого надо сделать всего одну вещь - в /etc/mime.types подправить одну строчку "text/html html htm xml", чтобы сервер в заголовке отправлял text/html, а не text/xml. Браузер "собака" не такая уж и глупая. В его парсере существует множество алгоритмов. Если вы возьмете FF+FireBug и посмотрите на DOM второго примера поста 40, то увидите что body и все что внутри него имеют семантику HTML при этом оставаясь элементами дерева XML. И тут нет противоречия, потому что XML "коробок побольше". Но внутри body я не могу просто так написать свой тег - мне нужно будет объявить другое пространство имен (которому принадлежит мой тег), чтобы парсер клиента не пытался его "понять" как элемент пространства HTML/XHTML и не наделал ошибок. Давайте, я возьму на себя смелость расширить для Вас, понятие команды применительно к тегу. Тег - с точки зрения программного продукта, это команда/инструкция в контексте какой-либо модели документа. >> Итак, я до сих пор придерживаюст мнения, что создавая новые теги и атрибуты и пространства имен там где это не предусмотрено (HTML/XHTML) вы тем самым не только нарушаете спецификации, но и вставляете палки в колеса другим разработчикам ПО и устройств. Если конечно, s0rr0w, вы хотите придерживаться такой философии, присоединяйтесь к Мелкософту. Я лично благодарен W3C. Эти ребята делают нужную работу по унификации и стандартизации. Когда каждый пишет как хочет, возникает слишком много абсурда. >Вас никто не запрещает придерживаться этого мнения. Но оно ошибочно. Спецификации имеют ряд неточностей, коллизий и ошибок. Именно поэтому их постоянно уточняют и дополняют. Я придерживаюсь философии, что если что-то было описано в спецификации - того и надо придерживаться. Спецификация XML главнее спецификации HTML в XHTML. стоп. стоп. не так быстро. я ни сколько не упираюсь, что спецификации не должны совершенствоваться. наоборот. я только за. я лишь вам обосновываю свою точку зрения (выражаясь иносказательно): что напильник должен быть применен именно там и именно так, где он нужен. [Offtopic] >> Все понятно, Вы просто не можете пояснить. Легко сказать - трудно сделать. Ну что ж Вы видимо еще молоды, Вам простительно. >Я поясняю на протяжении многих постов, но вот пояснения ничего не дают. Может потому что вы молоды? Максимализм и все такое... Точно! Я молод! Горячь и необуздан! Ха-ха. Спасибо за комплимент. Здесь - лучшее место. Сейчас - лучшее время. У-РА! [/Offtopic]

2 AlexMak. попробуйте поместить скрипт в body. Скорее всего Ослик затирает все что было ранее и пишет на этом месте одну строчку <script ... >. Когда-то у меня был подобный прикол. только Ослик сразу издыхал. Да и еще надо указать двойные кавычки document.write("<script type=\"text/javascript\" src=\"js/menu.js\"></script>"); Была ситуация когда не подгружал файл.

Продолжу тему контроллеров. С другой стороны давайте выйдем за рамки "железного ящика" одного контроллера. И представим себе, что мы продвинутые программисты и перед нами стоит задача сделать модуль управления большим производством, со множеством датчиков, контроллеров, контуров регулировая. Но чтоб сладкой фантазия не казалась внесем м-а-а-а-люсенький нюанс: все наши устройства высокого уровня (датчики оставим в стороне) говорят с нами разными языками (посылают информацию структурированную различными правилами. как бог подсказал разработчикам). Нам надо все это собрать и вывести на один компьютер (главный-управляющий). Сколько мы должны написать парсеров? столько сколько устройств. Пипец, подкрался незаметно. Каждый парсер тормозит компьютер. раз тормозит значит информация поступает несвоевременная, значит снижается скорость принятия решения. Значит снижается качество. Теперь подойдем с третьей стороны. Мы написали код (все тот же контроллер) но запрограммировали его на отдачу нестандртной информации. (то что другие простые устройства этот контроллер понимать скорее всего не будут - это факт) А потом нас перевели в другой отдел. повысили или еще что. На наше место придет другой программист. Он полезет в наш код и будет разбираться с нуля. Да еще звонить и просить объяснить что тут к чему, потому что звонит раздраженный покупатель и требует чтоб его "Трактор от ТРС" мог понять этот контроллер. Пожалейте себя, в конце концов.

>>>>Как правильно отображать блочные элементы внутри строчных? Если вы мне поясните, то я соглашусь, что спецификации не могут противоречить друг другу. >>>Спросите у разработчиков браузеров и видеокарт. как рекомендовано W3C я уже говорил >>http://www.w3.org/TR/CSS21/visuren.html http://www.w3.org/TR/CSS21/box.html >Точнее можно? Я просил указать место в спецификации, где разрешается внутри инлайн бокса создавать блок. http://forum.htmlbook.ru/index.php?showtop...ost&p=83918 Это своими словами сделанное резюме. Прочитайте, пожалуйста, сами первоисточник и сделайте свой вывод. >Well-formed, но невалиден. (прмеч. автора топика: пример 2 из топика 40) Доктайп действительно указывает на XML, но не забываем про DTD. В DTD указано, что это документ с локальным DTD, но элемент html имеет структуру XHTML. А так как структура приведенного документа не является HTML структурой, то этот документ невалиден. В моем коде не сказано, что DTD указывает на структуру документа HTML. В этом коде сказано, что в данном документе XML будут применены сущности соответствующие типу и именам указанным в публичном стандарте //W3C//DTD XHTML 1.0 Transitional//EN. Указано из какого источника браузер должен загрузить эти имена сущностей. Так же указано, что сущность € следует понимать как описано локально. А так же добавить новую сущность &baks; В первой директиве DOCTYPE сказано чтобы все это было применено начиная с корневого элемента html. А XML мне не запрещает использовать такие же буковки в именах тегов как в XHTML... (так же см топик 44) >Надо посмотреть в исходниках мозиллы, иначе можно только предполагать. s0rr0w, надо посмотреть в таком случае не только исходники Мозиллы. Но и Оперы, Конкурера и Ослика. Я специально использовал 4 браузера для чистоты эксперемента. Так же следует посмотреть исходники Apache 2.2.11. Именно с него я получал документы. >Есть структура данных, есть описание принципов отображения структуры, берем и показываем. Или не показываем. s0rr0w, поробуйте написать свой парсер. тогда Вам наверно станет понятна и моя точка зрения. Парсер - сам лично не имеет мозгов. Программист-человек в него вкладывает алгоритм как "действовать" в той или иной ситуации, как "понимать" тот или иной набор символов. Потому парсер как собака понимает только команды и инструкции. Но я принимаю вашу точку зрения. Ибо она достаточно широка, но не конкретна. Yarik Voronov 2 s0rr0w Вы не утрудили себя понять, смысл написанного после "Все дело в расширении". (см топик 40) s0rr0w 2 Yarik Voronov Простите, но расширение может быть разным. А контент - типизированным. Если gif картинку назвать как jpeg, то контент автоматически не изменится. Это будет картинка gif с расширением jpeg. Скормите браузеру контент HTML с mime-type'ом text/html под видом jpeg файла, и, о чудо, вы увидите не картинку, а HTML. SelenIT 2 s0rr0w Насколько я понял, Yarik Voronov имел в виду частный случай - открытие документа с локального диска. Тогда порядочные браузеры, действительно, определяют Content-type по расширению файла. s0rr0w Надо посмотреть в исходниках мозиллы, иначе можно только предполагать. расскажу вам реальный случай из моей жизни. есть у меня в машине магнитолла. достаточно старенькая 2003 года выпуска. работает хорошо и стабильно звук чистый. но есть в ней маленькая неприятность - она понимает только форматы AudioCD и MP3 (доказано и проверено, причем по расширению) как-то мне захотелось переписать на диск (CD-R) песни одной своей любимой группы. ессно дело хочу цифровой диск. и вот досада - песни оцифрованы и лежат с расширением WAV. ну ессно. дело не хитрое, надо перекодировать в MP3. скачал простой, но мощный перекодировщик на perl. только запустил перекодировку - ошибка: "Неизвестный формат данных". что за ерундень? наверно, кодировщик "старый", а новой версии на официальном репозитарии нет. лан, думаю, фигня, соберу из сырца. собрал - таже ерундень: "Неизвестный формат данных". Я думаю что еще за неизвестный формат - на компе проигрываются. значит известный. в скрипте перекодировщике можно выбрать столько форматов, что глаза разбегаются. Мучился наверно часа три (я ж ленивый, не хочу записывать 10 аудио болванок - класть некуда). уже полез в сам скрипт-перекодировщика с "напильником". и тут совершенно ненавязчиво мой взгляд останавливается на поле "описание" в проводнике KDE. А там черным по белому напротив каждого файла WAV написано: "аудио файл формата MPEG".... матерился мало, смеялся долго. Так вот тот источник песен альбомов группы видимо так боялся за свои права, что файлы MP3 тупо переименовал в WAV (WAV - формат записи звука без сжатия, кто не знает). я все естественно переименовал обратно, и с тех пор наслаждаюсь музыкой любимой группы даже в машине. После переименования и перекодировщик заработал как надо. Такой "оригинальный" способ защиты информации может быть и сработал бы лет 5 назад. но... Пора делать выводы. KDE хорошая штука - в ней есть прога которая анализирует типы mime по первым нескольким байтам файла. Но давайте не будем забывать что сеть - это не только сервера, а жизнь не только сеть. Встречается очень много других устройств (аппаратные-файрволы, контроллеры высокого и низкого уровня, просто устройста маршрутизации, модемы и т.п.). Я не говорю сколько разных типов клиентских устройств существует. Но не всякое из них может отправить корректно mime-type и не каждое может правильно его обработать. (Сервер в заголовке отправляет "Content-Type text/html; charset=windows-1251", давая четкое указание клиенту что сейчас он получит инфу в формате text синтаксиса html кодировки win). Но вернемся к устройствам. Допустим, нам надо запрограммировать очень маленький контроллер и написать к нему веб-интерфейс. к сожалению мы не можем в него втиснуть все функции сервера Apache, например, без ущерба для основного программного обеспечения, как бы того и ни хотели (у него ни мозгов ни памяти, более того надобности). А так же нам надо написать маленкий браузер (для компактного устройства), с которого и будет происходить управление контроллером в экстренных ситуациях. Вот здесь-то как раз нам и пригодятся дефолтные расширения файлов mime-типов и дефолтный синтаксис html (зачем нам изобретать велосипед - у нас же в котроллере нет столько мозгов, а в устройстве столько места). ок запрограммировали. теперь через год - выходит новая модификация устройства доступа например поддерживащее семантику xml для новых контроллеров. Но старый-то контроллер работает, его не сняли с производства. Потому как программисты мы должны оставить совместимость со старым форматом. Более того мы можем управлять и старым и новым контроллером например с КПК, ноутбука или компьютера. И каждому из этих клиентов будет ясно и понятно что они получают (даже без заголовка mime типа) Тем файлом /etc/mime.types на моей машине пользуются не только пользовательские программы. но и сервера (MySQL, Apache, Samba). И серверу Apache предельно ясно какой заголовок типа он должен отправить увидив файл с расширением jpeg/xml/pdf/html/... а мне нет надобности что-то там перекраивать. Apache "знает" что увидив .html он должен отдать его как текст, а увидив php (application/x-php) вызвать интерпретатор РНР и отдать клиенту результат. Разработчики Apache не тратят машинное и процессорное время на анализ первых нескольких байт кода. Как и не тратят времени машины на проверку того что там в результате программист-РНР "нашкодер". Итак, я до сих пор придерживаюст мнения, что создавая новые теги и атрибуты и пространства имен там где это не предусмотрено (HTML/XHTML) вы тем самым не только нарушаете спецификации, но и вставляете палки в колеса другим разработчикам ПО и устройств. Если конечно, s0rr0w, вы хотите придерживаться такой философии, присоединяйтесь к Мелкософту. Я лично благодарен W3C. Эти ребята делают нужную работу по унификации и стандартизации. Когда каждый пишет как хочет, возникает слишком много абсурда. Про DOM отпишусь в другой теме. Я не забыл. [Offtopic] >>Я свой тезис про коробок пояснил аж примером с картинкой. Поясните свой. Будте любезны. >Зачем? Ваше мышление не выходит за рамки браузера, HTML, XHTML, XML. А мое мышление не ограничивается сугубо визуальным представлением данных. Что я вам показывать буду? Все понятно, Вы просто не можете пояснить. Легко сказать - трудно сделать. Ну что ж Вы видимо еще молоды, Вам простительно. Так вот, s0rr0w. "Сидя в плотном железном ящике вы не можете точно сказать, каких он размеров снаружи, пока не покинете пределы этого самого ящика". От чего же смогу. Давайте, только конкретизируем, что понимать под точно сказать. Без соответсвующего инструмента и действий я и снаружу не смогу точно сказать какого он размера. Чтож поразмышляем. Во-первых, я знаю что он железный (по условию). Во-вторых, я знаю что это ящик (по условию). значит за ним что-то есть. Потому постучав по стенке я могу сказать какой она толщины и есть ли за ней пустое пространство. Отсчитав шаги от одной стены к другой, я могу сказать какой он длины и ширины в моих шагах. Посчитав сколько биений моего сердца проходит когда я прыгаю вверх я могу измерить высоту ящика в ударах моего сердца. В ударах своего сердца я могу сказать сколько времени я провел в этом ящики и происходило ли что-либо вокруг. Ощупав сварной шов (или просто угол) я могу сказать какой уровень технологии производства этого ящика. По этой информации я могу сделать вывод какого ящик размера снаружи. Если Вы мне датите ультразвуковой сканер, рулетку и фонарик - я вам точно в единицах Си (миллиметрах) скажу какого размера ящик снаружи, сидя внутри него. Но я не смогу сказать другого, какой мир находиться за этим ящиком. Но этого по условию и не требуется. [/Offtopic] >> 3.1.2. Using XHTML with other namespaces >Зачем вы мне приводите мою же ссылку? Что я там должен прочитать? SelenIT ответил за меня (топик 44) ЗЫ: Сегодня мне аська (программа Kopete из KDE 3) выдала: "Наш сервер не поддерживает вашу версию клиента. Скачайте новую версию клиента с нашего сайта". И что? Мне из-за этого ставить Windows? (вопрос риторический)

http://www.w3.org/TR/CSS21/visuren.html http://www.w3.org/TR/CSS21/box.html Не понял. Поясните. Я вам достаточно подробно объяснил процесс того, что происходит, когда браузер получает документ. Расскажите как это выглядит с вашей точки зрения. А то я вижу только голословное отрицание того что написано. Расскажите, например как происходит процесс интерпритации, по-вашему. /etc/mime.types (выдержка) # MIME type Extension (через пробел) application/docbook+xml docbook application/flash-video flv application/illustrator ai application/javascript js application/mac-binhex40 application/mathematica nb application/x-asmx asmx application/x-asp asp application/x-awk application/x-axd axd application/x-bzip bz2 bz application/xhtml+xml xhtml text/html html htm text/htmlh text/mathml mml text/plain txt asc text/rdf rdf text/rfc822-headers text/richtext rtx text/rss rss text/xml xml Вы не утрудили себя понять, смысл написанного после "Все дело в расширении". Первый закон Ньютона помните? В житейской итерпритации звучит просто: Все в мире относительно. Я Вам уже говорил что относительно HTML/XHTML спецификаций от W3C. Я свой тезис про коробок пояснил аж примером с картинкой. Поясните свой. Будте любезны 3.1.2. Using XHTML with other namespaces

>Деление на строчные и блочные элементы было задолго до CSS. Логика построения HTML базировалась на данном принципе. Логика CSS базировалась на этих же принципах, но со временем была расширена. Если раньше DIV был блочным, то он автоматически отображался как блок, а A - как строчный элемент, то с приходом CSS это перестало быть константой. Так как объектом применения CSS является только единичный тег без учета дерева документа, то инвертирование свойств display по сути является нарушением базисных принципов представления данных. s0rr0w, если бы DIV изначально должен был бы быть синим, то мы бы с Вами наверно пытались бы поспорить, что он не может быть красным. >Как правильно отображать блочные элементы внутри строчных? Если вы мне поясните, то я соглашусь, что спецификации не могут противоречить друг другу. Спросите у разработчиков браузеров и видеокарт. как рекомендовано W3C я уже говорил >Текстовая, sorrow. Текстовая. кнопочка западает >>Еще раз повторю, если бы это была КОМАНДА, то в XML тег <b> имел аналогичное представление что и в HTML. Но, это не команда, к нашему всеобщему счастью. Контейнер, блок, строчный элемент - это понятия абстрактные, применимые к результату форматирования XML/HTML. Это то, что Вы видите на дисплее и называете это контейнером, блоком, строчным элементом. Тег - это тоже понятие абстрактное, лексема (наименьшая имеющая смысл единица). Имеющая смысл... s0rr0w, если вы покажете код XML человеку далекому от веб-технологий, он увидит там набор букв, цифр и символов, а не контейнеров, блоков, строчных элементов. Команда, s0rr0w, это не только "бежать! стоять! сидеть! бухать!", это так же инструкция, указание. Относительно XML - указание/команда/инструкция браузеру, точнее парсеру в браузере сделать из тега (набора имеющего смысл символов) объект и отобразить его как блок, контейнер, строчный элемент. Я лично в коде XML/HTML/SVG ни разу не видел скомпилированного, уже отпарсеного, объектного кода/модуля (сразу без "посредников" понятного процессору/видеокарте) Давайте проведем маленький эсперимент. Возьмем следующий набол символов <?xml version="1.0" encoding="utf-8"?> <html> <body> <h1>Что это? <h2>Контейнер?</h2> </h1> <div> <p>От чего зависит <b>отображение</b>? </p> </div> <div> <i>Может все-таки от от конкретнй программы?</i> </div> <h1>И плевать им всем на заголовок xml?</h1> <h2>Потому, что расширение html...</h2> </body> </html> И сохраним этот набор как 1.xml и тот же набот символов как 2.html. откроем поочередно эти файлы в браузере. Я использовал FF 3.0.5, IE6SP2, Opera 9.63, Konqueror 3.5.7. Принтскрин для 1.xml http://forum.htmlbook.ru/index.php?act=att...=post&id=27 Принтскрин для 2.html http://forum.htmlbook.ru/index.php?act=att...=post&id=28 Что же такое? Я же по Вашей логике должен получить одинаковый результат. Ан нет. Все дело в расширении. И расширение диктует стиль и оформление, в данном случае. Я как линуксоид могу крупно повозмущаться. но не буду. Потому что расширения файлов были придуманы как раз для того чтобы отличать один тип файла от другого. применять к каждому типу свой набор команд, инструкций, понимать где заканчивается одна лексема и начинается другая. Может расширение файла с современной точки зрения и рудимент, но достаточно удобный и даже необходимый. Давайте вернемся в прошлый век. К началу Интернета, когда это слово писалось с большой буквы. К тому уровню технологий. HTML был придуман для того чтобы иметь однозначное, однотипное представление данных на разных машинах. Что бы жирный текст был жирным, а таблица таблицей. И тот язык-HTML ограничен, типизирован и закрыт по набору тегов, атрибутов и порядку их отображению. Он и остается таким по сей день и более того будет таким (принцип совместимости и преемственности), пока не расствориться. Его нельзя расширить, потому что он построен на логике и уровне прошлого века, для старых браузеров и машин. То что в HTML>4 начали вставлять костыли в виде CSS - то это этап переходного периода. Потому что на смену HTML просится XML+CSS+XSL как более гибкий, удобный и не помещенный в узкие рамки сети. Потому создавая новые теги и атрибуты и говоря программе так или иначе, что это документ HTML у Вас всегда буден невалидный HTML код (именно так я и написал в самом первом посте с которого обозначился спор). И не важно используете ли Вы стандартное пространство имен HTML или модифицированное для XML - XHTML. По поводу XHTML SelenIT правильно заметил: Но заметьте это не стало HTML 5.0.... Возможно в ближайшем будущем смениться и смысл того, что понимается под расширением .html. И это будет как раз документ xml c оформлением по умолчанию как в HTML. Хотя что я говорю, смысл уже меняется. >>Для меня любой документ, что HTML, что XML, что XHTML - это всего лишь один из подмножества SGML. И правила SGML не отменяли для этих языков. Вы же сужаете все разговоры строго до описанных на w3c. Найдите мне хоть один документ, которые запрещает мне создавать свои DTD для HTML. s0rr0w, по-моему Вы не можете/не хотите понять простой вещи: что в битком набитый спичечный коробок нельзя засунуть еще несколько спичек, не повредив коробка. надо взять коробок побольше. Проведем другой эсперемент. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html [ <!ENTITY % html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <!ENTITY euro "Привет! Я евро! Я росту!"> <!ENTITY baks "Че учтавился? Я бакс. Я сдуваюсь..."> %html; ]> <html> <body xmlns="http://www.w3.org/1999/xhtml"> <h1>Заголовок H1 <h2>Заголовок H2 внутри Н1</h2> </h1> <h1>Как отображается заголовок H1</h1> <h2>Как отображается заголовок H2</h2> <div> <p>От чего зависит <b>отображение</b>? </p> </div> <div> <b><>&©®</b> </div> <table width="300" border="1"> <tr> <td>Это ячейка</td> <div>Это DIV</div> <td>Это ячейка</td> </tr> </table> <h3>€</h3> <h3>&baks;</h3> </body> <h2>Как отображается заголовок H2</h2> </html> Принскрин http://forum.htmlbook.ru/index.php?act=att...=post&id=29 Чтож ослик подкачал.... Но 3 из 4 это хороший результат. Не все хотят быть ослами.... Так вот s0rr0w, я буду первым кто плюнет в лицо тому, кто скажет что мой код-xml неверен. Он еще как верен. Но вот какая штука - я указал браузеру отобразить все элементы внутри body как того требует html по умолчанию. естественно он мне их так нарисовал, как и сказано в HTML. но вот незадача, там не сказано как рисовать DIV между <TR></TR>, а H2 между <H1></H1>. Потому что по логике HTML такого быть не может. Если взять первоначальный смысл первой пары, то получается следующая глупость: вот ячеки таблицы и вдруг новый раздел с большой буквы, а потом опять ячеки. (например, вы смотрите добрый детский мультик про кота Леопольда и вдруг посередине начинается жесткое порно на пять секунд, а потом опять мультик. вы в шоке. мультик тоже).

самый-самый простой способ сделать фрейм. Все остальное сложное: серверные скрипты (PHP, JSP, ASP); Java Script + XML/HTML; SSI. Server Side Include, имхо, несколько проще, чем первые два варианта.

это xml, где определены три пространстива имен. в том числе и html40. не всем браузерам будет понятен такой код. потому послушайте beze и пишите сами. или в другом редакторе. то что напишете в Фронтпейдж 2003 буден на 100% понятно только продуктам от Мелкософта

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

homm, ты уверен? Все таки $mun = 2 << 31; <?php $num = 1 << 31; echo $num."<br/>"; //2147483648 $num = 2 << 31; echo $num."<br/>"; //4294967296 echo pow(2,32); //4294967296 ?> PHP Version 5.2.8

Народ! Вы о чем спорите? Как товаришчь возводит в степень? 2*2 = 4 4*4 = 16 16*16 = .... И так 32 раза. Естественно у него не хватает выделенной памяти под переменную и получает INF (переполнение) Для быстрого получения степени двойки можно использовать сдвиг влево $mun = 2 << 31; вроде бы так

Да SelenIT прав - пора закругляться. А то можем и договриться до того, что все разработчики браузеров строчат все, что в голову придет. А W3C только засоряет сеть никому не нужными мегабайтами информации. По поводу определения SGML. Согласен - это не модель переноса данных. Что это за модель я для себя уяснил. Кому интересно надо обратиться к первоисточнику или можно прочитать в Википедии По поводу событий на собственных тегах Утверждение во второй части действительно неверно. Все зависит от конкретной программы: FF3 позволяет назначать обработчики событий, а вот Konqueror 3.5.7 нет. И можно отобразить собственный тег, как например блочный, в рамках XML-модели.

s0rr0w, извините, но я не зациклен на одном стандарте-рекомендации. Я просто пытаюсь объяснить некоторую тонкость вопроса. Все что вы пишете справедливо, если вы используете XML в широком смысле, а не узкую его подмодель HTML/XHTML от W3C. Но как разработчик Вы должны корректно по меньшей мере указывать тип документа. Если вы используете в коде XML/XHTML собственные теги и атрибуты Вы не можете указывать тип документа как, например <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> Вы должны написать что-то такое: <!DOCTYPE html PUBLIC "-//S0rr0w//DTD XHTML 1.0 Transitional//EN" "http://s0rr0w.org/xhtml1/DTD/sorrow-xhtml1-transitional.dtd"> И в этом доктайпе все описать. И согласно Вашему типу все на 100% будет валидно. А потом проверить на соответствие XML и тоже все будет валидно. Но никак не может быть валидно отностительно XHTML 1.0 Transitional от W3C. И Вы сами об этом говорите: И спарведливо для XML-документа, но не для закрытой подмодели XHTML от W3C. То что браузеры не понимают типы документов XML/SGML других разработчиков вопрос времени. Вообще сейчас идет тенденция отказаться от DTD в пользу более гибкого инструмента W3C XML Schema (DTD) >>Тег - это есть команда в тестовом виде программе-браузеру в некоторой области машинной памяти организовать DOM-объект. >Какая-такая команда? Текстовая, sorrow. Текстовая. кнопочка западает >>Тег - это есть команда в текстовом виде программе-браузеру в некоторой области машинной памяти организовать DOM-объект. Назначить этому объекту своиства и стандартные методы и "дополнительные" свойства и методы, которые определили разработчики браузера. (Хотя это очень упрощенно, потому что сам документ SGML преобразуется в объекты языка программирования браузера (например С++) или становиться свойством к-л объекта). Поэтому пользовательские объекты (теги, созданные программно; скрипты), атрибуты и методы - это имена свойств объектов того языка программирования на котором написан браузер. А не расширение как таковой спецификации HTML/XHTML. >И нафиг тогда был создан DOM? От нефиг делать? Что ж так грубо? Внимательнее прочтите определение DOM Как следует, это тот программный интерфейс (например С++) который позволяет Вам на языке JS (тоже например) изменять содержимое документов, структуру и их оформление. Но все такие изменения происходят уже в сформированной программой-браузером (согласно алгоритмов разработчиков программы) модели документа, а не в текстовом файле-исходнике. Другой не менее справедливый тезис: "DOM - это то что будет создано на основе файла-исходника XML. И как эта модель может быть организована рекомендовано в стандарте DOM. А рекомендовано с целью унификации и упрощения разработки веб-страниц, в частности" Надеюсь Вы еще помните: document.all для IE5, document.getElementById для Netscape. >Внимательно читайте. Я не говорил, что CSS противоречит стандартам. Я показал пример, когда два стандарта могут создавать ситуации, когда они начинают противоречить друг другу. На момент обработки их браузером или любой другой программой. А я Вам обосновал (надеюсь убедительно), что никакого противоречия нет, если вы используете технологию XML + CSS (HTML > 4.0 и XHTML в эту связку я тоже отнес как подмодель XML). Если Вы хотите показать такой пример противоречия стандартов, то Ваш изначальный пример был не удачен, приведите другой, если хотите. >>Валидатор валидирует с учетом содержания того DTD, который Вы объявили в заголовке типа документа. А если Вы используете валидатор W3C то ессно дело, что хотите проверить на соответсвие W3C-стандартам и типу документа, а не своим. И тут не надо говорить что валидатор, с..., глупый и не понимает что мой клон HTML самый правильный >Вы специально проигнорировали что я написал три раза? Валидатор валидирует БЕЗ учета DTD, выбирая модель поведения из заголовка. Валидатор не глупый, он ограниченный. Создайте DTD к XML документу и создайте невалидный XML с точки зрения DTD. Валидатор покажет, что ваш документ валидный. Пример в студию. Но не надо говорить об XML в широком смысле, потому что наши разногласия относятся к узкой его подмодели XHTML. И то что я Вам говорил, это как раз тот момент ограниченности валидатора. И эта ограниченность на мой взгляд справедлива. Потому что Вы пытаетесь проверить свой документ на соответствие стандарту XHTML от W3C. А в XHTML от W3C четко сказано что есть, а чего быть не должно. З.Ы.: по поводу событий и определения SGML отпишусь позже

А что конкретно не правильно? У меня при клике Осел присваивал все на чем кликнуто инпуту.

s0rr0w, если Вы расширяете первоначалбный DTD XHTML 1.0 Transitional от W3C, то это уже не первоначальный стандарт XHTML 1.0 Transitional, как выбранный для примера. В этом вроде бы мы сошлись во мнениях. Теперь покажите мне пожалуйста в XHTML 1.0-спецификации тот раздел, который позволяет Вам расширять исходную декларацию типа документа своими тегами и атрибутами, своим простанством имен. Потому что мои поиски в этом направлении не увенчались успехом. То что вы мне показывали ранее есть не что иное как использование простанства имен XHTML как расширение XML-документа, но не наоборот. На строгое соответствие XHTML 1.0 Transitional. Только про это я и говорил, когда выражался "код ошибочен", "невалидный код". И по-моему, достаточно четко на то указал. Если сразу было непонятно,- пардон, что не писал крупными буквами. Зачем ее открывать? Её пора закрывать.... Согласен. Но DOM - это не есть документ SGML. И потому не надо пытаться смешивать две различные вещи, два разных стандарта, две различные области: модели переноса информации (SGML) и модели ее програмного представления в конкретном продукте (DOM). "Неверю и еще раз неверю" (с). Тег - это есть команда в тестовом виде программе-браузеру в некоторой области машинной памяти организовать DOM-объект. Назначить этому объекту своиства и стандартные методы и "дополнительные" свойства и методы, которые определили разработчики браузера. (Хотя это очень упрощенно, потому что сам документ SGML преобразуется в объекты языка программирования браузера (например С++) или становиться свойством к-л объекта). Поэтому пользовательские объекты (теги, созданные программно; скрипты), атрибуты и методы - это имена свойств объектов того языка программирования на котором написан браузер. А не расширение как таковой спецификации HTML/XHTML. Не расстраивайтесь, s0rr0w, к разрешению этого браузерно-стандартного конфликта и направлена работа W3C. Всегда есть момент инерции при принятии нового. сначала Вы пишите (5 постов вверх), что то для чего создан CSS противоречит стандартам, а сейчас, что так собственно и должно быть. не надо путать аппонента и ни в чем неповинного читателя. Валидатор валидирует с учетом содержания того DTD, который Вы объявили в заголовке типа документа. А если Вы используете валидатор W3C то ессно дело, что хотите проверить на соответсвие W3C-стандартам и типу документа, а не своим. И тут не надо говорить что валидатор, с..., глупый и не понимает что мой клон HTML самый правильный Мы с Вами рассуждали о валидном с точки зрения HTML/XTML коде, и якобы не валидном действии СSS по отношению к отображению этого кода в браузере. То что Вы предлагаете сделать сейчас это из раздела того как "браузеры пытаются переварить во что-то удобо варимое ошибочный код HTML/XHTML". Потому не вижу смысла как-либо иначе Ваш тезис коментировать.

Offtopic s0rr0w, загляните пож-та в перевод слова application - это "просьба; заявление; форма заявления;" в первую очередь. теперь в то что это означает прикладывая понятие к сфере программирования (мы ведь программисты??) application. Естесственные науки - "Прикладная программа - в широком смысле..." (О! великий и богатый русский язык!). так как общаемся на русском, - давайте использовать семантику русских слов. /Offtopic Правильно - "если расширить". Но это уже будет НЕ "DTD XHTML 1.0 Transitional" от W3C. Это будет DTD от s0rr0w. Потому, валидатор от W3C выдаст ошибку. Теперь задумаемся: "По умолчания, каким стандартам так или иначе следуют (пытаются следовать/игнорировать) разработчики ПО?" s0rr0w, пардон, Вы о чем? Это синтаксис языка, а я Вам втолковываю о семантике (понимание, интерпретация) Еще раз повторяюсь XHTML - это одно. DOM - это другое. У FF - своя объектная модель и IE - своя, у Opera - третья. Тривиально, выражаясь - объектная модель документа это порядок следования ноликов и единичек в оперативной памяти компьютера. Одна объектная модель позволяет делать к-л операцию, а другая нет. Одна позволяет себя расширятьновыми свойствами объектов, другая "машет лапкой и нервно курит". В одной модели существует 3 свойства объекта, в другой - 100 того же объекта (сильно упрощая). DOM от W3C - это набор рекомендаций по организации интерфейса доступа к объектам и их свойствам из программы и(или) скрипта. Теперь попробуйте выполнить вышеприведенный код с новым элементом <test> в IE6 - получите совершенно другой результат. Нет не обязательно. Чтобы хтмл обрел визуальный характер, надо чтобы парсер преобразовал команды описанные в хтмл в последовательность ноликов и единичек понятных драйверу видеокарты и процессору. А вот чтобы программист (веб-программист) имел возможность динамически редактировать эти нолики и единички браузер может (но не обязан) создать "посредника" между этими ноликами и единичками информации. "Посредника" понятного и браузеру и программисту. Да? Серьезно? s0rr0w, назначьте onclick элементу <test>. Кроме того, FF написал "неизвестный HTML элемент" потому что я сам задекларировал стиль и набор команд как XHTML в DOCTYPE, если бы я написал что тип документа SVG - FF выдал бы что это неизвестный элемент SVG "В базовом DTD написано" - конечно, там еще много написано. Но суть в том, что DTD (Document Type Definition определение типа документа) - это "значение свойств по умолчанию", то есть как браузер должен понимать элемент, если ничего другого нет. Но CSS и предназначен для того, чтобы менять эти "умолчательные" значения. HTML какой версии? 1, 3 или 4? Что касается версий 1-3 то точно не может. Потому что в них CSS не определен как расширение HTML. Когда декларировались эти версии, CSS вообще не существовало как такового. Потому в этих стандартах нет даже тега <style>. C точки зрения более поздних стандартов, блочный элемент позиционируется относительно того места и условый где он находиться и приобретает наследуемые свойства своего родителя. С другой стороны, загоните свой код в валидатор W3C и все увидите сами. Браузер не должен менять структуру DOM и не будет в таком случае. Потому что отрисовкой занимается другая часть кода-браузера. С точки зрения DOM, "ему" абсолютно начхать как должен (или может) отображаться тот или иной элемент. DOM - это объекты и их свойства, методы, т.е. структурированный набор ноликов и единичек в оперативной памяти, а не игра света и тени на дисплее. Дополнительно Правильно - "если расширить". Но это уже будет НЕ "DTD XHTML 1.0 Transitional" от W3C. Это будет DTD от s0rr0w. Потому, валидатор от W3C выдаст ошибку. И все будет верно, потому что код не соотвествует задекларированному типу в первой строчке документа. Следовательно код не верен - не валидный

Какая? Вдруг я тоже ее не включил?

в том месте где стояла - не считается

2 sc@r@bey - это точно flash анимация

s0rr0w, видимо надо начать с основ XHTML по сути своей не является XML приложением, он является xml расширением HTML W3C FAQ А я и не говорил что нельзя создавать свои теги и атрибуты. "Если нельзя, но очень хочется, то - можно". Только такой документ уже не будет XHTML или HTML. И мы не имеем права написать в заголовке <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">, например. это уже будет документ XML по своей сути (если мы выполнили все предписания для xml-документа), а не XHTML 1.0 Transitional. Естественно при таком раскладе как написано в том же FAQ: "HTML browsers accept any input, correct or incorrect, and try to make something sensible of it". Русскими словами, браузер в лучшем случае просто игнорирует теги и атрибуты не описанные в стандарте, ибо не понимает как их обрабатывать, в первую очередь - визуализировать. А то, что у каждого разработчика браузера свой взгляд на то, какие должны быть стандарты, - это тема другой оперы. Давайте не мешать мух и котлеты. "The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents." (DOM) Ключевые слова здесь "платформо-языко-независимый", "интерфейс". Т.е. это набор методов посредством, которых можно получить доступ к програмно-визуальной модели документа сформированной браузером, на основе синтаксиса (кода) полученного документа html. "Платформо-языко-независимый" - имхо, названия методов должны бы быть одинаковыми что в IE, что в FF, и более того - приводить к одинаковым результатам (покой нам только сниться...). Обобщая, кодом: var el = document.getElementById('myElement'); el.myaction = function (val) {alert(val)}; мы вносим изменения не в код HTML как таковой, а в програмно-визуальную модель документа в браузере. То есть в ту модель, которая сформирована для того, чтобы ее можно было "осязать" из программы или скрипта. А вот насколько эта модель корректна и безошибочна - вопросы к разработчикам браузеров. (IE6, как пример) С другой стороны, вернемся к "своим" тегам и атрибутам. Если их синтаксис верен (как синтаксис html/xtml/xml) то они могут не присутствовать в том, что мы видим, но обязательно присутствуют в програмной модели. Тут "обязательно" следует понимать с поправкой на конкретных разработчиков браузера/программны <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Untitled Document</title> </head> <body onload="alert([document.getElementById('test'), document.getElementById('test').getAttribute('name')]);"> <test id="test"></test> <script language="javascript" type="text/javascript"> document.getElementById('test').setAttribute("name","z"); </script> </body> </html> FF3 выдал "object HTMLUnknownElement". Следовательно мы можем применить к нему почти все методы (удалить из дерева, присвоить атрибут и т.д.), задекларированные разработчиками FF для HTML-элемента, кроме одного - не сможем отобразить элемент <test> как, например <div>. Потому мы не можем "повесить" обработчик событий на такой элемент. Вернее можем, но тогда мы должны сами программно вызывать такие события (initEvent()) Итак, XML/XHTML/HTML - это то что "понятно" любому поддерживающему стандарты програмному продукту (браузер, приложение). DOM - это набор методов доступа к программно - визуальной модели документа, сфомированной этим програмным продуктом. (ИМХО) А при чем здесь CSS? Никакого "конфликта стандартов" я здесь не усматриваю. Выдержка из аннотации к спецификации CSS2: "CSS2 позволяет сделать стиль представления документов независимым от их содержания, что существенно упрощает разработку Web-страниц и поддержку сайтов." Вообще, я не нашел ни в одной из перечисленных спецификаций, что <div> обязан всегда быть блочным, а <а> - встроенным. Да в HTML < 4.0, если я не ошибаюсь, <div> должен быть блочным. Но тогда не было СSS. Теперь каскадные таблицы стилей существуют, что во многом упрощает жизнь разработчикам сайтов. Новые времена - новые технологии - новые стандарты. Более того, в спецификации СSS четко написано как програмный продукт должен обрабатывать стили. Я соглашусь лишь с тем, что с точки зрения синтаксиса (CSS, HTML) приведенный код написан правильно (кавычки, скобочки, точки, имена свойств). И с точки зрения рендеринга все в этом коде верно: в пределах встроенного элемента <div>, элемент <a> отображается блочным (как того и хотел программист/верстальщик). Ну а если он хотел не того, чтож - ему надо "рендерить спецификацию"

Потому что html специализированный язык разметки. То есть строго регламентированный стандартами (HTML 4.01, XHTML 1.0 и прочая) в плане того какие атрибуты есть у того или иного элемента и вообще какие элементы (теги) есть и как они (теги) должны обрабатываться браузерами. Конечно, html-код c "дополнительными" атрибутами будет правильно отрабатываться браузерами, но не пройдет валидацию на соответствие использованному стандарту (см. DOCTYPE) З.Ы.: s0rr0w, классно, что вы гордитесь своим статусом "Бестолочи".

function My (inp) { this.value = inp; // уникальное свойство для нового сконструированного объекта } My.prototype = { someAction: function () {}, defaultValues: [1,2] // свойства общие для всех объектов сконструированных My } примерно также можно представить объект html как объект JS, но это грозит серьезными проблемами в IE (более подробно смотрите "утечки памяти IE", "замыкания"). Вот один из вариантов: var el = document.getElementById('myElement'); el.myaction = function (val) {alert(val)}; el.myvalue = true; el.myaction (el.myvalue); так же смотрите метод [Element].getAttribute("[attributeName]"); Если надо непосредственно через html-код задать какой-либо параметр, а потом его получить в JS. Но. В таком случае html-код уже не будет валидным, если использованы имена атрибутов отличных от указанных в спецификации. но, имхо, удобнее представлять объекты html, как значение свойств (параметров) объектов JS