
SelenIT
Expert-
Posts
4,327 -
Joined
-
Last visited
-
Days Won
140
Content Type
Profiles
Forums
Calendar
Store
Everything posted by SelenIT
-
Посмотрите на DOM этого фрагмента (в Файрбаге, Dev. Tools-ах, Стрекозе и т.п.). Когда пройдет первое удивление от результата, перечитайте спеку про тег <p> — что может, а что не может находиться у него внутри. И впредь не ставьте браузеры в такое щекотливое и двусмысленное положение. HTML — это вам не XML.
-
ВНЕЗАПНО и о5 Эх, ну когда уже хоть какой-нибудь из CSS3 layout-ов допилят...
-
По клику форма сабмитится, браузер посылает запрос и переходит в режим ожидания ответа (как при переходе по ссылке). В некоторых браузерах (IE в частности) в этом случае эффекты с картинками не применяются (в этом есть какая-никакая логика — какой смысл делать новый запрос, чтобы что-то поменять в странице, которая всё равно вот-вот будет целиком заменена чем-то новым). По идее, должна помочь замена дефолтного сабмита программным — дописать в конец онклика this.form.submit();return false. Но не проверял, поэтому не гарантирую.
-
А доктайп какой? Без доктайпа любой IE — IE 5.5...
-
И не только фиг, но и спека CSS2.1...
-
Ctrl+0. И впредь аккуратнее с колесиком мышки при нажатом контроле, у мозиллы, как выясняется, хорошая память на такие мелочи
-
Куча дублирования (почти идентичные ф-ции f1...f3, явно просящиеся в одну с параметром), переколбашивание DOM там, где достаточно смены стилей, оформление (кавычки, пропавший пробел между id и name — кстати, напрочь не нужным — в разметке, и т.п.), перемешанность в кучу JS и HTML, нелогичное именование ф-ций и переменных... Ну и недоступность ссылок для поисковиков, само собой (если, конечно, это не было извра... ой, изощренной целью). В общем, практически всё, извиняюсь за прямоту.
-
<input type="image" name="some_name[123]" .... и ключ на стороне сервера
SelenIT replied to warobushek's question in HTML Coding
Никогда не использовал, но по беглому анализу — вполне надежно. Браузеры, в соответствии со стандартом html4, передают пару some_name[123].x и some_name[123].y, а во что это преобразует PHP — это уже его серверная забота (не очень очевидная, судя по всему, но ломать обр. совместимость никто не заинтересован). -
Да. Правильно window.location = name. Но Great Rash прав, код — леденящее душу... неведомое древнее хтоническое нечто, летящее на крыльях ночи (причем как для человека, так и — особенно — для поисковиков). Сделайте по-простому, как все нормальные люди: три готовых ul-ки с обычными ссылками, спозиционируйте их абсолютно куда надо, по умолчанию задайте им display:none (удобнее всего через класс), а по наведению этот класс убирайте. И поисковики будут довольны (все ссылки видны), и отлаживать/улучшать (напр., добавлять к появлению/исчезновению красивенькую анимацию) будет на порядок проще
-
Новогодний совет от ископаемого Яндекса, часть вторая?
-
Пиксели — относительные единицы. Подавляющее большинство современных массовых пользователей (как бы это ни было печально для мастодонтов — приверженцев текстового зума, включая меня) меняет не размер шрифта, а масштаб всей страницы (вместе с рисованными надписями и прочей графикой), и блок будет увеличиваться пропорционально тексту в нем. Для 1% юзеров FF, включающих в настройках масштабирования галочку "Только текст", можно заменить height этого блока на min-height — при штатных условиях ничего не изменится, а при нештатных — ничего не вылезет. Em-ы округляются по-разному в разных браузерах, что приводит к скачущему (всего на пиксель, но всё равно "неаккуратненько") межстрочному расстоянию. К тому же непонятно, что делать с обычными картинками (сохранять с запасом по разрешению и ужимать?) и фонами (background-size, а для IE — AlphaImageLoader?). А проценты и вовсе не позволяют привязать размеры блоков к размеру шрифта — для размерностей длины у них совсем другой смысл...
-
Возможно, скажу ересь. Но, имхо, если IE6 не важен и главная задача "чтоб не разваливался дизайн" (а не "чтоб текст читался при любых капризах стихии"), то ничего нет лучше старых добрых пикселей. У всех более-менее новых браузеров есть "адаптивный зум", позволяющий масштабировать пиксельные надписи (в т.ч. на картинках), не вываливаясь при этом за края экрана (до определенного предела, конечно, но на практике его хватает). Чуть-чуть пострадать могут разве что пользователи IE7, но так им и надо при зуме там и em-ы не помогают...
-
Насколько я понимаю, да
-
Не обязательно через <a>, можно через <button>
-
internet explorer + <button> + смещение при клике
SelenIT replied to klierik's question in HTML Coding
А простого обнуления маргинов/паддингов кнопки недостаточно? -
Разве не 29 августа 1997?
-
Моя телепательная машинка подсказывает, что это и подразумевалось, но длинные слова заголовка не могут втиснуться в фиксированное пространство слева от картинки. Если так, то, имхо, единственный более-менее нормальный выход — вручную расставить в особо длинных словах мягкие переносы ()...
-
Насколько я понимаю, основная суть <hgroup> — объединить заголовок и подзаголовок в монолитную структуру и показать, что это такой хитрый заголовок одного блока, а не заголовок раздела + заголовок подраздела. Без него подзаголовок создал бы отдельную неявную секцию (с точки зрения outliner-а), что явно не соответствует замыслу автора.
-
Стало интересно, насколько можно минимализировать этот макет в плане графики. На правах прикола — вот такое безобразие (пока FF4 only, о пиксельной подгонке речи нет, чисто демо идеи, делал очень впопыхах, через час в поход ухожу просто ). Интересно, в правильное направление я смотрю или мимо?..
-
В ЖHTML на <hr> возложена роль "тематической отбивки" между абзацами в пределах секции (смена места действия в рассказе, переход к другой теме в рамках одного раздела справочника и т.п.). Хотя случаи, когда требуется именно это, имхо, всё равно будут довольно редкими. А вертикальные разделители между колонками (где еще может понадобиться "вертикальная линия" в тексте, по дефолту выкладывающемся горизонтальными блоками?), конечно, логичнее всего делать бордерами.
-
Если ничего не путаю, есть вариант с созданием временной таблицы в памяти и запросом с inner join с ней, в каких-то тестах вроде быстрее выходило. Но поддерживаю предыдущих отвечающих — сначала нужно просто привести базу в человеческий вид. И лишь затем, если проблема останется, оптимизировать запрос.
-
А может, речь про background-attachment: fixed для body?
-
"Отменить" прозрачность потомков прозрачного элемента нельзя. Если нужен непрозрачный элемент на прозрачном фоне контейнера, то одно из двух — либо контейнер не должен быть прозрачным, а иметь лишь прозрачный фон (png-картинку или, более современно, rgba-цвет + фильтр для старых IE), либо картинка должна быть не внутри этого контейнера (а лишь спозиционирована поверх него).