Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 203
п.1 - Согласен, порой даже на очень популярных сайтах забывают добавить лэйбл на "запомнить меня" при логине. Приходится играть в "попади в мааалюсенький квадратик")
п.5 - К сожалению не все мнемоники отображаются одинакого в разных браузерах.
п.5 - К сожалению не все мнемоники отображаются одинакого в разных браузерах.
ну, если бы я придумал что-то новое, имело бы смысл показывать
а так - почти все хорошо написанные сайты - хорошо сверстаны. мне например всегда нравился по верстке http://basher.ru/ ;) до его редизайна, во всяком случае, я часто смотрел в его коде как то или иное реализовано :)
а так - почти все хорошо написанные сайты - хорошо сверстаны. мне например всегда нравился по верстке http://basher.ru/ ;) до его редизайна, во всяком случае, я часто смотрел в его коде как то или иное реализовано :)
Fatal error: Call to undefined function mysql_pconnect() in /usr/local/www/http://www.basher.ru/htdocs/php/config.p… on line 6
Хотелось посмотреть на верстку.
Хотелось посмотреть на верстку.
Еще есть пару замечаний по верстке http://basher.ru/
Почему lang="en" если это русскоязычный сайт?
Почему везде используется тег <b>, а не <strong>?
Символ © не заменен на мнемонику.
E-mail не стоит писать в явном виде (mailto:webmaster@basher.ru).
Да, и кол-во <b> смущает (
Почему lang="en" если это русскоязычный сайт?
Почему везде используется тег <b>, а не <strong>?
Символ © не заменен на мнемонику.
E-mail не стоит писать в явном виде (mailto:webmaster@basher.ru).
Да, и кол-во <b> смущает (
sorry
Да, и кол-во <br ⁄> смущает (
Да, и кол-во <br ⁄> смущает (
А в каком виде его писать?
тэг используется для перхода на новую строку, но никак не для отступа. Для отступов лучше использовать CSS (padding или margin , по обстоятельствам)
Наверное вот так webmaster[@]basher.ru но ведь тогда нельзя будет использовать mailto... а еще можно через скриптик реализовать
Email encoder - как вариант
Спасибо за замечания.
Насчет языка возможно вы и правы. Если быть до конца честным, шапку я взял у Дэна и когда колбасил её под себя, не задумался над языком.
По поводу <b> — стоит понимать разницу. Да и потом, стронг это мода, болд — классика. Все равно что спорить, ООП подход круче или процедурный. Надо просто с умом пользоваться тем и другим в зависимости от ситуации, а не идти за модой.
Символ © не заменен на мнемонику потому, что он должен отображаться именно так во всех браузерах, а не как-то, как захочет того браузер. Проект собран на utf-8, а значит ничего страшного с © случиться не может.
Email указан явно, не спорю, но мне пофиг =))) почту собирает gmail, а там хороший антиспам. Не жалко.
Про брейки писал выше — применяются они не для верстки, а для формирования текста. Это нормально, тем более что альтернатива еще более идиотская.
Насчет языка возможно вы и правы. Если быть до конца честным, шапку я взял у Дэна и когда колбасил её под себя, не задумался над языком.
По поводу <b> — стоит понимать разницу. Да и потом, стронг это мода, болд — классика. Все равно что спорить, ООП подход круче или процедурный. Надо просто с умом пользоваться тем и другим в зависимости от ситуации, а не идти за модой.
Символ © не заменен на мнемонику потому, что он должен отображаться именно так во всех браузерах, а не как-то, как захочет того браузер. Проект собран на utf-8, а значит ничего страшного с © случиться не может.
Email указан явно, не спорю, но мне пофиг =))) почту собирает gmail, а там хороший антиспам. Не жалко.
Про брейки писал выше — применяются они не для верстки, а для формирования текста. Это нормально, тем более что альтернатива еще более идиотская.
тег strong, это не мода а требование юзабилити. и разница между ними существенная, потому что один выделяет слово при чтении например, а другой нет. почитайте руководствующие документы. а следуя вашему подходу про моду, неясно, зачем пошла мода дивной верстки. с табличками все было намного быстрее и проще
в том все и дело, оформляя текст я буду применять strong, а верстая и используя тег для верстки — b
так. объясните, что вы имеете ввиду под "верстать текст" и "оформлять текст" ?
Есть 2 тега, strong и b. Визуально они выглядят (по дефолту) одинаково. Но strong ко всему прочему — логическое выделение. На данный момент времени разницы между ними нет никакой. Любая «читалка» прочитает с восклицанием и b и strong.
Дак вот, верстая страницу, то же меню, я применяю bold, потому что он тут нужен лишь для графического выделения, я напишу для него тонну css стилей и сделаю неузноваемым. Тут он мне нужен лишь как «обертка» для какаого-то нода. Он короткий и понятный. Оформляя же текст, я буду использовать strong (хотя не факт), потому как тут тег выделения будет использоваться по примому назначению.
Примерно так…
Дак вот, верстая страницу, то же меню, я применяю bold, потому что он тут нужен лишь для графического выделения, я напишу для него тонну css стилей и сделаю неузноваемым. Тут он мне нужен лишь как «обертка» для какаого-то нода. Он короткий и понятный. Оформляя же текст, я буду использовать strong (хотя не факт), потому как тут тег выделения будет использоваться по примому назначению.
Примерно так…
а про utf8 согласен
E-mail в явном виде — это не ошибка. Если сайт серьезный, то искажать почтовые адреса или выдавать их через хитрые скрипты — дурной тон. (Если сайт несерьезный, тогда можно делать все что угодно.)
видимо например на kde.org все несерьёзные раз пишут емейлы "dyadya_vova gmail com". Откуда вы вообще взяли сей тезис? =)
На корпоративном сайте нужно уважать посетителя, а не причинять ему мелкие неудобства, попутно намекая на то, что компания даже со спамом бороться не может.
А kde.org — иной пример. Такой сайт должен минимизировать не только неудобства пользователей сайта, но и одновременно неудобства добровольных участников проекта. Точно так же почтовые адреса в явном виде не показывают публичные сервисы, социальные сети, и т. д.
А kde.org — иной пример. Такой сайт должен минимизировать не только неудобства пользователей сайта, но и одновременно неудобства добровольных участников проекта. Точно так же почтовые адреса в явном виде не показывают публичные сервисы, социальные сети, и т. д.
я всё-таки не понял - без яваскрипта меню не показывать - нормально, а емейлы - нет? Мне кажется абсолютно разумным с точки зрения компании вывести user company ru для всех пользователей у которых нет яваскрипта и собрать яваскриптом человеческий емейл для всех остальных. Те кто яваскрипт в наше время руками отключают неудобства даже и не заметят, потому что будут явно не простыми пользователями (а большая часть из них будет даже роботами а не людьми вовсе).
Не пожалел, что потратил пару минут на прочтение этой записи - свою функцию "напомнить" о том, что часто забывают, она выполняет отлично.
Оппа... а я про пункт 1. даже не в курсе был... думал это жабаскритпами делается... дуралей :)
Для сложной кроссбраузерной верстки делать оную как strict, мне кажется, очень тяжко. Все же следует начинать с transitional
а еще есть fieldset и legend, позволяющие просто группировать элементы формы.
запятую забыли перед пожалуйста ;)
фишка в том, что я перечислял то, что почти не влияет на внешний вид, а потому безбожно забывается...
фишка в том, что я перечислял то, что почти не влияет на внешний вид, а потому безбожно забывается...
http://sdelka.ru/ad/606/101.xhtml или вот так =)
Да, да. И ещё не забывайте ставить тэг в начале и конце документа.
Какой глупая статья.
Какой глупая статья.
Не знаю, стоит ли напоминать о объявлении в начале документа чего-то вроде
<?xml version="1.0" encoding="UTF-8"?>.как я уже сказал, я перечислял вещи, которые не влияют на прохождение валидаторами и почти не влияют на внешний вид, а потому все на них радостно забивают :)
Категорически против такого извращения!
ИЕ6 должен первой строкой в документе увидеть тег DOCTYPE, иначе - он перейдет в состояние Quirks Mode, и Ваш сайт развалится...
Искать причины по которым так получилось бывает очень сложно.
ИЕ6 должен первой строкой в документе увидеть тег DOCTYPE, иначе - он перейдет в состояние Quirks Mode, и Ваш сайт развалится...
Искать причины по которым так получилось бывает очень сложно.
Согласен, это проблема IE.
In browsers such as Mozilla, Netscape, Opera, and others, with or without the XML declaration, a page served with a DOCTYPE declaration will be rendered in standards mode.
With Internet Explorer, however, if anything appears before the DOCTYPE declaration the page is rendered in quirks mode.
Но не думаю что это "правильно".
In browsers such as Mozilla, Netscape, Opera, and others, with or without the XML declaration, a page served with a DOCTYPE declaration will be rendered in standards mode.
With Internet Explorer, however, if anything appears before the DOCTYPE declaration the page is rendered in quirks mode.
Но не думаю что это "правильно".
не стоит, потому что оно там мало того, что не обязательно, так ещё и IE введёт в quirks mode
>>а в-третьих, никогда не стоит верстать табличками
За исключением тех случаев когда надо вывести именно таблицу с данными.
Сейчас нередко можно встретить когда таблица с данными верстается дивами, потому что использовать таблицы "немодно"
За исключением тех случаев когда надо вывести именно таблицу с данными.
Сейчас нередко можно встретить когда таблица с данными верстается дивами, потому что использовать таблицы "немодно"
"никогда не стоит верстать табличками (т.к. таблички - они для табличных данных)"
верстать != выводить данные
да еще и пояснение :)
а если табличка с данными верстается дивами, то тут уж никакие советы не помогут :)))
верстать != выводить данные
да еще и пояснение :)
а если табличка с данными верстается дивами, то тут уж никакие советы не помогут :)))
действительно, пояснения я как то не заметил, фраза про неверстание таблицами сработала как красная тряпка :)
На самом деле CSS2 позволяет делать табличное отображение из любых элементов ( правда с кросбраузерной поддержкой этого чуда пока что глуховато ), так что в обозримом будущем грань между таблицами и прочими контейнерами сотрется.
Да и во многих случая неясно где разница между перечислением (LI) a когда это уже таблица - нестоит запрещать использовать таблицы просто изза того что у них дурная репутация
На самом деле CSS2 позволяет делать табличное отображение из любых элементов ( правда с кросбраузерной поддержкой этого чуда пока что глуховато ), так что в обозримом будущем грань между таблицами и прочими контейнерами сотрется.
Да и во многих случая неясно где разница между перечислением (LI) a когда это уже таблица - нестоит запрещать использовать таблицы просто изза того что у них дурная репутация
имхо БРЕД, т.к. для верстальщика, задача которого реализовать маразм дизайнера, порой без таблиц не добиться одинаковой картинки в Осликах (6,7) Огнелисе, Сафари и Опере без использования целой кучи хаков. Как тут написано, лишь когда все броузеры будут понимать и реально отображать то чего от них хотят, тогда может быть (я в этом честно говоря сомневаюсь) можно будет говорить, что верстка таблицами это вчерашний день. Пока что я не видел ни одного глобального и информационно насыщенного портала на дивах. Так что поживем и может быть лет эдак через 10, когда мелкософт обанкротится и ослика больше не будут выпускать на просторы сети, таблицы буду использоваться лишь для табличных данных.
Приведите два примера.
Понятное дело, что это клиника, но для утверждения "нередко можно встретить" нужны примеры.
Понятное дело, что это клиника, но для утверждения "нередко можно встретить" нужны примеры.
списка подобных вещей не веду, но пара линков найдется
http://www.rockstarapps.com/samples/perf… - таблицы результатов
http://www.activewidgets.com/grid/ - грид
http://www.rockstarapps.com/samples/perf… - таблицы результатов
http://www.activewidgets.com/grid/ - грид
Вы наверное в школе, если вам чего то не удавалось с первого раза, тут же забивали и говорили, что это не тру.
разумеется, я плохой человек.
просто надо понимать, что одна всем известная корпорация срала на стандарты, и вот что из этого вышла
вот вы показываете, что еще одна не менее известная корпорация на них срет
и это не пример для подражания
хотя... давайте, делайте невалидные сайты. мне же наплевать, не думаю, что буду посещать сайты людей, которые забивают на то, что им сразу не удается. исключительно из-за низкого уровня таковых (сайтов, а не людей).
просто надо понимать, что одна всем известная корпорация срала на стандарты, и вот что из этого вышла
вот вы показываете, что еще одна не менее известная корпорация на них срет
и это не пример для подражания
хотя... давайте, делайте невалидные сайты. мне же наплевать, не думаю, что буду посещать сайты людей, которые забивают на то, что им сразу не удается. исключительно из-за низкого уровня таковых (сайтов, а не людей).
неужели вы думаете, что гугль забил на стандарты потому, что у него не получилось?
я поражен вами :)
я поражен вами :)
Брать в пример на валидность такие глобальные сайты совершенно не стоит. Там никто не поддерживает стандарты так как во многом их поддержка не дам возможности реализовать поставленный функционал.
К примеру на валидность прогоняя любое веб-приложение так же получите множественные ошибки.
Но такие порталы - исключение.
По большей степени верстая сайты все же стоит иногда прогонять код через валидатор, ведь стандарты пишутся не просто так ;)
Да и, как правило, валидатор указывает на существенные ошибки разработчика, иначе в нем просто не было б смысла :)
К примеру на валидность прогоняя любое веб-приложение так же получите множественные ошибки.
Но такие порталы - исключение.
По большей степени верстая сайты все же стоит иногда прогонять код через валидатор, ведь стандарты пишутся не просто так ;)
Да и, как правило, валидатор указывает на существенные ошибки разработчика, иначе в нем просто не было б смысла :)
Есть стандарты, а есть люди, которые на них забивают по тем или иным причинам (недостаток знаний, лень, зачастую как причина недостатка знаний, или просто упертость). Не надо на них равняться.
Конечно, никому хуже не станет от невалидного кода. Но почему же тогда мы не ездим в машине по левой стороне задней передаче? Тоже вроде и не помешаем никому...
Конечно, никому хуже не станет от невалидного кода. Но почему же тогда мы не ездим в машине по левой стороне задней передаче? Тоже вроде и не помешаем никому...
Валидатор — это не цель, а инструмент.
И тем самым усложняете себе работу, теряете ваше время, если работаете в команде теряете время других….. в валидном коде легче разобраться. , найти и устранить ошибки, легче оптимизировать, апдейтить и тн.
Само ваше заявление «Сколько сайтов не делал все равно валидатор выдаем кучу ошибок, поэтому давно им не пользуюсь, чтобы настроение не портить :)» Говорит что не читали спецификации , а это значит что не понимаете что как работает и скорей всего работаете методом «тыка» …
Само ваше заявление «Сколько сайтов не делал все равно валидатор выдаем кучу ошибок, поэтому давно им не пользуюсь, чтобы настроение не портить :)» Говорит что не читали спецификации , а это значит что не понимаете что как работает и скорей всего работаете методом «тыка» …
s/секаса/секса/ :)
Пару вещей взял себе на заметку :)
п3., про списки - хорош, но почему-то в самом тесте статьи для пунктов используется обычный текст :) ?
> HTML документ должен описывать только данные и ничего кроме данных
(Мрачно) Вот только через CSS не опишешь.
(Мрачно) Вот только через CSS не опишешь.
сотрите это всё и напишите зановотипичный подход программиста, типа меня :) не думаю, что ваш менеджер проекта будет доволен, если вы сотрёте всё и начнёте переписывать заново. говорят, что нетскейп так и загнулся :)
хехе, я же не говорю код проекта стирать, а только html шаблоны :)
Эти шаблоны я с такой любовью верстал несколько дней табличками :)
да ну, я при помощи XRAY (закладурка такая удобная) переверстал несколько табличных версток в css за короткое время :)
а что такое xray? можно поподробнее, заинтересовало
запоздало, но: http://www.westciv.com/xray/
пост довольно хорош, только вот намедни читала как раз про лэйблы )
и имхо если ксс отключить то никакие списки не помогут ( визуально все равно что-то будет не так. вот сейчас работаю над одним бизнес порталом, структура настолько сложна и такое большое количество GUI элментов что как никрути а без ксс ничерта в нем не будет понятно (
с третьим пунктом полностью согласен, и еще хотел бы добавить что ни в коем случае не стоит прописывать стили по id. рано или поздно придеться менять ибо появиться две одинаковые кнопки и тп(в быстро развивающихся проэктах).
про мнемоники правильно, но вот имхо картинку с @ можно как раз использовать для обхода бота и визуально правильно передачи e-mail адресов.
я почему-то замечательно обхожусь без стрикта. и вижу что с ним проблеммы решаються куда дольше и сложнее чем без него. тем более что все зависит от опыта и практики.
8. если вам за время работы трахнули мозг арт директор с мэнеджером проэкта напару, то вы даже на Hello world написанный под их эгидой будете нечленораздельно выражаться )
и имхо если ксс отключить то никакие списки не помогут ( визуально все равно что-то будет не так. вот сейчас работаю над одним бизнес порталом, структура настолько сложна и такое большое количество GUI элментов что как никрути а без ксс ничерта в нем не будет понятно (
с третьим пунктом полностью согласен, и еще хотел бы добавить что ни в коем случае не стоит прописывать стили по id. рано или поздно придеться менять ибо появиться две одинаковые кнопки и тп(в быстро развивающихся проэктах).
про мнемоники правильно, но вот имхо картинку с @ можно как раз использовать для обхода бота и визуально правильно передачи e-mail адресов.
я почему-то замечательно обхожусь без стрикта. и вижу что с ним проблеммы решаються куда дольше и сложнее чем без него. тем более что все зависит от опыта и практики.
8. если вам за время работы трахнули мозг арт директор с мэнеджером проэкта напару, то вы даже на Hello world написанный под их эгидой будете нечленораздельно выражаться )
вообще в идеале эти самые лишние гуи элементы стоит выносить в ксс через там чего-нибудь наверное можно ведь как-то :))
а так ну в целом согласен. я ведь даже не советы написал, а напоминание того, что можно забыть ;)
про id добавил
а так ну в целом согласен. я ведь даже не советы написал, а напоминание того, что можно забыть ;)
про id добавил
там очепятка "читаЛ" я мужчина )
Согласен насчёт нормальности использования id. Я часто использую этот аттрибут для однозначного определения контейнеров. И прописываю стили для потомков отталкиваясь в разметке от id контейнера. Например:
DIV#menu A { … }Чем плохо, не понимаю? Особенно, если учесть другой совет автора и именовать идентификаторы по контенту.
а зачем указывать тег при указании id ?
Ммм, если честно, то незачем, но мне такой подход кажется удобнее: сразу видишь к какому тегу относится айдишник. Или кто другой, который будет редактировать код после меня увидит.
Так я Вас переубедил насчёт правомерности использования id для CSS? ;)
Так я Вас переубедил насчёт правомерности использования id для CSS? ;)
мм скажем так: писать название тега перед ид я не буду. потому что, например, в jquery такое делать не рекомендуется, а если в цсс буду а в js не буду то получится путаница :)
но и задавать вопросов я тоже больше не буду :)
но и задавать вопросов я тоже больше не буду :)
b2k говорил о другом, что лучше сразу прописать класс, так как может появиться вторая похожая кнопочка и надо будет дублировать описание для нового id
а вовсе не о правомерности использования id
а вовсе не о правомерности использования id
Понимаете, id - это идентификатор, элемент с идентификатором должен быть единственным на странице. Автор имел ввиду чудо-верстальщиков, использующих идентификатор везде и всюду, не ясно почему, может потому что короче чем class.
Использовать класс зачастую удобнее, например всем первым колонкам присваевать класс col1, а всем меню класс menu, а id задавать только элементам, требующим идентификации с помощью javascript, например.
Даже элементы, которые на первый взгляд могут быть единственными на странице, такие как header и footer, могут быть востребованы, например, во всплывающем блоке.
и в дополнении ко всему, автор не указал что верстать нужно в em, так как многие пользователи любят увеличивать шрифты. При достаточном опыте, желательно задавать все размеры в em, чтобы при увеличении шрифта пропорционально увеличивалась вся страница.
Использовать класс зачастую удобнее, например всем первым колонкам присваевать класс col1, а всем меню класс menu, а id задавать только элементам, требующим идентификации с помощью javascript, например.
Даже элементы, которые на первый взгляд могут быть единственными на странице, такие как header и footer, могут быть востребованы, например, во всплывающем блоке.
и в дополнении ко всему, автор не указал что верстать нужно в em, так как многие пользователи любят увеличивать шрифты. При достаточном опыте, желательно задавать все размеры в em, чтобы при увеличении шрифта пропорционально увеличивалась вся страница.
к слову, про масштабирование шрифтов неплохо описано в первой главе книги "Пуленепробиваемый Web-дизайн" Д. Седерхольма - http://www.oz.by/books/more1022427.html
Да, и вообще, считаю, что сайт должен создаваться в первую очередь для пользователя, а не для самоутверждения дизайнера, поэтому теже шрифты, задаваемые в пикселях, должны отойти от практики.
Да, и вообще, считаю, что сайт должен создаваться в первую очередь для пользователя, а не для самоутверждения дизайнера, поэтому теже шрифты, задаваемые в пикселях, должны отойти от практики.
про ID согласен.
а что касается всех размеров в em - это не всегда применимо. ибо при "попиксельном" (читай, графически перенасыщенном) шедевре дизайнера при изменении размера шрифта, всё поплавёт так, что мама-не-горюй!
отсюда вывод: дизайн должен быть "простым", чтобы указывать все размеры в em
а что касается всех размеров в em - это не всегда применимо. ибо при "попиксельном" (читай, графически перенасыщенном) шедевре дизайнера при изменении размера шрифта, всё поплавёт так, что мама-не-горюй!
отсюда вывод: дизайн должен быть "простым", чтобы указывать все размеры в em
я к тому зачем писать два стиля по id для разных кнопок к примеру...
Никогда на делайте на странице несколько элементов с одним id.
Иначе JavaScript программисту придется ой как не сладко.
Да и вообще плохо это.
Иначе JavaScript программисту придется ой как не сладко.
Да и вообще плохо это.
id должен быть уникальным.
id определяет уникальный элемент, ну и по хешу браузер скролится, я всегда использую #top и #content, часто #footer. Кроме того, по CSS id прибваляет селектору 100 баллов, а css только 10 (тэг — 1).
Все правильно, но банально…
По 4-му пункту: не вижу ничего дурного в том, чтобы писать JavaScript в самом HTML. Ибо если следовать совету "весь JS выносить в отдельный файл" получится либо очень много файлов, либо несколько, но больших. А ведь ява скрипт в HTML коде даёт большую гибкость, например, я могу из PHP передавать значение переменных в JS, что очень удобно
лучше конфиг и инициализацию всяких там классов для js пихать в хтмл, остальное - внешними фаилами. так тупо удобнее, если вдруг нам понадобится тот же js в другом документе
Само собой, я не имел в виду что весь JS оставлять в HTML)
ну а я не имел в виду выносить весь :) переменные в js тоже данные :)
тем более я не знаю, как его весь вынести. разве что хитро в сессию все пихать а в другом фаиле выводить%) не тру ))
тем более я не знаю, как его весь вынести. разве что хитро в сессию все пихать а в другом фаиле выводить%) не тру ))
Я вот сторонник концепции «тихого» Явапскрипта, когда количество скрипта в документе стремится к onload="Init()" в теге BODY.
Разве что некоторые библиотеки для потокового вывода использую, навроде SWFObject.
Разве что некоторые библиотеки для потокового вывода использую, навроде SWFObject.
2. теги <link>
изначально поддержка есть в Suite/Seamonkey, но в FF почему-то это убрано, похоже =/
Под FF есть например Site navigation bar
раз уж это напоминательная статья, то напомню, что
можно написать и как
<label>Логин: <input /></label>
также если верстка идёт именно в HTML, то закрывать тег input не нужно
<label for='login'>Логин: </label><input id='login' />
можно написать и как
<label>Логин: <input /></label>
также если верстка идёт именно в HTML, то закрывать тег input не нужно
Надо к этому добавить, что всеми любимый IE такую форму (инпут внутри лейбла) криво понимает и не ставит поле ввода на инпут при нажатии на лейбл. Так что надо или руками все-равно for и id прописывать, или экспрешн какой-нибудь добавлять, который сам все исправит.
странно, но у меня всегда всеми любимый IE эту конструкцию нормально воспринимал
хотя, если кроме input в label есть ещё что-то, например обертка для input или просто пустой тег, то тогда да, в ослике почему-то перестает переводиться фокус
хотя, если кроме input в label есть ещё что-то, например обертка для input или просто пустой тег, то тогда да, в ослике почему-то перестает переводиться фокус
лучше for и id.
А вообще в IE намного раньше появился, чем в Netscape - вроде как даже считается тег родным для ИЕ и писать инпут внутри лэйбла на мой взгляд - изврат
А вообще в IE намного раньше появился, чем в Netscape - вроде как даже считается тег родным для ИЕ и писать инпут внутри лэйбла на мой взгляд - изврат
Согласен с lifestar! Очень удобно в некоторых случаях передавать из PHP значения в javascript, причем организовать это в коде html. Например, я так делаю связанные селекты: сколько ни бился, чтобы вынести все в отдельный файл, не получилось. В теле html отлично работает.
Вообще говоря, хорошая статья. Признаяться, не знал про label. Сразу захотелось некоторые свои проекты переделать :-)
Вообще говоря, хорошая статья. Признаяться, не знал про label. Сразу захотелось некоторые свои проекты переделать :-)
да уж... можно было бы добавить: "сидите прямо, не сутультесь" и "мойте руки перед едой"
можно. но не нужно.
я это к тому, что каждый из нас мог бы написать нечто подобное. Никакой ценности эта заметка не несёт. Постить её в своём блоге - это ещё я бы понял. Но тут... Трата времени, и своего и чужого. Ничего полезного не почерпнуть из статьи. А можно было бы поднапрячь мозги и сделать более детальное описание затронутых тем. Привести интересные примеры, указать на ошибки в юзабалити сайтов (того же mail.ru который пренебрегает тэгом label). Вообщем, более профессионально подойти к вопросу.
Да, вот ещё что, я не знаю что такое "карма" и "хабрасила" и зачем они нужны, так что можете не утруждать себя понижением их. И раз вы решились сказать что-то во всеуслышание, научитесь спокойно принимайть критику.
И последнее: ну почему на сайте такой тематики так много сделано через задницу? Хотя бы ту же textarea, в которую я сейчас пишу, можно увеличить по высоте?
Да, вот ещё что, я не знаю что такое "карма" и "хабрасила" и зачем они нужны, так что можете не утруждать себя понижением их. И раз вы решились сказать что-то во всеуслышание, научитесь спокойно принимайть критику.
И последнее: ну почему на сайте такой тематики так много сделано через задницу? Хотя бы ту же textarea, в которую я сейчас пишу, можно увеличить по высоте?
я не понимаю смысла ваших слов.
вам не нравится статья? поставьте красную стрелочку вниз
вам не нравлюсь я? понизьте мне карму
вы видите какую-то ошибку? укажите мне на нее
вы решили поныть? вам не сюда.
вам не нравится статья? поставьте красную стрелочку вниз
вам не нравлюсь я? понизьте мне карму
вы видите какую-то ошибку? укажите мне на нее
вы решили поныть? вам не сюда.
Вы мне не можете нравиться/не нравиться, так как я с Вами не знаком и не знаю что Вы за человек.
статья не то чтобы не понравилась, просто на мой взгляд бесполезная.
про стрелочки не знал, но это ещё раз к вопросу о юзабилити это сайта (очень много косяков кстати у данного сайта именно в этой части).
ошибок не заметил, но заметил, что очень поверхностная статья, и предложил к вопросу подойти более серьёзно и углублённо. тогда может выплыть много деталей, которые неизвестны другим.
у меня есть своё мнение, также как и у Вас, я его высказал... К чему эта эмоциональность, не надо указывать мне куда мне — "сюда" или "не сюда".
статья не то чтобы не понравилась, просто на мой взгляд бесполезная.
про стрелочки не знал, но это ещё раз к вопросу о юзабилити это сайта (очень много косяков кстати у данного сайта именно в этой части).
ошибок не заметил, но заметил, что очень поверхностная статья, и предложил к вопросу подойти более серьёзно и углублённо. тогда может выплыть много деталей, которые неизвестны другим.
у меня есть своё мнение, также как и у Вас, я его высказал... К чему эта эмоциональность, не надо указывать мне куда мне — "сюда" или "не сюда".
вы похоже не поняли смысла этой статьи
я не даю советов, не показываю как надо и не учу жить
я просто написал несколько вещей, о которых легко забыть. чтобы любой мог повесить на стенку и, взглянув, сказать себе: йопт! забыл :( щас сделаем.
я не даю советов, не показываю как надо и не учу жить
я просто написал несколько вещей, о которых легко забыть. чтобы любой мог повесить на стенку и, взглянув, сказать себе: йопт! забыл :( щас сделаем.
Но ведь этот сайт могут посещать не только маститые разработчики, но и начинающие. Или же кто-то что-то пропустил при самобразовании.
То, что лично для Вас кажется пройденым этапом, другим будет полезно. Ресурс ведь общественный и статья писалась не лично для Вас.
То, что лично для Вас кажется пройденым этапом, другим будет полезно. Ресурс ведь общественный и статья писалась не лично для Вас.
Вы едва пришли на Хабр, а уже не довольны и делаете такие заявления. Почитали бы немного тут всё, разобрались.
Я вот считаю эту статью полезной, и не менее 38 человек, нажавших стрелочку вверх — тоже.
Автор статьи мне, как человек, кстати тоже понравился, ибо прекрасно отвечает на необоснованные негативные комментарии.
Я вот считаю эту статью полезной, и не менее 38 человек, нажавших стрелочку вверх — тоже.
Автор статьи мне, как человек, кстати тоже понравился, ибо прекрасно отвечает на необоснованные негативные комментарии.
Вы в стрикте не пройдете проверку валидатором после <a name="">
А зачем нужна такая конструкция? Для создания якоря гораздо удобнее пользоваться id.
только вот не во всех браузерах такие якоря работают
И в каком же браузере не работают?
http://kost.ru/stuff/id-anchor.html
Работает в ie5.01, ie5.5, ie6, ie7, opera 9, ff2, safari 3.04 (win).
http://kost.ru/stuff/id-anchor.html
Работает в ie5.01, ie5.5, ie6, ie7, opera 9, ff2, safari 3.04 (win).
Многих из перечисленных проблем можно было бы избежать, пользуясь нормальными редакторами вроде DreamWeaver. А если ещё ими правильно пользоваться, например используя DW-шаблоны, то не пришлось бы выносить СSS в отдельный файл. Ну только если уж очень хочется. :)
ууух, камментов много как…
Большое спасибо, про label элементарно позабыл. Остальное — не новость, так и делаю всегда :)
Большое спасибо, про label элементарно позабыл. Остальное — не новость, так и делаю всегда :)
Проверил у себя и увидел, что "webdeveloper и жмите ctrl-shift-S" не с "С", как написано в статье, а с "S". Если конечно вы имели ввиду отключение CSS, а не просмотр CSS.
я бы не стал картинку с логотипом выносить в css =)
Да, с большинством пунктов согласен.
Только вот верстать таблицами в некоторых случаях всё-таки придется.
Надо осознать, что xhtml код содержит не только семантику, но и layout в общем.
Т.е. с тех пор как появились теги
Только вот верстать таблицами в некоторых случаях всё-таки придется.
Надо осознать, что xhtml код содержит не только семантику, но и layout в общем.
Т.е. с тех пор как появились теги
, который никогда не нес и не будет нести никакого смысла, кроме того, что его содержимое располагается именно в нем, тогда понятия layout пришли в xhtml.
Если есть программисты Swing, Flex, то они могут вспомнить, что всегда существовала такая штука как TableLayout.
Конечно, создатели CSS позаботились о том, чтобы это было доступно и xhtml кодерам. Ввели новые значения свойства block:
table
table-row
table-cell
и т.д.
Всё бы ничего, но IE 6 не понимает их, поэтому такой лайаутовский шаблон как TableLayout сейчас можно реализовать только при помощи таблицы.
Имитировать его при помощи CSS существующими средствами, которые поддерживают все современные браузеры не представляется возможным.
Поэтому если вы видите, что у вас расположение элементов можно описать только при помощи TableLayout, то нужно использовать тег, только не забывайте вставлять в него всегда
Если есть программисты Swing, Flex, то они могут вспомнить, что всегда существовала такая штука как TableLayout.
Конечно, создатели CSS позаботились о том, чтобы это было доступно и xhtml кодерам. Ввели новые значения свойства block:
table
table-row
table-cell
и т.д.
Всё бы ничего, но IE 6 не понимает их, поэтому такой лайаутовский шаблон как TableLayout сейчас можно реализовать только при помощи таблицы.
Имитировать его при помощи CSS существующими средствами, которые поддерживают все современные браузеры не представляется возможным.
Поэтому если вы видите, что у вас расположение элементов можно описать только при помощи TableLayout, то нужно использовать тег
Хабра скушал мои < и &qt; Поэтому по второму разу:
Да, с большинством пунктов согласен.
Только вот верстать таблицами в некоторых случаях всё-таки придется.
Надо осознать, что xhtml код содержит не только семантику, но и layout в общем.
Т.е. с тех пор как появился тег div , который никогда не нес и не будет нести никакого смысла, кроме того, что его содержимое располагается именно в нем, тогда понятия layout пришли в xhtml.
Если есть программисты Swing, Flex, то они могут вспомнить, что всегда существовала такая штука как TableLayout.
Конечно, создатели CSS позаботились о том, чтобы это было доступно и xhtml кодерам. Ввели новые значения свойства block:
table
table-row
table-cell
и т.д.
Всё бы ничего, но IE 6 не понимает их, поэтому такой лайаутовский шаблон как TableLayout сейчас можно реализовать только при помощи таблицы.
Имитировать его при помощи CSS существующими средствами, которые поддерживают все современные браузеры не представляется возможным.
Поэтому если вы видите, что у вас расположение элементов можно описать только при помощи TableLayout, то нужно использовать тег table, только не забывайте вставлять в него всегда tbody
Да, с большинством пунктов согласен.
Только вот верстать таблицами в некоторых случаях всё-таки придется.
Надо осознать, что xhtml код содержит не только семантику, но и layout в общем.
Т.е. с тех пор как появился тег div , который никогда не нес и не будет нести никакого смысла, кроме того, что его содержимое располагается именно в нем, тогда понятия layout пришли в xhtml.
Если есть программисты Swing, Flex, то они могут вспомнить, что всегда существовала такая штука как TableLayout.
Конечно, создатели CSS позаботились о том, чтобы это было доступно и xhtml кодерам. Ввели новые значения свойства block:
table
table-row
table-cell
и т.д.
Всё бы ничего, но IE 6 не понимает их, поэтому такой лайаутовский шаблон как TableLayout сейчас можно реализовать только при помощи таблицы.
Имитировать его при помощи CSS существующими средствами, которые поддерживают все современные браузеры не представляется возможным.
Поэтому если вы видите, что у вас расположение элементов можно описать только при помощи TableLayout, то нужно использовать тег table, только не забывайте вставлять в него всегда tbody
приятно, когда автор следит за комментами и на все вопросы точно(или почти точно) отвечает.
va1en0k, вы несомненно молодец
va1en0k, вы несомненно молодец
2. Для FF действительно есть плагин, который по возможностям превосходит оперу (хотя бы потому, что список распазноваемых ссылок не ограничен Next, Prev, Home, Top и ещё несколькими). Это просто констатация факта :)
Кроме того, LINK поддерживается многими текстовыми браузерами (links, lynx) и поисковыми ботами (Яндекс точно поддерживает; но вряд ли это влияет на ранжирование).
Кроме того, LINK поддерживается многими текстовыми браузерами (links, lynx) и поисковыми ботами (Яндекс точно поддерживает; но вряд ли это влияет на ранжирование).
Отличная статья, спасибо. Для начинающих (точнее таких, чуть продвинутых) — вещь особенно полезная.
Мне, кажется, что многое из того, о чем пишет автор применимо к не очень большим сайтам с несложной структурой страниц.
Когда у вас портал страниц на 100, кучу контента генерируется на js, данные приходят через ajax, всякие там drag&drop и т.п. посмотрю я как вы обойдетесь без картинок в коде, таблиц, id у тегов, js внутри HTML.
Когда у вас портал страниц на 100, кучу контента генерируется на js, данные приходят через ajax, всякие там drag&drop и т.п. посмотрю я как вы обойдетесь без картинок в коде, таблиц, id у тегов, js внутри HTML.
используйте не тег , а тег .
А вы видели где нибудь работающий пример этого извращения??
А вы видели где нибудь работающий пример этого извращения??
Вопрос автору, и всем.
Как избежать align="absmiddle", например вот здесь: mayka . letka . ru (разделитель в горизонтальном меню)
Как избежать align="absmiddle", например вот здесь: mayka . letka . ru (разделитель в горизонтальном меню)
li {
background-position: 0 50%;
}
background-position: 0 50%;
}
Переверстать меню через конструкцию ul-li, а разделители задать через background
1 E у вас код перегружен DIV-ami…..
2 Макет вашей можно легко сверстать на таблицах
3 Font-size никогда не задается в px. IE6 не масштабирует текст для которого Font-size указан в px.
4. Верхнее горизонтальное меню правильнее и легче сделать списком и потом задать display: inline
5. А вот в левой стороне очевидный список сделали таблицей …
6. Надеюсь это рабочий проект и потом все стили вынесите в отдельный фаил, почему это делается … читайте здесь http ://developer.mozilla.org/en/docs/Properly_Using_CSS_and_JavaScript_in_XHTML_Documents
7. Ну а изображения расположите с помощью CSS
8. charset=windows-1251 это каменный век … используйте utf8
2 Макет вашей можно легко сверстать на таблицах
3 Font-size никогда не задается в px. IE6 не масштабирует текст для которого Font-size указан в px.
4. Верхнее горизонтальное меню правильнее и легче сделать списком и потом задать display: inline
5. А вот в левой стороне очевидный список сделали таблицей …
6. Надеюсь это рабочий проект и потом все стили вынесите в отдельный фаил, почему это делается … читайте здесь http ://developer.mozilla.org/en/docs/Properly_Using_CSS_and_JavaScript_in_XHTML_Documents
7. Ну а изображения расположите с помощью CSS
8. charset=windows-1251 это каменный век … используйте utf8
Еще бы добавил кроме -, использование связки - - для создания списка определений.
По поводу strict - Там нету iframe - предлагают юзать тег object.
Тогда такой вопрос. Как засубмитеть в object -?
C iframe - всё просто
Тогда такой вопрос. Как засубмитеть в object -?
C iframe - всё просто
По 4му пункту….
HTML это все еще не XML и это возможно изменится когда IE начнет поддерживать тип содержания application/xhtml+xml, так что полное разделение представления и контента, ну достижимо, но большими усилиями и то не во всех случаях.
Посмотрите на Яндекс, google , artlebedev.ru как они сделаны ? Без табличек ? Без таблиц будет рационально верстать когда в IE будет поддерживается свойство CSS display: table-cell (будет в IE8).
Большинство страничек можно сверстать на таблицах. Это быстрее и эффективнее. Экономит время и соответственно деньги.
Если вы думаете что я не прав, задумайтесь … думаете вышеупомянутые сайты верстали случайные люди?
Ну а кто равняется на csszengarden … это не верстка , это искусство,
имеющего мало общего с реальной практикой.
Я думаю у всех конечная цель сделать сайт максимально эффективно, с понятным кодом и в кратчайшее сроки. Табличная верстка дает вам это. Задумайтесь сколько времени вы потратили на то что бы искать решения проблем при безтабличной верстки. Еще табличная верстка хорошо масштабируется во всех браузеров что важно для usability
HTML это все еще не XML и это возможно изменится когда IE начнет поддерживать тип содержания application/xhtml+xml, так что полное разделение представления и контента, ну достижимо, но большими усилиями и то не во всех случаях.
Посмотрите на Яндекс, google , artlebedev.ru как они сделаны ? Без табличек ? Без таблиц будет рационально верстать когда в IE будет поддерживается свойство CSS display: table-cell (будет в IE8).
Большинство страничек можно сверстать на таблицах. Это быстрее и эффективнее. Экономит время и соответственно деньги.
Если вы думаете что я не прав, задумайтесь … думаете вышеупомянутые сайты верстали случайные люди?
Ну а кто равняется на csszengarden … это не верстка , это искусство,
имеющего мало общего с реальной практикой.
Я думаю у всех конечная цель сделать сайт максимально эффективно, с понятным кодом и в кратчайшее сроки. Табличная верстка дает вам это. Задумайтесь сколько времени вы потратили на то что бы искать решения проблем при безтабличной верстки. Еще табличная верстка хорошо масштабируется во всех браузеров что важно для usability
Не согласен с тем, что таблицами проще верстать, чем дивами. И почему это будет эффективнее? Откуда такое мнение? Поспрашивайте в верстальщиков с опытом, что проще - дивы и таблицы, я думаю, процентов 80-90, ответят, что дивы. Они логичнее, понятнее, меньше кода, и самое главное - что либо изменить на сайте не составит особого труда. А таблицы? Ужас...
По
7. фреймы
Фреймы это устаревшая технология … так что про них можно забыть. Вместо фреймов надо использовать overflow v css , например задать эму значение scoll… кому интересно может посмотреть на msdn-е там так сделано
7. фреймы
Фреймы это устаревшая технология … так что про них можно забыть. Вместо фреймов надо использовать overflow v css , например задать эму значение scoll… кому интересно может посмотреть на msdn-е там так сделано
По
9. код должен быть готов к анализу машиной
Вместо того, чтобы плодить API, можно делать страницу понятной для анализа при помощи всяких XML-парсеров и т.п.
Ну…. Пока наш самый главный парсер – IE этого не поддерживает … думаю заморачеватся над этим нет смысла
9. код должен быть готов к анализу машиной
Вместо того, чтобы плодить API, можно делать страницу понятной для анализа при помощи всяких XML-парсеров и т.п.
Ну…. Пока наш самый главный парсер – IE этого не поддерживает … думаю заморачеватся над этим нет смысла
6 пункт — нет, не всегда. Зачастую он только мешается, и не дает нормально работать во всех браузерах (недавно был пример с куево тучек полупрозрачный границ, полупрозрачными закруглениями, полупрозрачным текстом, с прозрачными кнопками с текстом). Все эти вещи не сделать со strict.
А конкретно можно пример что именно нельзя сделать? Скорей всего вы используете устарелую технологию которою убрали из Strict …. Скорей всего есть новый способ это сделать, просто вы эго не знаете. Давайте ссылку интересно разобраться …
Бред. Вы хотите сказать, что в strict`е нельзя сделать полупрозрачные тени, углы и т.д.? Не путайте людей, всё это можно сделать, что-то Вы там намудрили. От doctype рендеринг png-файлов не зависит.
я дичайше извиняюсь, но ЧТО ЭТО?
20 минут писал ответ и гребаный сафари все уничтожил. Выложусь кратко
мнемоники в жопу, это когда уникод нормально не поддерживался использовали
#a #b в css - конструкция лишённая смысла
#a div.class.class2 - конструкция совсем не лишённая смысла да ещё и в несколько раз более шустрая чем .class.class2
даже при "точном выводе текста"
таблицы - всё-таки валидный элемент всех спецификаций гипертекста
стрикт - хорош для самообучения
xml - контейнер для данных. (X)HTML - язык разметки. Не тупить.
label разумнее использовать так
так можно избежать уйму никому не нужных id.
мнемоники в жопу, это когда уникод нормально не поддерживался использовали
#a #b в css - конструкция лишённая смысла
#a div.class.class2 - конструкция совсем не лишённая смысла да ещё и в несколько раз более шустрая чем .class.class2
даже при "точном выводе текста"
<br/><br/> необходимо менять на <p>. Точнее - при вводе пользователем. Если только это не код.<b> менять на font-weight: bold, стронг использовать только в логическом выделении. И проставить font-weight: bold на стронг если по задумке дизайна текст должен быть жирным. С таким же успехом можно сделать стронг не жирным а лохматым - это нормально. Жирность для стронга как и наклонность для em - не является обязательным.таблицы - всё-таки валидный элемент всех спецификаций гипертекста
стрикт - хорош для самообучения
xml - контейнер для данных. (X)HTML - язык разметки. Не тупить.
label разумнее использовать так
<label>
label
<input name="cotnrol_for_label" ... />
</label>
так можно избежать уйму никому не нужных id.
увлекаться <b> вместо <strong>теперь так? кстати, по стрикту b, i, big, small (…) вполне себе разрешены (i и b есть в WD HTML5, хотя нет в WD XHTML2), хотя еще недавно считал, что они воспроизводятся только для совместимости.
Всегда верстайте в strict! Это несложно, но интересно ;)Вы ошибаетесь, HTML4/transitional куда веселее :)
Верстание табличками/дивами соотносится с ценой/качеством/опытом/временем/сложностью.
Не всегда овчинка стоит выделки.
Можно подойти абстрактно и считать всю информацию, в том числе и дизайн - табличными данными, и выводить это табличками :)
Сам недавно начал верстать div'ами, и мои извращенные представления о дизайне не всегда вписываются в эту идеологию. Пошерстив раз 20 инет на предмет возникающих затруднений, понимаешь что ты не одинок.
Не всегда овчинка стоит выделки.
Можно подойти абстрактно и считать всю информацию, в том числе и дизайн - табличными данными, и выводить это табличками :)
Сам недавно начал верстать div'ами, и мои извращенные представления о дизайне не всегда вписываются в эту идеологию. Пошерстив раз 20 инет на предмет возникающих затруднений, понимаешь что ты не одинок.
iframe очень даже используется в html5
apiblog.youtube.com/2010/07/new-way-to-embed-youtube-videos.html
apiblog.youtube.com/2010/07/new-way-to-embed-youtube-videos.html
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О чем не стоит забывать, когда верстаешь HTML