SelenIT
-
Posts
4,327 -
Joined
-
Last visited
-
Days Won
140
Content Type
Profiles
Forums
Calendar
Store
Everything posted by SelenIT
-
Как минимум чтобы ссылки были ссылками, а не дивами с onclick, чтобы у форм была нормальная кнопка для отправки (и валидация формы на сервере, само собой), чтобы важная информация по умолчанию не была невидимой и т.п. Вообще для мобильной версии чем всё проще, тем лучше, как я понимаю, с мобильников ходят за информацией, а не сказочными красотами...
-
С Transitional получается другой режим, "почти стандартный", я имел в виду именно Strict (неважно, X или нет). Вообще, лишние 25 пикселей наводят на мысль о вываливании за body маргинов заголовка или чего-то подобного, о том, чтобы на это влияла разница режимов, не слышал, но сильно не удивлюсь, если оно так. Интересная тема, надо будет покопаться.
-
Насколько я в курсе, так и должно быть. Мини-опера сама не выполняет JS, а эмулирует его работу на сервере (том самом, который сжимает для нее разметку и графику). Лучше делать мобильную версию сайта не зависящей от JS (не считая продвинутых устройств типа айфонов и андроидов, где работает почти всё то же, что и на десктопе).
-
Смена изображения при наведении на кнопку формы <input>
SelenIT replied to chillout's question in HTML Coding
Просто обернуть кнопку в <span> с нужной фоновой картинкой оказалось недостаточно? -
Новые браузеры не будут спрашивать, переходите вы или нет, они будут разбирать страницы по правилам HTML5 независимо от заявленного доктайпа. HTML5 is not an option. Это, конечно, не значит, что нужно напропалую бросаться использовать новые теги, WebForms2, клиентское хранилище, геолокацию и прочие вкусняшки... но учесть это придется. 100$, что с любым другим строгим доктайпом было бы то же самое. Но буду безумно благодарен за пример. Хотя с ифреймами у IE9 вообще отдельная тема — один новый специальный квирксмод для них чего стоит...
-
Смена изображения при наведении на кнопку формы <input>
SelenIT replied to chillout's question in HTML Coding
Как вариант — по наведению делать кнопку полностью прозрачной (opacity:0), чтобы через нее просвечивала фоновая подложка с нужным рисунком. -
Может, путь к файлу стилей попал под горячую руку какому-нибудь AdBlock-у или другой резалке рекламы? Для надежности я бы переименовал каталог во что-нибудь менее провоцирующее.
-
Не совсем, разные режимы в зависимости от доктайпа есть у всех браузеров. У каждого браузера есть свой "черный список" архаичных доктайпов (включая отсутствие доктайпа) для включения Quirks mode, и список поменьше (обычно туда входят Transitional- и Frameset-варианты HTML 4.0x и XHTML 1.0) для переходного режима (хорошая табличка). Другое дело, что в своих квирксмодах другие браузеры ведут себя приличнее, чем IE, и, как правило, не отрубают поддержку новых фич. Но не все и не всегда (у Оперы даже в переходном режиме бывают сюрпризы). Поэтому, чтобы не гадать, отчего не работает та или иная фича (от ошибки кодера или документированной причуды браузера), самое простое и практичное решение — последовать совету Светланы и писать на "ЖHTML" ("живом хатээмэле", наиболее близком к браузерной реальности и становящемся к ней всё ближе) с простым доктайпом <!doctype html>. Это гарантирует во всех браузерах максимальную поддержку новых фич, на какую они только способны. Кстати, одиночные теги в нем можно писать и со слешем, и без, этим в нем тоже не нужно заморачиваться
-
http://forum.htmlbook.ru/index.php?showtopic=13589&view=findpost&p=93519 ?
-
Да, я извиняюсь, поторопился. В ячейке, да с height=100%, без дополнительной обертки действительно не работает. Вот так вроде работает (по крайней мере, в последних версиях): <!DOCTYPE html> <head> <style type="text/css"> body { margin:0; padding:0; width:100%; height:100%; position:absolute; } div { position:absolute; top:100px; bottom:50px; width:100%; } </style> </head> <html> <body> <table height="100%" width="100%" border="0" cellpadding="0" cellspacing="0" bgcolor="green"> <tr height="100px"> <td> </td> </tr> <tr> <td bgcolor="yellow"> <div> <iframe width="100%" height="100%" frameborder="0" src="http://google.com/"></iframe> </div> </td> </tr> <tr height="50px"> <td> </td> </tr> </table> </body> </html> Правда, при таком подходе сама таблица оказывается не сильно нужна...
-
Единственный вариант, который могу предложить — position:absolute;top:100px;bottom:50px.
-
Для IE существует вот такое: http://home.roadrunner.com/~bmerkey/examples/landscape-test.html Для других сходу не вижу другого пути, как дрессировать трансформации (применять их к выборочным таблицам, добавлять в нужных местах page-break-before и т.п...).
-
Разумеется. Однако в эпоху XHTML-мании очень часто раздавались голоса "зачем учить HTML 4, он немодный и неперспективный, надо учить XHTML 1". А то, что XHTML 1.0 полностью повторяет семантику HTML 4.01 (чьим XML Reformulation является), как-то забывали. И слепо поклонялись слешам, напрочь забыв о сути. Конечно, это тоже не проблема языка, но издержки его неудачной популяризации (и неправильного позиционирования, где-то). И в итоге тот "притянутый" пример стал очень даже типичным (я не раз встречал в реальной практике). Лично я с прошлой страницы отстаиваю тезис, что проблема HTML — вовсе не в "простом синтаксисе для домохозяек". Проблема непрофессионального веба — в бездумности, непонимании смысла своих действий, что выливается в надругательство над семантикой языка. И формальное ужесточение синтаксиса (с которым XHTML оказывается даже проще HTMLя, т.к. в нем нет неявного закрытия тегов и подобных неочевидностей) эту проблему никак не решает — скорее наоборот. В общем, перефразируя классика: "Разруха — не в кавычках и слешах, она в головах" И в этой связи меня терзают обоснованные сомнения, что "волшебному иксу", после общепризнанного 10-летнего фейла, утраты очевидных преимуществ и выявления явных недостатков, удастся вторично завоевать этот самый "волшебный" ореол "крутизны". Я бы поставил и ящик пива, что в ближайших лет 10 этого не случится. Разве что MS решит окончательно затроллить W3C и начнет маниакально продвигать application/xhtml+xml в своих новых сервисах...
-
Беда XHTML в том, что он не приучает к порядку, он приучает к формальности. И дает опасную иллюзию, что кодеру не надо думать, будто за него уже подумали валидатор и сам дизайн языка. Типа, соблюдай три несложных правила (закрытие тегов, слеши в одиночных и кавычки в атрибутах) — и всё всегда будет в шоколаде. Даже если написать <p>абзац <h1>с заголовком</h1> внутри</p>. XML веллформный, оснований для "желтой карточки" нет. И если в HTML такой код может хотя бы намекнуть горе-кодеру, что он слегка неправ (отсутствием стиля для абзаца у слова "внутри"), то в XHTML браузеру придется завязаться в узел, но как-то с грехом пополам отобразить такую противоестественную структуру. А думать надо. Всегда. Независимо от выбранного синтаксиса/стиля. Потому что работа кодера именно в этом. А недостающие слеши эти многострадальные, если надо, может и редактор через автозамену расставить...
-
Похоже, этот древний-древний баг: https://bugzilla.mozilla.org/show_bug.cgi?id=8253 Не должно ничего изменить, имхо. Единственная альтернатива, которую я вижу — сделать этот эффект скриптом (добавляя еще один <span> для первой буквы динамически). Но проще убедить заказчика "не хотеть странного", по-моему.
-
Спасибо за информацию (я, если честно, не знал). Но должен уточнить. В спецификации сказано, что :first-letter применяется к блочным контейнерам, к которым относятся любые элементы с display:block (независимо от их изначального происхождения). Так что в данном случае span полностью подходит под соотв. определение. И более того, в статическом случае (просто для .moduletablemenu li a span:first-letter, без :hover) псевдоэлемент в нем срабатывает! Так что, похоже, здесь всё-таки досадный баг Мозиллы.
-
Т.е. ради одной возможности писать в доктайпе какую-то длинную тарабарщину вместо простого и понятного <!doctype html> и зеленой галочки валидатора верстальщики повально начнут отказываться от уже успевших полюбиться многим <article>, <section> и т.п., я верно понял? При том, что по новому стандарту доктайп для application/xhtml+xml вообще не нужен?
-
Для повального перехода мало "крутизны", нужны явные преимущества. 10 лет назад, когда всеобщая XMLизация считалась единственно верной дорогой, в качестве таких преимуществ предлагались пресловутая легкость парсинга ("доступность каждой микроволновке") и интеграция с др. неймспейсами, прежде всего SVG и MathML. Сегодня любой уважающий себя мобильник может осилить HTML5-парсер, который позволяет внедрять SVG и MathML и в text/html (со всеми его преимуществами устойчивости к непредвиденностям), а основная сложность приходится на CSS и от стиля разметки не зависит. Какой эксклюзив может сегодня предложить "волшебный икс"?
-
Кстати, на это: В том-то и дело, что HTML позволяет правильно написать одно и то же несколькими способами (принцип TIMTOWDI). И этим можно пользоваться (выбирая из этих способов наилучший с точки зрения поддержки браузерами и т.п.). Писать с ошибками, ясное дело, никто не призывает. Но и в SVG тоже можно написать <ellipse></ellipse> вместо <ellipse/> А вот XHTML в невалидирующем режиме дает возможность написать вопиюще неправильно с точки зрения логики/семантики HTML DOM (упомянутая ссылка в ссылке), и никакой желтый экран за это не накажет (потому что формальный синтаксис XML соблюден). Хотя, по большому счету, синтаксис для веба — ничто, семантика — всё
-
Потому что HTML — это язык для Cети. С разными каналами — проводными и без, быстрыми и медленными, стабильными и не очень. И желательно, чтобы большая и полная полезной информации страничка не превращалась в тыкву оттого лишь, что где-то мышка бежала, хвостиком махнула. И кривой и неуклюжий HTML дает в этом больше гарантий, чем стройный и сексуальный X. "Лень/не лень" — это детский сад. Разумеется, я буду соблюдать правила пользования любым инструментом. Но то, что любая собака типа аутпоста может порушить мою с любовью вылизанную верстку и конечный пользователь вместо нее увидит красные крокозябры на желтом фоне, меня не устраивает. И, полагаю, не только меня. Хотя да, городить многоэтажные проверки вместо простого 3-кратного повторения parentNode (для доступа к многострадальной таблице из ячейки) всего лишь из-за того, что кому-то было лень учесть элементарную логику DOM в парсере (под предлогом "заставить кодеров писать строго") мне, действительно, не очень-то хочется
-
Сила HTML5 в однозначности правил перевода быдлокода в нормальный DOM. Поэтому его не сможет убить ни один файрвол и ни одна секретарша. Но требования соблюдения логики страницы там строже, чем в (X)HTML, дешевым трюком типа "<span>вот строка, куда <ins>ВНЕЗАПНО <div>я вставил блок</div></ins> гыгы</span>" их уже не обманешь.
-
Нет, потому что стандарт написан с запасом прочности. Есть единственный вариант DOM-структуры и есть несколько равнозначных способов ее описания разметкой (один предпочтительный — все теги в одном регистре, все атрибуты в кавычках и т.п., но и другие допустимые). Да, цена такой устойчивости — усложнение парсинга, но на деле не так уж оно катастрофично (пример парсера HTML5 это доказывает). XML — хорошая попытка упростить парсинг, но цена этого — потеря устойчивости. Минимальные отличия в коде, вплоть до форматирования, выливаются в различия в DOM, т.е. в функциональность и поведение. Стоило разработчикам стандарта XHTML попытаться "простить кодерам" <tbody> в таблице (на том основании, что "никто его не пишет") — накрылась переносимость многих яваскриптов, полагавшихся на постоянство структуры таблицы. Потому, что у XML такого запаса прочности не было. Если же парсить XHTML невалидирующими парсерами (в реальных браузерах именно так) — как быть с ситуациями типа "абзац в абзаце" или "ссылка в ссылке", бессмыслменными и невозможными в HTML, но формально не нарушающие XML-веллформности и потому не вызывающие "желтого экрана смерти"? А насильно валидировать каждый раз — лишний запрос DTD и лишнее время на обработку (если только сервера W3C вообще выдержат такую нагрузку). Парсинг разметки — пустячная часть процесса построения и отображения страницы в современном браузере, и далеко не в нем главная сложность. А попытки вынести сложность из парсинга вынуждают еще больше усложнять последующие стадии, потому что сама-то сложность логики построения страницы (дефолтное поведение разных элементов и т.п.) никуда не девается.
-
Тем не менее, в HTML можно быть уверенным, что хоть одно TBODY в DOM-е любой таблицы будет — неважно, есть оно в коде или нет, и TABLE всегда будет четвертым по счету предком ячейки. В XHTML это не гарантировано и полностью дано на откуп автору, и table может быть и четвертым, и третьим. Так где строгости больше?
-
Проблема в том, что ошибку мог допустить не только верстальщик/контент-менеджер/программист. Но и, например, Agnitum Outpost со включенной резалкой баннеров, заменявший их на жуткий ужас (популярная причина отказа от XHTML в 2005-2007-м). Хочу — делаю таблицу с tbody, хочу — без... это строгость?
-
Тоже верно. Красивая идея "вот-вот сделать веб доступным для микроволновок" путем упрощения парсинга донельзя ценой неудобств для обычных пользователей и неучета имеющегося контента изначально была несбыточной.
