Тэг i: Тег | htmlbook.ru

Leave a Comment / Разное / By /

Семантическое значение HTML-тегов, разница между тегами i и em, b и strong

05.07.18 ИТ / HTML 6287

Язык HTML разрабатывался таким образом, что практически каждый элемент в нем содержит семантический смысл. Семантический смысл тегов – это значит, что каждый тег не просто задает тот или иной внешний вид интерфейса на странице, но и еще сообщает о том, зачем этот тег, поясняет смысл и назначение тега.

Теги предназначены не обязательно для создания внешнего вида интерфейса, хотя в настоящее время они предназначены именно для этого. Внешний вид тегов может трактоваться и отрисовываться как угодно, на разных движках и ОС они могут отличаться внешне. Но семантическое значение тегов всегда одинаковое, такое, какое четко задано в спецификации.

Начинающие пользователи, как правило, вообще не задумываются о смысле тегов, им нужно только получить нужный внешний вид. Но это неправильный подход, нужно использовать теги осмысленно. Для чего это нужно? Всевозможные поисковые системы, сервисы используют

семантические правила для извлечения необходимой информации, а это значит, что если станица правильно спроектирована с использованием подходящих тегов, то она будет гораздо ценней для этих поисковиков и сервисов. Это немаловажный фактор при продвижении сайта.

Например, часто можно встретить вопросы, какой тег использовать, тот или иной, когда они внешне выглядят абсолютно одинаково. Тег i и тег em как раз такие теги. Внешне ничем не различаются, но семантический смысл разный. Первый тег i просто выделяет текст курсивным начертанием, второй же тег em придает тексту, помещенному в него, особый смысл. Текст становится более важным на странице. То есть, если не смотреть внешний результат, то тег em дает смысловое выделение, а тег i нет. Когда же посмотреть в браузере результат, выглядят они одинаково, но особое значение у текста в теге

em. Таким образом, разница между i и em установлена.

Другой аналогичный пример, теги b и strong. Здесь даже из названия можно понять, что второй тег гораздо значимый. Действительно, b просто выделяет текст жирным начертанием, а strong выделяет жирным и придает семантический смысл тексту, помещенного в этот тег. Особенно важно для поисковых систем, текст в strong играет большое значение при выдаче. Итак, разница между b и strong тоже установлена.

Таким образом, нужно уметь правильно понять, как применять теги в той или иной ситуации. Ведь от правильного применения зависит успех продвижения сайта в современных поисковых системах. Семантическое значение HTML достаточно просто понять, особенно актуально это для новых тегов HTML5. Они, например, позволяют четко обозначить структуру страницы, благодаря новейшим тегам. Но чтобы рассмотреть эту тему, потребуется написать целую статью, об этом позже.

html — Зачем в большом количестве используют тег i?

Вопрос задан

Изменён 6 лет 3 месяца назад

Просмотрен 215 раз

Все чаще и чаще замечаю, что в туториалах на сайтах разработчиков плагинов появляется тег

< i>, зачем? Его очень часто используют, но не пойму, в чем его преимущество.

Примерно так: 

<span>
  <i></i>
  <i></i>
</span>

P.S. Про эффект тега знаю.

  • html
  • design
  • css

5

Короткий

В настоящее время его используют для иконок.

1

Используют из-за собственной лени — это единственное объяснение.
Если не вспоминать, для чего изначально был придуман этот тег, можно еще допустить следование за модным бутстрапом (ну как же, бутстрап — это авторитет), хотя именно разработчикам бутстрапа я обязан постоянному потоку присылаемых на доработку проектов))).

Если внимательно глянуть на большинство BS-шаблонов, где надо и где не надо используются заголовки h3-h5, те же i, и не побоюсь этого слова — EM! EM, Карл! Про теги b и strong нужно наверно промолчать. лет 10 назад это было бы конечно абсолютно без разницы и всякий начинающий верстальщик с радостью вставлял h4 — опля и жирный текст сразу и размер шрифта не надо присваивать))) А сейчас поисковики начали делать добрые дела — разбирать зерна меж плевел.
В свои проектах для таких вещей, для которых большинство применяет тег i, активно применяю псевдотеги before и after — в коде страницы вообще нет мусора! Попробуйте, вам понравится!

2

Зарегистрируйтесь или войдите

