SelenIT
-
Posts
4,327 -
Joined
-
Last visited
-
Days Won
140
Content Type
Profiles
Forums
Calendar
Store
Everything posted by SelenIT
-
Насколько я в курсе, в новом HTML есть две ипостаси "волшебного икса": легитимизация многострадальных слешей в обычной HTML-сериализации (которая text/HTML) и XML-сериализация как таковая (с необязательным доктайпом, но обязательным правильным. Content-type). На гордое звание несуществущего XHTML5 может претендовать лишь второе. И то, видимо, уже нет - в свете новости от WHATWG о переходе на безверсионную модель...
-
По-моему, сейчас распределение тупости в вебе сместилось: пропихиванием своей проприетарщины сейчас рулят яблочные с гугловыми на хвосте, а мелкомягкие, наоборот, маниакально и дотошно реализуют старые "проверенные временем" наработки W3C (типа CSS2.1. и - ВНЕЗАПНО - XHTML). Снова будто назло, но уже по-другому Остается лишь надеяться, что мелкомягким хватит ума не грохнуть ту отсебятину, которая за эти годы вошла в черновики стандарта (типа text-overflow и т.п.) Говоря о MS, я имею в виду эволюцию IE8 -> IE9. Всё, что раньше - история.
-
Оно упоминается в разделе спеки, помеченной как non-normative, не знаю, насколько это серьезное основание принимать его в качестве термина . Но обработка application/xhtml+xml в браузерах, по-моему, действительно ближе к описанной в спеке для XHTML-синтаксиса HTML5, чем к чему-либо другому.
-
Имхо, скорее наоборот. Насколько я понимаю, это попытка (не от хорошей жизни стандартизировать то, что происходит с настоящим XHTML (который application/xhtml+xml) в реальных браузерах (DTD и вообще доктайп побоку, работают все теги, включая те, что deprecated, можно внедрять другие неймспейсы типа SVG и MathML и т.п. + некоторые новые скриптовые радости). По-моему как раз разумная штука — только для очень специфичных задач, как и "настоящий XHTML" прежде (по крайней мере, пока IE8- живы). Название, да, странное, но оно и не считается официальным, это условность чисто "для краткости". Существующие страницы на XHTML 1.x (c правильным Content-type) с точки зрения браузеров — всё равно XHTML5, по построению стандарта.
-
Vlad, спасибо, пороюсь в этом направлении, может, найду заветную комбинацию). rus, огромное спасибо за ссылку, похоже, то, что надо! И пример, и ссылка на доку... Буду изучать!
-
Простейший <!DOCTYPE html> тоже должен помочь.
-
Спасибо, поищу. Но всё равно недоумеваю, ведь такая элементарная и часто востребованная вещь наверняка должна делаться как-то совсем просто...
-
Неправда, нужно везде соблюдать правила того языка, на котором пишешь. Или <table width="500"> (HTML), или <table style="width:500px"> (CSS), но не <table width="500px"> (нежизнеспособный противоестественный гибрид. Другое дело, что по-хорошему явному заданию размеров в разметке вообще делать нечего...
-
Vlad, да, так. Колос, про макросы интересно, а где можно найти какой-нибудь туториал "для полных чайников" по ним и тамошнему яваскрипту? rus, спасибо за наводку, учту на будущее!
-
Делаю толпу превьюшек для галереи, из инструментов под рукой только фотошоп. Создаю action, применяю. На выходе — пачка миниатюр 120х80 (как мне и надо), но почему-то каждая весит 18-30 кБ (обычно такие весят килобайт 5-7). Ладно, записываю новый экшн на базе "Save for web" с качеством 60, натравляю на ту же папку... и фотошоп радостно пересохраняет мне все файлы со всеми EXIFами, в результате каждая превьюха весит уже 30-40 кБ (!). Я знаю, что я ламер и 90% действий делаю через "не то". Но как решить проблему и всё-таки заставить фотошоп массово пожать картинки? Не верю, что он этого не умеет, ставить левые смотрелки и т.п. только ради этого не охота. Заранее спасибо за любые подсказки/наводки.
-
Насколько я понимаю, к тому идет. WHATWG собирает все свои наработки в большую кучу под старым именем Web Applications 1.0, и разметка (включая требования к ее парсингу браузерами) — лишь небольшая часть этой кучи...
-
Ух ты, мой любимый X-оливор! Вообще по сабжу есть две классические статьи — на русском и на импортном (во второй всё разложено даже слишком подробно, особенно глава "Myths of...", разве что примеры некоторые уже устарели). Имхо, главная причина фейла XHTML — как ни странно, HTML-совместимость. Из-за которой он стал восприниматься "трудящимися массами" как всего лишь "новый модный HTML, в котором нужно ставить слеши в <br> и <img>". Если бы создатели изначально продвигали его как замену HTML, работающую по принципиально другим правилам, способную закрыть собой не только нишу традиционного HTML, но и гораздо более широкий спектр задач, не оставляя лазеек в стиле "одной ногой мы еще стоим в социализме поддерживаем NS4, а другой уже шагнули в коммунизм перешли на XML" — возможно, как ни странно, с приходом новых браузеров новшество получило бы большее распространение. Правда, еще вопрос, нужен ли был для этого отдельный язык, ведь сам по себе XML уже тогда поддерживали все браузеры (даже IE5.5+ — в отличие от XHTML, увы. Но тогда в этом еще был бы прок. А если разрешить практически ничего не менять, кроме косметических нюансов (доктайп, пресловутые слеши и т.п.) и при этом считаться модным — к гадалке не ходи, что 99,9...% воспользуется именно этой опцией и напрочь проигнорирует главную вкусность новшества. Так и вышло... Нет. И ни один парсер не увидит. В отсутствие кавычек естественный ограничитель значения — пробел. В этом плане, согласен, обязательность кавычек для всех атрибутов (особенно value полей форм) — явный плюс. Какая-никакая подстраховка от XSS. Но при отсутствии понимания, как работают реальные парсеры браузеров — очень слабая. А повальная мода на XHTML-валидность по W3C-валидатору такому пониманию, увы, далеко не способствовала...
-
caligula, покажите "неработающий" пример. Всё должно работать, только для новых элементов нужно указывать display:block (по умолчанию они ведут себя как span), скорее всего где-то в коде опечатка. ЕМНИП, 2-й ФФ поддерживал новые теги только в XHTML-режиме (c типом контента application/xhtml+xml и т.п.). В обычном HTML, насколько я в курсе, стало работать начиная с 3.0.
-
Насколько я понял, там на это дело натянут двойной пре... дохранитель: подчеркивание перед свойством оставляет его видимым только для старых IE, а дальше уже ветвятся условия внутри этого вымирающего семейства. Так что риск, что какая-либо новая версия чего-либо будет понимать первую запись и не понимать вторую, всё-таки исчезающе мала, и в данном конкретном случае "плонето безопасносте" . Но злоупотреблять подобной бякой, конечно, не стоит. Как вариант, специально обученным динозаврам можно отдавать полнофункциональную, но полностью лишенную красоты и удобства мобильную версию... Потому что внутри <style> не может быть никаких тегов, содержимое <style> не обязано парситься как HTML-разметка (скорее наоборот и реакция браузера на HTML-коммент внутри <style> может быть непредсказуемой (вплоть до ошибки). Вот так еще допустимо: <style> /* нормальный код */ </style> <!--[if lt IE 7]> <style> /* извратный код для старых IE */ </style> <![endif]-->
-
Gnom7, по той ссылке как раз речь про расширение для FF в режиме Tidy, а Tidy — не валидатор как таковой, т.е. "сверялка" кода с DTD-схемой (а-ля validator.w3.org), а "HTML Linter", т.е. инструмент для приведения кода к хорошему стилю. В чем-то они с валидатором солидарны, а в чем-то дополняют друг друга. На практике Tidy, возможно, даже полезнее (особенно в случае XHTML). Насчет пустых элементов логика у него простая — в них нет смысла, их не увидят текстовые браузеры и поисковики, а "раз не видно разницы, зачем писать больше". Но иногда такие элементы действительно нужны для оформительских (как минимум, пока CSS3 не получил полной поддержки) и интерфейсных целей, поэтому слепо подчиняться советам Tidy не стоит — вебмастеру, в конце концов, виднее. А настоящий валидатор против этого ничего не имеет.
-
Да, я был невнимателен, про Mobile Profile 1.0 и Basic я просмотрел, признаю (просто ту ссылку привели как аргумент применительно к обычному XHTML 1.x, и отвечал я применительно к нему же), насчет script для базового/мобильного XHTML согласен. Насчет остального можно поспорить — многое из того, что писали в книгах 90-х (и даже более новых) скорее стыдно "знать". Скорее всего, речь в них шла о пустых td-шках, которые, действительно, древние нетскейпы отказывались отображать без внутри. Как минимум, спецификация XHTML 1.0 ясно говорит: Запись <span /> в XML (и, соответственно, XHTML с правильным Content-type) полностью эквивалентна записи <span></span>, обе они валидны. Другое дело, что при отдаче как text/html браузер кладет большой игнор на слеш в ней и воспринимает эту конструкцию как незакрытый тег. Поэтому эта конструкция и "не рекомендуется" к использованию. Если я еще что-то упустил, буду всё же благодарен за доказательства...
-
гхм... всё-таки стрёмное это дело - гиф-анимация
-
Предлагаю за предложения делать бегущую строку гиф-анимацией ввести наказание в виде 3-х суток непрерывного принудительного просмотра этой страницы (а за рецидив - еще и упячки вдобавок, во всплывающем окне поверх. И хорошо бы еще через модем или GPRS...
-
Ради возможности сделать фон (просвечивающий через дырку в картинке и дающий эффект "перекраски" иконок) и текст одного цвета, но разнести их в пространстве, чтоб не сливались. Но что делать, раз нельзя, значит нельзя - придется добавлять в ссылку span (для иконки) и задавать фон ему...
-
Определить line-height, но не через style.lineHeight
SelenIT replied to clavin's question in JavaScript
document.getElementById('ddd').currentStyle.lineHeight в IE и document.defaultView.getComputedStyle(document.getElementById('ddd'), '').lineHeight в остальных не годятся? -
eyexal, так почему всё-таки эта высота так влияет? Не помогает даже position:relative (для обоих действующих лиц). Убрать высоту не вариант (до смены разметки). Менять разметку, видимо, придется, но хочется узнать, где в такой конструкции нарушение стандарта... psywalker, подвох появляется, когда высота ссылки оказывается больше высоты li-шки.
-
Имеется ряд ссылок с display:block, выступающих за границы родительского элемента с display: inline-block (живой пример — главное меню на www.zgames.com). В IE7-8, FF и Вебкитах это работает как ожидается, но в актуальных Операх (как минимум начиная с 10.61, включая альфу 11) и IE9 beta в режиме IE9 наблюдается странная вещь: нижние выступающие части ссылок почему-то некликабельны, а в Операх вдобавок текст этих выступающих частей исчезает при скроллинге и появляется заново только после наведения. Неужели так и должно быть по стандарту? Буду крайне благодарен за подсказку, какому месту стандарта противоречит такая конструкция. Задача, для которой понадобился такой изврат — возможность менять цвет иконок меню (на внутр. страницах) из админки, независимо от цвета ссылок. Цвет заливки просвечивает через иконки, "вырезанные" из нейтрального фона (по типу маски). Заливать всю ссылку нельзя, т.к. при отключенных картинках текст может слиться с фоном. Тривиально решается доп. блоком внутри ссылки (скорее всего, так и сделаю), но всё равно интересно узнать, можно ли реализовать ее без добавочной разметки...
-
Объединять имеет смысл ради уменьшения кода (gzip, конечно, скрадывает разницу, но не до конца) — ускорение загрузки. А ради ускорения отрисовки надо рефакторить саму верстку и уменьшать кол-во блоков с фильтрами и (тем более) экспрешнами. 10 разных блоков с фильтрами - не здорово. Тем более "opacity=100" в фильтре — вообще странно, для полной непрозрачности лучше совсем убрать фильтр. А вообще при теперешней доле IE6 его юзеров вполне можно оставлять без полупрозрачных красивостей — абы функционал быстрей показывался...
-
В IE нельзя определить в обработчике, какая кнопка из нескольких button type="submit" на форме была нажата (отправляются innerHTML всех имеющихся вместо value одной нажатой, как положено). Поэтому если нужна разная чисто серверная функциональность для разных кнопок, то button-ы, увы, "не катят". Если же кнопка одна (чисто чтоб засабмитать), никаких преград нет (факт отправленности можно проверять по актуальным переменным, а то и по request_method-у). Но главное (имхо) преимущество кнопок перед ссылками и т.п. (помимо семантики) — именно легкость в обозначении интерактивной природы в дефолтной браузерной манере. Если дефолтная браузерная отрисовка (надо полагать, наиболее привычная юзеру данного браузера) — не плюс, а минус (дизайнер-извра"оригинал"), проще сразу извернуться скриптом (как делают всевозможные CKEditor-ы и т.п.).
-
Вдогонку: судя по тем же грандам, валидностью (и вообще "идеологической чистотой") мобильной версии можно не париться?
