Jekyll automatically adds an id attribute to headings and a link to that URL fragment that appears when you mouse over the heading.
I want to disable this for a specific heading which is inside an item detail card which always appears at the top of any page, and the link looks out of place in this context.
Is there a simple way to e.g. mark a specific heading to be excluded, or could the link be removed with some JavaScript? Or is there another HTML tag that I should be using for this type of heading?
The heading is in an HTML layout and I'm using the Primer theme.
Example snippet:
<h2>{{ component.name }}</h2>
Result (heading in orange):
This card will probably be floated to the left or right of the main page content, wiki style.
The Primer theme includes AnchorJS in line 26 of the default layout as you can see in the GitHub source.
AnchorJS seems great and pretty flexible. From https://www.bryanbraun.com/anchorjs:
AnchorJS lets you drop deep anchor links (like these) onto any
webpage, and be on your way.
You don't need to set up IDs or worry about URLs. AnchorJS will
respect your IDs if you have them, and generate them if you don't.
It uses an attractive link icon by default, but you can customize the
display via options and CSS styling.
The page also explains different ways how to remove anchors, here's the one you most probably need to target only specific headings:
/**
* Example 2
* Add anchors to all h2s, except for those with a class of "no-anchor".
*/
anchors.add('h2:not(.no-anchor)');
In your case, you could add a CSS class on your special h2 and it will not show an anchor anymore if you target the class with your CSS.
Christian's answer gets to the heart of the issue, but because one cannot change the way Primer adds the links without replacing the whole default.html file, it may be easier to hide the link with CSS.
/* also add class="no-anchor" to heading tags in HTML */
.no-anchor .anchorjs-link {
display: none;
}
However, this leaves the ID intact so someone determined enough could still link to that heading.
Related
Currently my code looks like this:
<div class="carouselTypo">
<p class="carouselTypo__p" data-target="#active1">A</p>
<p class="carouselTypo__p" data-target="#active2">B</p>
<p class="carouselTypo__p" data-target="#active3">C</p>
</div>
The same code could also be written like this:
<ul class="carouselTypo">
<li class="carouselTypo__p" data-target="#active1">A</li>
<li class="carouselTypo__p" data-target="#active2">B</li>
<li class="carouselTypo__p" data-target="#active3">C</li>
</ul>
Now I'm wondering, which one is better or correct? Or does it not matter?
Actually if you remove the default css I don't think it does matter in this case.
but you should always prefer to use the element that represents your elements prototype,
because sometimes the browser has different behavior for different elements.
for example lets take the the anchor tag.
you can make it in tow ways:
create a button which opens the href
create an anchor tag with href
if you remove the default css the look the same but they don't,
because the browser has other way to deal with anchor tag, for example with anchor tag if you hover the anchor you will see in the bottom the url address:, or you will be able to shift-click which opens the link in a new tab.
<button onclick="document.location.href = 'https://stackoverflow.com';">
hover / shift-click doesn't work
</button>
hover / shift-click works
maybe you can make the shift-click yourself for example, but there are more different can't be done by you, for example accessibility service / extensions will probably react different with other tags.
So if you are making a list of something I recommend you to use the ul Although I don't see any different in non style behavior. (but again, for example maybe there is an extension which collects lists data and it won't work on the div method.)
The functional advantage is that divs mean little on their own, whereas ul lis explicitly mean "this is an un/ordered list of items."
The term "semantics" refers to the way that you use the inherent meaning of existing structures to create explicit meaning. HTML is comprised of tags that mean certain things by themselves. And there are established rules/guidelines/ways to use them so that your published HTML document conveys what you want it to mean.
If you list something in your document, then add an ordered list (UL) or an unordered list (OL). On the other hand, the page division (DIV) element is used to create a specific & separate piece of content.
The div element "divides." When you look at a page, there are specific parts like a content body, the footer, a header, navigation, menus, forms, etc. And you can use div tags to create these divisions. Often, the page parts correspond with a visual layout, so using explicit page divisions (DIVs) to cut up your layout in CSS is a natural fit. This way the div tags become structural.
If you misuse or overuse the div tag, it can create unintended meaning & code bloat.
To confuse matters: Google uses h3 and div to "divide" their listed search results. ul > li > h3 + div
So when you turn off all styles (Shift+Cmd/Crtl+S in Firefox w/ WebDeveloper toolbar), the divs should go away, and stack naturally. Your naked HTML should still render a nice page with a clear hierarchy: top to bottom, most important content first, and lists with bullets & numbers for listed items. And it's a good idea to add a link near the top (for non-visual users) that allows you to skip down to main content, important forms, or the main headings (like a table of contents).
Finally, keep in mind that you are building a document. Without all the visual effects, it should still be a cogent document.
It will affect your code readability. If you use ul and li, your code is more readable.
The spec says the following about the <nav> element (emphasis mine):
The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.
It never specifically says that <button> is disallowed, and nowhere it says that only <a> elements should be used for navigation (yet it mentions "links"), but all the examples seem to be a bunch of anchors in lists. The one example (11) that isn't a list still has only anchor elements for navigation inside.
The next example (12) shows an example of navigation within application, but uses anchors again.
So, are button elements allowed inside <nav>?
In HTML 5.2, section 4.8. is about links:
Links are a conceptual construct, created by a, area, and link elements, that represent a connection between two resources […]
As one would expect, the definitions of a ("a hyperlink"), area ("a hyperlink"), and link ("the link(s)" etc.), all refer to links, while the definitions of button and input don’t.
So:
A nav element should contain elements with href attribute (a/area/link). Otherwise it wouldn’t be warranted to use nav in the first place (exceptions aside).
A nav element may also contain buttons. For example, a button that is used to toggle between showing all levels of the navigation, and showing only the top-level. (However, if the buttons are used for navigation, they should be links instead of buttons anyway.)
The HTML5 Standards allows any kind of flow content inside of <nav>-tags and <button> tags are considered being flow content, but you should consider to avoid them for semantical reasons. Buttons based on <button> are UI elements which are exclusively javascript driven (or in some tricky scenarios by the default behavior of the browser when using forms) without any functionality or semantical reference towards an 3rd party reference. Therefor using <button>-tags inside of <nav>-tags makes no sense for clients/robots who do operate without considering javascript.
Modern UI-Frameworks like Bootstrap, Semantic-UI or others do provide the ability to implement buttons in multiple ways (as <button>-tags as well as <a>-tags). Taking such abilities into account, you should prefer to rely on <a>-tag based buttons for semanatic reasons.
Depends how you define "allowed".
It is valid HTML, but you may want to read up on accessibility and the difference between a button (that should signal clickable actions) and a link (that should navigate somewhere).
http://web-accessibility.carnegiemuseums.org/content/buttons/
I am working on a new blog's design and markup right now and I have found a place where I'm tempted to nest two anchor tags within a single heading tag:
<h3><a>Popular<a/>|<a>Recent</a></h3>
Which looks like this:
(source: autochemky.com)
The purpose of doing this would (obviously) be to enable "POPULAR" as a link to display popular articles and "RECENT" a link to display recent articles. . . clicking one or the other would only change the visible content (article list) on the sidebar and not link to a new page (either via ajax or having them both already loaded and one being a hidden div).
Doing this is a measure to avoid additional potentially unnecessary code involving more than one h3 element or more than one visible list of articles.
I suppose my questions to go along with this are (in order of importance and assuming HTML5):
Is the markup valid/acceptable?
Would this have any realistic/noticeable effect on SEO?
Would you prefer to achieve the same result in a different way?
Assuming HTML5 - it's acceptable, HTML5 introduced that any element can be inside an <a> tag (pretty sure)
Changes in HTML5
Although previous versions of HTML restricted the a element to only containing phrasing content (essentially, what was in previous versions referred to as “inline” content), the a element is now transparent; that is, an instance of the a element is now allowed to also contain flow content (essentially, what was in previous versions referred to as “block” content)—if the parent element of that instance of the a element is an element that is allowed to contain flow content.
Not a noticeable effect on SEO, it's a minor detail, as minor as you probably should be using a <h1> tag if that is the header of a section seeing as that is the base in the new HTML5 semantics.
I'd stick to what you have there definitely.
Well, yes, it's valid to have several a elements inside a heading (as long as you don't nest the a elements).
But I think your heading doesn't make sense. It's either "Popular" or "Recent", not both at the same time, right? So your heading is missing its purpose: describing the content of its section.
You should use a content toggler that is not part of the heading:
<section>
<h1>Popular</h1>
<nav>Or see recent content</nav>
<ul>
<li>…</li>
<li>…</li>
</ul>
</section>
(If you wish, you could change the wording and style it that way that it looks like your example, by positioning the link to the other content next to the heading.)
Clicking at "recent content" should change the heading from "Popular" to "Recent", and changing the link to popular content
If you don't use the URL anchor + CSS to hide/show the corresponding content, and you don't have a fallback for users/bots without JS, you should display both at the same time, popular and recent content, for users with disabled JavaScript.
Regarding:
The h3 is because it is one of the sections in the sidebar and my sidebar sections are all headed by h3. I have seen some sites that use h2 and some that use h3, I chose h3.
Just to get sure: You are not free to use any heading level you like. You need to follow your document outline. If the use of h3 is correct depends on your whole page structure.
Can I use <section> tag inside unordered list?
I know, that <section> represent a generic section of document. Usually we find heading inside.
So... I have list of products. Usually about 20 per page. Each element have:
heading,
short description (max 255 chars),
thumbnail, some details, button.
So each list item is something like section, "is a thematic grouping of content, typically with a heading".
Of course I don't use, <section> to styling purpose.
I think, <section> also could be here a wrapper for a list, and each element of list <article>.
What is your opinion?
Using a <section> tag inside an <li> tag validates (you can try this using the “Text Field” option on http://html5.validator.nu/), and the spec doesn’t seem to suggest you shouldn’t use it in this way (see http://dev.w3.org/html5/spec-author-view/the-section-element.html#the-section-element), so that seems fine to me.
The <article> tag is meant for “self-contained compositions”. I’ve never been entirely clear what that means outside of several blog posts being listed on a single page, but I think product summaries sound like a decent fit for that too. So your second idea of a <section> containing the entire list, and an <article> for each product, probably sounds best.
A List of DOs…
DO use section for each individual section of a tab switcher or content slider (if an unordered list isn’t needed)
DO use section to divide a lengthy “terms and conditions” (or similar) page into numbered sections
DO nest section elements if necessary (as you might do with the “terms and conditions” page)
A List of DON’Ts…
DON’T use section to divide content from the header and footer; use div instead (see the doctor)
DON’T use section to wrap a tab switcher for DOM manipulation or styling
DON’T use section for sidebar or other tangentially-related content boxes; use aside instead
DON’T use section just to add a border or drop shadow around something; use div instead
DON’T use section for the wrapper when implementing faux columns; again, use div instead
DON’T use section to nest elements when trying to avoid IE6′s float double-margin bug (or a similar layout-related issue); again, use div
DON’T use section to hold an individual author bio on a blog post or news article; use aside instead
Stolen from When to Use the HTML5 “section” Element
I'm editing books/articles in HTML. These texts were printed once and I scan them, convert them into an intermediate XML-Format and then I transform them into HTML (by XSLT). Because some of those texts are extinct from the market today and are only available through the major libraries I want to publish them in a way so that people could possibly cite them by referring to the page numbers in the original document. For this purpose my intermediate XML-format has an element that marks a page-break. Right now I'm working on the XML->HTML transformations and I'm wondering myself how to transform these page breaks in HTML. They should not appear in the final HTML by default (so a simple | doesn't fit) but I plan to wrap these documents with some lightweight JavaScript that will show the markers when needed. I thought about <span>s with a | in it that are hidden by default.
Is there a better, possibly 'semantic' way to this problem?
Page breaks are very much a thing of layout, and HTML isn't designed to describe layout, so you aren't going to find anything that is semantic for this within the language.
The best you can hope for is some sort of kludge.
Since a page break can occur in the middle of a paragraph, and <p> elements can contain only inline elements you can eliminate most of the options from the outset.
The two possibilities that suggest themselves to me are <span> and <a>. The former has no semantics, that latter is designed to be linked to (with a name attribute) or from (with an href attribute), and you could consider a page from an original document something that you might wish to link to.
No matter what element you use, I wouldn't include a marker in it and then hide it with CSS. That sort of presentational flag is something I would consider adding via :before in a stylesheet (combined with a descendent selector for a body class that can be toggled with JS since you want the toggle)
Alternatively, if you want to take a (very) broad view of the meaning of "HTML" you could consider the l element (from the defunct XHTML 2 drafts) and markup each line of the original document. Adding a class would indicate where a new page began (and you could use CSS counters and borders to clearly indicate each page and number it should you so wish). Pity the browser vendors refused to get behind a real semantic markup language and favoured HTML 5 instead.
Use a <div class="Page"> for each page, and have a stylesheet containing:
.Page {
page-break-after: always;
}
Maybe you can use an xml tag not parsed/interpreted by html like <pagebreak/>.
In this way viewing the html the tag will be not rendered but using jQuery or any other Javascript library, transform, when asked, these particular tags in standard or whatsoever visual mark.
I think this can be a semantic approach...