Комментарии 241
Поаплодировал бы. Уже на втором шаге становится понятно как все просто то.Спасибо
C текущими ограничениями задачи решение справляется на 5.
Но чем не угодили таблицы?
Но чем не угодили таблицы?
Некоторые framework'и, например Zend. Сами отрисовывают форму но не использую таблицы. Проще грамотно написать CSS, чем переопределять.
Спасибо за отличный ответ. Сохранил в шкатулке аргументов для использования.
Хоть Zend и не использую, но таблицы в сложных динамически изменяющихся формах весьма напрягают, а вот пояснять это на словах с примерами обычно лень, поэтому не хватало как раз такого простого и ясного аргумента. :)
Хоть Zend и не использую, но таблицы в сложных динамически изменяющихся формах весьма напрягают, а вот пояснять это на словах с примерами обычно лень, поэтому не хватало как раз такого простого и ясного аргумента. :)
А как же встречный вопрос «С каких пор форма — это табличные данные?»*
_______
* Хотя, к сожалению, это обычно попахивает холиваром.
_______
* Хотя, к сожалению, это обычно попахивает холиваром.
Ну попахивает… а что сделать если нормальные доводы часто пахнут либо минусами, либо холиваром =)
НЛО прилетело и опубликовало эту надпись здесь
ну тат как раз таки можно трактовать форму как таблицу: имя поля — значение поля
Я сначала об этом подумал, но потом решил, что такое определение притянуто за уши.
Однако, когда я нахожу независимое повторение своих мыслей, я задумываюсь пуще прежнего… (=
Итак, W3C какбэ говорит нам:
Однако, когда я нахожу независимое повторение своих мыслей, я задумываюсь пуще прежнего… (=
Итак, W3C какбэ говорит нам:
The HTML table model allows authors to arrange data — text, preformatted text, images, links, forms, form fields, other tables, etc. — into rows and columns of cells.источникОфициально признаю: я был неправ.
Ещё немножко из стандартов. HTML Techniques for Web Content Accessibility Guidelines 1.0 гласит:
С приветом, ваш холивароненавистник. (:
5.3 Не используйте таблицы для создания макета (каркаса), если таблица, будучи приведённой к линейному виду, не имеет смысла. («линейный вид» — это содержимое ячеек таблицы в виде строки, порядок содержимого определяется порядком появления ячеек в вёрстке — прим. перев.)Соотнеся предыдущую цитату и эту, можно сделать вывод, что мы имеем право без зазрения совести сверстать форму используя таблицы, однако никто не запрещает сделать то же самое с помощью блоков и CSS.
5.4 Если таблица используется для создания макета (каркаса), то не используйте структурную разметку с целью визуального форматирования.
К примеру, содержимое элемент <th> (table header) обычно отображается отцентрованным и полужирным начертанием. Если же ячейка не является заголовком, то следует использовать CSS или атрибуты элемента (а не ставить элемент <th> вместо <td> — прим. перев.)
С приветом, ваш холивароненавистник. (:
В Zend_Form используется связка тегов dl, dt,dd
Ну не любят некоторые таблицы, и все)
Если серьезно, тыблицами получается больше тегов.
Если серьезно, тыблицами получается больше тегов.
Если закрывающие теги не использовать, то меньше.
А вообще, ИМХО слишком очевидная вещь, чтобы на неё тратить 6 скринов и столько текста ) Хотя всё-равно спасибо автору за труд.
Ещё наверно можно решить проблему разделив метки и поля по двум блокам.
А вообще, ИМХО слишком очевидная вещь, чтобы на неё тратить 6 скринов и столько текста ) Хотя всё-равно спасибо автору за труд.
Ещё наверно можно решить проблему разделив метки и поля по двум блокам.
Закрывать или нет — это все равно, т.к. речь идет о элементах, а не их текстовом представлении
спецам, может, и очевидное… а начинающим — даст понимание, как сделать именно так и что такое float и clear. Доступно, наглядно, просто.
есть хорошая статья на эту тему
>Ещё наверно можно решить проблему разделив метки и поля по двум блокам.
просто убило!!! ((( верстаем дивами, а мыслим таблицами?
просто убило!!! ((( верстаем дивами, а мыслим таблицами?
сто раз уже поднималась эта тема, ну ё-моё.
вот Вы все сделали таблицами, на сайте куча форм.
заказчик: надо сделать label сверху, а input шириной 100%.
серверная часть написана на компилируемом языке, шаблонный движок для форм — часть программы.
ваши действия какие?
автору топика надо в css файле 1 строчку заменить.
вот Вы все сделали таблицами, на сайте куча форм.
заказчик: надо сделать label сверху, а input шириной 100%.
серверная часть написана на компилируемом языке, шаблонный движок для форм — часть программы.
ваши действия какие?
автору топика надо в css файле 1 строчку заменить.
Когда у них инпуты будут разной и не очень предсказуемой длины — вернутся к таблицам, как миленькие.
не будьте так уверены.
НЛО прилетело и опубликовало эту надпись здесь
А альтернативы нет. Все эти забавы с тремя одинаковыми инпутами не стоят электричества, которыми они написаны. Как только появляются задачи из реальной жизни — здравствуй таблица.
А это — вполне пример из жизни)
бросьте Вы чепуху говорить.
Чепуху?
А давайте представим, что второй инпут будет шириной в два символа, потому что это как будто возраст и нефиг ему таким длинным быть. Ваш ход? Или, вернее — ваш код?
А давайте представим, что второй инпут будет шириной в два символа, потому что это как будто возраст и нефиг ему таким длинным быть. Ваш ход? Или, вернее — ваш код?
Хочу заметить, Вы заставляете меня решать задачу в контексте чужого кода, который, кстати, меня не совсем устраивает.
Вот ответ:
.field input[type=text] {
width: 14em;
}
.field input.age {
width: 4em;
margin-right: 10em;
}
Если он Вас устраивает, пожалуйста, верните карму — без тегов писать очень неудобно.
Вот ответ:
.field input[type=text] {
width: 14em;
}
.field input.age {
width: 4em;
margin-right: 10em;
}
Если он Вас устраивает, пожалуйста, верните карму — без тегов писать очень неудобно.
Вы знаете — совершенно не устраивает. Это IE7:
Я знаю в чем проблема и фикс в состоянии придумать, но не в этом дело. Все это игры в песочнице. Я прошу прощения за такой элементарный пример — не хотел никого оскорблять, поторопился. Надо было промолчать, как обычно.
Для описания реальной проблемы мне нужно потратить час, как минимум. Написать ТЗ, практически. Я не готов сейчас этим заниматься. И уж точно, никто из читателей не станет тратить свои часы даже на ознакомление с документацией.
Карму вернул — я хотел лишь выразить отношение, но не ограничивать функционал.
Я знаю в чем проблема и фикс в состоянии придумать, но не в этом дело. Все это игры в песочнице. Я прошу прощения за такой элементарный пример — не хотел никого оскорблять, поторопился. Надо было промолчать, как обычно.
Для описания реальной проблемы мне нужно потратить час, как минимум. Написать ТЗ, практически. Я не готов сейчас этим заниматься. И уж точно, никто из читателей не станет тратить свои часы даже на ознакомление с документацией.
Карму вернул — я хотел лишь выразить отношение, но не ограничивать функционал.
Я знаю, что предложенное мной решение не кроссбраузерное из-за [type=text], но, как Вы правильно сказали, это легко исправляется (как я полагал тут была важнее принципиальная, а не техническая реализация).
Однако, не соглашусь с Вами, это не игры в песочнице. Я очень много делал форм, в т.ч. очень сложных и никогда не прибегал к таблицам.
Да, можно придумать задачу, которая без таблиц решается очень сложно (но все же, решается). Однако эти частные (и не частые) проблемы с лихвой окупается гибкостью кода и, главное, разделением данных и их представления.
Однако, не соглашусь с Вами, это не игры в песочнице. Я очень много делал форм, в т.ч. очень сложных и никогда не прибегал к таблицам.
Да, можно придумать задачу, которая без таблиц решается очень сложно (но все же, решается). Однако эти частные (и не частые) проблемы с лихвой окупается гибкостью кода и, главное, разделением данных и их представления.
1. Не из-за [type=text].
2. Бестабличные решения «любой ценой» — не окупаются.
Я могу предположить откуда непонимание. Вы, вероятно, делали много форм для разных проектов в одну-две итерации. Моя проблема — в постоянной поддержке и дополнениях для многолетних проектов. У меня нет возможности «за месячишко» проапдейтить весь CSS и оттестировать так, чтобы все работало.
2. Бестабличные решения «любой ценой» — не окупаются.
Я могу предположить откуда непонимание. Вы, вероятно, делали много форм для разных проектов в одну-две итерации. Моя проблема — в постоянной поддержке и дополнениях для многолетних проектов. У меня нет возможности «за месячишко» проапдейтить весь CSS и оттестировать так, чтобы все работало.
1. Не из-за [type=text]
Хорошо, перефразирую: как минимум из-за [type=text]. Это не важно в текущем контексте.
«за месячишко» проапдейтить весь CSS
Это расхожее заблуждение, каюсь, раньше рассуждал так же!
При постоянной плотной работе с «бестабличной» версткой решения в общем случае уже известны и оттестированы. И при правильном построении архитектуры css-файлов «весь CSS» апдейтить не придется, т.к. отвечающий за расположение элементов формы код локализован.
Что касается «поддержки и дополнений многолетних проектов», тут соглашусь, если Вы делаете формы руками, то, конечно уже абсолютно не важно, используете ли вы таблицы или нет, потому что проблема скрыта гораздо глубже.
Я убежден, что любая форма — это проекция некоторой сущности в программе на ее интерфейс и, соответственно, ни одна форма не должна строится «руками». Изменять программно строящиеся формы проще всего средствами CSS, в случае бестабличной верстки. Если в проекте таблицы, придется либо, в лучшем случае, менять xslt-шаблоны генерации форм, в самом же печальном случае, менять код программы, что вообще недопустимо.
Игра шириной и отступом справа — хорошая идея. Но не понятно что делать с выпаадющими списками. При попытке задать для них фиксированную ширину браузеры делают их все-равно уже, чем инпуты, и соответсвенно они не выравниваются по левому краю за счет отступа справа :-(
С элементами формы ситуация вообще сложная, т.к. они по-разному отрисовываются в разных браузерах почти всегда.
Поэтому, я предпочитаю работать с оберткой элементов в div или dl dt dd (потому и сказал выше, что код меня не совсем устраивает).
Соответственно, думаю, проблема с выпадающим списком решается установкой ему значения width: 100%, а нужную ширину и отступ надо задать его контейнеру. Также через обертки намного проще добиться кросс-браузерности.
Поэтому, я предпочитаю работать с оберткой элементов в div или dl dt dd (потому и сказал выше, что код меня не совсем устраивает).
Соответственно, думаю, проблема с выпадающим списком решается установкой ему значения width: 100%, а нужную ширину и отступ надо задать его контейнеру. Также через обертки намного проще добиться кросс-браузерности.
Uni-From (http://sprawsm.com/uni-form/)
Все примеры из реальной жизни решал или с помощью Uni-From с небольшими допиливаниями или с помощью своих CSS без таблиц.
Все примеры из реальной жизни решал или с помощью Uni-From с небольшими допиливаниями или с помощью своих CSS без таблиц.
я собственно о том же и намекнул.
за свою жизнь сверстал туеву хучу форм «из реальной жизни» и ни разу даже в голову не пришло сказать «здравствуй таблица».
бред какой-то.
за свою жизнь сверстал туеву хучу форм «из реальной жизни» и ни разу даже в голову не пришло сказать «здравствуй таблица».
бред какой-то.
Ваш пример не дотягивает по сложности даже до того, что в постинге. Фиксированная колонка — проблем с ресайзом нет, потому что нет ресайза. При попытке «зарезинить» колонка с лейблами плюет на контент и занимает половину экрана по-любому.
Почему же, я кое-где, например, использую ширину в 35% для лейблов, то есть всё тянется и занимает не половину экрана, а 35% от родительского элемента.
Опять же по этим 35% удобно выравнивать другие элементы (кнопки, подсказки и т.д.).
P.S. В примере sprawsm.com/uni-form/ label шириной 45%.
Опять же по этим 35% удобно выравнивать другие элементы (кнопки, подсказки и т.д.).
P.S. В примере sprawsm.com/uni-form/ label шириной 45%.
У меня экран в 2000 пикселей. Представляете, где оказался ваш лейбл, когда я фиксированную ширину убрал? Не в кассу ваш пример, из-за фиксированной колонки у вас не было обсуждаемых проблем.
С таблицами будет не так?
Вообще говоря это дело верстальщика, не нужно делать форму на 100% от экрана.
В приведенных вами случаях нет никаких преимуществ таблиц над дивами.
Вообще говоря это дело верстальщика, не нужно делать форму на 100% от экрана.
В приведенных вами случаях нет никаких преимуществ таблиц над дивами.
У меня разрешение экрана 2560×1600 — 26 дюймовый монитор.
Представляете какая маленькая у вас таблица регистрации для меня?: р
имхо — не люблю строго заданные размеры на сайтах… они больно мелкие для меня -((
p.s.
zoom спасает
Представляете какая маленькая у вас таблица регистрации для меня?: р
имхо — не люблю строго заданные размеры на сайтах… они больно мелкие для меня -((
p.s.
zoom спасает
Представляю )
Но делать сайты на 100% от ширины экрана надо уметь, иначе можно получить плохо читаемый и понимаемый контент.
Не вижу ничего плохого ни в фиксированных, ни в резиновых сайтах. Просто и то и другое надо делать с умом.
Предпочитаю делать плавающую ширину с ограничениями по максимальной и минимальной ширине, если нет других условий по дизайну.
Но делать сайты на 100% от ширины экрана надо уметь, иначе можно получить плохо читаемый и понимаемый контент.
Не вижу ничего плохого ни в фиксированных, ни в резиновых сайтах. Просто и то и другое надо делать с умом.
Предпочитаю делать плавающую ширину с ограничениями по максимальной и минимальной ширине, если нет других условий по дизайну.
НЛО прилетело и опубликовало эту надпись здесь
это ваш выбор, не нужно его навязывать другим. Верстаете подобное таблицами, верстайте с большим удовольствием. Я вообще не понимаю как можно разводить холивар из-за таблиц и не таблиц… нравятся таблицы, верстаете ими, а кому-то ими не нравится, кто-то хочет семантическую вёрстку и не просто потому что это для кого-то модно, а потому что нужно. И на будущее не думайте, что у вас товарищ опыта больше чем у других.
Причем тут холивар? Я хочу не победить (Митьки никого не хотят победить), а найти решение. Просто меня разочаровал (опять) шум вокруг хорошего, но очень элементарного решения.
И не считать себя опытнее других на фоне этих комментов очень сложно.
И не считать себя опытнее других на фоне этих комментов очень сложно.
Извините конечно, но вы разницу не чувствуете где у вас есть опыт и где его нет. Я понимаю таблицами вы верстать умеет большой молодец. Но если вы не понимаете в чём смысл отказа от таблиц и в чём преимущество максимального использования css, то лучше воздержаться вообще в чужой теме свои мысли продвигать. Когда будет топик как сверстать форму таблицами вы будете блестать своим опытом, а в данной теме вы ничего не понимаете. к сожалению.
Опыт? Да больше половины комментирующих не знают, что такое hasLayout или верстка одной формы для разных языков.
С чего вы взяли, что я не вижу смысла в отказе от таблиц? Откуда вы взяли, что я не использую CSS «максимально»? Почему я не должен воспринимать эти фразы как хамство с вашей стороны?
Я не хочу верстать таблицами. Мне неудобно. Но супер-семантика вне ваакума статей на хабре еще не работает.
С чего вы взяли, что я не вижу смысла в отказе от таблиц? Откуда вы взяли, что я не использую CSS «максимально»? Почему я не должен воспринимать эти фразы как хамство с вашей стороны?
Я не хочу верстать таблицами. Мне неудобно. Но супер-семантика вне ваакума статей на хабре еще не работает.
НЛО прилетело и опубликовало эту надпись здесь
Семантика в таких вещах — это философия в программировании. Безусловно
А на практике, главное это результат.
Примерная аналогия — можно прийти в загс в костюме, а можно в джинсах и футболке. Результат будет одним — ты станешь женатым человеком (если за этим правда приходил туда :)). Вопросы соответствия нормам абстрактны так же как и сами нормы (пример — течения панков, готов и эмо в музыке).
А на практике, главное это результат.
Примерная аналогия — можно прийти в загс в костюме, а можно в джинсах и футболке. Результат будет одним — ты станешь женатым человеком (если за этим правда приходил туда :)). Вопросы соответствия нормам абстрактны так же как и сами нормы (пример — течения панков, готов и эмо в музыке).
У
вообще никакой семантики нет, если что. Так что в данном случае правильнее всего .У
div вообще никакой семантики нет, если что. Так что в данном случае правильнее всего dl.НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
С чего бы это? Описание значения — значение.
Красивое решение. Одно замечание: атрибут for у тега <label> должен совпадать с id элемента формы, а не с его атрибутом name.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Поработаю немного за КО, пока он занят в другом топике, и предложу Вам написать что-то интересное в Песочницу =) С удовольствие схожу к Вам на премьеру ;)
Зачем вы так? Некоторые в подобной ситуации скрипя зубами используют таблицы.
Кто не знал — узнал, остальные прошли мимо.
Кто не знал — узнал, остальные прошли мимо.
НЛО прилетело и опубликовало эту надпись здесь
Уважаемый diggy. Если Вы считаете, что пост не актуален для Вас, зачем вы пишете комментарии?
Сходите перекусите.
Я «пользовался таблицами стилей» и до сих пор пользуюсь. Верстаю уже не первый год.
Тут простое и элегантное решение, освежающее память. Да, это не изобретение велосипеда и не прорыв в верстке. Но зато автор напомнил, что можно быть проще. Порой бывает, что так навалом работы, что сам себе все усложняешь.
Я «пользовался таблицами стилей» и до сих пор пользуюсь. Верстаю уже не первый год.
Тут простое и элегантное решение, освежающее память. Да, это не изобретение велосипеда и не прорыв в верстке. Но зато автор напомнил, что можно быть проще. Порой бывает, что так навалом работы, что сам себе все усложняешь.
Спасибо!
Взял на заметку
Взял на заметку
Очень изящное решение. Спасибо, буду использовать. И не только на формах — вы навели на кое-какие мысли расставлять элементы и в других областях с помощью схожего метода.
Выравнивание полей формы помощью CSS — не хватает предлога «с»
а мне понравилось, простенько и со вкусом
Кстати, в этом способе нельзя делать перенос строки в описании поля. Иначе большой line-height сделает не самую приятную картинку. Поэтому таблицы все равно универсальнее…
ЗЫ: vertical-align работает для inline элементов, коеми являются <input>
ЗЫ: vertical-align работает для inline элементов, коеми являются <input>
хорошее решение, но хорошо бы причесать:
избавиться от зависимости можно задав line-height в ex.
body {font-size:14px;}
.field {clear:both; text-align:right; line-height:25px;}
избавиться от зависимости можно задав line-height в ex.
НЛО прилетело и опубликовало эту надпись здесь
непонятно, почему из-за float сбилось вертикальное выравнивание.
Уже что-то подобное использовал, но без дивов, одни лэйблы и инпуты, просто необходимо тогда задавать длину лэйбла.
я использую другой вариант
результат тотже
<style>
.form_line label
{
display:inline-block;
display:-moz-inline-block;
width:120px;
}
</style>
<div class="form_line">
<label></label>
<input />
</div>
результат тотже
У Вас label фиксированной ширины
Лучше наоборот:
display:-moz-inline-block;
display:inline-block;
Тогда третий фаерфокс подхватит правильный стиль.
Но способ в принципе содержит очень много косяков, многострочные и просто высокие поля и подписи можно забыть.
display:-moz-inline-block;
display:inline-block;
Тогда третий фаерфокс подхватит правильный стиль.
Но способ в принципе содержит очень много косяков, многострочные и просто высокие поля и подписи можно забыть.
НЛО прилетело и опубликовало эту надпись здесь
А как сделать, чтобы input занимал все возможное место в блоке известной длины, если у него есть «сосед» неизвестной длины?
Схематично:
div width:500px
input
span float:right (width — неизвестен, динамически изменяющийся контент)
/div
То есть span должен прижиматься справа, а input занимать все оставшееся место.
Схематично:
div width:500px
input
span float:right (width — неизвестен, динамически изменяющийся контент)
/div
То есть span должен прижиматься справа, а input занимать все оставшееся место.
Классно! Спасибо!
Все круто, спасибо, только с точки зрения логики тут требуется не дивы, а DL-список.
Сорри, что немного не по теме — давно хотел поделиться, но на отдельный пост не тянет.
Очень нравится для разметки парных данных (название — поле ввода, имя — значение и т.п.) использовать списки определений DL.
название1 поле ввода1
название2 поле ввода2
…
В коде выглядит очень логично и красиво.
Очень нравится для разметки парных данных (название — поле ввода, имя — значение и т.п.) использовать списки определений DL.
название1 поле ввода1
название2 поле ввода2
…
В коде выглядит очень логично и красиво.
НЛО прилетело и опубликовало эту надпись здесь
Что за привычка вообще вкладывать элемент input в элемент label?
НЛО прилетело и опубликовало эту надпись здесь
Это хорошая привычка, т.к. не требует id в инпуте
В данном случае не подходит
В данном случае не подходит
Большинство браузеров при таком написании автоматически привязывают label ко вложенному в него input.
Т.е. при нажатии на label выделяется вложенный input.
IE 6 точно так не умеет. :(
Т.е. при нажатии на label выделяется вложенный input.
IE 6 точно так не умеет. :(
этот способ подразумевает лейбл отдельно от инпута
Попытка №2
… использовать списки определений DL.
<DL>
<DT>название1 </DT> <DD>поле ввода1</DD>
<DT>название2 </DT> <DD>поле ввода2</DD>
…
</DL>
…
… использовать списки определений DL.
<DL>
<DT>название1 </DT> <DD>поле ввода1</DD>
<DT>название2 </DT> <DD>поле ввода2</DD>
…
</DL>
…
что-то тебя упорно игнорируют… хотя + ставят =)
Может и мне свое добро таким способом апгрейдить… Хотя я уже забыл когда в последний раз вручную верстал форму…
Может и мне свое добро таким способом апгрейдить… Хотя я уже забыл когда в последний раз вручную верстал форму…
попробовал dl списки… разочарован =(
Получается, что элемент формы (без применения css) всегда будет занимать 2 строки: строку «название» и строку «поле». Допустим у нас есть форма из 15 элементов (хотя такие редко встречал). Для ее отображения нужно 30 строк по примерно 25px каждая. Итого 750px + у сайта есть header + у браузера есть toolbars всякие. В итоге чтобы гарантировано увидеть всю форму нужен монитор с разрешением 1600*1200 (ну если вы минималист, то 1280*1024 и то впритык). Перебор как по мне.
Если же ударяться в css, то тут уже нужно колдовать (не забываем также про проклятый IE6). И решение уже не блещет изящностью.
Блин… не суждено мне с таблиц в формах уйти :'( Как не смотри, а они для форм наиболее универсальны, хотя и избыточны…
Получается, что элемент формы (без применения css) всегда будет занимать 2 строки: строку «название» и строку «поле». Допустим у нас есть форма из 15 элементов (хотя такие редко встречал). Для ее отображения нужно 30 строк по примерно 25px каждая. Итого 750px + у сайта есть header + у браузера есть toolbars всякие. В итоге чтобы гарантировано увидеть всю форму нужен монитор с разрешением 1600*1200 (ну если вы минималист, то 1280*1024 и то впритык). Перебор как по мне.
Если же ударяться в css, то тут уже нужно колдовать (не забываем также про проклятый IE6). И решение уже не блещет изящностью.
Блин… не суждено мне с таблиц в формах уйти :'( Как не смотри, а они для форм наиболее универсальны, хотя и избыточны…
НЛО прилетело и опубликовало эту надпись здесь
Жизнь сурова и иногда бывают селекты различной ширины, и в это трудно поверить, но и ногда даже чекбоксы и радиокнопки: www.picamatic.com/show/2009/07/15/04/44/4448332_bigthumb.PNG
наиболее универсальным решением будет:
label — фиксированная ширина
input — тоже float: left
field — убрать text-align и по уму будет заменить div.class на fieldset
После этого можно добавлять любые инпуты и смотреться оно будет стабильно ровно
наиболее универсальным решением будет:
label — фиксированная ширина
input — тоже float: left
field — убрать text-align и по уму будет заменить div.class на fieldset
После этого можно добавлять любые инпуты и смотреться оно будет стабильно ровно
Насчет селектов разной длины — верно. А за чекбокс и радиобаттон справа от лейбла — геена огненная. С гвоздями.
Подразумевается, что размеры инпутов одинаковые
Обычно в макетах так и бывает
Если нужен малениький инпут, то это все равно решается
Обычно в макетах так и бывает
Если нужен малениький инпут, то это все равно решается
В конце концов, чекбокс и радио-батон можно взять в блок такой же ширины, как и инпут
в конце концов — идеальным будет решение с минимальным количеством тегов и css для них.
Я просто сообщил, о том, что увидел прочитав пост по диагонали, это не в упрек было сделано, а с той целью, чтоб вы выняли урок и облегчили себе жисть в будущем. Можете также доработать пост и демо. Ведь именно в этом прелесть блогов и сообщества, чем больше пишешь — тем больше сам умнеешь. ну, всмысе пока дают писать и не заминусуют.
Я просто сообщил, о том, что увидел прочитав пост по диагонали, это не в упрек было сделано, а с той целью, чтоб вы выняли урок и облегчили себе жисть в будущем. Можете также доработать пост и демо. Ведь именно в этом прелесть блогов и сообщества, чем больше пишешь — тем больше сам умнеешь. ну, всмысе пока дают писать и не заминусуют.
НЛО прилетело и опубликовало эту надпись здесь
глупости, адекватное применение таблицы — там где табличнве данные и только. Завтра заказчик попросит сделать label над input. Автор уберет у label float:left и напишет dispalay:block, а вы полезете шаблоны по сайту править.
НЛО прилетело и опубликовало эту надпись здесь
вы сами нд этими словами думали? «область имеющая строки и столбцы» — это сейчас, когда нужен такой вид. Потом — не «ничего страшного», а переделывание на «так как нужно». У вас может и являются компромиссом, мой опыт мне говорит о полном отказе от таблиц в формах, как бы те смотрелись.
Страшное видно, нужно будет переделывать, и здесь не имеет смысла оправдывать решение.
Адекватное применение таблицы — там где это оправдано. В реальном мире «где табличные данные и только» не выдерживает никакой критики, т.к. есть сроки.
Не нравится тег table? Используйте xml+xslt. Не знаете xslt? А о чем тогда вообще говорить?
О том, что поддерживать конструкцию из трех дивов и 20 строчек css на много сложнее, чем таблицу и 5 строчек css, я вообще молчу.
Сейчас семантика в html — понятие крайне абстрактное. Особенно когда «должно было быть готово еще вчера».
Да, верстка дивами каркас а сайта — прекрасно. Но мелкий компонент CMS внутри не стоит ни одной строчки css.
Ко всему надо подходить с умом и искать компромисс. Серебряной пули не существует.
Не нравится тег table? Используйте xml+xslt. Не знаете xslt? А о чем тогда вообще говорить?
О том, что поддерживать конструкцию из трех дивов и 20 строчек css на много сложнее, чем таблицу и 5 строчек css, я вообще молчу.
Сейчас семантика в html — понятие крайне абстрактное. Особенно когда «должно было быть готово еще вчера».
Да, верстка дивами каркас а сайта — прекрасно. Но мелкий компонент CMS внутри не стоит ни одной строчки css.
Ко всему надо подходить с умом и искать компромисс. Серебряной пули не существует.
клон TolTol?
>>Не нравится тег table? Используйте xml+xslt. Не знаете xslt? А о чем тогда вообще говорить?
а это из какой такой оперы, почему вдруг задето? Давай и в xslt эту тему помуссируем, нос утру — мне не тяжело.
>>Не нравится тег table? Используйте xml+xslt. Не знаете xslt? А о чем тогда вообще говорить?
а это из какой такой оперы, почему вдруг задето? Давай и в xslt эту тему помуссируем, нос утру — мне не тяжело.
таблице де факто не могут быть адекватным решением — они сковывают макет. и от применения css толку будет мало.
поправьте если не так, но всё же правильнее будет
.field label { описание }
дабы не «задевать» других лейблов на странице
кстати, добавив в стиль label { text-align:right; остальное из примера } может получится вполне интересное решение
.field label { описание }
дабы не «задевать» других лейблов на странице
кстати, добавив в стиль label { text-align:right; остальное из примера } может получится вполне интересное решение
спасибо за пост) недавно столкнулся как раз с такой проблемой… решение очень оригинальное.
Все прекрасное — просто :)
У меня такой задачи не было, обычно ширина заголовков идет фиксированная. За способ спасибо — может в будущем пригодится ;)
У меня такой задачи не было, обычно ширина заголовков идет фиксированная. За способ спасибо — может в будущем пригодится ;)
Проще использовать два блока, к примеру так:
Хотя ваше решение очень легко поддерживать.
<div style="float:left;">
<label for="n1">Имя</label>
<label for="ln">Фамилия</label>
<label for="a1">Место жительства</label>
</div>
<div style="float:left;">
<input type="text" id="n1" />
<input type="text" id="ln" />
<input type="text" id="a1" />
</div>
Хотя ваше решение очень легко поддерживать.
Да, ваше решение хорошо, но, правда, поддерживать сложнее
Не проще. Т.к. если потом прийдётся расположить описание сверху инпута — вам прийдётся перевёрстовать.
НЛО прилетело и опубликовало эту надпись здесь
Получется, что логически label слабо связан с input, находятся в разных блоках.
Можно использовать то, что предложил Aivean habrahabr.ru/blogs/css/64530/#comment_1796474
НЛО прилетело и опубликовало эту надпись здесь
в мемориз
Спасибо за статью. Все четко и понятно расписано.
Взял на заметку.
Взял на заметку.
Если бы еще и submit можно было под инпуты выровнять, то вообще прекрасно было бы…
www.picamatic.com/show/2009/07/15/05/28/4448772_349x115.jpg
www.picamatic.com/show/2009/07/15/05/28/4448772_349x115.jpg
Я бы использовал более семантичную разметку:
Красиво и не нужно придумывать лишние id.
<fieldset>
<label><span>Поле:</span><input/></label>
<label><span>Поле2:</span><input/></label>
</fieldset>
Красиво и не нужно придумывать лишние id.
Да, у Вас хорошее решение. Единственное, это не самая суть статьи.
Решение не плохое! Но как Вы решаете проблему с ІЕ6?
что такое IE6?
А что не так с ним? вот демо (решение как у автора статьи) awdg.com.ua/form.html
Проверьте сами.
Проверьте сами.
Не только IE 6, но и IE 7.
НЛО прилетело и опубликовало эту надпись здесь
убрав границы fieldset стилем?
Здорово получилось. Единственное, что для полноты картины можно заменить оберточный див на филдсет, как предложено выше. Но это не столь важно в контексте статьи.
Делаю почти также, только label с фиксированной шириной, позволяет выравнивать другие элементы в форме относительно полей ввода без особых хлопот.
Взгляните также на Uni-From (http://sprawsm.com/uni-form/) — гибкая и дивная.
Взгляните также на Uni-From (http://sprawsm.com/uni-form/) — гибкая и дивная.
>>и назначим ему обновление потока.
что назначим?
что назначим?
отлично, спасибо!
Популярность статьи, в картинках объясняющей что 2*2=4 пугает.
браво, решение на 5+
В реальности все же удобнее ширину левой части задавать явно, чтобы длинная подпись не могла растянуть форму.
Ну и еще, дело вкуса, конечно, но мне больше нравится форму делать списком, а не дивами, имхо удобнее :)
Ну и еще, дело вкуса, конечно, но мне больше нравится форму делать списком, а не дивами, имхо удобнее :)
вы бы сделали заготовку которая с другими типами полей тоже дружит.. а то если заменить <input type="text" /> на <textarea name="a" /></textarea> - то все ломается
Я использую похожий вариант, но у него есть два приемущества перед вашим:
- не надо прописывать атрибут for для label (ну, разве что, для IE 6 и 7)
- можно использовать длинные описания в несколько строк (в вашем варианте будет неправильное выравнивание)
body {font-size:14px;}
label span {float:left; padding-right:10px; text-align:left;}
.field {clear:both; text-align:right; line-height:25px;}
.main {float:left;}
<div class="main">
<div class="field">
<label><span>Имя</span>
<input type="text" name="n" /></label>
</div>
<div class="field">
<label><span>Фамилия</span>
<input type="text" name="ln" /></label>
</div>
<div class="field">
<label><span>Место жительства</span>
<input type="text" name="a" /></label>
</div>
</div>Забыл написаль, что ни ваш, ни мой вариант не очень правильно работает в Опере 9 (9.5+ уже всё нормально).
Да, и как отметили уже выше, данный способ не подходит для полей формы разной длины. Но для простейших форм — мамое то, я думаю.
что у автора топика, что у Вас шрифт и line-height заданы в пикселях.
вы в самом деле прямо так и делаете на боевых проектах?
вы в самом деле прямо так и делаете на боевых проектах?
Посмотрите, тут это уже обсуждалось, здесь не нужен, можно обойтись и лейблом.
Детский сад. Неужели это заслуживает целой статьи.
НЛО прилетело и опубликовало эту надпись здесь
А это разве не очевидно?
Не сочтите за дотошливость, но в Opera 9.00 Build 8505 (Win XP) и в Opera 8.54 Build 7730 (Win XP) это решение не работает.
Решение в общем-то очевидное, ничего сверхестественного вы тут не написали — логически довольно просто дойти. Но вот использовать его можно далеко не всегда ибо в случае присутствия хитрого оформления с такой формой слишком тяжело жить. А гора float-ов для браузера кстати сложнее чем таблицы рисовать.
Правда, афигительный бонус — возможность достаточно просто изменять её на лету яваскриптом, чем таблицы похвастаться уже не могут.
Правда, афигительный бонус — возможность достаточно просто изменять её на лету яваскриптом, чем таблицы похвастаться уже не могут.
Аплодирую стоя:) Сам несколько дней назад решал подобную задачу. Так красиво не получилось:)
не скажу ни слова об очевидности и актуальности решения задачи, однако же большой вам плюс за такую наглядную подачу материала. Обычно, просто кидают пример рабочего кода в несколько десятков строк, в котором бывает как-то лениво копаться. Но в вашем случае, даже самые ленивые разобрались еще не дочитав до конца :)
все хорошо, и в посте и в комментариях почитал много хороших решений, но вот автору статьи бы посоветовал заменить теги в «Шаг первый… Шаг пятый» с U на H3
ибо некоторые думают, что все что подчеркнуто есть ссылка ;)
ибо некоторые думают, что все что подчеркнуто есть ссылка ;)
Кароче вывод такой: ничего не надо использовать, а делать так, как оно в браузерах лучше отображается. Сайт именно в них просматривать будут.
НЛО прилетело и опубликовало эту надпись здесь
А как теперь сделать так:
?
?
класный метод. спасибо
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Выравнивание полей формы с помощью CSS