Регистрация через Google

Регистрация через Facebook

Регистрация через почту

Отправить без регистрации

Почта

Необходима, но никому не показывается

Отправить без регистрации

Почта

Необходима, но никому не показывается

Нажимая на кнопку «Отправить ответ», вы соглашаетесь с нашими пользовательским соглашением, политикой конфиденциальности и политикой о куки

git checkout — Как я могу получить последнее имя тега в текущей ветке в Git?

спросил

Изменено 1 год, 3 месяца назад

Просмотрено 401 тысяч раз

Какой самый простой способ получить самый последний тег в Git?

 git пометить HEAD
тег git b HEAD^^
git тег c HEAD^
git-тег

вывод:

 а
б
с

Должен ли я написать сценарий для получения даты и времени каждого тега и их сравнения?

  • git
  • git-checkout
  • git-tag
  • getlatest

1

Чтобы получить самый последний тег (пример вывода после):

 git description --tags --abbrev=0 # 0. 1.0-dev

Чтобы получить самый последний тег с количеством дополнительных коммитов поверх помеченного объекта и более:

 git описать --tags # 0.1.0-dev-93-g1416689

Чтобы получить самый последний аннотированный тег :

 git description --abbrev=0

11

Вы можете взглянуть на git description , который делает что-то близкое к тому, что вы просите.

10

Будет выводить тег последней помеченной фиксации во всех ветках

 git описать --tags $(git rev-list --tags --max-count=1)

8

Чтобы получить самый последний тег, вы можете сделать:

$ git for-each-ref refs/tags --sort=-taggerdate --format='%(refname)' --count=1

Конечно, вы можете изменить аргумент счетчика или поле сортировки по желанию. Кажется что вы, возможно, хотели задать немного другой вопрос, но это действительно отвечает на вопрос, как я его интерпретирую.

11

Как насчет этого?

TAG=$(git описать $(git rev-list --tags --max-count=1))

Технически не обязательно получить последний тег, но последний отмеченный коммит, который может быть или не быть тем, что вы ищете.

4

Вы можете выполнить: git description --tags $(git rev-list --tags --max-count=1) говорил здесь: Как получить последнее имя тега?

2

 git описать --abbrev=0 --tags

Если вы не видите последний тег, убедитесь, что вы выбрали источник, прежде чем запускать его:

 git remote update

1

«Самый последний» может иметь два значения с точки зрения git.

Вы могли бы иметь в виду «у какого тега самая поздняя дата создания по времени», и большинство ответов здесь относятся к этому вопросу. Что касается вашего вопроса, вы хотели бы вернуть тег с .

Или вы можете иметь в виду «какой тег ближе всего в истории разработки к какой-либо именованной ветке», обычно это ветка, в которой вы находитесь, HEAD . В вашем вопросе это вернет тег a .

Конечно, они могут отличаться:

 A->B->C->D->E->F (HEAD)
       \\
        \ X->Y->Z (v0.2)
         П->В (v0.1)

Представьте, что разработчик пометил Z как v0.2 в понедельник, а затем пометил Q как v0.1 во вторник. v0.1 является более поздним, но v0.2 ближе в истории развития к HEAD, в том смысле, что путь, на котором он находится, начинается в точке, более близкой к HEAD.

Думаю, вам обычно нужен второй ответ, более близкий по истории разработки. Вы можете узнать это, используя git log v0.2..HEAD и т. д. для каждого тега. Это дает вам количество коммитов в HEAD, поскольку путь, заканчивающийся на v0.2 , расходится с путем, за которым следует HEAD.

Вот скрипт Python, который делает это, перебирая все теги, выполняющие эту проверку, а затем распечатывая тег с наименьшим количеством коммитов в HEAD, поскольку путь тега расходится:

https://github.com/MacPython/terryfy/ blob/master/git-closest-tag

git description делает что-то немного другое, поскольку он отслеживает (например) HEAD, чтобы найти первый тег, который находится на обратном пути в истории от HEAD. С точки зрения git, git описывает поиск тегов, которые «доступны» из HEAD. Поэтому он не найдет такие теги, как v0.2 которые находятся не на обратном пути от HEAD, а на пути, который оттуда расходился.

Не знаю, почему нет ответов на вопрос. т. е. все теги (включая неаннотированные) и без суффикса:

 git description --tags --abbrev=0

