Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 108
это ведь PHP ;)
очень наглядно, распечатаю на А0 и на стенку, спасибо ))
В принципе так по возможности и делаю. Понятный код.
И зачем все подряд в <div> заворачивать?
То же меню: <ul> сам по себе является блочным элементом
и обертка в виде другого блочного элемента ему в общем случае не нужна.
То же меню: <ul> сам по себе является блочным элементом
и обертка в виде другого блочного элемента ему в общем случае не нужна.
меню в отдельный див там не завернуто - там все содержимое страницы завернуто в отдельный див
и написано зачем так сделано
и написано зачем так сделано
Обратите внимание на блок «Semantically Clean Menu».
да, но увы на практике всё осложняет IE: в шестом известный expression а-ля min-width не работает для body; а в седьмом странное смещение центрированной статичной страницы (при изменении масштаба).
по сути, там многие дивы таки являются больше вспомогательными, чем семантически оправданными, но всё же автор не перегибает и это всё равно остаётся адекватная xhtml-верстка...
по сути, там многие дивы таки являются больше вспомогательными, чем семантически оправданными, но всё же автор не перегибает и это всё равно остаётся адекватная xhtml-верстка...
Подумал о том же.
Очередной пример дивитиуса.
Очередной пример дивитиуса.
Угу. Мне это тоже не понравилось. Единственное применение этому может быть, если ДЕЙСТВИТЕЛЬНО нужен некий контейнер, имеющий особые стили или скрипты для себя - но на это ведь не указано, так что на деле - пофиг :)
простой случай. этот самый див с меню должен иметь 20% в width от общей ширины страницы, однако меню должно иметь 30px отступ слева. Вы будете долго трахаться с одиноким
- , пока не додумаетесь обернуть его в див. Как раз в общем случае обёртка обязательна. А вот в частном (верстка статичная, не резинка) можно обойтись без обертки.
Мне не нравиться. Для меня мой стиль удобнее. И в CSS параметры в одну строчку пишу.
>> И в CSS параметры в одну строчку пишу.
Я думал я один такой :)
Я думал я один такой :)
И я такой ;)
кому как удобнее, то так и пишет
кому как удобнее, то так и пишет
В смысле про CSS параметры в строчку.
Это так, но если работает команда или предполагается дальнейшая разработка другими лицами - лучше писать чистый и понятный код. По себе знаю, как трудно визуально воспринимать чужой неструктурированный код в одну строку.
всегда можно воспользоваться сервисами по форматированию кода. А вот параметры желательно группировать по их значимости (сперва свойства позиционирование блока, потом отсупы,потом оформление) Так, написанный "одной строкой" css вполне себе читабилен и прост для понимания.
Согласен с Вами, по этому когда предполагается, что к CSS разметке буду иметь отношение не только я - пишу её в столбик ;)
мы все такие ;) стили «в одну строчку» позволяют быстро искать элементы, долго не скроля.
вообще-то, у меня гибридный стиль: если мало элементов (скажем, до 8–10) — можно в одну, else — группирую в строки по смыслу (позиционирование, размеры; оформление; т.п.)
вообще-то, у меня гибридный стиль: если мало элементов (скажем, до 8–10) — можно в одну, else — группирую в строки по смыслу (позиционирование, размеры; оформление; т.п.)
Добро пожаловать в клуб =)
Про doctype, body's id и проч - хорошо.
А вот сама идея про "инклудить футер и прочее" - полный бред. У нас 2007й год на дворе, модель MVC не то что популярна, а musthave (иногда иначе, но все равно далеко не всегда так как здесь). Гибкость изменения дизайна, структуры сайта и прочего.
Так что автору не зачет, имхо.
А вот сама идея про "инклудить футер и прочее" - полный бред. У нас 2007й год на дворе, модель MVC не то что популярна, а musthave (иногда иначе, но все равно далеко не всегда так как здесь). Гибкость изменения дизайна, структуры сайта и прочего.
Так что автору не зачет, имхо.
как связаны mvc и модульность дизайна? :)
mvc разделяет дизайн и код (а точнее предполагает некоторый View, который отделяет пхп-код от хтмл) + предполагает работу с модулями , а не делает include_once('menu.html');
а я пользуюсь mvc и шаблонизатором у меня является сам php. и по-другому получить другой блок кода не получится в любом случае.
view - отделяет не php-код от html, а реализацию бизнес-модели (model) от пользовательского интерфейса. связующее звено - controller
view - отделяет не php-код от html, а реализацию бизнес-модели (model) от пользовательского интерфейса. связующее звено - controller
Вы используете MVC и делаете include_once('menu.html'); ? А как же контроллер? Как же связующее звено? :)
> шаблонизатором у меня является сам php
ну здесь я с Вами согласен, сам думаю бросать смарти и заняться зендовской техникой, но я имел в виду отделение пхп-кода от шаблонов, а пхп-шаблоны или нет - уже не важно.
> шаблонизатором у меня является сам php
ну здесь я с Вами согласен, сам думаю бросать смарти и заняться зендовской техникой, но я имел в виду отделение пхп-кода от шаблонов, а пхп-шаблоны или нет - уже не важно.
контроллер взаимодействует только с пользователем, рыться в шаблонах и инклудить футеры, хеадеры и меню ему не к чему, иначе это уже не mvc
Я и не говорил что он должен рыться в футерах. А вот меню - обычно отдельный модэл (потому что изменяем в админке и настраиваться должен и вообще), поэтому пихать его как статический шаблон - изначально неверный совет был бы, согласитесь.
ну он совсем не статический шаблон - там php- (или смарти- или еще какой) код генерирует само меню по данным, переданным в компонент View
непосредственно в шаблоне, где требуется меню я инклудю его блок, а контроллером передаю во вью данные, требуемые для меню
непосредственно в шаблоне, где требуется меню я инклудю его блок, а контроллером передаю во вью данные, требуемые для меню
То есть в этот шаблон передаются данные и для этого шаблона (футеры) и для меню? А как же пространства имен? Или я все неправильно понял?
в компонент вью передаются все данные, нужные для генерации всей страницы (включая и меню), а он уже решает что куда
хотя даже в части вью, по-моему разделение отдачи одных данных одной части шаблона и других-другой не всегда оправдана
хотя даже в части вью, по-моему разделение отдачи одных данных одной части шаблона и других-другой не всегда оправдана
> в компонент вью передаются все данные, нужные для генерации всей страницы
ну было бы странно если бы не все, но насколько я думал контроллер получает уже результат отработки меню и просто дает его конкретному шаблону как переменную, а не как структуру данных, которая будет применяться в отработке подключаемого шаблона.
ну было бы странно если бы не все, но насколько я думал контроллер получает уже результат отработки меню и просто дает его конкретному шаблону как переменную, а не как структуру данных, которая будет применяться в отработке подключаемого шаблона.
а переменная не может-быть массивом? :)
я лично генерирую меню в шаблоне из массива, можно по другому - тут уж на вкус и цвет
я лично генерирую меню в шаблоне из массива, можно по другому - тут уж на вкус и цвет
Я имел в виду переменную в виде строки, которая будет вместо этого include'а.
по-моему это не очень удобно и не вполне логично - генерировать html-код меню вне шаблонизатора
это не мвц. в мвц связь от контроллера к модели при построении страници односторонняя. связь от модели к контроллеру - это только реакция на дейсвия пользователя.
ээ.. Так вроде как односторонняя.
Тоесть:
есть модель меню, в которой можно получить, к примеру, данные верхнего меню, данные нижнего меню. Есть View для верхнего меню один, другой, есть View для нижнего меню один, другой, третий (там цвета разные, дизайн и проч).
Контроллер берет отбработку View для верхнего меню с шаблоном, допустим, первым, данные нижнего обрабатывает, допусьтим, вторым шаблоном для нижнего. Потом пихает верхнее меню в переменную $menuTop, нижнего в $menuBottom.
А в примере, на сколько я понял, происходит так:
берем данные меню верхнего от модели в $topMenu (на этот раз это уже некий массив или объект), нижнее в $bottomMenu и парсится все вместе.
В таком случае надо бы шаблону еще и указывать что верхний пусть обрабатывает $topMenu, нижний $bottomMenu и так далее. Я правильно понял?
p.s.: также насчет связи односторонней, правильно ли я понял?
Тоесть:
есть модель меню, в которой можно получить, к примеру, данные верхнего меню, данные нижнего меню. Есть View для верхнего меню один, другой, есть View для нижнего меню один, другой, третий (там цвета разные, дизайн и проч).
Контроллер берет отбработку View для верхнего меню с шаблоном, допустим, первым, данные нижнего обрабатывает, допусьтим, вторым шаблоном для нижнего. Потом пихает верхнее меню в переменную $menuTop, нижнего в $menuBottom.
А в примере, на сколько я понял, происходит так:
берем данные меню верхнего от модели в $topMenu (на этот раз это уже некий массив или объект), нижнее в $bottomMenu и парсится все вместе.
В таком случае надо бы шаблону еще и указывать что верхний пусть обрабатывает $topMenu, нижний $bottomMenu и так далее. Я правильно понял?
p.s.: также насчет связи односторонней, правильно ли я понял?
упс. я хотел сказать про односторонность связи между контроллером и вью. и имел ввиду что контроллер который берет результат работы вью и чтото еще с ним делает это уже нарушение архитектуры. это имхо
Тоесть вы, все же, за вариант с include'ами? Или как иначе такое реализовать с односторонностью?
да я за инклуды, ну или их аналоги в конкретных шаблонных движках. я считаю что это красивее. и к тому же из практических соображений лучше. К этому сразу пример: было много страниц и на всех одинаковое меню. Сделали как вы описывали. И тут надо на одной из страниц поменять внешний вид меню (структура остаеться неизменной) - выходит что мы лезем в контроллер(чтобы сказать ему, что для этой страници у нас другой шаблон меню используеться), чтобы фактически поменять внешний вид
Ну здесь я согласен, но обычно ситуации типа таких если возможны (изменение дизайна кардинально, в виде другого шаблона) - это дело выносится в админку и здесь уже выигрыш контроллера - он берет из БД какой шаблон хотел юзер и парсит его, что в шаблонах (особенно работа с БД) не очень приятно.
Ну, в общем, вывод как обычно получился - для конкретной ситуации свое решение. Блин :)
Ну, в общем, вывод как обычно получился - для конкретной ситуации свое решение. Блин :)
а почему выигрыш контроллера?
я просто заменю в своем mvc-фреймовке, при его инициализации компонент view, на view_db (они реализуют один интерфейс или абстрактный класс), который просто берет шаблоны из бд.
тогда мне прийдется написать только новый вью - его вызовы останутся теми-же
или я что-то не так понял? :)
я просто заменю в своем mvc-фреймовке, при его инициализации компонент view, на view_db (они реализуют один интерфейс или абстрактный класс), который просто берет шаблоны из бд.
тогда мне прийдется написать только новый вью - его вызовы останутся теми-же
или я что-то не так понял? :)
...onfocus="this.value=''...
...style="clear:both...
НЕunobtrusiveНО!
...style="clear:both...
НЕunobtrusiveНО!
Meta с кодировкой всё же очень желательно ДО title указывать.
w3/401/charset:
The META declaration must only be used when the character encoding is organized such that ASCII-valued bytes stand for ASCII characters (at least until the META element is parsed). META declarations should appear as early as possible in the HEAD element.
w3/401/charset:
The META declaration must only be used when the character encoding is organized such that ASCII-valued bytes stand for ASCII characters (at least until the META element is parsed). META declarations should appear as early as possible in the HEAD element.
мне понравилась IDентификация <body> — красиво на мой взгляд :)
______
вообще же.. я конечно не вижу остальных страниц этого «сайта», возможно гибкость и полный контроль там сильно важны, но мне больше нравится такой подход:
((а всё остальное (сверху-снизу) дописывать во внешнем файле-php-обработчике))
— значительно проще и более соответствует пункту «common content included», получается «yet more common content included» :-))
______
вообще же.. я конечно не вижу остальных страниц этого «сайта», возможно гибкость и полный контроль там сильно важны, но мне больше нравится такой подход:
начало of index.htmlконец of index.html((а всё остальное (сверху-снизу) дописывать во внешнем файле-php-обработчике))
— значительно проще и более соответствует пункту «common content included», получается «yet more common content included» :-))
Зачем же было эту картинку в .jpg сохранять — .png или .gif значительно лучше!
По-моему, нету там ничего нового.
Странно, но я по какой-то причине всегда так и писал код. Хотя, кто сказал что это и есть ПРАВИЛЬНО?
А вот здесь видно еще лучше
Как я понимаю автора кода! Сам люблю чтобы link-и к link-ам, meta к meta, скрипты к скриптам :)
Блин, действительно очень прописные истины...
кто автор картинки-то?
ИМХО, юзеры Оперы и ФФ обновляются куда чаще, чем ословоды - благо система автоматического уведомления/обновления и там, и там наличеиствует. Так что встретить человека, например, с 6-й Оперой сейчас почти нереально, и в разработке под Оперу и ФФ МОЖНО ориентироваться на последние версии, в отличие от ослика IE, который обновляется редко, а скачивается ещё реже...
скрипты не рекомендуют инклудить в хидере только эстеты кода, но не работы проекта. Это как учебники школьникам по физике пишут ученые, у которых нет детей и которые никогда не преподавали.
На одном из моих проектов пару лет назад тусило под 100 000 уников каждый день, и я в те еще времена рискнул инклудить все скрипты в конце страницы. Работа половины сайта (или удобство работы с ним) зависило от JS, который грузился в самом конце и как следствие, ни один из них не работал, пока страница не загрузится до конца =) разве это правильно? Меня пользователи закидали email`ами с просьбами вернуть все обратно.
У нас пока еще слишком много пользователей со слабым коннектом. Круто было бы иметь бентли в каменные времена. Еще колесо неизобрели, а у тебя бентли. Только толку то от него? Время defer для россии еще не пришло.
На одном из моих проектов пару лет назад тусило под 100 000 уников каждый день, и я в те еще времена рискнул инклудить все скрипты в конце страницы. Работа половины сайта (или удобство работы с ним) зависило от JS, который грузился в самом конце и как следствие, ни один из них не работал, пока страница не загрузится до конца =) разве это правильно? Меня пользователи закидали email`ами с просьбами вернуть все обратно.
У нас пока еще слишком много пользователей со слабым коннектом. Круто было бы иметь бентли в каменные времена. Еще колесо неизобрели, а у тебя бентли. Только толку то от него? Время defer для россии еще не пришло.
Код не красивый - тэг <input> отступает на 4 пробела, а не на 3 как все остальные. Так же у этого текстового поля нет восстановления подсказки если оставили его пустым, и будут убиваться данные, если что-то наберешь и заново поставишь на него курсор.
Вот как это надо было сделать: <input value="Search..." onfocus="if(this.value==this.defaultValue) this.value='';" onblur="if(this.value=='') this.value=this.defaultValue;" />
У картинки точно не проставлены размеры, поэтому грузиться страница будет голимо.
Много акцентов на форматировании кода, которое никто не увидит, и такие огрехи с версткой.
Вот как это надо было сделать: <input value="Search..." onfocus="if(this.value==this.defaultValue) this.value='';" onblur="if(this.value=='') this.value=this.defaultValue;" />
У картинки точно не проставлены размеры, поэтому грузиться страница будет голимо.
Много акцентов на форматировании кода, которое никто не увидит, и такие огрехи с версткой.
код, кстати, очень похож на http://simplebits.com/ и во многом повторяет технику Дэна. Спорить тут бесполезно, что касается верстки Дэн всегда был на высоте. Думаю, если все будут равняться на его стиль, мир станет лучше.
Угу, семантическая стриктовая верстка. Зачем в доктайпе транзишнал оставили не совсем понятно, а так - хорошая памятка для начинающего верстальщика.
Раз уж выбрали темой рисунка html, так и учили бы ему. С точки зрения php-программиста - детский подход для создания полустатичного сайта с несколькими простыми страничками.
Имхо в красивом HTML коде не будет включений php, тем более таких. Обратное верно.
Собственно, так и стараюсь писать. Но мне не понравились два больших куска текста, в которых сам текст убивает сделанную до этого разметку. Для ленивых можно нажимать в Visual Studio специальную кнопаську, которая сама приведет документ к подобному виду.
1)Это xhtml имхо есть некоторая разница. - мелочь конечно
2)Если хотите красивый код то не правильнее ли пользовать шаблонизатор и не делать этих детских инклудов? тем более криво сделанных, если уж делать то include_once("{$_SERVER['DOCUMENT_ROOTE']}/dir/file.php");
2)Если хотите красивый код то не правильнее ли пользовать шаблонизатор и не делать этих детских инклудов? тем более криво сделанных, если уж делать то include_once("{$_SERVER['DOCUMENT_ROOTE']}/dir/file.php");
В 3х местах не согласен:
1. Зачем цеплять ID к BODY для идентификации и стилизации разных страниц? Разве нельзя пользоваться разными ID для основного "page-wrap" DIVа, который рекомендуется использовать опять же на каждой странице. Так получится однозначно лаконичнее...
2. И вообще, лично я в некоторых местах всётаки за таблицы. И случай с
3. Почему некоторые поля инклудятся (NEWS, EVENTS, etc..) а некоторые нет (WELCOME) и колбасятся в тело основной страницы?
4. Почему некоторые блоки имеют вёрстку с дивами в теле основной страницы
1. Зачем цеплять ID к BODY для идентификации и стилизации разных страниц? Разве нельзя пользоваться разными ID для основного "page-wrap" DIVа, который рекомендуется использовать опять же на каждой странице. Так получится однозначно лаконичнее...
2. И вообще, лично я в некоторых местах всётаки за таблицы. И случай с
<div id="page-wrap"> мне кажется именно тот... Таблицу проще тянуть и это более однозначно воспринимается всеми браузерами.3. Почему некоторые поля инклудятся (NEWS, EVENTS, etc..) а некоторые нет (WELCOME) и колбасятся в тело основной страницы?
4. Почему некоторые блоки имеют вёрстку с дивами в теле основной страницы
<div class="events-box"><?php include_once("events.html")?></div>а некоторые дивы, создающие логические блоки запрятаны в файлы-инклуды <?php include_once("menu.html")?> - тут <div id="menu"> находится в подключаемом файлеОп, получилось даже в четырёх...
Так сильно захлестнул творческий оргазм что не заметил как добавился ещё один пунктик. :)
Так сильно захлестнул творческий оргазм что не заметил как добавился ещё один пунктик. :)
1. id к body это хорошее решение, когда на странице что-то действительно отличается от других страниц, например разноцветные заголовки. К тому же у page-wrap есть свои стили, и в вашем случае прийдётся писать что-то вроде:
page-wrap-home,
page-wrap-article,
page-wrap { ... }
плюс стиль к каждому page-wrap
2. После layoutgala начинаешь понимать смысл обёртывающего дива (даже если там ни одного стиля нет :)
А ещё понимаешь беспомощность таблиц, но это отдельный разговор.
page-wrap-home,
page-wrap-article,
page-wrap { ... }
плюс стиль к каждому page-wrap
2. После layoutgala начинаешь понимать смысл обёртывающего дива (даже если там ни одного стиля нет :)
А ещё понимаешь беспомощность таблиц, но это отдельный разговор.
1. а в чём проблема? так вот через запятую и прописать в CSS все варианты.
2. ну и в чём заключается беспомощность таблиц?
2. ну и в чём заключается беспомощность таблиц?
1. Громоздкость названий стилей плюс лишние строчки в css, хотя, конечно не проблема.
2. Беспомощность? в отсутствии гибкости. Один и тот же дивный html код можно отдезайнить множеством способов, как в layoutgala.
К примеру, захочешь оптимизировать сайт под кпк, и сделать чтобы пользователи кпк видели не 3 колонки, а в две (не убрать лишнюю колонку, а поместить её под другой): таблицами такое не реализовать.
Или если требуется сделать другую тему для сайта, в которой меню будет не слева, а справа. Там где можно обойтись правкой только css, в случае таблиц прийдётся править и html, а это усложняет переключение тем.
2. Беспомощность? в отсутствии гибкости. Один и тот же дивный html код можно отдезайнить множеством способов, как в layoutgala.
К примеру, захочешь оптимизировать сайт под кпк, и сделать чтобы пользователи кпк видели не 3 колонки, а в две (не убрать лишнюю колонку, а поместить её под другой): таблицами такое не реализовать.
Или если требуется сделать другую тему для сайта, в которой меню будет не слева, а справа. Там где можно обойтись правкой только css, в случае таблиц прийдётся править и html, а это усложняет переключение тем.
1. "page-wrap home", "page-wrap article"
Одно мне не понятно:
футер и хедер php include, а вот сам контент из базы потянуть застеснялись что ли? :)
футер и хедер php include, а вот сам контент из базы потянуть застеснялись что ли? :)
Это, случаем, взято не отсюда?
Не очень ясно зачем там PHP'шные инкюды, а так — идеологически грамотно. Поддерживаю.
А вот тут противоречие:
«Your HTML should be focused on structure and content, not styling! Keep all of your styling in your CSS, there should be no deprecated tags (e.g <font>) in site.»
и тут же в коде: <div style="clear: both;"></div> (можно догадаться зачем это, но тем не менее, давно уже известны различные фиксы для этого — тот же clearfix)..
или вот ещё хуже: <div id="right-content"> — судя по всему тут не имеется в виду "правильный контент", т.к. до этого инклудился left-sidebar (тут, кстати, противоречие с пунктом «Important Content First»)
«Your HTML should be focused on structure and content, not styling! Keep all of your styling in your CSS, there should be no deprecated tags (e.g <font>) in site.»
и тут же в коде: <div style="clear: both;"></div> (можно догадаться зачем это, но тем не менее, давно уже известны различные фиксы для этого — тот же clearfix)..
или вот ещё хуже: <div id="right-content"> — судя по всему тут не имеется в виду "правильный контент", т.к. до этого инклудился left-sidebar (тут, кстати, противоречие с пунктом «Important Content First»)
Красивый HTML это всё равно что красивый постскрипт.
Красивым должен быть исходный документ, оформленный либо визуальным редактором, либо макроязыком типа Markdown. То, что видит броузер, должно быть красиво только для него.
Красивым должен быть исходный документ, оформленный либо визуальным редактором, либо макроязыком типа Markdown. То, что видит броузер, должно быть красиво только для него.
HTML возможно и красивый.. но вот в качестве шаблона - полный ужас
Хм... что то не очень. Тут многое можно оспорить (даже например в CSS стиль для body можно было так и писать, а не присваивать ему id). Насчет XHTML - оформлен по правил, но реализация PHP тут не нравится.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как выглядит красивый HTML код