#html #semantics #spry
#HTML #семантика #spry
Вопрос:
Я создаю веб-сайт с использованием разметки HTML 5, но столкнулся с проблемой относительно того, где разместить элемент навигации — потому что я использую «Панель вкладок» SPRY как для навигации, так идля содержимого:
<header>
<div id="TabbedPanels1" class="TabbedPanels">
<ul class="TabbedPanelsTabGroup">
<li class="TabbedPanelsTab" tabindex="0">Home</li>
<li class="TabbedPanelsTab" tabindex="0">Profile/li>
<li class="TabbedPanelsTab" tabindex="0">Contact</li>
</ul>
<div class="TabbedPanelsContentGroup">
<div class="TabbedPanelsContent">Content 1</div>
<div class="TabbedPanelsContent">Content 2</div>
<div class="TabbedPanelsContent">Content 3</div>
</div>
</div>
Я подумал, что лучшим местом для вставки элемента NAV было бы обертывание элемента UL, но это нарушает работу панели вкладок SPRY (может быть, я могу просто исправить это, изменив некоторые пути к файлам в CSS?).
Кроме того, поскольку основное содержимое сайта будет размещаться в областях «Содержимое» панели с вкладками, мне интересно, какой наилучший подход для создания этого сайта, в отношении навигации, СТАТЕЙ и т.д., Так что это семантически правильно?
Возможно, я иду по этому неправильному пути?
Ответ №1:
Я не знаком с SPRY, но вы, вероятно, правы в том, что вам нужно отредактировать CSS, если вы хотите иметь больше семантической разметки.
Предполагая, что каждая «вкладка» — это отдельная статья, вот как я бы это отметил:
<div id="TabbedPanels1" class="TabbedPanels">
<nav>
<ul class="TabbedPanelsTabGroup">
<li class="TabbedPanelsTab" tabindex="0">Home</li>
<li class="TabbedPanelsTab" tabindex="0">Profile/li>
<li class="TabbedPanelsTab" tabindex="0">Contact</li>
</ul>
</nav>
<div class="TabbedPanelsContentGroup">
<article class="TabbedPanelsContent">Content 1</article>
<article class="TabbedPanelsContent">Content 2</article>
<article class="TabbedPanelsContent">Content 3</article>
</div>
</div>
Это небольшое изменение, но оно добавляет по крайней мере некоторую улучшенную семантику к разметке, при этом оставляя большую часть структуры нетронутой, так что не требуется вносить МАСШТАБНЫЕ изменения в код фреймворка SPRY.