0

git description --tags

возвращает последний тег, видимый текущей веткой

0

 тег git --sort=committerdate | хвост -1

2

Проблема с описанием в процессах CI/CD заключается в том, что вы можете столкнуться с фатальной ошибкой : теги не могут описать .

Это произойдет потому, что для git описать --help :

Команда находит самый последний тег, который доступен из фиксации .

Если вам нужен последний тег в репозитории, независимо от того, может ли ветвь, в которой вы находитесь, достичь тега, обычно потому, что он не является частью дерева текущей ветки, эта команда предоставит вам самый последний созданный тег во всем репо. :

 тег git -l --sort=-creatordate | голова -n 1

2

 тег git -l ac* | хвост -n1

Получить последний тег с префиксом «ac» . Например, тег с именем ac1.0.0 или ac1.0.5 . Другие теги с именами 1.0.0 , 1.1.0 будут игнорироваться.

 тег git -l [0-9].* | хвост -n1

Получить последний тег, первый символ которого равен 0-9 . Итак, эти теги с первым символом a-z будут игнорироваться.

Дополнительная информация 

 git tag --help # Справка для `git tag`
 
 тег git -l <шаблон>

Список тегов с именами, соответствующими заданному шаблону (или всем, если нет образец дан). Запуск «git tag» без аргументов также приводит все теги. Шаблон представляет собой подстановочный знак оболочки (т. е. сопоставленный с использованием fnmatch(3)). Можно указать несколько шаблонов; если кто-то из них соответствует, тег отображается.

 tail -n <число> # показать последнюю часть файла
tail -n1 # Показать последний элемент

Обновление

С тегом git --help о аргументе sort . Он будет использовать лексикографический порядок по умолчанию, если свойство tag.sort не существует.

Порядок сортировки по умолчанию используется значение, настроенное для переменной tag. sort, если она существует, или лексикографический порядок в противном случае. См. git-config(1).

После Google кто-то сказал, что git 2.8.0 поддерживает следующий синтаксис.

 тег git --sort=committerdate

1

Что такое неправильный со всеми предложениями (кроме объяснения Мэтью Бретта, актуального в этом ответном посте)?

Просто запустите любую команду, предоставленную другими в истории jQuery Git, когда вы находитесь в другой точке истории и проверьте результат с визуальным представлением истории тегов (я сделал , поэтому вы видите этот пост):

 $ git log --graph --all --decorate --oneline --simplify-by-decoration

Сегодня многие проекты выполняют релизы (и тэги) в отдельной ветке от основной ветки .

Для этого есть веская причина .

Просто посмотрите на любые хорошо зарекомендовавшие себя проекты JS/CSS. По соглашению пользователей они содержат двоичные/уменьшенные файлы выпуска в формате DVCS. Естественно, как сопровождающий проекта, вы не хотите захламлять свою основную ветку diff история с бесполезными двоичными двоичными объектами и выполнение фиксации артефактов сборки из основной ветки .

Поскольку Git использует DAG, а не линейную историю — трудно определить метрику расстояния , поэтому мы можем сказать — о, эта версия ближе всего к моей HEAD !

Я начинаю свое собственное путешествие (загляните внутрь, я не стал копировать модные пробные изображения в этот длинный пост):

Какой ближайший тег в прошлом относительно ветвления в Git?

В настоящее время у меня есть 4 разумных определения расстояния между тегом и ревизией с уменьшением полезности:

  • длина кратчайшего пути от HEAD до объединить базу с тегом
  • дата из объединить базу между HEAD и тегом
  • число оборотов достижимое из HEAD, но не достижимое из тега
  • дата тега независимо база слияния

Я не знаю, как вычислить длину кратчайшего пути .

Скрипт, который сортирует теги по дата из объединить базу между HEAD и тегом:

 $ git tag \
     | пока читал т; делать \
         b=`git merge-base HEAD $t`; \
         echo `git log -n 1 $b --format=%ai` $t; \
       сделано | Сортировать

Используется в большинстве проектов.

Скрипт, который сортирует теги по

количеству оборотов которые доступны из HEAD, но недоступны из тега:

 $ git tag \
    | пока читал т; do echo `git rev-list --count $t..HEAD` $t; Выполнено \
    | сортировать -n

