SelenIT
-
Posts
4,327 -
Joined
-
Last visited
-
Days Won
140
Content Type
Profiles
Forums
Calendar
Store
Everything posted by SelenIT
-
А зачем?
-
Содержимое тега <script> по умолчанию воспринимается как разметка, а знак < в ней — как начало тега (естественно, несуществующего и незакрытого), что ломает XML-веллформность к бутявкам некузявым. Чтобы этого не происходило, скрипты нужно заворачивать в CDATA-блоки (а чтобы те не ломали сам скрипт, их дополительно приходится экранировать JS-комментами). P.S. Объединять клиентский XSLT и скрипт с использованием document.write — не лучшая идея.
-
Объявление переменной с помощью var предполагает, что слева от "=" — идентификатор, а в идентификаторе не может быть "[" и "]". Да и в чем смысл резать хвост кошке по частям инициализировать массив поэлементно, почему не целиком? var id = [458, 958, 145, 358, 256]; И кода меньше, и проблем
-
Ну так в этом и корень зла. Нет доктайпа — браузер в Quirks mode, в котором никто ничего не гарантирует. Хотите стандартов — ставьте стандартный доктайп (напр. <!DOCTYPE html>).
-
Доктайп какой? Такие приколы в Quirks mode частенько случаются.
-
И не только #table1 > tbody > tr > td {...} /* если вы не видите суслика, это не значит, что его нет =) */
-
http://jsfiddle.net/UuRKk/ ?
-
Абсолютно верно!
-
Длиннее, чем ничего (как в случае контекста/clearfix-а). Работает не везде и не всегда (проверьте в IE7). Является по сути текстовым контентом (а-ля символом \n), не несущим смысловой нагрузки и потому засоряющим документ. Негибко.
-
HTML5 вполне позволяет пользоваться строгим синтаксисом. Плюс, по мне лучше более вольный синтаксис, но строгая и однозначно предсказуемая DOM, чем строгий синтаксис, но фривольная DOM (типа таблицы, в которой tbody может быть, а может не быть) в XHTML. Хотя это, конечно, "на вкус на цвет"... но всё же мне кажется, для резкого отказа от совместимости с IE8- нужны какие-то более весомые причины
-
Ну да, не работает document.write() в FF в XHTML. Вот здесь советуют использовать асинхронную загрузку API для обхода. А для чего сильно "обскрипченному" сайту академический Content-type, чем штатный "всеядный" HTML5 не устраивает? которому доктайп вообще не нужен.. )
-
Перенос строки тут ни при чем, text-indent и подавно. А вот насчет margin-ов - это правильный ответ и совет. Кстати, у абзацев отступ "примерно со строку" по умолчанию (если его сгоряча не перебили каким-нибудь "ластиком").
-
Если ошибка не в 17-й строке (26-й символ), то... даже не знаю что думать, надо смотреть проблемный код (в идеале - в виде минимального тестового примера на jsfiddle.net, воспроизводящего проблему).
-
По общей логике, инпуты, а значит и лейблы, не обязаны находиться в форме - они могут быть частью чисто клиентского приложения, данные которого никуда сабмитить не надо (как минимум, в HTML4 это разрешалось - "The elements used to create controls generally appear inside a FORM element, but may also appear outside of a FORM element declaration when they are used to build user interfaces"). Так что решение не только остроумное, но и вполне надежное. Но лучше, конечно, продумывать логику страницы так, чтобы оторванных от родной формы контролов было как можно меньше!
-
Поток потоком, а на размеры документа абсолютно позиционированное что угодно влияет только в путь... Если задача - просто добавить картинки по бокам, может, лучше делать это не псевдами, а фонами на две внешние обертки?
-
http://css-tricks.com/indeterminate-checkboxes/ ?
-
Это при стандартных условиях он один . А шаг вправо/шаг влево (просмотр с мобилки, печать, RSS, поисковики, copy/paste и т.п.) — так разница в итоге и проявляется... И общее правило в таких случаях — чем меньше лишнего, тем меньше проблем. Исключения тоже бывают, но гораздо реже.
-
Минуточку, разве clear:left у нечетных элементов при таком раскладе не предполагается? вариант использовать c clear: both; Сорри, совсем не вариант, особенно в 2012-м.
-
До лучших времен (как справедливо отметила Catherine) придется трогать. И тупо дублировать для обоих состояний: .strategicRedButton { background-position: 0 199px; } .strategicRedButton:hover { background-position: -99px 199px; } P.S. Причем лучшие времена наступят явно нескоро: в CSS3 этих свойств уже совершенно точно не будет, только в CSS4...
-
В FF в обоих случаях выделение симметрично (видно, если покрасить фон body темным). Так и есть. В текущем CSS, насколько мне известно, нет. Только тупо подгонять line-height для каждого конкретного шрифта...
-
Это да, но иногда они ж, проказники, вылазят из него на прогулку...
-
Перед вторым циклом добавить s = []? И, кстати, имхо, var s = []; лучше внутрь функции внести — меньше глобальных проблем будет...
-
Да, сорри, я не сразу посмотрел код и понял, что фонт-сайз задается самому псевдику, не отошел в тот момент от соотв. статьи на хабре, где предлагали font: 0/0 для всего . С твоим фиксом этот способ действительно наилучший — и по чистоте кода, и по доступности. Для старых IE возможны варианты (вставка картинки одноразовым экспрешном, откат к конскому text-indent и т.п.), но, имхо, самое подходящее для них в 2012-м году — изящная деградация (с быстрой загрузкой и легкой читабельностью).
-
margin-bottom более высокому блоку разве недостаточно?
-
Разве одно лишнее слово в одном браузере хуже, чем вообще них ничего нигде?
