from an accessibility point of view: is it o.k to close a cite tag with a footer tag inside the blockquote like it is shown in this example https://www.thewebmaster.com/html/tags/examples/blockquote/blockquote-tag-footer-element/ or maybe 'figcaption' is more recommended? What way is the most suitable for accessibility and screen readers when creating blockquote?
I've been looking at many articles and found them contradict each other and not clear enough
The spec for blockquote gives you some guidance. It specifically says:
Attribution for the quotation, if any, must be placed outside the blockquote element.
In your webmaster example, the attribution is inside the blockquote.
The third example in the blockquote spec uses figcaption (outside of the blockquote), which you had considered. That feels like the best solution for accessibility.
In my opinion, the footer solution isn't appropriate as it doesn't convey the footer semantic. You are exposing in the accessibility tree two sentences inside the blockquote, without separating semantically the quotation and the information on the caption.
I prefer the solution with figcaption.
Related
I have 3 testimonials that I'm going to use in a website I'm working on. I've read up on block-quotes and I believe that this is the tag best suited for them.
Here is a basic blockquote I found on a forum:
<blockquote>
<p>Pellensque.</p>
<p>Pellentesque.</p>
<p class="credit"><cite>Name</cite>, Title</p>
</blockquote>
Is it semantically correct to use the cite tag to state a person's name and title?
I read that its intended use is to point to the original URL source of the quote.
Also, when inspecting some site's html, I found one that used an h3 for the quotation and h6 for the name and title. Is this in line with best practice?
Or is it better to adjust the text purely in CSS with line-weight and other properties?
I read that its intended use is to point to the original URL source of the quote.
That would be the cite attribute of the <blockquote> element. See here in the HTML5 spec. What you're looking at is the <cite> element, for which marking up the title or author (as demonstrated) of a quotation is appropriate.
Also, when inspecting some site's html, I found one that used an h3 for the quotation and h6 for the name and title. Is this in line with best practice?
If the headings are part of the quotation, then marking up those headings with the respective h elements is fine, as you're reproducing the headings as-is. However, a citation is not a heading, so using a heading to mark up a citation is inappropriate.
Other than that, the <blockquote> element is ideal for marking up testimonials.
In the end I used this HTML markup.
<figure class="rocking-quote">
<blockquote>
<p></p>
</blockquote>
<figcaption>Name, Position</figcaption>
</figure>
Here is the link to a AListApart article I found that really helped:
http://alistapart.com/blog/post/more-thoughts-about-blockquotes-than-are-strictly-required
And here is what the WHATWG "cite" element Living Standard has to say about the "cite" element.
https://html.spec.whatwg.org/multipage/semantics.html#the-cite-element
What I got from these sources is basically that the cite element must represent the title of a work and an author's name does not qualify as one.
Also, I can't just use a "p" tag to cite the author after the blockquote, because what's contained in the "p" tag has nothing semantically that lets a machine know that they are related.
So, the result is a wrapping figure tag with a "quote" class that denotes the type of figure it is, and a corresponding "figcaption" tag that allows for captioning the figure with the author's name and position (job).
If anyone has any suggestions or thoughts please share.
On my page I have few blocks (div) that have the same style regarding background and border (menu panel, info panel, footer panel, ...).
Now I would like to write that style only once and not repeat it for every panel. Yet I don't see any comfortable way of doing that.
One approach I investigated was to introduce a dedicated class (for example panelClass) that would capture the common panel styles. Then in (X)HTML I would just add that class to every element that is supposed to be a panel.
But this doesn't feel right. After all I would be "revealing implementation" in the (X)HTML. I'm no longer able to transparently change things easily because that requires modification of the (X)HTML.
Not to mention that it introduces issues with order of the classes (and thus order in which CSS attributes will be overwritten if needed).
EDIT: (an extended explanation for kolin's answer)
By “revealing implementation” I meant that the (X)HTML (“the content”) is much more strongly connected to the CSS (“the presentation”) than I would like them to be. Maybe I’m pursuing an unreachable ideal (maybe even an unreal or a dummy one!) but I’m trying to keep “the content” separate from “the presentation”.
Thus having a class menu isn’t bad because it describes “contents” not “presentation”. While using instead (what I understood from the cited articles and few others on that site) classes like menu box bordered left_column is bad because it mixes presentation with contents. Once you start adding such classes you might very well add that CSS directly to style attribute. It sure would be much more work and an unmaintainable result but conceptually (when regarding contents-presentation separation) it wouldn’t make a difference.
Now I do realize that in real life for real pages (rich and nice) it is virtually impossible to keep contents entirely separate from presentation. But still you may (should?) at least try to.
Also just look at the “But” in the end of the article The single responsibility principle applied to CSS. In my opinion the island class he used is already presentational because it does not describe contents. It describes how to show it. And that is immediately obvious once you see how widely he used (or might have used) that class on elements having nothing in common as regarding contents.
END EDIT
Another approach was to use selectors grouping. So I would have something like:
#menu, #info, #footer {
background: /* ... */
border: /* ... */
}
This avoids the need to modify (X)HTML. But still causes order issues. And also makes it hard to group styles logically. Especially if they are distributed among many files.
I think that what I really would like to have is to be able to name a group of attributes and just import them somehow in selectors. Something like #include in C++ for example. Is there any way to achieve this? I doubt it but maybe...
If not then is there any other method?
Using classes to define styles is the correct way to do it.
One approach I investigated was to introduce a dedicated class (for example panelClass) that would capture the common panel styles. Then in (X)HTML I would just add that class to every element that is supposed to be a panel.
For me this is exactly the way I would do it.
But this doesn't feel right. After all I would be "revealing implementation" in the (X)HTML.
is there a security problem with revealing implementation?
A few selected posts from Harry Roberts :
http://csswizardry.com/2012/04/my-html-css-coding-style/
http://csswizardry.com/2012/04/the-single-responsibility-principle-applied-to-css/
http://csswizardry.com/2012/05/keep-your-css-selectors-short
I find his style of using CSS eye opening, and it may help you
update
Following on from your update, I agree with you that you should try and seperate structure from presentation, although there will be times where we can't quite manage it. Whether it is fully possible or not, i don't know.
I partially disagree about the island class, the padding property to me kind of hovers over the border of structural and presentational. structural because it alters the layout of whatever element it is applied to, presentational because the padding alters how it looks on the page.
in an ideal world you should never need a class attribute that encompasses menu box bordered left_column, because you would write a couple of classes that seperate out the structure and presentation.
thinking about your case I might create a panel class
.panel{
margin:10px 0;
padding: 10px;
display:block
}
and a panel-display class
.panel-display{
background-color:#1111e4
}
.panel-display > a{
color:#fff
}
in this way I could just play with the presentation without affecting the structure of the site.
(n.b. I'm not sure if this helps you in anyway!, it just seems logical to me)
Sometimes when I see a website I like or sites from respected people, I see the source codes and try to understand them (as we all do).
On Jeremy Keiths site he uses the following code:
[role="navigation"] a {
font-weight: bold;
text-decoration: none; }
I have never seen this before, and a few other times I saw code (which can be considered a "trick") that I had never seen before.
Other than asking what the above code means, my question is - is there any documentation, book or blogs that go through to learn about the advanced/less known CSS "tricks"?
The above targets elements that have a role attribute, such as:
<div role="navigation">
...
</div>
A class would make sense here too, but it's just another way of doing it. Attribute selectors are a standard part of CSS2, but at the time IE6 didn't support them so it hasn't been used much until recently.
There are many other such selectors that have been around for a long time but couldn't be used due to limitations imposed by IE. See Quirksmode for more examples.
That is a CSS attribute selector. It's saying "All <a> tags that are descendents of an element that has an attribute of role with a value of navigation should be styled in the following way ..."
He's using it for accessibility principally, and for styling only secondarily.
If you are looking to learn some of the newest things about CSS, I'd recommend css3.info and css3please.com. The first is a great source of examples of new tricks, and the second one lets you play with the new stuff in the browser. Other than that ... I've found that the best way to learn is to answer questions here (looking things up when you are not sure) combined with reading -- Eric Myers, Paul Irish, Quirksmode -- all of these are good resources for learning things that are new to you.
In this example, the <nav> is wrapped in a <div> and then then assigned a navigation role. The same can be achieved with just
nav a {}
A lot of sites seem to mix a "little" HTML5 with XHTML. I really don't see a reason why they don't use HTML5 "completely". The whole point of HTML5 is to be more semantic and to write less code that's more meaningful.
Some useful links.
http://html5doctor.com/
http://htmldog.com/
http://desizntech.info/2009/03/discover-the-cool-of-css-25-advanced-css-techniques/
As of now, you'll need a bit of javascript to make HTML5 elements work in IE. These links should help
http://html5doctor.com/how-to-get-html5-working-in-ie-and-firefox-2/
http://remysharp.com/2009/01/07/html5-enabling-script/
Role is a new XHTML2 attribute.
http://www.wait-till-i.com/2009/05/16/pitching-a-hack-or-a-product-dos-and-donts/
http://www.w3.org/TR/2008/WD-xhtml-role-20080407/
Cool, which browser did it work in?
http://www.w3.org/TR/2001/CR-css3-selectors-20011113/#selectors
E[foo="bar"]
an E element whose "foo" attribute value is exactly equal to "bar"
I'm actually coding a website and a doubt came to me. I have a list of images (it's an artist portfolio, so it should be images), some of which have a "Featured" badge. Is it semantically correct to wrap the img into a strong tag instead of using a class="featured"? Will it add strong emphasis to the image?
Reading the W3C spec., it refers strong and em as text-level semantics, but I'm not sure what happens with media like img.
Thank you so much.
I think that's fine. You may already be doing this, but you need to make sure that the ALT text describes why the images has been emphasized. Eg alt="man with dog - featured"
I think that it would be perfectly acceptable to do this and preferable.
First of all, I think the HTML 4 spec allows it. Question is, can you rely on what browser will do with it. I would not take my chances with that.
But at least, in many browsers you can attach formatting to
strong img {
/* mark up for the featured image */
}
And this should then work for all browser that support it.
I wouldn't use the strong tag on images, I am not sure why it would be preferable since it refers to 'emphasized' text only: an aural user agent may use different voices for emphasis, it would be pointless for images.
Why don't you just use a class?
If I have class names such as "left", "right", "clear" and xhtml like
Continue
With CSS like
.right {
float: right;
}
I know it's not a semantic name, but it does make things much easier sometimes.
Anyway, what are your thoughts?
I don't think that's a very good idea. Now when you (or a future maintainer) go to change your website layout, you'll either have to change .right to {float:left;} (obviously a bad idea) or go through all your HTML files and change right to left.
Why do you want that particular link to be floated right, and the other .continueLink's not to? Use the answer to that question to choose a more descriptive class name for that link.
css is about presentation of the structure of your html page.
Meaning its classes should represent the structure of the document ('article', 'extra-links', 'glossary', 'introduction', 'conclusion', ...).
You should avoid any class linked to a physical representation ('left', 'right', 'footnotes', 'sidenotes', ...), because, as the Zen Garden so clearly illustrates, you can decide to place any div in very different and various ways.
The purists will say don't do it, and the pragmatists will say it's fine. But would the purists define .right as float: left?
It might be advisable to avoid names that are the same as values in the CSS specs to avoid confusion. Especially in situations where multiple developers work on the same application.
Other than that I see no problem. I would qualify the right or left name like this: menuleft, menuright etc.
Being a purist, I say no don't do it. For reasons mentioned earlier.
Being a pragmatist, I just wanted to say that never have I seen website rework that involved pure html changes without css, or pure css without html, simply because both parts are being developed with the other in mind. So, in reality, if somebody else would EVER need to change the page, I bet my salary they will change both html and css.
The above is something that collegue purists around often tend to ignore, even though it's reality. But bottom line; no, avoid using a className such as "right". :-)
.right and other classes like that, certainly makes it quick to write create a tag with a float:right rule attached to it, but I think this method has more disadvantages than advantages:
Often a class-style with a single float:right; in it will lack something, your example wil only float right if the other class rule contains a display:block in it, since an "a" tag is not a block level element. Also floating elements more often than not needs to have width an height attached. This means that the code in your example needs additional code to do what it says, and you have to search in two places when you have to change your css.
I tend to style my html by dividing the page into different div-tags with unique id's, and then styling elements in these div by inheritance like this.
div#sidebar { float:right; width:200px; }
div#sidebar ul { list-style-type:none; }
This makes it possible to partition my css files, so that it is easy to find the css-code that styles a particular tag, but if you introduce .right and other classes you are starting to disperse the rules into different areas of the css file, making the site more difficult to maintain.
I think the idea of having a very generic classes is born from the wish of making it possible to change the entire layout of the site by changing a couple of rules in a stylesheet, but I must say that in my 8 years of website development with 30+, different sites under my belt i haven't once changed the layout of a website and reused the HTML.
What I have done countless times is making small adjustments to regions of pages, either due to small changes in the design or to the introduction of new browsers. So I'm all for keeping my css divided into neat chunks that makes it easy to find the rules I am looking for, and not putting the code in different places to achieve a shorter stylesheet.
Regards
Jesper Hauge
Yeah, semantically speaking it is wrong, but, for example, there are times when I'm positioning images within a block of body copy and I'll give them the class "right".
Maybe "alt" is a more suitable class name.