Если в истории вашего проекта есть странные даты коммитов (из-за ребаз или другой перезаписи истории, или какой-то дебил забыл заменить батарею BIOS или из-за другой магии, которую вы делаете с историей), используйте приведенный выше скрипт.

Для последней опции ( дата тега независимо от базы слияния ), чтобы получить список тегов, отсортированных по дате, используйте:

 $ git log --tags --simplify-by-decoration --pretty="format:% %d" | сортировать -r

Чтобы узнать дату текущей версии, используйте:

9,]*$// | sed ‘s . ….. ‘

ЕСЛИ ВАМ НУЖНО БОЛЬШЕ ОДНОГО ПОСЛЕДНЕГО ТЕГА

(git description —tags иногда дает неверные хэши, я не знаю почему, но для меня —max-count 2 не работает)

вот как вы можете получить список с двумя последними именами тегов в обратном хронологическом порядке, отлично работает на git 1.8.4. Для более ранних версий git (например, 1.7. *) в выводе нет строки «tag:» — просто удалите последний вызов sed

. Если вам нужно более двух последних тегов — измените этот «sed 2q» на «sed 5q». или что вам нужно

Затем вы можете легко преобразовать каждое имя тега в переменную или около того.

2

Следующее работает для меня, если вам нужны последние два тега (например, для создания журнала изменений между текущим тегом и предыдущим тегом). Я тестировал его только в ситуации, когда последним тегом был HEAD .

 PreviousAndCurrentGitTag=`git description --tags \`git rev-list --tags --abbrev=0 --max-count=2\` --abbrev=0`
PreviousGitTag=`echo $PreviousAndCurrentGitTag | вырезать -f 2 -d ' '`
CurrentGitTag=`echo $PreviousAndCurrentGitTag | вырезать -f 1 -d ' '`
GitLog=`git log ${PreviousGitTag}. .${CurrentGitTag} --pretty=oneline | sed "s_.\{41\}\(.*\)_; \1_"`

Это соответствует моим потребностям, но поскольку я не волшебник git, я уверен, что его можно улучшить. Я также подозреваю, что он сломается, если история коммитов продвинется вперед. Я просто делюсь, если это кому-то поможет.

Если вы хотите найти последний тег, который был применен к определенной ветке, вы можете попробовать следующее:

 git description --tag $(git rev-parse --verify refs/remotes/origin/"branch_name")

Если вам нужен один вкладыш, который получает последнее имя тега (по дате тега) текущая ветка :

 git for-each-ref refs/tags --sort=-taggerdate --format=%(refname:short) --count=1 --points-at=HEAD

Мы используем это, чтобы установить номер версии в настройках.

Пример вывода:

 v1.0.0

Работает и в Windows.

3

Сначала я подумал, что вы могли бы использовать git rev-list HEAD , в котором перечислены все версии в обратном хронологическом порядке в сочетании с тег git --содержит . Когда вы найдете ссылку, где git tag --contains создает непустой список, вы нашли самые последние теги.

Это старая ветка, но, похоже, многим людям не хватает самого простого, легкого и самого правильного ответа на вопрос ОП: чтобы получить последний тег для текущей ветки , вы используете git description HEAD . Сделанный.

Редактировать: вы также можете указать любое допустимое имя ссылки, даже удаленное; т. е. git описывает источник/мастер 9| $ВЕТВЬ | awk -F- '{напечатать $NF}'

По заданному вопросу

Как получить последнее имя тега в текущей ветке

вы хотите

 git log --first-parent --pretty=%d | Тег grep -m1:

--first-parent говорит git log не детализировать какие-либо объединенные истории, --pretty=%d говорит показывать только украшения, т.е. локальные имена для любых коммитов. grep -m1 говорит «соответствует только одному», поэтому вы получаете только самый последний тег.

, если ваши теги сортируются:

 git tag --merged $YOUR_BRANCH_NAME | grep "префикс/" | сортировать | хвост -n 1

Здесь не так много упоминаний о неаннотированных и аннотированных тегах. 'describe' работает с аннотированными тегами и игнорирует неаннотированные.

Это уродливо, но выполняет запрошенную работу и не находит никаких тегов на других ветках (и не на той, которая указана в команде: master в примере ниже)

