SelenIT
-
Posts
4,327 -
Joined
-
Last visited
-
Days Won
140
Content Type
Profiles
Forums
Calendar
Store
Everything posted by SelenIT
-
Ну зачем же так самокритично . Все когда-то начинали... А на будущее, очень рекомендую проштудировать этот ресурс. Там хорошо объясняется, как избежать подобных проблем...
-
А сделать этой страничке View Source не пробовали? На самом деле все передается, только не отображается, потому что браузер воспринимает это как незнакомый тег. Если нужно вывести на экран как код, htmlspecialchars действительно поможет.
-
Эта тема будет вечной В теории (в сухом остатке), HTML 4.01 Strict - для HTML-страниц с чистой логической разметкой, все оформительские вещи (цвет-размер и пр.) выносятся в CSS, а действия - в скрипты (даже target=_blank у ссылок нужно заменять скриптом!). HTML 4.01 Transitional - в принципе то же самое, но немножко пожертвовать стройностью кода ради красоты/удобства допускается, поэтому разрешены некоторые устаревшие теги и атрибуты (<font>, тот же target и т.п.). HTML 4.01 Frameset - только для наборов фреймов. XHTML 1.0 Strict, Transitional и Frameset - по сути все то же самое, но переписанное в более строгом XML-синтаксисе. Если сервер будет отдавать их как HTML, разницы с соответствующим HTML (при соблюдении правил совместимости, описанных в спецификации) не будет никакой. Если отдавать как XML - браузеры будут их по-другому парсить (в теории - чуть быстрее, хотя пользователь разницы не почувствует), по-другому строить объектную модель страницы для скриптов, а при ошибке синтаксиса XML - вместо страницы покажут желтый экран с сообщением об ошибке. IE всех версий умеет парсить их только как HTML. XHTML 1.1 - в первом приближении то же самое, что XHTML 1.0 Strict (за вычетом несущественных на практике мелочей). Но это в теории. На практике же браузеры смотрят на доктайп лишь с одной целью - выбрать режим отображения страницы. Это отдельная большая тема, про это можно почитать, к примеру, здесь. Если совсем грубо, браузерам важнее наличие доктайпа, чем его конкретный вид - доктайпы <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">, <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> и <!doctype html> (HTML5) во всех современных браузерах дают один и тот же эффект. Так что доктайп, по большому счету, важен лишь для валидатора. Но крайне желательно, чтобы вся страница заявленному доктайпу соответствовала, т.е. не только разметка проходила валидацию, но и стили были написаны в правильном регистре (особенно для XHTML) и т.д.. В случае XHTML простейший способ проверить это - сохранить файл с расширением .xhtml и открыть с диска Firefox-ом или Оперой, она должна выглядеть и работать так же, как и с расширением .html. Vindex10, Это да. Это как посмотреть. С точки зрения браузеров, при отдаче как HTML (т.е. в 99% случаев) их нет . И если <br /> понимается и действует как обычный <br>, то вот <a name="oops" /> превращается в незакрытый строчный тег. Так что я бы все же советовал переходить к XHTML осторожно и вдумчиво, с четким пониманием, чем он отличается от HTML и как применять его универсально.
-
Я бы даже сказал не "чревато", а "обязательно приведет к"
-
Bolmazov, это Вы смотрите в source принимающей страницы... или прямо в браузере?
-
Есть еще вариант graceful degradation, не требующий дополнительных каритнок. Правда, на практике она не всегда получается достаточно graceful...
-
По смыслу явно ul-li напрашивается - это же именно список вариантов. Плюс крайне желательно подписи в label-ы обернуть...
-
Странная идея. Зачем так объединять? При увеличении шрифта (в FF2/Safari, например) рвется визуальная связь между кнопками и подписями, оно надо? Плюс неплохо было бы обернуть подписи в label, чтобы они тоже стали кликабельными. Ну и совсем строго говоря, для такой группировки полей таблица не нужна...
-
Для данного типа документа - не только "ничего", а единственно правильно. Любые попытки его закрыть браузер проигнорирует, а валидатор посчитает ошибкой. Это HTML, а не XML
-
Знаю два способа — display:inline-block либо float:left без явного задания ширины. В обоих случаях, в теории, ширина должна считаться по алгоритму "shrink-to-fit" ("в обтяжку"), если содержимое умещается в одну строку. На практике первое, к сожалению, не работает в FF2 и не совсем корректно работает в IE (блочным тегам для того же эффекта в нем приходится задавать display:inline). Второе работает везде, но приходится бороться с сопутствующими проблемами ("вываливанием" блоков из контейнера, трехпиксельным отступом в том же IE и т.д.).
-
Точнее, то, что по ссылке — http://www.w3.org/TR/html4/strict.dtd. Но читать и расшифровывать его формат все-таки нелегко. Вышеприведенная страничка, где этот DTD разобран по косточкам, все логические зависимости повязаны ссылками и т.п., на мой взгляд, для понимания "что да почему" гораздо легче...
-
Там написано "Тип документа не разрешает элемент INPUT в этом месте". Но не поясняется, что за зверь этот загадочный "тип документа". Для непосвященного человека это может быть не понятно...
-
То, какие элементы где могут содержаться, задается в определении типа документа (DTD). Для HTML 4.01 Strict DTD такой. Для элемента FORM там указано: т.е. непосредственно в теге <form> могут находиться блочные элементы либо <script> (то, что в первых скобках). В свою очередь, блочные элементы определяются как следующий список: где, опять же, %heading; расшифровывается как любой из заголовков H1 — H6, %list; — списки UL и OL, а %preformatted; означает элемент PRE.Любые другие элементы непосредственно внутри формы DTD запрещает. Поэтому INPUT-ы и другие строчные элементы в форме обязательно нужно оборачивать во что-то блочное (из списка выше).
-
А нельзя задать эти border-ы не для ul, а для li в нем? Плюс padding-bottom для ul на размер нижнего рисунка...
-
Да, у Оперы известна такая проблема. Хотя стандарт такую запись разрешает.
-
Все-таки именно для IE5-6, при заявленном Doctype. В седьмом и выше эта запись работает только в Quirks mode.
-
Например, то, что все преимущества XHTML (кроме "дисциплинирования кодера") работают только при отдаче его со специальным Content-type application/xhtml+xml. Который, увы, не поддерживается (и, по-видимому, не будет поддерживаться) в IE. А FF2 (к счастью, на этой неделе объявленный устаревшим, но все еще удерживающий порядка 6% аудитории) отображает XHTML-страницы, отданные с правильным Content-type, лишь после полной загрузки. При отдаче же как text/html (что чаще всего и происходит) XHTML парсится тем же парсером, что и обычный HTML - со всеми его особенностями и недостатками...
-
Статья полезная и познавательная, но действительно перегруженная и неоднозначная. Самая главная мысль там, на мой взгляд — то, что XHTML 1.x не дает никаких преимуществ перед HTML 4.01 с точки зрения семантики: набор элементов/атрибутов там по факту один и тот же, выносить оформление в CSS можно точно так же, и т.д. Однако, когда далее автор говорит о "полной несовместимости XHTML 1.x" с "любым из будущих стандартов HTML/XHTML", он немного лукавит: на самом деле, именно потому, что HTML 4.01 и XHTML 1.x — по сути два синтаксиса описания одной и той же семантики, тот же подход сохраняется и в HTML 5, где допустимы оба варианта синтаксиса (разве что требования соответствия синтаксиса и Content-type стало более строгим). Вот несовместимость XHTML 1.1 и XHTML 2 - это действительно малоизвестный факт, не позволяющий с полным правом назвать первый "перспективным стандартом", тут я полностью согласен. А так аргументы автора во многом повторяют известный цикл статей Ивана Сагалаева на ту же тему. Хотя наглядная демонстрация того, чем обернутся многие широко известные примеры "якобы XHTML" (включая знаменитый PositionIsEverything) при настоящем XML-парсинге, безусловно, стоит того, чтобы задуматься о соразмерности цены овчинки и выделки (справедливости ради, за три года существования статьи многие "плохие примеры" существенно исправили свое поведение — напр., mezzoblue). Действительно, лучше один раз увидеть, чем сто раз услышать/прочитать: если уж берешься писать на XHTML — делай это так, чтоб результат не стыдно было показать настоящему XHTML-парсеру (а иначе зачем вообще с ним возиться?). Недостижимость полной совместимости XHTML и HTML при попытках отдавать браузерам разный Content-type "по их предпочтениям" — тоже важный момент, неплохо разобранный в статье. Правда, лично для меня самым убедительным доказательством стал пример разной DOM из одного исходника (у того же Сагалаева). Ну а ненадежность способов определения предпочтительного Content-type и экскурс в экзотические фичи SGML, напрямую конфликтующие с XML-синтаксисом "самозакрывающихся" тегов — лишь дополнительные аргументы о том, что эта задача — не просто "один IF в серверном скрипте", как часто доводится слышать от продвинутых XHTML-адептов (еще один весомый аргумент на чашу весов, "а надо ли оно вообще..." . Но в целом, по-моему, логика развития отрасли на сегодня подтверждает процитированные в статье слова техдиректора Оперы (и, по совместительству, создателя CSS) Хаукона Ли: "Я не думаю, что XHTML 2 — реалистичный вариант для массового пользования. Вот HTML 5 — да". По крайней мере, даже надежды автора статьи на то, что MS "вот-вот" начнет поддерживать application/xhtml+xml (оснванные, насколько я понимаю, на этом заявлении в блоге разработчиков, появившемся за три месяца до самой статьи) так и не оправдались: до обещанного релиза IE8 остались считанные месяцы, а поддержки как не было, так и нет (что в первой бете, что во второй)...
-
Вовсе нет. HTML 4.xx Transitional - полноценный стандарт, и в ряде случаев (например, при необходимости ставить target="_blank" для внешних ссылок) вполне может оказаться лучшим выбором. То, что браузеры отображают страницы с урезанным Transitional-доктайпом (без DTD) в Quirks mode - это совсем другая история...
-
Регистр имени файла/пути точно совпадает? Если сервер под *nix - регистр важен...
-
Можно. И лучше при этом оставить кнопку кнопкой - пусть лучше от наличия JS зависит лишь визуальный эффект (и то только в IE6), но не основная функциональность. Вот хорошая статья с примерами.
-
Регулировать длинну подвала при помощи обычного многоточия.
SelenIT replied to Timurco's topic in Tricks and solutions
Если уж бороться за семантику, так я бы и "звездочки" из HTML вынес... <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ru"> <head> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/> <title>test</title> <style type="text/css"> #author { padding: 1em; margin: 1em; text-align: center; border-top: 1px dotted #888; /* ...чем не точки? ;-) */ border-bottom: 1px dotted #888; } #author:before, #author:after { content: '**************'; /* чисто декоративные элементы - место им в CSS */ } #author em { font-style: normal; color: #FF4500; } </style> </head> <body> <div id="author">Дизайн и <em>верстка</em> — Тимур Ярматов</div> </body> </html> Правда, в IE будет работать лишь с 8-й версии. В других нормально. И еще замечание по примеру выше - если уж ставите XHTML, то пишите теги в нижнем регистре не только в коде, но и в CSS. Иначе с правильным Content-type не заработает... -
По-моему, нужно четко различать язык контента и язык интерфейса. Второе можно определять по Accept-language (не по геогрфическому положению на основе IP - человек может гостить в чужой стране или юзать провайдера с "иностранным" IP) и запоминать в куках, но разные языковые версии контента обязаны иметь разные адреса. Хотя... я бы и интерфейс переключал через явную ссылку Но по-хорошему совсем без серверного программирования (PHP и т.п.) тут не обойтись.
-
Что такого уж страшного во втором варианте? $tmp = array(); $result = mysql_query($query); while ($f = mysql_fetch_assoc($result)) { foreach ($f as $field_name => $value) $tmp[$field_name][] = $value; } echo '<table>'; foreach ($tmp as $row_name => $cells) echo '<tr><td>'.implode('</td><td>', $cells).'</td></tr>'; echo '</table>';
-
Да кто ж ему мешает валидацию-то пройти? Валидатор уже есть... Больше того, только в HTML5 проходят валидацию такие зачастую полезные вещи, как <input autocomplete="off">. Вообще, мне этот стандарт нравится тем, что ориентируется на практику, а не на идеализированную теорию. Взять тот же парсинг: формально старый HTML должен был парситься по правилам SGML (действительно запутанным и громоздким) с учетом DTD - но браузеры игнорировали и DTD, и эти правила, и применяли свои, во многом более простые (и правильно делали - если я ничего не путаю, по правилам SGML запись <br/> могла бы интерпретироваться бы как разрыв строки + символ ">", так что плакала бы обратная совместимость XHTML). HTML5, грубо говоря, просто методично описал, как парсят разметку реальные браузеры... и объявил этот алгоритм стандартом . И о тонкостях доктайпов наконец можно не задумываться. Честно признается, что доктайп нужен только для включения строгого режима при text/html - для него оставили "обрубок" <!doctype html>, и он корректно срабатывает во всех браузерах новее 6-го Нетскейпа (включая 6-й IE!). А для application/xhtml+xml (HTML5 включает и XML-вариант синтаксиса - т.н. "XHTML5") доктайп вообще не нужен, браузеры ориентируются не на него, а на пространство имен корневого элемента (xmlns="http://www.w3.org/1999/xhtml"). И такие страницы (без доктайпа!) тоже прекрасно отображаются всеми современными браузерами, поддерживающими этот режим (по факту - всеми, кроме IE). Так что пользоваться некоторыми преимуществами действительно уже можно. Хотя пока осторожно .