Комментарии 36
способ конечно интересный, но лично мне кажется опасный для новичков. я в свое время тоже делал некий класс который умел выводить форму, универсальную вроде как. так вот после полу года работы проекта заказчик поставил такие условия что эта универсальная форма не могла удовлетворить требования. пришлось переписывать класс заново на отдельные формы для всего. это я сейчас понимаю что универсальная форма тогда была плохо спроектирована.
поэтому хочу сказать что новичкам надо быть очень осторожным с такими универсальными штуками. я бы рекомендовал именно новичкам делать каждую форму отдельно, а при получении опыта можно переходить на какую то универсальность, относительную конечно. тогда можно обратить внимание на данную статью.
поэтому хочу сказать что новичкам надо быть очень осторожным с такими универсальными штуками. я бы рекомендовал именно новичкам делать каждую форму отдельно, а при получении опыта можно переходить на какую то универсальность, относительную конечно. тогда можно обратить внимание на данную статью.
это я сейчас понимаю что универсальная форма тогда была плохо спроектирована.
В этом и дело, нужно хорошенько подумать перед ее проектированием, да и иметь одну заготовку для всех проектов, просто не реально. Я например пишу для каждого отдельную форму именно для этого проекта, предварительно просмотрев возможные ее варианты
само собой что заготовка одна на проект. проблема в том, что требования вещь такая которая может изменятся. И если у вас сейчас есть заготовка которая удовлетворяет требования, то это вовсе не значит что она будет удовлетворять измененные в будущем требования. В этом и состоит основная проблема — предугадать возможные изменения требований и спроектировать заготовку так чтобы потом на изменения было потрачено минимум усилий.
Для новичка без опыта эту задачу решить довольно сложно.
Для новичка без опыта эту задачу решить довольно сложно.
Zend_Form :)
В сафари немного плывут формы.
На мой взгляд, группировать каждое поле с его лейблом через fieldset — это не совсем корректно, т.к. тег предназначен для группировки нескольких полей
The FIELDSET element allows authors to group thematically related controls and labels. Grouping controls makes it easier for users to understand their purpose while simultaneously facilitating tabbing navigation for visual user agents and speech navigation for speech-oriented user agents. The proper use of this element makes documents more accessible.
…
In this example, we create a form that one might fill out at the doctor's office. It is divided into three sections: personal information, medical history, and current medication. Each section contains controls for inputting the appropriate information.
насколько я понимаю назначение fieldset, вы его используете неверно, вкладывая один в другой. все-таки fieldset предназначен для группировки взаимосвязанных полей, а не придания физической структуры. для этого есть div.
еще и не используя legend (да, legend элемент необязательный. Но используя его, вы повышаете доступность вашего документа (цитата из стандарта))
еще и не используя legend (да, legend элемент необязательный. Но используя его, вы повышаете доступность вашего документа (цитата из стандарта))
По поводу fieldset:
1. В данном примере нет взаимосвязанных полей.
2. Вкладывание fieldset'ов ни где не запрещается
3. Если fieldset объединяет связанные поля, то тем самым описывает структуру, так зачем лишние div, которые по своей сути, имеют косвенное отношение к формам
Так что там все верно ;)
А по поводу legend — можно использовать, если необходимо, но они тяжело поддаются стилизации (кроссбраузерной)
1. В данном примере нет взаимосвязанных полей.
2. Вкладывание fieldset'ов ни где не запрещается
3. Если fieldset объединяет связанные поля, то тем самым описывает структуру, так зачем лишние div, которые по своей сути, имеют косвенное отношение к формам
Так что там все верно ;)
А по поводу legend — можно использовать, если необходимо, но они тяжело поддаются стилизации (кроссбраузерной)
На мой взгляд, группировать каждое поле с его лейблом через fieldset — это не совсем корректно, т.к. тег предназначен для группировки нескольких полей
Это примитивный пример, разумеется можно помещать по несколько полей. Но использовать перенос строки для разделения элементов формы, тоже не корректно. Поэтому я использую
<fieldset class="field"> для группировки нескольких, логически связанных полей, а <fieldset> для отделения элементов друг от друга. Может быть это не достаточно заметно в приведенном примере
fieldset class=«field»
ul class=«li»
table class=«cell»
XD
ul class=«li»
table class=«cell»
XD
www.sprawsm.com/uni-form/ — типа CSS Form framework
www.alistapart.com/articles/prettyaccessibleforms — то же что и у вас только сбоку на alistapart
www.smashingmagazine.com/2006/11/11/css-based-forms-modern-solutions/ — подборка вариантов оформления форм + всякие онлайновые построители форм
www.alistapart.com/articles/prettyaccessibleforms — то же что и у вас только сбоку на alistapart
www.smashingmagazine.com/2006/11/11/css-based-forms-modern-solutions/ — подборка вариантов оформления форм + всякие онлайновые построители форм
Не сочтите за занудство, но именование классов типа .form-w-300 — порочная практика.
Перед названием класса я всегда задаю себе вопрос — изменится ли это название класса, если поменяются его свойства. То есть, если завтра вы захотите сделать эту форму в 350px вам придется либо менять класс, либо вводить в заблуждение верстальщиков (а может и вас самого), которые возможно будут править ваш CSS.
Я делал также раньше, смотря на подобные примеры, пока на собственном опыте не убедился в порочности такой практики.
Можно ведь написать что-то типа #login {width:300px;}.
Перед названием класса я всегда задаю себе вопрос — изменится ли это название класса, если поменяются его свойства. То есть, если завтра вы захотите сделать эту форму в 350px вам придется либо менять класс, либо вводить в заблуждение верстальщиков (а может и вас самого), которые возможно будут править ваш CSS.
Я делал также раньше, смотря на подобные примеры, пока на собственном опыте не убедился в порочности такой практики.
Можно ведь написать что-то типа #login {width:300px;}.
реально половина поста сделана по уму, вторая половина (где добавляется ширина) — что зря.
Если это логин форма — пишите дополнительный класс login и кастумизируйте ширину, цвет, что хотите.
Если вас через год поросят легкий редизайн темы, вы будете по всем шаблонам убирать свои классы .w-500 и ставить .w-300 вместо того, чтобы просто написать .login{width:300px}
Если это логин форма — пишите дополнительный класс login и кастумизируйте ширину, цвет, что хотите.
Если вас через год поросят легкий редизайн темы, вы будете по всем шаблонам убирать свои классы .w-500 и ставить .w-300 вместо того, чтобы просто написать .login{width:300px}
в тексте замените lable на label =)
Если ищете универсальности, то не обязательно изобретать велосипед. Можно воспользоваться одним из CSS Frameworks, например, Blueprint.
CSS Framework Blueprint имеет вполне конкретное оформление элементов формы, любое отклонение требует кастомизации css.
При чем тут универсальность?
При чем тут универсальность?
Отклонение требует не кастомизации, а расширения CSS, что не совсем одно и то же.
Универсальность, на мой взгляд, в том, что вы получаете стандартизованные отступы, размеры шрифтов и т.д. по всему проекту один раз и навсегда. Все, что не укладывается в схему (включая формы) — возможно расширить (но не писать с нуля) с помощью собственных стилей в отдельном файле. Либо использовать плагины, которые, по-сути, и есть расширение стандартных стилей.
Например, www.quantcast.com/ использует этот фреймворк, но формы там разные. Или вот есть плагин Buttons для изменения отображения кнопок в формах (не могу найти на него ссылку, но демо лежит в скачиваемой версии).
P.S. Я разработчик, не верстальщик, поэтому не претендую, что мое мнение единственно правильное, но Blueprint мне показался очень удобным инструментом.
Универсальность, на мой взгляд, в том, что вы получаете стандартизованные отступы, размеры шрифтов и т.д. по всему проекту один раз и навсегда. Все, что не укладывается в схему (включая формы) — возможно расширить (но не писать с нуля) с помощью собственных стилей в отдельном файле. Либо использовать плагины, которые, по-сути, и есть расширение стандартных стилей.
Например, www.quantcast.com/ использует этот фреймворк, но формы там разные. Или вот есть плагин Buttons для изменения отображения кнопок в формах (не могу найти на него ссылку, но демо лежит в скачиваемой версии).
P.S. Я разработчик, не верстальщик, поэтому не претендую, что мое мнение единственно правильное, но Blueprint мне показался очень удобным инструментом.
Отклонение требует не кастомизации, а расширения CSS, что не совсем одно и то же.
Универсальность, на мой взгляд, в том, что вы получаете стандартизованные отступы, размеры шрифтов и т.д. по всему проекту один раз и навсегда. Все, что не укладывается в схему (включая формы) — возможно расширить (но не писать с нуля) с помощью собственных стилей в отдельном файле. Либо использовать плагины, которые, по-сути, и есть расширение стандартных стилей.
Например, www.quantcast.com/ использует этот фреймворк, но формы там разные. Или вот есть плагин Buttons для изменения отображения кнопок в формах (не могу найти на него ссылку, но демо лежит в скачиваемой версии).
P.S. Я разработчик, не верстальщик, поэтому не претендую, что мое мнение единственно правильное, но Blueprint мне показался очень удобным инструментом.
Универсальность, на мой взгляд, в том, что вы получаете стандартизованные отступы, размеры шрифтов и т.д. по всему проекту один раз и навсегда. Все, что не укладывается в схему (включая формы) — возможно расширить (но не писать с нуля) с помощью собственных стилей в отдельном файле. Либо использовать плагины, которые, по-сути, и есть расширение стандартных стилей.
Например, www.quantcast.com/ использует этот фреймворк, но формы там разные. Или вот есть плагин Buttons для изменения отображения кнопок в формах (не могу найти на него ссылку, но демо лежит в скачиваемой версии).
P.S. Я разработчик, не верстальщик, поэтому не претендую, что мое мнение единственно правильное, но Blueprint мне показался очень удобным инструментом.
Ох, знакомая ситуация. Я тоже дошёл до этого и радовался целых 5 минут, потому что в следующей вёрстке часть полей переносились на новую строчку, а часть полей шли за лейбелом. Самое нормальное, это задавать класс fieldset'у. Кстати fieldset лучше не юзать, я вот с ходу не вспомню (если вспомню то напишу), но у него была какая-то очень серьёзная проблема в известном браузере. Я использую dl — dt+dd.
Если обнулить дефолтные стили, то с fieldset проблем в ие гораздо меньше, а иногда и совсем нет:)
Ну для каждой верстки нужно допиливать конечно. Да и писал я о том как сделать 1 html шаблон, а его стили уже допиливать можно под разные проекты, а где-то, может и сам html переделать немного придется под задачу
Ну для каждой верстки нужно допиливать конечно. Да и писал я о том как сделать 1 html шаблон, а его стили уже допиливать можно под разные проекты, а где-то, может и сам html переделать немного придется под задачу
Очень напомнило дела трёхлетней давности, о которых потом написал Лёша Рыбаков:
Создаём сложные формы без таблиц
Создаём сложные формы без таблиц. Часть вторая
Создаём сложные формы без таблиц
Создаём сложные формы без таблиц. Часть вторая
Ответьте, пожалуйста, а чем обосновано использование <fieldset> в качестве контейнера для полей? С точки зрения правильности вложенности все верно, но с точки зрения логики — не уверен. Так как задача у этого тега группировать несколько элементов, а не единичные. Так же если убрать «ваш» reset, получится не очень здорово, так как <fieldset> имеет свое визуальное представление по умолчанию, да и предполагается его использовать с <legend>.
Было бы интересно услышать чем Вы руководствовались.
Было бы интересно услышать чем Вы руководствовались.
В этом примере и нет связанных полей, поэтому каждый элемент имеет свой fieldset, за исключением чекбоксов и радио, в этом случае обусловлено тем, что нужно эти поля как-то разделять, так как они инлайновые, а использовать fieldset (который объеденяет связанные label и input) логичнее, на мой взгляд, чем перенос строки или какой то контейнер, типа div.
Да согласен, если убрать reset (не мой, а Эрика Мейера), не очень хорошо получится, но он есть и все хорошо ;)
В принципе, если заменить fieldset на div, dl, ol, ну или еще что то, идея самой статьи не изменится, но мне более по душе fieldset
Да согласен, если убрать reset (не мой, а Эрика Мейера), не очень хорошо получится, но он есть и все хорошо ;)
В принципе, если заменить fieldset на div, dl, ol, ну или еще что то, идея самой статьи не изменится, но мне более по душе fieldset
Ясно, то есть какого-то сакраментального смысла в этом нет. Для вашей цели не могу понять чем хуже было бы использовать, тот же
Не понятно чем вам не угодил <div>. Я бы еще понял, если Вы использовали в стилях FORM FIELDSET {… }, а так вы обращаетесь FORM .field {… }.
Еще раз повторюсь, что <fieldset> предполагается использовать с <legend> (который должен быть первым элементом в <fieldset>), и как бы предназначен несколько для другого.
К тому же, если бы я верстал данный макет (а я не использую reset'ов) — я бы очень был не рад такой форме :)
Не первый раз встречаю использование <fieldset> таким образом, а после таких статей видимо встречать буду еще чаще…
<div class="field">...</div>Не понятно чем вам не угодил <div>. Я бы еще понял, если Вы использовали в стилях FORM FIELDSET {… }, а так вы обращаетесь FORM .field {… }.
Еще раз повторюсь, что <fieldset> предполагается использовать с <legend> (который должен быть первым элементом в <fieldset>), и как бы предназначен несколько для другого.
К тому же, если бы я верстал данный макет (а я не использую reset'ов) — я бы очень был не рад такой форме :)
Не первый раз встречаю использование <fieldset> таким образом, а после таких статей видимо встречать буду еще чаще…
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Один шаблон формы для всего проекта