Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 194
а бывают плохие и даже отвратительные, как спецификация ECMAScript
О! Ещё один! Задолбали бросаться камнями в сторону JavaScript от непонимания.
Javascript хороший язык, но с очень плохой спецификацией. Она насквозь мутная и при этом допускает множественные толкования там, где это недопустимо.
JavaScript это всего лишь один из вариантов ECMAScript. Есть еще, например, ActionScript 3.
| множественные толкования там, где это недопустимо.
— ни разу не встречал. В общем не надо гнать на язык с которым не привыкли работать.
А статья хорошая. Сам верстаю в XHTML — нравится порядок… Надо будет переучиваться :)
| множественные толкования там, где это недопустимо.
— ни разу не встречал. В общем не надо гнать на язык с которым не привыкли работать.
А статья хорошая. Сам верстаю в XHTML — нравится порядок… Надо будет переучиваться :)
Семантика, порядок, не особо помеха. Переучиваться — вряд ли, учиться — да! Я верстаю уже больше 7 лет… сейчас смотрю на html5 эксперементирую… жесть конечно :) учусь.
строго имхо: По поводу JS, ребят, я дизайны рисую, и верстаю… с JS получается мегаинтересно. Как по мне JS просто обязан разваиватся, с ним веб будет лучше…
строго имхо: По поводу JS, ребят, я дизайны рисую, и верстаю… с JS получается мегаинтересно. Как по мне JS просто обязан разваиватся, с ним веб будет лучше…
JavaSxript всего лишь — язык, а степень понимания зависит не только и не столько от спецификации
Да уж, например, автоматическая расстановка точек с запятой — просто идеальный пример граблей, на которые вставал практически каждый. И эти грабли — не единственные.
Можно на Javascript написать потенциально все что хочется, писать и в императивном, и функциональном стиле, но это требует больших усилий, чем в любом нормально спроектированном языке и выглядит монструозно и на грани читаемости в любом случае.
Можно на Javascript написать потенциально все что хочется, писать и в императивном, и функциональном стиле, но это требует больших усилий, чем в любом нормально спроектированном языке и выглядит монструозно и на грани читаемости в любом случае.
Что? Какая «автоматическая расстановка точек с запятой»? Вы о стиле кодирования, где можно упускать знак ";"? Ну дык поменяйте стиль, ибо этот — вам не подходит)
Я о том, что при переносе строк может полностью поменяться смысл кода.
Курить Javascript: The Good Parts от Крокфорда
Это не мне надо курить, а TheShock. Насколько я помню, Крокфорд эту особенность в The Good Parts критикует. И вообще, где-то он говорил, что разочаровался в Javascript.
Угу, как раз недавно обсуждали.
Крокфорд вообще поговорить любит. От этого Javascript хуже не становится.
Крокфорд вообще поговорить любит. От этого Javascript хуже не становится.
Помимо критики, он так же говорит много чего про то, что в JS есть
Да уж придется потерпеть, коли так вышло.
Кстати, Douglas Crockford примерно такой же точки зрения придерживается.
Или он по-вашему тоже недопонимает JavaScript?
Кстати, Douglas Crockford примерно такой же точки зрения придерживается.
Или он по-вашему тоже недопонимает JavaScript?
По-моему JavaScript плох даже после понимания…
через несколько лет в каждой региональной газете появятся объявления типа «ремонт и настройка ПК, заправка принтеров, 1С, сайты на HTML5»
Сей отрывок вызвал у меня когнитивный диссонанс.
Сей отрывок вызвал у меня когнитивный диссонанс.
Имхо, статья длинная и достаточно тяжёлая. Впринципе, неплохая, но кое-где вы допустили ошибки.
Например, сравнение правильного именования элементов c «OOP» — некорректно.
Правильные имена должны быть в любой парадигме, в т.ч. процедурной.
Я приведу на примере класса, но точно так же можно взять в пример и процедурный код.
Если изменится законы и совершенолетие будет наступать не в 18, а в 21, то придётся рефакторить весь код, потому корректно называть как-то так:
Грубо, конечно, но суть понятна.
Проблема в том, что в программировании это понимает большинство (хотя и не все именуют правильно), а вот за CSS в силу того, что язык разметки и многие относятся к нему «несерьёзно» сложилось мнение у многих, что можно именовать элементы по отображению.
И дело даже не в том, что содержимое может поменятся, а в том, что имя класса должно описывать сущность, что это за элемент и почему его необходимо выделить именно так, а не где он и какой он.
Например, сравнение правильного именования элементов c «OOP» — некорректно.
Правильные имена должны быть в любой парадигме, в т.ч. процедурной.
Я приведу на примере класса, но точно так же можно взять в пример и процедурный код.
class Person {
public bool isOlderThan18 () {
return this.age > 18;
}
};
// и так в приложении:
if (person.isOlderThan18()) {
print 'может покупать выпивку';
} else {
print 'не может покупать выпивку';
}
Если изменится законы и совершенолетие будет наступать не в 18, а в 21, то придётся рефакторить весь код, потому корректно называть как-то так:
class Person {
public bool isAdult () {
return this.age > 18;
}
};
Грубо, конечно, но суть понятна.
Проблема в том, что в программировании это понимает большинство (хотя и не все именуют правильно), а вот за CSS в силу того, что язык разметки и многие относятся к нему «несерьёзно» сложилось мнение у многих, что можно именовать элементы по отображению.
И дело даже не в том, что содержимое может поменятся, а в том, что имя класса должно описывать сущность, что это за элемент и почему его необходимо выделить именно так, а не где он и какой он.
У вас хороший пример, он отлично показывает оторванность семантистов от реальной жизни.
Понимаете, если вы пишете софт для крупной фирмы или государства, который будет крутится на серверных фермах ближайшие лет 30 — вы, безусловно, правы.
Но в мире верстки все совершенно не так. Там нет «законов», которые могут внезапно измениться. Есть макет дизайна, утвержденный заказчиком и дизайнером. Все, вот как оно есть в макете — так оно останется навсегда. Вся семантика, абстрактные классы и все прочие — это все предполагает, что будет версия 2.0, а за ней 3.0, и так далее. А в верстке этого не будет. Ну, то есть оно может и будет, но это будет совершенно другой дизайн, с совершенно другой, сделанной с нуля, версткой, как минимум на намного более новой версии CMS или вообще на другой CMS. Верстальщик решает конкретную задачу, у которой заведомо не будет продолжения. Любая абстракция в этой ситуации только вред.
Я, конечно, не рассматриваю ситуацию создания стандартного шаблона авторами CMS. Я говорю именно о студиях, выпускающих конечные сайты.
Понимаете, если вы пишете софт для крупной фирмы или государства, который будет крутится на серверных фермах ближайшие лет 30 — вы, безусловно, правы.
Но в мире верстки все совершенно не так. Там нет «законов», которые могут внезапно измениться. Есть макет дизайна, утвержденный заказчиком и дизайнером. Все, вот как оно есть в макете — так оно останется навсегда. Вся семантика, абстрактные классы и все прочие — это все предполагает, что будет версия 2.0, а за ней 3.0, и так далее. А в верстке этого не будет. Ну, то есть оно может и будет, но это будет совершенно другой дизайн, с совершенно другой, сделанной с нуля, версткой, как минимум на намного более новой версии CMS или вообще на другой CMS. Верстальщик решает конкретную задачу, у которой заведомо не будет продолжения. Любая абстракция в этой ситуации только вред.
Я, конечно, не рассматриваю ситуацию создания стандартного шаблона авторами CMS. Я говорю именно о студиях, выпускающих конечные сайты.
Такие названия показывают наплевательское отношение разработчиков и/или непонимание сути вёрстки. Вся соль в том, что мне совершенно всё-равно, назвать этот метод "
В современных ide отличная автозамена и при необходимости поменять все left на right не будет никакой проблемы. Но это просто хороший стиль программирования. Так само, как последовательные стандарты, разделение логики и представления, да и просто традиция писать все имена на английском, а не транслите.
Или вы не имеете ничего против названия класса «levaya-panel»? Это просто некрасиво и этому есть причины.
isAdult" или "isOlderThan18". Так само, как всё-равно, назвать класс "left" или "toolbar". Реализация не изменится, изменится только имя, которое для парсера совершенно не имеет смысла, пусть я его даже назву "sex" или "kak-ya-zdez-trahalsa-s-ie". Но если у вас проблема придумать осмысленное название классу элемента, то проблема в том, что вы просто не понимаете сути того, что вы делаете.В современных ide отличная автозамена и при необходимости поменять все left на right не будет никакой проблемы. Но это просто хороший стиль программирования. Так само, как последовательные стандарты, разделение логики и представления, да и просто традиция писать все имена на английском, а не транслите.
Или вы не имеете ничего против названия класса «levaya-panel»? Это просто некрасиво и этому есть причины.
Все, вот как оно есть в макете — так оно останется навсегда.Наверное это справедливо только для очень маленьких простых сайтов.
В компании где я работаю, значительная часть тасков — правки уже существующих сайтов без кардинального изменения дизайна. И разумеется никто не перевёрстывает сайт заново, и уже тем более не переносит всё на другой движок. Зачем? Есть хорошо свёрстанный сайт, с отлаженным backend, зачем перевёрстывать всё заново если нужно внести правки?
Чем легче поддерживать код — тем быстрее вносятся правки — меньше тратится времени — больше работы выполняется — больше денег — profit.
Поддержка — вообще отдельная тема.
В данном случае, ИМХО, имеется в виду именно первичная разработка.
В данном случае, ИМХО, имеется в виду именно первичная разработка.
Как таковая первичная разработка может быть только с зафиксированным ТЗ. Очень часто требования и ТЗ меняются до окончательной сдачи и первичная разработка плавно переходит в поддержку — сложно становится отделить разработку новых фич от изменения уже написанного для облегчения разработки нового. А если стоит вопрос выбрать имя для панели left или sidebar1, то, имхо, sidebar1 избавит от необходимости переименования в будущем, а в настоящем ничем разработку не задержит.
Если уж создали метод, то назовите его правильно — что он делает, а не повторите его исходный код. В этом идея моего сообщения. Согласны?
Слишком не в тему. А зачем? Остановится надо тогда, когда надо остановится. Зависит от проекта, условий, денег, времени, желания, дурь на Солнце и ещё кучи факторов) Но ту часть, что вы _уже_ сделали — надо сделать качественно.
Нет, вы занимаетесь подменой понятий.
Вы всё-равно даёте этому диву название, вам не нужно проектировать, менять что-то или писать кучи кода, как в случае с дополнительными методами. Вам всего лишь нужно дать осмысленное название.
Вы же не написали в комменте
вместо
И при общении с коллегами-программистами вы не будете говорить «добавь пару пунктов в левую штуку», а скажете что-то типа «добавь пару пунктов в тулбар».
Вы всё-равно даёте этому диву название, вам не нужно проектировать, менять что-то или писать кучи кода, как в случае с дополнительными методами. Вам всего лишь нужно дать осмысленное название.
Вы же не написали в комменте
допустимо назвать ту штуку слева «left»
вместо
допустимо назвать сайдбар «left»
И при общении с коллегами-программистами вы не будете говорить «добавь пару пунктов в левую штуку», а скажете что-то типа «добавь пару пунктов в тулбар».
Мне кажется, что этот момент в условиях веб-разработки во многом зависит от бюджета и сроков. Можно навертеть кучу предусмотренных возможностей, но они не будут укладываться в бюджет, вы сорвете сроки разработки и провалите проект.
Сорвать сроки могут как раз неосмысленные названия, которые будут замедлять ход последующей разработки.
Смотрите, при создании ПО ничего не пишется с бухты-барахты. Каждый слой абстракции — это не только дополнительный слой абстракции, но и время на его написание, следовательно деньги на его написание.
При создании ПО балансируют между двумя факторами — «деньги, затраченные на создание сейчас» против «деньги затраченные на поддержку потом». Так вот, осмысленные название значительно сокращают деньги, затраченные на поддержку потом, при этом увеличение стоимости создания стремится к нулю.
При создании ПО балансируют между двумя факторами — «деньги, затраченные на создание сейчас» против «деньги затраченные на поддержку потом». Так вот, осмысленные название значительно сокращают деньги, затраченные на поддержку потом, при этом увеличение стоимости создания стремится к нулю.
Блин, ну что значит неосмысленные?
Вы вообще понимаете, о чем речь?
Есть CMS.
В ней, к примеру, есть 4 потенциальных места для вставки блоков — слева, справа, сверху и снизу.
Где-то в админке красивыми кнопочками указывается: логин слева, корзина справа, новости тоже справа под корзиной, баннер сверху.
Потом придет условный сеошник и скажет: выкиньте баннер, зато сделайте мне блок сео-ссылок снизу.
А ему — да пожалуйста, у нас все заложено в шаблоне. Здесь нажмите «выкл», а здесь «вкл».
И действительно, где-то в шаблоне верстальщик как-то указывал, что вот именно здесь надо вставлять левые блоки, а вот здесь правые.
И вот как, по вашему, назвать общий контейнер для левых блоков, если не #left?
Вы вообще понимаете, о чем речь?
Есть CMS.
В ней, к примеру, есть 4 потенциальных места для вставки блоков — слева, справа, сверху и снизу.
Где-то в админке красивыми кнопочками указывается: логин слева, корзина справа, новости тоже справа под корзиной, баннер сверху.
Потом придет условный сеошник и скажет: выкиньте баннер, зато сделайте мне блок сео-ссылок снизу.
А ему — да пожалуйста, у нас все заложено в шаблоне. Здесь нажмите «выкл», а здесь «вкл».
И действительно, где-то в шаблоне верстальщик как-то указывал, что вот именно здесь надо вставлять левые блоки, а вот здесь правые.
И вот как, по вашему, назвать общий контейнер для левых блоков, если не #left?
Ага. А в этой же CMS будет возможности менять шаблоны. Потому ни в какой нормальной цмске не делают блоков с названиями «left» и «right». В том же phpbb3 аватарки пользователей по-умолчанию справа, но можно легко поставить их слева.
Да вы что? Это вы сейчас phpbb3 назвали нормальной, да еще и CMS?
О да, простите, в Wordpress колонки действительно называются не left и right, а col1 и col2. Точнее наоборот. Действительно, это семантический прорыв!
О да, простите, в Wordpress колонки действительно называются не left и right, а col1 и col2. Точнее наоборот. Действительно, это семантический прорыв!
Я phpbb вообще оценки не давал, не надо мне приписывать того, что я вам не говорил.
Да, "{name}1" и "{name}2" — это куда лучше для абстрактных и равнозначных блоков, чем «left» и «right». Хотя, конечно, название получше можно было подобрать, чем «col»
Да, "{name}1" и "{name}2" — это куда лучше для абстрактных и равнозначных блоков, чем «left» и «right». Хотя, конечно, название получше можно было подобрать, чем «col»
И таки я не понимаю вашего примера.
«В ней, к примеру, есть 4 потенциальных места для вставки блоков — слева, справа, сверху и снизу.»
Ага, сразу под блоком с ссылками, над панелью управления, два места в хедере и три — в футере. И что? А в другом шаблоке ссылки будут справа, а панель управления — слева?
«В ней, к примеру, есть 4 потенциальных места для вставки блоков — слева, справа, сверху и снизу.»
Ага, сразу под блоком с ссылками, над панелью управления, два места в хедере и три — в футере. И что? А в другом шаблоке ссылки будут справа, а панель управления — слева?
Вы админку джумлы там, или там вп, или амиры, или шоп-скрипта, или уме, или еще какой-нибудь user-friendly cms когда-нибудь видели?
Ага.
И что? Таким же образом можно было написать «в шапке», «в меню», «в тулбаре», «в подвале».
И если верстальщик поменяет два блока местами, то секретарша не будет кричать: «почему я говорю поставить его справа, а оно стоит слева??!!»
И если верстальщик поменяет два блока местами, то секретарша не будет кричать: «почему я говорю поставить его справа, а оно стоит слева??!!»
Вы вообще понимаете, что вы пишете?
Если верстальщик поменяет местами блоки left и right, чтобы довести до слез секретаршу, я его уволю.
Другими методами это не лечится.
Если верстальщик поменяет местами блоки left и right, чтобы довести до слез секретаршу, я его уволю.
Другими методами это не лечится.
Ну, во-первых, там указана позиция, а не название блока, а во-вторых, в хорошей CMS должно быть все по-другому: шаблон определяет набор динамических блоков (позиций, условно говоря) со своими названиями, и при вставке блока-виджета надо выбирать «Хедер», «Левый сайдбар», «Текст внутри между третьим и четвертым постом», а не вот этот ужас, что на картинке. (Кстати, если сделать управление блоками sortable-списком будет круче)
Простите, конечно, за упоминание недостойного Вордпресс, но (это я к примеру, одним ВП все не заканчивается) управление меню и виджетами там как раз так и сделано.
В общем, для того, чтобы хорошо верстать и держать в поддержке код (а даже мелкие шаблончики на ВП приходится, нет-нет, и доделывать, переверстывать по чуть-чуть), надо, чтобы архитектура у движка была в поряде :)
Простите, конечно, за упоминание недостойного Вордпресс, но (это я к примеру, одним ВП все не заканчивается) управление меню и виджетами там как раз так и сделано.
В общем, для того, чтобы хорошо верстать и держать в поддержке код (а даже мелкие шаблончики на ВП приходится, нет-нет, и доделывать, переверстывать по чуть-чуть), надо, чтобы архитектура у движка была в поряде :)
Скажите пожалуйста, чем названия «хедер» и «левый сайдбар» лучше для нормального русского человека, чем «сверху» и «слева»?
На картинке показано именно то, что вы описали.
На картинке показано именно то, что вы описали.
На третий пункт взгляните. А потом подумайте еще раз, чем три блока «Подвал сайта», «Левая колонка» и «Реклама в тексте» лучше. И давайте заканчим тему идиотского именования файлов, идентификаторов и переменных, ведь это с опытом приходит, правда ведь?
В том-то и дело, что молодежь начитается всякой модной фигни о том, что крутые пацаны обязательно придерживаются семантических правил и паттернов, прости Господи, проектирования, а потом приходит на работу и с умным видом начинает городить огород на 10 файлов, создавать себе проблемы и героически, но не до конца их решать там, где надо написать 1 простую строчку кода и пойти дальше.
С опытом как раз приходит понимание, что для каждого средства есть свой калибр целей, и что реально больших целей в этой жизни мало.
С опытом как раз приходит понимание, что для каждого средства есть свой калибр целей, и что реально больших целей в этой жизни мало.
Та да, все — лохи, а вы ;)
Это не опыт, это усталость :)
Я все же поясню, на мой взгляд, очевидную вещь (что правила и стандарты облегчают жизнь в дальнейшем). Паттерны и семантика, прежде всего служат для облегчения поддержки (особенно, при работе в команде, хотя клиент также не должен быть привязан к программисту, который им верстал небольшой шаблон), возможность масштабирования (планирование «на вырост») и реюзабельность (я в большинстве своих проектов верстки использую уже готовые шаблоны, в которых все уже поименовано, плюс не стоит забывать о том, что движок также может быть сменен, тогда хорошо сделанная верстка может быть легко адаптированна под новую архитектуру шаблона).
В общем, я за то, чтобы даже администратор в пыльном свитере делал раскладку проводков по цветам в патчкорде по стандартам и подписывал проводки (а еще лучше — рисовал схему), даже когда компьютеров всего пять штук. Потому что заставлять кого-то каждый раз делать все заново — это непрофессионально.
В общем, я за то, чтобы даже администратор в пыльном свитере делал раскладку проводков по цветам в патчкорде по стандартам и подписывал проводки (а еще лучше — рисовал схему), даже когда компьютеров всего пять штук. Потому что заставлять кого-то каждый раз делать все заново — это непрофессионально.
Сеошник, подражая парсеру html, не оперирует терминами «сверху» и «снизу», а если и оперирует, то имеет в виду место в html-коде, а не визуальное отображение на странице.
CMS, логика админки которой становится непредсказуемой от изменения CSS шаблона, сложно назвать юзабельной и универсальной, по-моему. А если мне нужно три сайдбара — два левых и один правый — как мне указать второй слева? Как-то завязывать серверную логику на классы html-элементов («left», «left1» => «слева», «left2» => «справа»)? А при натягивании стороннего шаблона переименовывать всё? Куда юзабельнее и универсальнее, по-моему, чтобы админка показывала визуально расположение панелей с их именами для данного шаблона, а пользователь задавал в какую панель поместить блок по её имени.
CMS, логика админки которой становится непредсказуемой от изменения CSS шаблона, сложно назвать юзабельной и универсальной, по-моему. А если мне нужно три сайдбара — два левых и один правый — как мне указать второй слева? Как-то завязывать серверную логику на классы html-элементов («left», «left1» => «слева», «left2» => «справа»)? А при натягивании стороннего шаблона переименовывать всё? Куда юзабельнее и универсальнее, по-моему, чтобы админка показывала визуально расположение панелей с их именами для данного шаблона, а пользователь задавал в какую панель поместить блок по её имени.
Вы мыслите Jooml-ой
Отличная статья, прочитал на одном дыхании. Спасибо. Был не в курсе про изменение поведения тэга a. *Пошёл проверять свои реализации*
HTML не настолько хорош, как тут пытается рассказать автор ;)
В частности, frames deprecated, а что на замену?
И сейчас не вспомню, но там еще есть толпа других проблем
В частности, frames deprecated, а что на замену?
И сейчас не вспомню, но там еще есть толпа других проблем
А зачем вам фреймы? Тогда уж и обсудим замену.
Сплиттеры. Единственный способ их сделать нативно, без толп яваскрипта. И хоть с какой-то поддержкой в том же mobile safari
Что такое «сплитеры»?
Ага, значит это штучка между двумя блоками, которой можно регулировать их размер?
И именно для этого нужно оставить в стандарте фреймы, которые имеют кучу недостатков?
Тем более, вам не надо писать кучу js-кода, ведь он уже написан в виде плагина для jQuery
И именно для этого нужно оставить в стандарте фреймы, которые имеют кучу недостатков?
Тем более, вам не надо писать кучу js-кода, ведь он уже написан в виде плагина для jQuery
> И именно для этого нужно оставить в стандарте фреймы, которые имеют кучу недостатков?
Недостатки надо устранять, а не убирать с глаз долой.
> Тем более, вам не надо писать кучу js-кода, ведь он уже написан в виде плагина для jQuery
И еще десятка других плагинов. Повторю:
Убрать функциональность полностью и сказать «трахайтесь, реализуйте сами» — это не прогресс, а регрессия.
Повторю:
И хоть с какой-то поддержкой в том же mobile safari
Недостатки надо устранять, а не убирать с глаз долой.
> Тем более, вам не надо писать кучу js-кода, ведь он уже написан в виде плагина для jQuery
И еще десятка других плагинов. Повторю:
Убрать функциональность полностью и сказать «трахайтесь, реализуйте сами» — это не прогресс, а регрессия.
Повторю:
И хоть с какой-то поддержкой в том же mobile safari
Кстати, а можете перечислить недостатки фреймов?
Фрейм, в данном случае, является логикой поведения. То что ms не поддерживает скрипты, означает то что ему нужно подсовывать мобильную версию софта, без скриптов и html5, на каком нибудь chtml, а не то что нужно реализовывать логику поведения на html. А с dragenter-dragleave событиями html5 сплитер становится легок в реализации как никогда…
При чем тут MS????
>А с dragenter-dragleave событиями html5 сплитер становится легок в реализации как никогда…
Нихрена он легким не становится. Не говоря уже о мобильных браузерах
>А с dragenter-dragleave событиями html5 сплитер становится легок в реализации как никогда…
Нихрена он легким не становится. Не говоря уже о мобильных браузерах
Mobile Safari ведь
Намного легче чем отлавливать и хранить событие mousedown, mousemove, mouseup… А про мобильные браузеры я уже сказал: Нефиг пользователю с экраном в 320x240 подсовывать сплиттеры, использовать надо тот инструмент, который для этого заточен.
Убрать функциональность, которая скорее вредна, чем полезна — добро. Это как заменить карбюратор на инжектор в машине, вместо того чтобы прикручивать к карбюратору микроконтроллеры…
Убрать функциональность, которая скорее вредна, чем полезна — добро. Это как заменить карбюратор на инжектор в машине, вместо того чтобы прикручивать к карбюратору микроконтроллеры…
> Намного легче чем отлавливать и хранить событие mousedown, mousemove, mouseup…
Все равно нафига это реализовывать самому с нуля?
> Нефиг пользователю с экраном в 320x240 подсовывать сплиттеры, использовать надо тот инструмент, который для этого заточен.
Вы про iPad слышали? Нет? Просветитесь
> Убрать функциональность, которая скорее вредна, чем полезна — добро.
Фреймы внезапно стали вредными? Нуну. Как много нам открытий чудных…
Все равно нафига это реализовывать самому с нуля?
> Нефиг пользователю с экраном в 320x240 подсовывать сплиттеры, использовать надо тот инструмент, который для этого заточен.
Вы про iPad слышали? Нет? Просветитесь
> Убрать функциональность, которая скорее вредна, чем полезна — добро.
Фреймы внезапно стали вредными? Нуну. Как много нам открытий чудных…
И, вдобавок. Убрать функциональность полностью и сказать «трахайтесь, реализуйте сами» — это не прогресс, а регрессия.
Браузерка. Фрейм под чат, фрейм под список игроков онлайн, основной фрейм.
Речь о текстовых браузерках, а-ля БК.
Речь о текстовых браузерках, а-ля БК.
javascript'ом получится намного лучше.
Не хочу начинать холивар, но на JS придется делать тучу кода, чтобы работало хотя бы то же изменение размеров фрейма путем перетаскивания границы мышью.
Ага. Тоже в сплитерах проблема?
И тащить за собой фреймворк?
[irony]Браузеры не умеют отображать ассмеблер :([/irony]
основан не на SGML, а на XML, то есть представляет собой совершенно другой языкXML является подмножеством SGML.
Вообще, стандарт XHTML потребовался для того, чтобы использовать HTML-подобную разметку внутри XML-документов.Не совсем так, хотя для этого он тоже пригоден. Вы можете и так использовать HTML-разметку (с незакрытыми тэгами и незакавыченными атрибутами) внутри XML — завернув ее в секцию CDATA.
W3C создавала XHTML с расчетом, что разработчики будут создавать свои неймспейсы и использовать их. После чего они посмотрели бы на часто используемые неймспейсы и включили бы их в следующий стандарт.
В XHTML существуют правила, например, запрет вложенности для тегов <a> и <p>, которые не могут быть выражены в терминах XML.А в терминах чистого XML такие вещи и не контролируются. XML должен быть well-formed. Всякие вещи типа вложенности тэгов, допустимости у их тех или иных атрибутов и т.д., т.е. все, что касается именно валидности, контролируются средствами проверки грамматики — типа DTD, XSD и RelaxNG.
Не понимаю зачем ждать. Уже сейчас можно использовать HTML5, вообще не вижу причин не делать этого. Я на всех проектах по умолчанию верстаю в HTML5.
>Я на всех проектах по умолчанию верстаю в HTML5.
Под версткой в HTML5 вы понимаете верстку с doctype HTML5 или избыточную и инвалидную верстку с костылями для броузеров которые не поддерживают новшества HTML5, еще не принятого в качестве стандарта?
Под версткой в HTML5 вы понимаете верстку с doctype HTML5 или избыточную и инвалидную верстку с костылями для броузеров которые не поддерживают новшества HTML5, еще не принятого в качестве стандарта?
В чём invalid'ную?
Инвалидная означает, что верстка ходит на JS-костылях, а без них она превращается в говно.
Отдельные продвинутые индивидуумы типа TecHMeaT, считают это нормой. Впрочем у него много заблуждений. Например он уверен, что тупорылому Яндексу непофиг какой стандарт используется для верстки. Это, кстати, достаточно оригинальная и свежая ересь.
Отдельные продвинутые индивидуумы типа TecHMeaT, считают это нормой. Впрочем у него много заблуждений. Например он уверен, что тупорылому Яндексу непофиг какой стандарт используется для верстки. Это, кстати, достаточно оригинальная и свежая ересь.
Спасибо за комплимент :)
Да, считаю нормой. Объясняю свою позицию. В нормальных браузерах всё хорошо, а у ослов всегда всё тормозило, и если сайт отрисуется на полсекунды медленнее, чем в нормальном браузере — да ну и что, пользователи ослов привыкли к тормозам, они не заметят разницы.
Кроме «тупорылого» Яндекса есть еще несколько поисковиков. Всем им пофиг какой стандарт. Им важна семантика. Так уж сложилось, что HTML5 семантичнее старых версий. Логично?
И вся эта моя «ересь» не единожды подтверждалась на деле в реальных проектах.
Удачно вам оставаться на прямых ногах в прошлом, а я на костылях побежал в будущее!
Да, считаю нормой. Объясняю свою позицию. В нормальных браузерах всё хорошо, а у ослов всегда всё тормозило, и если сайт отрисуется на полсекунды медленнее, чем в нормальном браузере — да ну и что, пользователи ослов привыкли к тормозам, они не заметят разницы.
Кроме «тупорылого» Яндекса есть еще несколько поисковиков. Всем им пофиг какой стандарт. Им важна семантика. Так уж сложилось, что HTML5 семантичнее старых версий. Логично?
И вся эта моя «ересь» не единожды подтверждалась на деле в реальных проектах.
Удачно вам оставаться на прямых ногах в прошлом, а я на костылях побежал в будущее!
>а я на костылях побежал в будущее!
С человеком бегущим на костылях в будущее особо спорить не хотелось бы. Но все же.
>у ослов всегда всё тормозило, и если сайт отрисуется на полсекунды медленнее,
Неприятность в костылях не столько в задержке, а в том что пока они не отработали сайт отображается криво, а потом скачками начинает выправляться. Причем если верстка сложная, а элементов требующих костылей много, полсекундой может и не обойтись — юзеры IE работают не на самых новых комп.
>И вся эта моя «ересь» не единожды подтверждалась на деле в реальных проектах.
Это и есть ересь. Говорить о влиянии чего-либо на алгоритмы поиска основываясь на 2-3 «реальных проетах», может толкьо человек не понимающий что такое SEO. Вы даже не удосужились погуглить эту тему. Я это сделал за вас:
Почитайте что по этому поводу думают в Google:
www.google.com/support/forum/p/Webmasters/thread?tid=1d3850aec4e3dd96&hl=en
— здесь специалисты Google говорят что им пох HTML5
www.google.com/support/forum/p/Webmasters/thread?tid=2d4592cbb613e42c&hl=en
— Здесь они говорят то же самое и рекомендуют особо торопливым бежать на костылях взад:
Personally, I would recommend using HTML5 where you think that it already makes sense, perhaps reverting to HTML4 if you can determine that the browser won't support the elements of HTML5 that you use properly. While this will not result in an advantage for your content in our search results, it generally wouldn't be disadvantageous either.
С человеком бегущим на костылях в будущее особо спорить не хотелось бы. Но все же.
>у ослов всегда всё тормозило, и если сайт отрисуется на полсекунды медленнее,
Неприятность в костылях не столько в задержке, а в том что пока они не отработали сайт отображается криво, а потом скачками начинает выправляться. Причем если верстка сложная, а элементов требующих костылей много, полсекундой может и не обойтись — юзеры IE работают не на самых новых комп.
>И вся эта моя «ересь» не единожды подтверждалась на деле в реальных проектах.
Это и есть ересь. Говорить о влиянии чего-либо на алгоритмы поиска основываясь на 2-3 «реальных проетах», может толкьо человек не понимающий что такое SEO. Вы даже не удосужились погуглить эту тему. Я это сделал за вас:
Почитайте что по этому поводу думают в Google:
www.google.com/support/forum/p/Webmasters/thread?tid=1d3850aec4e3dd96&hl=en
— здесь специалисты Google говорят что им пох HTML5
www.google.com/support/forum/p/Webmasters/thread?tid=2d4592cbb613e42c&hl=en
— Здесь они говорят то же самое и рекомендуют особо торопливым бежать на костылях взад:
Personally, I would recommend using HTML5 where you think that it already makes sense, perhaps reverting to HTML4 if you can determine that the browser won't support the elements of HTML5 that you use properly. While this will not result in an advantage for your content in our search results, it generally wouldn't be disadvantageous either.
Чёрт, Вы меня не переубедили )
Через 2 года сегодня оставленные мною костыли будут уже просто лишней строчкой в коде.
А гуглил ли я… Я перечитал достаточно много литературы по этому поводу, в том числе документацию Google, где достаточно ясно написано, каким для него код является идеальным. Разработчики Google на конференциях повторяют тоже самое и приводят факты.
Действительно, не будем спорить. Пусть каждый решит для себя что есть идеал.
Через 2 года сегодня оставленные мною костыли будут уже просто лишней строчкой в коде.
А гуглил ли я… Я перечитал достаточно много литературы по этому поводу, в том числе документацию Google, где достаточно ясно написано, каким для него код является идеальным. Разработчики Google на конференциях повторяют тоже самое и приводят факты.
Действительно, не будем спорить. Пусть каждый решит для себя что есть идеал.
>Я перечитал достаточно много литературы по этому поводу
Лучше признайтесь, что никогда не занимались SEO а про HTML5 в этой связи сболтнули неподумавши.
Впрочем можете и не признаваться. Оно и так ясно.
Лучше признайтесь, что никогда не занимались SEO а про HTML5 в этой связи сболтнули неподумавши.
Впрочем можете и не признаваться. Оно и так ясно.
Вы наверное матерый продвигайзер, куда мне, грузчику с ликероводочного…
Это я так, наткнулся на пару текстов в гуглокоде, подумал, что полезная инфа, наверное они меня наивного обманули. Что-то где-то еще находил, но там по басурмански написано было, наверное я не так понял смысл :(
Всё-всё, больше не спорю. Теперь я постиг вселенскую истину!
Это я так, наткнулся на пару текстов в гуглокоде, подумал, что полезная инфа, наверное они меня наивного обманули. Что-то где-то еще находил, но там по басурмански написано было, наверное я не так понял смысл :(
Всё-всё, больше не спорю. Теперь я постиг вселенскую истину!
Бывают случаи, когда целевой аудиторией является бот Яндекса.
Тогда можно хоть HTML 1 использовать, лишь бы он страницы кушал :)
Тогда можно хоть HTML 1 использовать, лишь бы он страницы кушал :)
Под версткой в HTML5 я понимаю именно «верстку», а не доктайп :)
Вы видимо плохо представляете, что такое HTML5, раз называете верстку в этом стандарте избыточной и инвалидной. А то что ослам нужны костыли — давно устоявшаяся практика, нет смысла холиварить по этому вопросу.
В моей верстке всё работает и работает нормально. Сайты с моей версткой отлично видятся поисковиками, гораздо лучше, чем с классической версткой. Для меня эти 2 показателя являются решающими и… я хотел с высокой колокольни на всякие другие типа минусы.
Вы видимо плохо представляете, что такое HTML5, раз называете верстку в этом стандарте избыточной и инвалидной. А то что ослам нужны костыли — давно устоявшаяся практика, нет смысла холиварить по этому вопросу.
В моей верстке всё работает и работает нормально. Сайты с моей версткой отлично видятся поисковиками, гораздо лучше, чем с классической версткой. Для меня эти 2 показателя являются решающими и… я хотел с высокой колокольни на всякие другие типа минусы.
Понимаете, пока не вышел IE9 — могут быть эээ… сюрпризы. Ну оно конечно здорово, что стандарт предельно понятный и точный, но вот с IE никогда нельзя знать заранее. А вдруг они какой-то пункт поняли не так? И из-за этого ваша верстка поплывет?
Во всех проектах используете header footer article и прочий nav?
Верстая левую колонку сайта, запрещается называть её #left, потому как на самом деле это не просто левая колонка, а тулбар
Потому, что когда мы захотим сделать поддержку арабского или иврита, колонка #left в комбинации direction: rtl; будет вызывать разрыв шаблона. Впрочем, так делать было неправильно и для HTML 4.01 То, что это зафиксировали в гайдлайнах — это правильно.
что в html-коде почти любой современной страницы можно наблюдать цепочки вида </div></div></div>. В количестве этих </div> очень даже легко ошибиться
Эммм, вы не пробовали редактировать код сайта не в нотепаде, а в редакторе с подсветкой парных тегов и переходами между ними? Если уж более «девелоперский» Scite это умеет, то всякие Notepad++ — тем более.
особенно если на странице есть контент, отправленный рядовыми пользователями. Лишний или просто расположенный не там </div> может привести к развалу всей верстки
А вот за возможность рядовым пользователям писать произвольный HTML, еще и без контроля за парностью тегов нужно отрывать кий. По самую бабушку.
Как отобразить браузеру или подсветить редактору невалидные конструкции? (Почему их нужно все равно отображать написанно в статье).
Не закрыт внешний тэг? (А внешние тэги отвечают я верстку макета)
Но судя такой записи
Можно утверждать что ошибка в нутри контейнера article и отобразить страницу более корректно
PS За незакрытые тэги нужно не только кий отрывать…
<div><div><div></div></div> Не закрыт внешний тэг? (А внешние тэги отвечают я верстку макета)
Но судя такой записи
<div><article><div></article></div> Можно утверждать что ошибка в нутри контейнера article и отобразить страницу более корректно
PS За незакрытые тэги нужно не только кий отрывать…
> Как отобразить браузеру или подсветить редактору невалидные конструкции?
О да, автоматическое исправление таких тривиальных (если не сказать «тупых») ошибок — очень полезно. Чтобы Вася Пупкин мог не отвлекаться на всякие мелочи типа незакрытых тегов при разработке своего мега-портала.
О да, автоматическое исправление таких тривиальных (если не сказать «тупых») ошибок — очень полезно. Чтобы Вася Пупкин мог не отвлекаться на всякие мелочи типа незакрытых тегов при разработке своего мега-портала.
Не так хороша статья, как ее заголовок =). Спасибо, порадовали с утра =). Теперь работаться будет веселее =)
В статье интересные моменты почерпнула. Особенно про тег .
А про то, что лучше атрибуты тегов не брать в кавычки, я бы ой как поспорила. И про создание валидного кода автоматическими редаторами тоже бы высказалась…
Но я рада, что доктайпов стало меньше. И за фреймы я рада. Давно им сказала R.I.P., рада и Transitional туда проводить…
В общем, статья приятная. Спасибо.
А про то, что лучше атрибуты тегов не брать в кавычки, я бы ой как поспорила. И про создание валидного кода автоматическими редаторами тоже бы высказалась…
Но я рада, что доктайпов стало меньше. И за фреймы я рада. Давно им сказала R.I.P., рада и Transitional туда проводить…
В общем, статья приятная. Спасибо.
вот что меня больше всего напрягает в этих стандартах, так это их ну слишком долгое принятие.
блин, ребята, вы же рулите всем вебом. увеличьте штат за счет представителей от браузеров и утверждайте каждый год
блин, ребята, вы же рулите всем вебом. увеличьте штат за счет представителей от браузеров и утверждайте каждый год
Ошибка номер раз
«Девочка» может спокойно в документах писать < вместо <, если это CDATA
Ошибка номер два
Между B и STRONG разница есть, и приличная. Корни уходят в книжную типографику, когда акценты в фразах выделялись именно strong-ом. Сегодня на них могут и должны реагировать аудио-читальщики текста, делая «ударение» на словах в этом теге.
Например «Это <strong>МОЙ</strong> хлеб и я его никому не отдам!» Тут strong уместен
А в фразе "<b>Начало производства</b>. Начинать производство нужно с разрешительных документов." выделение несет чисто визуальных характер, никакого акцента, никаких эмоций.
Личное недовольство
<header>, <footer>, <article> и прочие <nav> — капля в море, которая не закрывает и 10% потребности в тегах. Очень жаль, что никто из w3c не додумался до смешения всех плюсов XML и HTML, сделав XML для оформления и структуризации с вольным именованием тегов и микроформатами в придачу, и HTML для контента. Будем теперь мучаться с вечным дифицитом тегов. Или забъем и будем и дальше использовать собственные теги.
«Девочка» может спокойно в документах писать < вместо <, если это CDATA
Ошибка номер два
Между B и STRONG разница есть, и приличная. Корни уходят в книжную типографику, когда акценты в фразах выделялись именно strong-ом. Сегодня на них могут и должны реагировать аудио-читальщики текста, делая «ударение» на словах в этом теге.
Например «Это <strong>МОЙ</strong> хлеб и я его никому не отдам!» Тут strong уместен
А в фразе "<b>Начало производства</b>. Начинать производство нужно с разрешительных документов." выделение несет чисто визуальных характер, никакого акцента, никаких эмоций.
Личное недовольство
<header>, <footer>, <article> и прочие <nav> — капля в море, которая не закрывает и 10% потребности в тегах. Очень жаль, что никто из w3c не додумался до смешения всех плюсов XML и HTML, сделав XML для оформления и структуризации с вольным именованием тегов и микроформатами в придачу, и HTML для контента. Будем теперь мучаться с вечным дифицитом тегов. Или забъем и будем и дальше использовать собственные теги.
С последним абзацом совершенно согласен. Ведь в чём проблема сделать «пользовательские теги» стандартными и с поведением по-умолчанию, как у div/span? Было бы просто отлично!
Если я не ошибаюсь, подчёркивание как элемент типографики это неуклюжее наследие печатных машинок. Они имели единственную гарнитуру, и, как следствие, были лишены курсивного начертания, необходимого для выделения текста. Взамен использовалось подчёркивание.
Я считаю, всё правильно сделали. Подчёркиванием, чаще всего, злоупотребляют.
Я считаю, всё правильно сделали. Подчёркиванием, чаще всего, злоупотребляют.
Если бы хотели убить подчеркивание как стиль, убрали бы из CSS text-decoration:underline
Тут именно что семантисты убрали тег.
Нет, я все понимаю, ну объявите его deprecated, ну дайте ему определение «использовать только для целей совместимости», но убирать из стандарта-то зачем?
Понимаете, 90% верстальщиков не перестанут пользоваться этим тегом, поэтому из браузеров его тоже не уберут.
Получим в итоге, что в стандарте тега нет, а по факту есть и везде работает.
Такая ситуация только подрывает авторитет стандарта и ничего не более.
Тут именно что семантисты убрали тег.
Нет, я все понимаю, ну объявите его deprecated, ну дайте ему определение «использовать только для целей совместимости», но убирать из стандарта-то зачем?
Понимаете, 90% верстальщиков не перестанут пользоваться этим тегом, поэтому из браузеров его тоже не уберут.
Получим в итоге, что в стандарте тега нет, а по факту есть и везде работает.
Такая ситуация только подрывает авторитет стандарта и ничего не более.
После прочтения статьи у меня сложилось мнение, что ничего хорошего с тегами в html5 не сделали. Одни убрали, ввели кучу новых, часть старых взяли и стали использовать для другого, у многих тегов теперь обтекаемое описание. Закрывающие теги оставили. Имхо, порядка больше не стало это точно.
Сегодня утром начал новую вёрстку с, совершенно новые ощущения, будто трогаешь руками обнажённые нервы.
cool story, bro
Спасибо, статья порадовала! Вступление забавное :)
Искренне благодарю за статью! Очень интересно
Автор статьи совершенно не разбирается в предмете. Он не понимает, что такое SGML и XML, что такое их приложение, что такое правильно построенный (well-formed) и валидный XML-документ. Он даже XML-элементы называет тегами, хотя при описании семантики это неверно (даже стандарт HTML5 всячески пытается уйти от текстового представления документа с его тегами). Ну или вот прекрасное
хотя если почитать XHTML In XML Schema, то увидим такое
и где тут mixed=«true» у complexType?
Или вот никак не могу согласиться:
программы этот контент нам презентуют во вменяемом виде. Конечно, кто-то до сих пор пишет HTML в блокнотике. Но вообще, обычно берут CMS, у которой есть либо WYSIWYG-редактор, либо язык вики-разметки. Так вот в любом случае, текст, введённый пользователем, нужно тщательно отпарсить во внутреннее представления и потом по внутреннему представлению генерить (X)HTML, подставляя, где нужно, теги (в том числе и закрывающие) и экранируя текст. Если всего этого CMS делать не умеет, то грош ей цена
Ну во-первых, не надо уж использовать упомянутый чуть выше PHP (впрочем, лучше вообще его не использовать) не по назначению. Может, не следует генерить (X)HTML из кода, а взять шаблонизатор? Тогда таких проблем не возникнет.
В xhtml же технически возможен (и с точки зрения XML даже валиден!) вот такой код:
текст ячейки текст между ячейками, отображайте где хотите
хотя если почитать XHTML In XML Schema, то увидим такое
<xs:element name="tr">
<xs:complexType>
<xs:choice maxOccurs="unbounded">
<xs:element ref="th"/>
<xs:element ref="td"/>
</xs:choice>
<xs:attributeGroup ref="attrs"/>
<xs:attributeGroup ref="cellhalign"/>
<xs:attributeGroup ref="cellvalign"/>
</xs:complexType>
</xs:element>
и где тут mixed=«true» у complexType?
Или вот никак не могу согласиться:
Однако, подобное поведение — отказ от обработки всего документа при обнаружении любой ошибки — абсолютно неприемлемо для веба, где большую часть контента создают отнюдь не программы и даже не верстальщики, а сайт-менеджеры, писатели, блоггеры и, зачастую, рядовые посетители сайтов
программы этот контент нам презентуют во вменяемом виде. Конечно, кто-то до сих пор пишет HTML в блокнотике. Но вообще, обычно берут CMS, у которой есть либо WYSIWYG-редактор, либо язык вики-разметки. Так вот в любом случае, текст, введённый пользователем, нужно тщательно отпарсить во внутреннее представления и потом по внутреннему представлению генерить (X)HTML, подставляя, где нужно, теги (в том числе и закрывающие) и экранируя текст. Если всего этого CMS делать не умеет, то грош ей цена
Постоянные переключения синтаксиса в одном файле ни к чему хорошему не приводят, глаз программиста замыливается, и становятся возможными достаточно трудно вылавливаемые синтаксические ошибки.
Ну во-первых, не надо уж использовать упомянутый чуть выше PHP (впрочем, лучше вообще его не использовать) не по назначению. Может, не следует генерить (X)HTML из кода, а взять шаблонизатор? Тогда таких проблем не возникнет.
Спасибо вам. Яркий представитель секты семантистов выше уже высказался, а вот фанатичного XML-поклонника как-то не было.
Нет, правда, здорово. Вы заявляете, что я называю XML-элементы тэгами (о ужас! как я мог использовать немодные синонимы?!), из чего делаете безусловный вывод, что я совершенно не разбираюсь в предмете!
Одновременно, мою статью вы просто не поняли. Ну, то есть, совсем. Все доводы про ошибки проектирования языка, про техническую возможность — вы слова прочитали, нашли знакомые буквы, но смысла в них не увидели.
Вы просто-таки классический пример XML-бюрократа. Не поняв сути даже близко, прицепиться к специально для этого придуманным формальностям и заявить, что раз даже формальности не выполнены — значит перед вами точно абсолютное пустое место. Именно это и составляет суть существования и бюрократов, и самого языка XML.
Моя статья не зря содержит слова «победа научного материализма». Она, эта победа, как раз и одержана над такими как вы и TheShock. Пока семантисты и XML-исты занимались семь лет ерундой, технари своими силами решили проблему.
Извините, если получилось резковато, я не хочу ни в коем случае задеть или обидеть вас лично. Я просто защищаю свой образ мыслей. Все люди во что-то верят, кто-то в Христа, кто-то в Большую *опу, кто-то в XML или семантику, кто-то в кумиров, а кто-то в непогрешимость своей левой пятки. Я вот с некоторых пор больше всего доверяю мат. логике, и я рад, что именно мои единомышленники победили в подковерных войнах за стандарт html5.
PS. Да-да, картинку с д'Артаньяном мне уже постили.
Нет, правда, здорово. Вы заявляете, что я называю XML-элементы тэгами (о ужас! как я мог использовать немодные синонимы?!), из чего делаете безусловный вывод, что я совершенно не разбираюсь в предмете!
Одновременно, мою статью вы просто не поняли. Ну, то есть, совсем. Все доводы про ошибки проектирования языка, про техническую возможность — вы слова прочитали, нашли знакомые буквы, но смысла в них не увидели.
Вы просто-таки классический пример XML-бюрократа. Не поняв сути даже близко, прицепиться к специально для этого придуманным формальностям и заявить, что раз даже формальности не выполнены — значит перед вами точно абсолютное пустое место. Именно это и составляет суть существования и бюрократов, и самого языка XML.
Моя статья не зря содержит слова «победа научного материализма». Она, эта победа, как раз и одержана над такими как вы и TheShock. Пока семантисты и XML-исты занимались семь лет ерундой, технари своими силами решили проблему.
Извините, если получилось резковато, я не хочу ни в коем случае задеть или обидеть вас лично. Я просто защищаю свой образ мыслей. Все люди во что-то верят, кто-то в Христа, кто-то в Большую *опу, кто-то в XML или семантику, кто-то в кумиров, а кто-то в непогрешимость своей левой пятки. Я вот с некоторых пор больше всего доверяю мат. логике, и я рад, что именно мои единомышленники победили в подковерных войнах за стандарт html5.
PS. Да-да, картинку с д'Артаньяном мне уже постили.
Да при чём тут XML-фанатизм? Как раз я-то разбираюсь в чисто технических вещах и у меня есть строгие доводы в пользу XML. А вот Ваша статья как раз демонстрирует фанатичную любовь в SGML-синтаксису HTML, подкрепляемому неверными или сомнительными доводами. Вот этот Ваш ответ, извините, — пустая демагогия.
Почему XML-синтаксис не прижился? Потому т.н. «веб-программисты» не осилили. Потому что W3C занимались синтаксисом, а не пытались сделать что-то для улучшения семантики HTML. Кстати, HTML5 ничего не говорит о синтаксисе. Точнее, там он присутствует, но описание HTML-элементов даётся в нейтральной манере, чтобы можно было семантику завернуть в любой синтаксис. Кстати, если глянуть на XHTML 1.0, то можно увидеть, что по сути это такой же XML-синтаксис для HTML 4. Так что противопоставлять XHML и HTML5 попросту неверно, т.к. это всё равно, что противопоставлять HTML 4 и HTML5 — разумеется, второй лучше. А почему XHTML 2 так и не был готов? А не потому, что разработчики принадлежали к сектам семантистов и XML-истов, а потому, что были банальными бюрократами.
Почему XML-синтаксис не прижился? Потому т.н. «веб-программисты» не осилили. Потому что W3C занимались синтаксисом, а не пытались сделать что-то для улучшения семантики HTML. Кстати, HTML5 ничего не говорит о синтаксисе. Точнее, там он присутствует, но описание HTML-элементов даётся в нейтральной манере, чтобы можно было семантику завернуть в любой синтаксис. Кстати, если глянуть на XHTML 1.0, то можно увидеть, что по сути это такой же XML-синтаксис для HTML 4. Так что противопоставлять XHML и HTML5 попросту неверно, т.к. это всё равно, что противопоставлять HTML 4 и HTML5 — разумеется, второй лучше. А почему XHTML 2 так и не был готов? А не потому, что разработчики принадлежали к сектам семантистов и XML-истов, а потому, что были банальными бюрократами.
Ну а какой ответ вы ожидали получить, если вы критикуете статью, которую то ли не удосужились прочесть, то ли не смогли понять? Почему я должен вам разжежывать мысли, которые и изложены в начале этой страницы? XML-синтаксис «не пошел» не потому, что «веб-программисты» все как на подбор тупые, а потому что он просто не применим к вебу, в 99% случаев не дает никаких плюшек, но при этом замусоривает код большим количеством цифрового шума и менее адекватен поставленной задаче, чем HTML. Почему я должен спорить с вами об XML схемах? К вебу они не имеют ну совсем никакого отношения, и поэтому в моей статье про них ничего нет.
PS. Хотя что я, в самом деле. Вы предлагаете «вообще не использовать PHP» и «взять шаблонизатор», хотя PHP и есть в чистом виде шаблонизатор, прокладка между базой данных и веб-браузером.
Ну, о как технических вещах тут еще говорить?
PS. Хотя что я, в самом деле. Вы предлагаете «вообще не использовать PHP» и «взять шаблонизатор», хотя PHP и есть в чистом виде шаблонизатор, прокладка между базой данных и веб-браузером.
Ну, о как технических вещах тут еще говорить?
XML-синтаксис «не пошел»… потому что он просто не применим к вебу, в 99% случаев не дает никаких плюшек, но при этом замусоривает код большим количеством цифрового шума и менее адекватен поставленной задаче, чем HTML.
Ага, этому и посвящена достаточна большая часть Вашей статьи. Вот только чтобы такие вещи утверждать, мало их написать на заборе. И ниже Вы начинаете пояснять, почему так. Так вот моё утверждение: все эти аргументы несостоятельны. Потому что банально неверны. Почему неверны, можно понять, разобравшись путём с XML. В принципе, я в первом комментарии кратко объяснил, что к чему. Но Вы-то ярый борец с «XML-сектой», потому, видимо, разбираться с XML — ниже Вашего достоинства.
Почему я должен спорить с вами об XML схемах? К вебу они не имеют ну совсем никакого отношения, и поэтому в моей статье про них ничего нет.
Ну какой-то мифический получается веб. В вебе что используется? HTML/XHTML. Формально их синтаксис описать надо? Надо. А это и делается с помощью DTD или более мощного средства, существующего в XML-мире — XML-схем. Ну вот я привёл кусок такого формального описания. Можно было бы и кусок DTD скопипастить. Или вообще кусок текста из стандарта. Однако, текст небезгрешен, его можно трактовать по-всякому, не в пример формальному описанию.
Вы предлагаете «вообще не использовать PHP» и «взять шаблонизатор», хотя PHP и есть в чистом виде шаблонизатор, прокладка между базой данных и веб-браузером.
PHP — не лучший шаблонизатор. Я бы предпочёл apache velicity, razor или самописный. Некоторые суровые парни высказались бы в пользу XSLT. Но это неважно. А важно то, что при прямом использовании проставлять кавычки и закрывающие теги в PHP не сильно страшно, вопреки Вашему ещё одному аргументу против XML-синтаксиса HTML (или XHTML, что верно для HTML 4).
Она, эта победа, как раз и одержана над такими как вы и TheShock. Пока семантисты и XML-исты занимались семь лет ерундой, технари своими силами решили проблему.
Вот в этом и есть ваш фейл. html5 поддержал идеи семантики, а не опроверг их! Часто используете хедеры-навы-футеры? Вот вам соответсвующие теги. Нужны пользовательские атрибуты? Вот вам «data-»! Та даже те же новые виды инпутов. Всё-равно проверки делаются javascript-ом давно, они нужны только для пущей семантики!
Зато убрали теги center, font, strike. Переосмыслили теги
<b> и <i>:The b element now represents a span of text to be stylistically offset from the normal prose without conveying any extra importance, such as keywords in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is emboldened.
The i element now represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name, or some other prose whose typical typographic presentation is italicized. Usage varies widely by language.
Ещё раз обратите внимание, убрали тег <center>, а не добавили теги <left> и <right> в стиле того маразма, который вы предлагали выше. Вместо классов
col1 и col2 теперь желательно использовать использовать aside.html5 принес больше семантики, чем xhtml и html4 вместе взятые. И это именно победа над такими как вы, которые не думают о будущем своего проекта, о тех, кто будет его поддерживать и развивать. Вы будете терпеть из-за этого убытки и это ваше наказание, и ваше решение принимать его в обмен на возможность не вникнать в суть проекта.
Если кто не понял, то теперь b и i — это не теги «жирный» и «курсив», а несут смысловую нагрузку.
Какой же вы тугой. Никто не против семантики как таковой, в умеренной форме она несет здравые и разумные мысли. Все только приветствуют появление тэгов для типовых секций страницы: <header> («шапка»), <footer> («подвал»), <nav> (блок навигации) и прочие там <aside> («в стороне» или «сбоку»). Тег <center> убрали, потому что он означал «блок с выравниванием строк по центру» и мог сбить с толку потенциальных пользователей того же <aside>, ну и вообще данные с представлением нужно по возможности разделять. И этом, разумеется, HTML5 представляет собой шаг вперед.
Но чтобы понять, что списки лучше верстать тегами списков, заголовки — тегами заголовков, а для тела статей использовать тег <article>, достаточно простого здравого смысла, без всяких семантических теорий. К сожалению, идеи настоящего семантического веба, в том виде в каком их озвучивал тот же Тим Бернерс-Ли, до сих пор не реализованы и вряд-ли будут. Зато на модном слове вдоволь оттоптались людишечки, желающие повысить свое ЧСВ и поучить других, как им правильнее жить, например, что колонки left и right надо обязательно называть col1 и col2.
Но чтобы понять, что списки лучше верстать тегами списков, заголовки — тегами заголовков, а для тела статей использовать тег <article>, достаточно простого здравого смысла, без всяких семантических теорий. К сожалению, идеи настоящего семантического веба, в том виде в каком их озвучивал тот же Тим Бернерс-Ли, до сих пор не реализованы и вряд-ли будут. Зато на модном слове вдоволь оттоптались людишечки, желающие повысить свое ЧСВ и поучить других, как им правильнее жить, например, что колонки left и right надо обязательно называть col1 и col2.
Тугой — это вы. Но вы этого не поймёте, потому что никогда не услышыте прот те лучи ненависти, которые будут вам направлять люди, поддерживающие вашу писанину.
*услышите
Вы знаете, если кто-то исходит на лучи от ненависти, увидев <div id=left> — ему срочно надо в больничку. Я серьезно.
В больничку надо автору этого маразма. На крайняк — вон из профессии.
Как и тому, кто использует
Как и тому, кто использует
<b> вместо <span class="vector"></span>. Потому что автор математических текстов всё-равно будет их вставлять специальной кнопкой. Зато если заказчик скажет: «анука сделай, чтобы все векторы были картинкой со стрелочкой» и если у вас нормальная верстка — написали кусок js-a и вуаля. А так — придётся перечитывать все тексты, где там <b> вставлено чтобы вектор выделить, а где чтобы слово акцентировать.Вероятность того, что заказчик скажет мне «анука», близка к нулю. Потому что после этого он перестанет быть заказчиком. Если он это попросит нормально (как доп. пункт к ТЗ, за отдельные деньги), то простейший js, превращающий все односимвольные <b> в буквы со стрелочками, пишется за 2 минуты. Нет ни одной причины тратить время (=деньги) сейчас на то, что потребуется с очень малой вероятностью в будущем, и что в этом будущем можно будет реализовать за 2 минуты.
Выше в комментах кто-то, возможно вы, доказывал, что нельзя называть блок #left, потому что может быть, в будущем сайт придется переводить на арабский и там это вызовет проблемы. Во-первых, арабы хоть и пишут справа налево, но сами понятия права и лева у них совпадают с общемировыми. А во-вторых, в будущем, конечно, с сайтом небольшой российской фирмы (а на 99% я делаю именно их) много чего может случиться, но я даже не могу придумать более невероятное событие, чем его перевод на арабский, если фирма изначально никаких отношений с арабами не имела.
В-общем, на этом дискуссию предлагаю прекратить. Аргументы у вас закончились, а доводить кого-то до истеричных оскорблений я не хочу. Спасибо, что изложили основные доводы своей религии, сейчас я внесу ссылки на самые яркие ваши комментарии в статью.
Извините, если я где-то перегнул с троллингом.
Выше в комментах кто-то, возможно вы, доказывал, что нельзя называть блок #left, потому что может быть, в будущем сайт придется переводить на арабский и там это вызовет проблемы. Во-первых, арабы хоть и пишут справа налево, но сами понятия права и лева у них совпадают с общемировыми. А во-вторых, в будущем, конечно, с сайтом небольшой российской фирмы (а на 99% я делаю именно их) много чего может случиться, но я даже не могу придумать более невероятное событие, чем его перевод на арабский, если фирма изначально никаких отношений с арабами не имела.
В-общем, на этом дискуссию предлагаю прекратить. Аргументы у вас закончились, а доводить кого-то до истеричных оскорблений я не хочу. Спасибо, что изложили основные доводы своей религии, сейчас я внесу ссылки на самые яркие ваши комментарии в статью.
Извините, если я где-то перегнул с троллингом.
Первые два абзаца — лучшее, что написано в этом посте.
Любить XML или нет, но разработчик, тем более руководитель оных, должен владеть правильной терминологией или стремиться к этому.
Любить XML или нет, но разработчик, тем более руководитель оных, должен владеть правильной терминологией или стремиться к этому.
Я просто в восторге от стиля изложения автора! Отличная статья, во многих случаях мнения сходны.
Как и многие вышевысказавшиеся выражаю большое спасибо вашему слогу и вообще содержимому статьи, согласен во многом, особенно в части про семантический маразм
А вы с какой целью интересуетесь? :)
Неясна ваша позиция.
Я против семантического экстремизма, во всем должен быть здравый смысл. И блоки я буду именовать так, как захочу, хоть left-col хоть sidebar хоть aside.
И естественно id/class нового блока буду писать исходя из соображений адекватности, в том числе, если блок переедет слева вправо он сразу же сменит IDшник или класс, если оно задано явно.
Про 100% стилизацию при помощи одного только css не стоит поднимать полемику — тут я на 100500% согласен с автором статьи, обычно 1 макет, одна верстка. В следующем варианте будет другая. Я сделал такой вывод исходя из своего почти 8-летнего опыта. Для всего остального есть абсолютно независимая верстка, но это не тема данной статьи
И естественно id/class нового блока буду писать исходя из соображений адекватности, в том числе, если блок переедет слева вправо он сразу же сменит IDшник или класс, если оно задано явно.
Про 100% стилизацию при помощи одного только css не стоит поднимать полемику — тут я на 100500% согласен с автором статьи, обычно 1 макет, одна верстка. В следующем варианте будет другая. Я сделал такой вывод исходя из своего почти 8-летнего опыта. Для всего остального есть абсолютно независимая верстка, но это не тема данной статьи
Пепелсбей, приди!
Больше всего удивляет, чем не угодил тег подчеркивания. Тем, что им «слишком часто» пользуются? Может, те, кто это утверждают, еще и сайты за меня делать будут? Чего уж там, давайте!
Однако, подобное поведение — отказ от обработки всего документа при обнаружении любой ошибки — абсолютно неприемлемо для веба, где большую часть контента создают отнюдь не программы и даже не верстальщики, а сайт-менеджеры, писатели, блоггеры и, зачастую, рядовые посетители сайтов.
Вот именно, что контента. Код же этим людям писать не следует, на то визуальные редакторы есть.
В XHTML существуют правила, например, запрет вложенности для тегов <a> и <p>, которые не могут быть выражены в терминах XML.
Если какие-то правила нельзя выразить с помощью XSD или DTD, то почему их можно выразить с помощью только DTD?
Бывают, например, произведения классиков, в которых они используют курсив и полужирное начертание исключительно в художественных целях (то есть так, как им лично захотелось), или, может, в соответствии с устаревшими на данный момент правилами языка, или еще как-то не по правилам.
Классики могут любое оформление текста использовать в художественных текстах. И что, весь CSS в HTML обратно запихивать?
Перечитаю эту замечательную и полную оптимизма статью о победе HTML5 года через 2, нет 5…
Напомните только о ней, pls :)
Напомните только о ней, pls :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
HTML5 как победа научного материализма