Полная версия этой страницы: HTML - советуем, спрашиваем, делимся
Спасибо. Вы правы... просто подумал что это какой-то хитрый синтаксис, типа 7++, --1... Оказалось банальное "минус четырнадцать"...
Вопрос по HTML и css:
хочу сверстать меню, где часть пунктов короткие, в одну строку, часть переносятся на вторую строку
Как это можно реализовать, без использования картинок?
хочу сверстать меню, где часть пунктов короткие, в одну строку, часть переносятся на вторую строку
Как это можно реализовать, без использования картинок?
Используй <br>, в чем проблема?
https://webref.ru/html/br
https://webref.ru/html/br
Вопрос в том, как отцентрировать по вертикали сроки в блоках...
В блоках - через line-height. Надо вручную подобрать такое значение, чтобы текст посреди оказался.
Либо флексбоксы, но это только для новых браузеров.
Либо флексбоксы, но это только для новых браузеров.
Цитата(Эроласт @ 25 Jun 2016, 21:48) 
В блоках - через line-height. Надо вручную подобрать такое значение, чтобы текст посреди оказался.
Поэтому я бы использовал <table><tr><td> со свойством vertical-alignЦитата(izrukvruki @ 24 Jun 2016, 17:26)
Вопрос по HTML и css:
хочу сверстать меню, где часть пунктов короткие, в одну строку, часть переносятся на вторую строку
Как это можно реализовать, без использования картинок?
хочу сверстать меню, где часть пунктов короткие, в одну строку, часть переносятся на вторую строку
Как это можно реализовать, без использования картинок?
Если у тебя именно последовательность блоков, напоминающая таблицу - тогда, либо юзай таблицу, либо имитируй ее через display: table-cell и vertical-align/
Если у тебя блок MxN в котором может быть как однострочный, так и многострочный текст - тогда можно применить выравнивание по вертикали с помощью инлайнблокового контекста и распирателя. В качестве распирателя может использоваться псевдоэлемент "before/after".
https://jsfiddle.net/ohdrp1pt/
line-height не рекомендую, если есть ненулевая вероятность, что текст будет меняться.
Вот если честно - эти <div>'ы напрягают! Чем <table> не устраивает???
Назовите хоть пару случаев, когда бы они они работали лучше, чем таблицы (исключая фиксированный размер сайта по ширине!)
(да, уже готов парировать - позавчерашний день спорит со вчерашним! но предоставьте действительно годные инструменты!)
Назовите хоть пару случаев, когда бы они они работали лучше, чем таблицы (исключая фиксированный размер сайта по ширине!)
(да, уже готов парировать - позавчерашний день спорит со вчерашним! но предоставьте действительно годные инструменты!)
Не согласен с тем, что DIV - вчерашний день.
Да, есть семантические теги (но это частный случай блочного элемента со своим назначением и иногда с доп.параметрами по умолчанию), и есть общий базовый блочный элемент div (который я и использовал, потому что не знал назначения элемента в вопросе izrukvruki)
Но блочная верстка это есть что ни на есть "сегодня".
Да, есть flex, есть grid (это не теги, а css-подходы, которые так же применяются к "блочным" тегам). Это завтра, которое вот-вот наступит, но опять же оно не столь кардинально, чтоб называть блочную верстку вчерашним днем. С момента, когда прогрессивный инет перешел на блочную верстку появился только один известный мне кардинально другой способ отображать контент на веб-странице - это отрисовывать его на канвасе. Но это уже не верстка, это уже почти анимация (сродни флеш), которая имеет большое количество недостатков и подходит только для узкого количества случаев.
Так все-же в чем преимущество блочной верстки по сравнению с табличной:
1. Адаптивность.
Это самое главное преимущество блочной верстки. В эпоху экранов поголовно 1024х768 это было без разницы, теперь же, когда сайт должен удобно отображаться и на мобиле и на ноуте и на экране телевизора - без адаптивности никуда.
И здесь дело не только в фиксированной ширине, а в том, что в зависимости от разрешения блоки не только ресайзятся, но и более удобно компонуются, и в том, что на меньших экранах можно очень сильно видоизменить какой-то блок управляя только его стилем отображения.
2. Семантичность.
DIV - это общий случай блочного элемента. Помимо него есть еще куча более конкрентых тэгов для той или иной ситуации. FOOTER, HEADER, ARTICLE, SECTION, NAV, FIGURE, DIALOG, ASIDE - эти тэги не имеют никаких преимуществ перед обычным дивом, но наличие этих тегов в верстке делают исходный код понятнее как разработчику так и поисковым роботам (СЕО будет отдельным пунктом).
3. SEO
Это скорее комбинация первых двух пунктов. Но если ты хочешь, чтоб твой сайт хорошо индексировался поисковиками ты должен заботиться о адаптивности и семантичности. Поэтому идет отдельным пунктом.
Сайты неадаптированые под мобильную верстку - хуже индексируются (гуглом так точно, про другие - не знаю).
А использование семантических тегов позволяют делать дополнительные акценты на важные контентные части страницы или, наоборот, указать на навигационные элементы. Еще очень часто в СЕО рекомендуют главный контент писать перед декоративными или навигационными блоками. Да, в блочной верстке, часто бывает трудно это сделать, в табличной же - вовсе не возможно.
4. Изменяемость и поддержка
Если ты решил, что левую и правую колонку нужно поменять местами или вклинить еще одну колонку - то в табличной верстке это может привести к очень серьезным проблемам. Тебе нужно будет перешерстить все TR-ки и внести в них изменения. А если есть еще collspan - тогда еще и их нужно будет перешерстить. С ужасом вспоминаю те моменты, когда нужно было поддерживать разбитый на подшаблоны сайт с табличной версткой.
Отдельным гемороем будет динамическое изменение такой страницы, например при помощи джаваскрипта (или частным случаем такого динамического изменения является адаптивность - изменение отображения в зависимости от размера экрана благодаря media-query).
5. Компактность html кода
Чтоб понять в каком блоке ты находишься достаточно взлянуть на парочку родительских элементов. В таблице же - ты всегда в td, или в виде исключения в th.
Благодаря html5-тегам и минимуму классов можно оставить в верстке только "ЧТО отображать", и исключить "КАК отображать", тем самым пенести вес страницы на css. Хотя в современном мире вес не слишком важен (по крайней мере в контексте верстки), но может быть ощутим при частых ajax запросах.
При грамотной расстановке тегов и классов, оперируя вложенностью можно писать достаточно простые css-селекторы, которые явно и однозначно описывают как какой блок отобразить.
В той же таблице в нужно обязательно давать класс всем TD-шкам, чей внешний вид мы хотим изменить.
И ложка дегтя
Единственный существенный недостаток блочной верстки по отношению к табличной - это большая завязанность на css. Без css (например, если файл не загрузился) блочная верстка выглядит откровенно стремно. Табличная же верстка в этом плане выглядит удобоваримо. Элементы страницы все-равно помещаются примерно на свои места.
Но преимущество это сомнительно при всех недостатках выше.
Да, есть семантические теги (но это частный случай блочного элемента со своим назначением и иногда с доп.параметрами по умолчанию), и есть общий базовый блочный элемент div (который я и использовал, потому что не знал назначения элемента в вопросе izrukvruki)
Но блочная верстка это есть что ни на есть "сегодня".
Да, есть flex, есть grid (это не теги, а css-подходы, которые так же применяются к "блочным" тегам). Это завтра, которое вот-вот наступит, но опять же оно не столь кардинально, чтоб называть блочную верстку вчерашним днем. С момента, когда прогрессивный инет перешел на блочную верстку появился только один известный мне кардинально другой способ отображать контент на веб-странице - это отрисовывать его на канвасе. Но это уже не верстка, это уже почти анимация (сродни флеш), которая имеет большое количество недостатков и подходит только для узкого количества случаев.
Так все-же в чем преимущество блочной верстки по сравнению с табличной:
1. Адаптивность.
Это самое главное преимущество блочной верстки. В эпоху экранов поголовно 1024х768 это было без разницы, теперь же, когда сайт должен удобно отображаться и на мобиле и на ноуте и на экране телевизора - без адаптивности никуда.
И здесь дело не только в фиксированной ширине, а в том, что в зависимости от разрешения блоки не только ресайзятся, но и более удобно компонуются, и в том, что на меньших экранах можно очень сильно видоизменить какой-то блок управляя только его стилем отображения.
2. Семантичность.
DIV - это общий случай блочного элемента. Помимо него есть еще куча более конкрентых тэгов для той или иной ситуации. FOOTER, HEADER, ARTICLE, SECTION, NAV, FIGURE, DIALOG, ASIDE - эти тэги не имеют никаких преимуществ перед обычным дивом, но наличие этих тегов в верстке делают исходный код понятнее как разработчику так и поисковым роботам (СЕО будет отдельным пунктом).
3. SEO
Это скорее комбинация первых двух пунктов. Но если ты хочешь, чтоб твой сайт хорошо индексировался поисковиками ты должен заботиться о адаптивности и семантичности. Поэтому идет отдельным пунктом.
Сайты неадаптированые под мобильную верстку - хуже индексируются (гуглом так точно, про другие - не знаю).
А использование семантических тегов позволяют делать дополнительные акценты на важные контентные части страницы или, наоборот, указать на навигационные элементы. Еще очень часто в СЕО рекомендуют главный контент писать перед декоративными или навигационными блоками. Да, в блочной верстке, часто бывает трудно это сделать, в табличной же - вовсе не возможно.
4. Изменяемость и поддержка
Если ты решил, что левую и правую колонку нужно поменять местами или вклинить еще одну колонку - то в табличной верстке это может привести к очень серьезным проблемам. Тебе нужно будет перешерстить все TR-ки и внести в них изменения. А если есть еще collspan - тогда еще и их нужно будет перешерстить. С ужасом вспоминаю те моменты, когда нужно было поддерживать разбитый на подшаблоны сайт с табличной версткой.
Отдельным гемороем будет динамическое изменение такой страницы, например при помощи джаваскрипта (или частным случаем такого динамического изменения является адаптивность - изменение отображения в зависимости от размера экрана благодаря media-query).
5. Компактность html кода
Код
<main class="block-user-profile">
<header>Профиль пользователя Шуруп</header>
<article>
<h1>Биография Шурупа</h1>
<p> Родился 5 декабря 1982 года в городе ... </p>
<p> 1999 году окончил среднюю школу №17 города ирпеня </p>
</article>
<aside>
<header>Краткое </header>
<section class="about">
<ul>
<li>рост: 186см</li>
<li>вес: 106кг</li>
<li>цвет волос: брюнет</li>
</ul>
<details>
<ul>
<li>Зарегистрирован ...</li>
<li>Последний раз был ...</li>
<ul>
</details>
<button class="show-more">Больше</b>
</section>
<section class="contacts">
...
</section>
</aside>
<footer>
<a href="mailto:...">написать сообщение</a>
</footer>
</main>
<header>Профиль пользователя Шуруп</header>
<article>
<h1>Биография Шурупа</h1>
<p> Родился 5 декабря 1982 года в городе ... </p>
<p> 1999 году окончил среднюю школу №17 города ирпеня </p>
</article>
<aside>
<header>Краткое </header>
<section class="about">
<ul>
<li>рост: 186см</li>
<li>вес: 106кг</li>
<li>цвет волос: брюнет</li>
</ul>
<details>
<ul>
<li>Зарегистрирован ...</li>
<li>Последний раз был ...</li>
<ul>
</details>
<button class="show-more">Больше</b>
</section>
<section class="contacts">
...
</section>
</aside>
<footer>
<a href="mailto:...">написать сообщение</a>
</footer>
</main>
Чтоб понять в каком блоке ты находишься достаточно взлянуть на парочку родительских элементов. В таблице же - ты всегда в td, или в виде исключения в th.
Благодаря html5-тегам и минимуму классов можно оставить в верстке только "ЧТО отображать", и исключить "КАК отображать", тем самым пенести вес страницы на css. Хотя в современном мире вес не слишком важен (по крайней мере в контексте верстки), но может быть ощутим при частых ajax запросах.
При грамотной расстановке тегов и классов, оперируя вложенностью можно писать достаточно простые css-селекторы, которые явно и однозначно описывают как какой блок отобразить.
В той же таблице в нужно обязательно давать класс всем TD-шкам, чей внешний вид мы хотим изменить.
И ложка дегтя
Единственный существенный недостаток блочной верстки по отношению к табличной - это большая завязанность на css. Без css (например, если файл не загрузился) блочная верстка выглядит откровенно стремно. Табличная же верстка в этом плане выглядит удобоваримо. Элементы страницы все-равно помещаются примерно на свои места.
Но преимущество это сомнительно при всех недостатках выше.
Shurup
насчёт web - понятно.
Но всё ж таки - html - это не исключительно инструмент интернета. На нём и справки всякие создаются.
html имеет преимущества относительно формата rtf - это универсальность для любой ОС, легкочитаемость, легко генерируется программно, большее богатство форматирования. И для этих целей - табличная вёрстка, имхо, сильно предпочтительнее.
насчёт web - понятно.
Но всё ж таки - html - это не исключительно инструмент интернета. На нём и справки всякие создаются.
html имеет преимущества относительно формата rtf - это универсальность для любой ОС, легкочитаемость, легко генерируется программно, большее богатство форматирования. И для этих целей - табличная вёрстка, имхо, сильно предпочтительнее.
Вроде еще один аргумент в пользу ДИВов, то что они отображаются сразу по мере загрузки, а таблица только когда полностью загрузится... Особо актуально на ОЧЕНЬ больших таблицах и с картинками... но не актуально в эпоху быстрого инета.
Цитата(Shurup @ 27 Jun 2016, 09:12)
Отдельным гемороем будет динамическое изменение такой страницы, например при помощи джаваскрипта (или частным случаем такого динамического изменения является адаптивность - изменение отображения в зависимости от размера экрана благодаря media-query).
Ну почему же? Вот, недавно как раз писал как раз такой скрипт - исправление ширины всех ячеек в строке по объёму контента в них. Ничего особо сложного.
Код
<script lang="javascript">
function res_td() {
var tr=document.getElementsByTagName("tr");
for (j=tr.length-1; j>=0; j--) {
c=tr[j].childNodes.length;
if (c==1) {continue};
sum=0;
for (i=0; i<tr[j].childNodes.length; i++) {
sum=sum+tr[j].childNodes[i].childNodes[0].offsetHeight*tr[j].childNodes[i].childNodes[0].offsetWidth;
};
for (i=0; i<tr[j].childNodes.length; i++) {
var w=tr[j].childNodes[i].childNodes[0].offsetHeight*tr[j].childNodes[i].childNodes[0].offsetWidth/sum*100+"%";
tr[j].childNodes[i].style.width=w;
};
};
return false;
};
function res_td() {
var tr=document.getElementsByTagName("tr");
for (j=tr.length-1; j>=0; j--) {
c=tr[j].childNodes.length;
if (c==1) {continue};
sum=0;
for (i=0; i<tr[j].childNodes.length; i++) {
sum=sum+tr[j].childNodes[i].childNodes[0].offsetHeight*tr[j].childNodes[i].childNodes[0].offsetWidth;
};
for (i=0; i<tr[j].childNodes.length; i++) {
var w=tr[j].childNodes[i].childNodes[0].offsetHeight*tr[j].childNodes[i].childNodes[0].offsetWidth/sum*100+"%";
tr[j].childNodes[i].style.width=w;
};
};
return false;
};
Цитата(hippocamus @ 27 Jun 2016, 13:50)
Shurup
насчёт web - понятно.
Но всё ж таки - html - это не исключительно инструмент интернета. На нём и справки всякие создаются.
html имеет преимущества относительно формата rtf - это универсальность для любой ОС, легкочитаемость, легко генерируется программно, большее богатство форматирования. И для этих целей - табличная вёрстка, имхо, сильно предпочтительнее.
насчёт web - понятно.
Но всё ж таки - html - это не исключительно инструмент интернета. На нём и справки всякие создаются.
html имеет преимущества относительно формата rtf - это универсальность для любой ОС, легкочитаемость, легко генерируется программно, большее богатство форматирования. И для этих целей - табличная вёрстка, имхо, сильно предпочтительнее.
Если для отображения применяется виндовый компонент типа WebBrowser, который долгое время был по сути ИЕ5 - тогда да. Если же есть возможно для отображения использовать современные средства - тогда генерация только упростится. Как сейчас в разработке десктопных приложений - я уже не в курсе, давно не в этой сфере.
Но как веб-разработчик нередко сталкиваюсь с версткой емейл-писем и рассылок. И да, там если хочешь, чтоб выглядело примерно одинаково и в gmail и в Outlook Express - единственный вариант верстки - таблица. К счастью, непосредственно я этого не делаю, есть кому это поручить. Но в целом, сравниваю такое изощерённое развлечение с искусством разжигать костёр с помощью резиновго мяча и вилки.
Цитата(Shurup @ 27 Jun 2016, 21:21)
Но в целом, сравниваю такое изощерённое развлечение с искусством разжигать костёр с помощью резиновго мяча и вилки.
Цитата(Shurup @ 27 Jun 2016, 21:21)
Если для отображения применяется виндовый компонент типа WebBrowser, который долгое время был по сути ИЕ5 - тогда да.
Почти верно, компонент - кроссплатформенный TWebBrowser из библиотеки FireMonkey.
Наверное глупый вопрос: можно ли в коде страницы использовать произвольные теги? Например <qwerty></qwerty>
вроде большинство браузеров обработает его как тег <p>, но может ли это вызвать ошибку/проблему?
вроде большинство браузеров обработает его как тег <p>, но может ли это вызвать ошибку/проблему?
Цитата(izrukvruki @ 01 Aug 2016, 17:03)
Наверное глупый вопрос: можно ли в коде страницы использовать произвольные теги? Например <qwerty></qwerty>
А нафига?
Мало ли…
Чтоб вместо div class="qwerty" использовать просто qwerty
я плохо понял какой из пунктов отвечает на мой вопрос...
Цитата(tolich @ 01 Aug 2016, 14:21)
я плохо понял какой из пунктов отвечает на мой вопрос...
Там что-нибудь написано про кастомные элементы и атрибуты? Нет? Я так и думал. А список поддерживаемых ниже.
Хотя, наверно, можно как-нибудь расширение прикрутить...
Хотя, наверно, можно как-нибудь расширение прикрутить...
Не, ну вообще есть спецификации WebComponents и CustomElements в их составе - http://www.html5rocks.com/en/tutorials/web...customelements/.
Вкратце - сейчас ведется разработка спецификации кастомных элементах в HTML. В принципе, проект довольно зрелый, и уже можно использовать (я бы не колебался, будь надобность). Мало того, в хроме уже есть поддержка нативно, но для кроссбраузерности, конечно, нужно подключить полифилл (небольшой, 5 килобайт).
Выглядит так:
Это, конечно, если ты хочешь писать по-правильному, придерживаясь стандартов. В принципе, можно рискнуть и попробовать использовать кастомные элементы просто так, но это недокументирование поле, здесь у браузеров могут быть любые прихоти.
Вкратце - сейчас ведется разработка спецификации кастомных элементах в HTML. В принципе, проект довольно зрелый, и уже можно использовать (я бы не колебался, будь надобность). Мало того, в хроме уже есть поддержка нативно, но для кроссбраузерности, конечно, нужно подключить полифилл (небольшой, 5 килобайт).
Выглядит так:
Код
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Custom elements</title>
<!-- Полифилл желательно должен стоять самым первым -->
<script src="https://cdnjs.cloudflare.com/ajax/libs/webcomponentsjs/0.7.22/CustomElements.min.js"></script>
<script>
// Зарегистрируем элемент - тогда его использование в коде будет полностью валидным.
// Название, в принципе, может быть любым, единственное требование - в нем обязательно должен присутствовать дефис (для совместимости с дальнейшими расширениями html)
document.registerElement("my-element");
</script>
</head>
<body>
<my-element>Траляля</my-element>
</body>
</html>
<html>
<head>
<meta charset="utf-8">
<title>Custom elements</title>
<!-- Полифилл желательно должен стоять самым первым -->
<script src="https://cdnjs.cloudflare.com/ajax/libs/webcomponentsjs/0.7.22/CustomElements.min.js"></script>
<script>
// Зарегистрируем элемент - тогда его использование в коде будет полностью валидным.
// Название, в принципе, может быть любым, единственное требование - в нем обязательно должен присутствовать дефис (для совместимости с дальнейшими расширениями html)
document.registerElement("my-element");
</script>
</head>
<body>
<my-element>Траляля</my-element>
</body>
</html>
Это, конечно, если ты хочешь писать по-правильному, придерживаясь стандартов. В принципе, можно рискнуть и попробовать использовать кастомные элементы просто так, но это недокументирование поле, здесь у браузеров могут быть любые прихоти.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.