Consider that you land on a category webpage, whose sole purpose it is to direct you to the appropriate sub-category by informing you what's inside each with an image and a short title.
When it comes to UX considerations — it was suggested that the following arrangement would be the most optimal (text before image):
Each photo and text combination would link to the respective sub-category.
Considering semantic HTML5, since these are titles of sub-categories and not exactly captions, would it be appropriate to use the <figcaption> element? Or is something else?
Using figure captions:
<h2>Our Planet's Animals</h2>
<p>Contrary to popular belief...</p>
<figure>
<a>
<figcaption>Rhinos</figcaption>
<img />
</a>
</figure>
Using headers (or something else) instead:
<h2>Our Planet's Animals</h2>
<p>Contrary to popular belief...</p>
<figure>
<a>
<h3>Rhinos</h3>
<img />
</a>
</figure>
Or, what lese would be correct semantically, and allow ease of styling?
I think the use of the figure element would not be correct here, as this content is probably the main content of the page, but for figure it says:
[…] but that could, without affecting the flow of the document, be moved away from that primary content […]
You'd use figure if you have a diagram in a paper or a photograph in a news article etc.: content that "[…] is typically referenced as a single unit from the main flow of the document".
Instead, I'd use section for each category and enclose all categories in a nav (because it is the main navigation for that sectioning content, which is opened by the heading "Our Planet's Animals").
<h2>Our Planet's Animals</h2>
<p>Contrary to popular belief...</p>
<nav> <!-- nav could be omitted -->
<section>
<a>
<h1>Rhinos</h1> <!-- you could use h3 here instead -->
<img />
</a>
</section>
<section>
…
</section>
<section>
…
</section>
<section>
…
</section>
</nav>
If you don't want to use headings, one could also use a list for the categories (dl or ul). I think the ul fits better than dl here:
<h2>Our Planet's Animals</h2>
<p>Contrary to popular belief...</p>
<nav> <!-- nav could be omitted -->
<ul>
<li><a>Rhinos <img /></a></li>
<li>…</li>
<li>…</li>
<li>…</li>
</ul>
</nav>
It might also be possible to use section in each li element (<li><section>…</section></li>), but I'm not sure how this would affect the document outline.
Related
In the following markup, what is the best BEM approach?
This?:
<footer role="footer">
<footer class="footer__inner">
<div class="footer__left">© Some text</div>
<div class="footer__right">Some text</div>
</footer>
</footer>
OR this?:
<footer role="footer">
<footer class="footer__inner">
<div class="footer__inner__footer__left">© Some text</div>
<div class="footer__inner__footer__right">Some text</div>
</footer>
</footer>
Or none of them are right and you know a better way?
Thanks
You want to have clean reusable blocks. Ask yourself which part you might want to reuse.
Multi level nesting of blocks are frowned upon. And that's for a good reason. In case of reusability there should only be one block as root reference. Everything below that one block is, from a bem syntactic point of view, simply an element of that block. Not a sub-block, not a sub element, but only an element.
So, BEM doesn't care about your HTML structure. It's much more a question of what purpose a block or an element has.
I can't really tell from your example what the purpose of your nested footers might be, but it looks to me as if you consider the role attribute of your outer footer element as part of BEM-naming. But it's not. Keep in mind the idea of separation of concerns. role="footer" is HTML semantic. You should not use it as BEM naming reference because you might want to change that HTML attribute one day and then your BEM semantic would go up in smoke.
So, here's what I would do.
Let's say you want your outer footer to be the reusable element then you might want to name your classes like this (just as an example):
<footer class="footer" role="footer">
<footer class="footer__textbox">
<div class="footer__text footer__text--left"> <!-- left as modifier -->
<div class="footer__text footer__text--right"> <!-- right as modifier -->
</footer>
</footer>
Now you can take your footer and use it in any appropriate section of the page and anyone reading your code can get grasp an idea about the purpose of this css structure.
First variant looks fine for me.
Second is wrong as you shouldn't reflect DOM structure in class names. See https://en.bem.info/methodology/faq/#why-does-bem-not-recommend-using-elements-within-elements-block__elem1__elem2
Markup suggest by LongHike is also good.
My client is a retail store with an online boutique on Magento. I'm implementing Schema.org in Microdata.
The problem comes from the fact that his prices are different depending on the closest city from the user. What "offer" elements do I use in order to set things straight with machines?
My fear is that Google could show the wrong price in the SERP. I don't want to deceive users!
A single Product can have multiple Offer items (via the offers property), exactly for such a purpose.
In the Offer item, you use properties that describe in which situation (for whom, when, etc.) the offer is valid. For location-based offers, the eligibleRegion property can be used:
[…] the geo-political region(s) for which the offer […] is valid.
(With the ineligibleRegion property you can list for which location the offer is not valid.)
So in Microdata it could look like this:
<article itemscope itemtype="http://schema.org/Product">
<h1 itemprop="name">Product 1</h1>
<section itemprop="offers" itemscope itemtype="http://schema.org/Offer">
<h2>Offer 1</h2>
<div itemprop="eligibleRegion" itemscope itemtype="http://schema.org/City">…</div>
</section>
<section itemprop="offers" itemscope itemtype="http://schema.org/Offer">
<h2>Offer 2</h2>
<div itemprop="eligibleRegion" itemscope itemtype="http://schema.org/City">…</div>
</section>
</article>
The documentation for Google’s Product Rich Snippet doesn’t mention a case where a Product has multiple Offer items (except for the different case of AggregateOffer), so it’s unclear if a Rich Snippet can be displayed in such a case.
I try to study a Bootstrap 3 last three months.
All fine, but I would like to put in my navbar the additional image (in right side of it).
In my opinion, to insert a picture directly in HTML code like:
picture
- bad idea, and I created a with a background picture, specified through CSS, but the picture does not appear on the page ...
How can I do it?
And possible whether to do it at all?
<nav class="navbar navbar-default">
<div class="container-fluid">
<div class="navbar-header">
<a class="navbar-brand" href="#">
<img alt="Brand" src="...">
</a>
</div>
</div>
</nav>
Follow this guide
http://getbootstrap.com/components/#navbar-brand-image
To have an additional image on the other side of the menu, you just need to put it as part of the link menu. See example:
http://jsbin.com/mupobo/edit?html,output
I am trying to get my anchors of thumbnails to open to a different page but at the specific element. I don't think it is working as there is a jquery plugin on the page that the elements exist on and I can't find a way to target them. When you click on a image it opens on the first in the sequence but not on the image requested. How can this be solved?
Please see my page here http://i-n-t-e-l-l-i-g-e-n-t-s-i-a.com/melissafranklin.com/index.html
The href attribute of the <a> tag should match the src attribute of the <img> tag
Use this:
<a href="images/paintings/7copy.jpg">
<img src="images/paintings/7copy.jpg" alt="">
</a>
Instead of this:
<a href="paintings.html">
<img src="images/paintings/7copy.jpg" alt="">
</a>
When I do this...
<li>
<a href="#">
<img src="#" width="#" height="#" alt="#" />
<ol class="#">
<li>#</li>
<li>#</li>
<li>#</li>
</ol>
</a>
</li>
It renders it in Firefox like this...
<li>
<a href="#">
<img src="#" width="#" height="#" alt="#" />
</a>
<ol class="#">
<li>a href="#">#</a></li>
<li>a href="#">#</a></li>
<li>a href="#">#</a></li>
</ol>
</li>
Seems to render properly in Webkit. Any ideas?
Although HTML5 now permits <a> elements to contain block-level elements (e.g. ol), Firefox's parser traditionally didn't accept that, instead converting them into a sequence of separate <a> inside the block level elements such that they only surrounded inline level elements, which is what you see.
Because Firefox was the only one of the major browser makes that did that, the Mozilla people accepted the HTML5 change, agreed to alter their parser to permit the <a> element to wrap block content. (It's just one of many parser changes for HTML5, although it seems to be possibly the most prominant one)
That change has happened in Firefox 4, so you won't see the problem there, but Firefox 3.x still uses the old behaviour.
Workarounds, include using a <div> with an onclick attribute instead of the <a>, and using JavaScript to wrap the block in an <a> element, but there's no non-JS solution. Given that (a) the page should still be usable as is, and (b) that Firefox 3.x should die out in the not too distant future, one reasonable option is just to accept the quirky Firefox 3 behaviour for now.
The <a> tag has a default style of display:inline; which makes it unsuitable for containing block level elements.
However, you can get around the problem by changing the display property of the <a> element to either block or inline-block, depending on how you want it to display.
(I note that you're using HTML5, so you'll be fine. Be aware that in xhtml, it is simply not allowed to enclose block-level elements inside an <a> tag. This won't affect you in this case, but it's worth knowing in case you ever have to work with code with an xhtml doctype)