Вероятно, фильтрация должна быть оптимизирована (консолидирована), но опять же, это кажется работой. 9commit'|grep 'tag:.*)$'|awk '{print $NF}'|sed 's/)$//'|head -n 1

Критика приветствуется, так как я собираюсь использовать это 🙂

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя электронную почту и пароль

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

html — атрибут Alt или title для i-тега

спросил

Изменено 4 года, 3 месяца назад

Просмотрено 116 тысяч раз

Я использую font-awesome и отображаю их шрифты так:

Отобразится милый символ замка. Чтобы пользователь знал, что именно это означает, я попытался добавить такие атрибуты, как title и alt, но безрезультатно.

Можно ли использовать какой-либо атрибут для тега , который выполняет ту же задачу, что и alt для изображений и заголовок для ссылок?

  • html
  • теги
  • потрясающий шрифт

2

Вы можете использовать атрибут title для элемента i , как и любой другой элемент, например.

Поможет ли - более сложный вопрос. Браузеры обычно показывают заголовок значение атрибута как «подсказка» при наведении курсора мыши, но зачем пользователю наводить курсор мыши на значок? И такие всплывающие подсказки неудобны в использовании; так называемые всплывающие подсказки CSS часто работают лучше.

Средства чтения с экрана могут предоставить пользователю дополнительный доступ к атрибутам title , но я не уверен, что они делают с элементами с пустым содержимым.

5

С продвижением WAI-ARIA при использовании значков шрифтов вам, вероятно, следует использовать комбинацию из следующего для улучшения доступности:

  • Представление роли для удаления неявной собственной ролевой семантики элемента. Это особенно важно, если вы (ab) используете элемент с собственной семантикой для предоставления значков, как это имеет место в вашем примере с использованием элемента i (который, согласно спецификациям, «представляет собой фрагмент текста в альтернативном голос или настроение [...]" ).
  • Метка-ария для предоставления строкового значения, которое помечает элемент -или- как собственный атрибут заголовка HTML, если вы согласны с тем, что браузер отображает всплывающую подсказку при наведении курсора.
  • Атрибут aria-hidden для скрытия сгенерированного контента от вспомогательных технологий (поскольку вы используете семейство шрифтов-иконок, существует сгенерированный символ :before или :after). По спецификации:

Авторы МОГУТ, с осторожностью, использовать aria-hidden , чтобы скрыть видимо отображаемые контент из вспомогательных технологий только в том случае, если акт сокрытия этого содержание предназначено для улучшения опыта пользователей вспомогательных технологий путем удаления избыточного или постороннего контента. Авторы использование aria-hidden для скрытия видимого контента от программ чтения с экрана ДОЛЖНО гарантировать, что идентичные или эквивалентные значения и функциональные возможности подвергается воздействию вспомогательных технологий.

Я не знаю вашего точного варианта использования, поэтому я позволю себе использовать более простой случай предоставления номера телефона. В порядке убывания предпочтения I будет использовать:

 
  
  +33 7 1234576

(или любой вариант, подразумевающий:
  - элемент `i` с атрибутом представления `role`
    вместо внутреннего элемента `span`
  - атрибут title вместо атрибута aria-label)
 
 <диапазон
  aria-label="Наш номер телефона">+33 7 1234576
(или любой вариант с использованием `title` вместо `aria-label`)
 
 <роль = "презентация"
  aria-label="Наш номер телефона">+33 7 1234576
(или любой вариант с использованием `title` вместо `aria-label`)

Обратите внимание, что атрибуты aria-label и title должны описывать содержимое элемента. Не следующий родственный элемент. Итак, I чувствую, что следующее решение равно , а не в соответствии со спецификациями (даже если большинство инструментов специальных возможностей на самом деле будут вести себя так же, как если бы номер телефона находился внутри элемента span ):

 +33 7 1234576

Вместо этого вы должны использовать или что-то в этом роде. Вы можете использовать атрибут title="" , чтобы дать текст при наведении, если это то, что вы ищете. Что касается обеспечения доступности для программ чтения с экрана или ценности SEO, вы можете добавить следующий CSS:

 .иконка-замок{
    отступ текста:-99999px;
}

А затем напишите свою разметку следующим образом:

 Что я хочу сказать программе чтения с экрана

2

Я думаю, что роль шрифтов, которые действуют как изображения, должна быть зарезервирована для role="img".

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *