SelenIT
-
Posts
4,327 -
Joined
-
Last visited
-
Days Won
140
Content Type
Profiles
Forums
Calendar
Store
Everything posted by SelenIT
-
Ну по постановке задачи понятно же, что проблема на самом деле в HTML при white-space: normal . А исходник... да кто вообще в него смотрит, в исходник тот... кроме PHP-программиста, разве что?
-
Ну, котёнок — это чисто для наглядности. А вот попытка динамически добавить к подобной, с позволения сказать, форме еще один контрол в некоторых браузерах может вызвать сходные ощущения и у разработчика (насчет списка не ручаюсь, но с таблицами — лично напарывался на подобные грабли лет 8 назад). И чего ради? Ну что, что мешает вынести форму наружу <ul> и получить стабильную, предсказуемую и везде управляемую DOM-структуру?
-
Как вы можете без содрогания смотреть на <form> между <ul> и <li>... это ж всё равно, что живому котёнку запихать что-то между внешней стенкой желудка и шкурой... ему же больно!
-
Vertical-align для инлайнов центрирует относительно высоты строки, а не блока. Для произвольного кол-ва строк, имхо, лучше всего display: table-cell для самих ссылок: http://jsfiddle.net/mC3j2/1/
-
Необученность студии хорошим манерам не избавляет от отвественности
-
Разметку вначале приведите в порядок. UL вам не див какой-нибудь, чтоб пихать в него что попало, как заблагорассудится.
-
Проверьте на validator.w3.org вот такое: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <title>HTML 4.01 Strict!</title> <p>свободу содержимому тегов!
-
Если кол-во видов деятельности фиксированное и каждая фирма может относиться к любому их числу (т.е. связь многие ко многим) — то конечно выносить их в отдельную таблицу и делать впридачу к ней таблицу связи вида "id фирмы — id вида деятельности". С правильными индексами будет не медленнее, чем одна монстроподобная таблица. Если картинки уникальны для каждой фирмы, то логично оставить их полями в основной таблице фирм.
-
И забыть про вкладывание одних интерактивностей в другие (как <input type="submit"> в ссылку в первом примере). Помимо невалидности, это бред с точки зрения элементарной логики: когда браузер заставляют разрываться и выполнять взаимоисключающие команды — добра не жди.
-
Кстати, Strict — это не про синтаксис, а про набор тегов/атрибутов (HTML 4.xx тоже бывает Strict). А плюсы от XML-синтаксиса проявляются лишь при XML-разборе, для HTML-парсера он, наоборот, источник возможной неоднозначности...
-
Валидно. Более того, рекомендовано Гуглом
-
Буквально определение из спецификации переводится как Т.е. говорит элементу, что он сам (если речь о "поплавке") или его строчные потомки (если речь о блоке - а значит, и сам блок) должны целиком провалиться под самый высокий из вышестоящих "поплавков" с соответствующей стороны (с любой стороны в случае both). Если надо, для этого вводится просвет ("clearance", клиренс), который добавляется к верхнему margin-у и "отпихивает" элемент от предыдущего блока ровно настолько, сколько нужно, чтоб вышестоящие поплавки ему не мешали (см. тж. здесь).
-
Кстати, послезавтра официально заканчивается поддержка FF3.6 для неандертальцев. Наконец можно будет полностью забыть о префиксах для border-radius и box-shadow!
-
Почему так, неплохо раскрыто в этой старинной статье (примеры 7 и 8 - как раз проблема и решение).
-
Отлично (правда, медленно, но результат стоит ожидания) сжимает PNGшки Color Quantizer.
-
Возможно, но не в IE. Еще варианты описаны здесь.
-
IE4-5 — скорее всего какие-то старые боты, имхо.
-
Я говорил про большинство пользователей Windows среди людей, не являющихся дизайнерами или пафосными столичными менеджерами Старые IE, да, сейчас, наверное, только в бедных госконторах и у отдельных принципиальных чудаков...
-
Дело не в href, а в id, который используется как якорь. В примере id задан ссылкам, поэтому и :target-ами будут они. Были бы id-ы у li-шек - работало бы для них.
-
Как правильно использовать тег <img> и p:first-letter
SelenIT replied to Vitaliy S's question in HTML Coding
Вообще-то все варианты так себе. В чем конечная задача? Может, <img> тут просто не нужен? -
CSS-пикселей там всё равно 1024?768. Так что кол-во CSS-пикселей (по стандарту обязанных стремиться к 1/96 дюйма) и размер экрана всё-таки неплохо коррелируют (хотя разброс, да, основательный).
-
Первая строка вставляет перенос строки через каждые ($maxlen - длина префикса) символов. Вторая подставляет в начало каждой строки сам префикс. В итоге получаются строки общей длиной $maxlen, каждая из которых начинается с префикса (имитация цитирования в текстовых емейлах). Точка — конкатенация строк. На моё имхо, функция далека от совершенства — логичнее разбивать не тупо по лимиту символов, а по границам слов (пробелам) в пределах лимита (через регулярки). Но для быстрого начала сойдет)
-
Как при таких раскладах ведет себя исходная страница «о компании»? Моё имхо основано на том, что поиск по сайту — в общем-то разновидность навигации. И «принципу наименьшего удивления» больше отвечает ситуация, когда одна и та же сущность является пользователю однотипным образом вне зависимости от того, каким путем он на эту сущность вышел. И если по логике сайта показ отдельной вакансии — состояние страницы "о компании" (со всем связанным контекстом, подразумеваемым важным для соискателя — иначе зачем было вакансию в этот лайтбокс заталкивать, а не делать отдельной страницей, удобной для закладок/распечатки, с самого начала?), то логичнее это же состояние и из поиска выдавать.
-
Мне тоже последний кажется самым логичным. А остальные — созданием лишних сущностей
-
Потому что писать вот такое НЕЛЬЗЯ: Веб — не полиграфия. У пользователя может быть совсем другой шрифт, другой масштаб и т.п., поэтому нельзя заранее предсказать, какую площадь займет контент с точностью до пикселя — и запереть его в железную клетку с такими размерами. Свободу контенту! Редакторы типа "плетущего-во-сне", к сожалению, этому не помогают. Вообще сайт нужно переверстывать полностью. Начиная от отсутствия доктайпа (прощай надежды на адекватность в IE) и заканчивая злокачественными новообразованиями напрочь не нужных в основной массе таблиц.
