In real work, I always use EM for italics, STRONG for selection. And SMALL.
I decided to update their knowledge in HTML + decided to look towards the HTML 5
So, xHTML 1.0 strict, as the language of separating flies and cutlets, and allowed the following inline elements related to the text:
I, EM, B, STRONG, BIG, SMALL
here, I came across the first question - why the tags B and I have not been eliminated or at least not become deprecated in XHTML? After all, if you look at the DTD, then about the tag B & I is clearly written:
<! ELEMENT b% Inline;> <! - Bold font ->
<! ELEMENT i% Inline;> <! - Italic font ->
Is the fat content and courses are structural, logical feature? This is clearly a visual feature.
Next, I looked at http://www.w3schools.com/html5/html5_reference.asp and was surprised that the tag BIG somehow removed from the HTML5, and its logical equivalent SMALL - left! Although BIG was even in XHTML 1.0 Strict!
Where is the logic in such permutations? Explain.
There are uses for tags such as i and small that are not presentational but semantic. <small> represents fine print (or legal print) and side comments. And i can be used for text that is traditionally italicized but not emphasized, e.g. book titles, foreign words, and Latin names of species.
As to why <big> has been dropped while <small> hasn't, see this answer.
First of all EM is not for italics, it is for EMPHASIS. STRONG is for strong emphasis. You should never use them for any other purpose. Not according to the HTML 4 specs, XHTML or HTML5.
For presentational effects one should use CSS.
So why has B, I and SMALL been kept in HTML5?
To prevent abuse of EM and STRONG. If you can not use CSS, like on a forum or a wiki, it is better to use non semantic elements, than to abuse semantic ones. As in our comments for Stackoverflow, where I suspect em and strong is being abused a lot, thanks to the WYSIWYG editor we are using.
There might be legitimate reasons to use bold or italics besides what is covered by EM, STRONG and DFN. HTML5 defines this as text that should be spoken in different voice or mood, it thus adds a kind of semantic and a legitimate use case. This slight redefinition is controversial.
In lieu of B and I some software and/or users insert style-attributes. That is trading one evil for an even worse one.
The same applies to SMALL as well. It has received a similar use case, where it sort of carries a semantic meaning. It does NOT mean side commments.
BTW, B and I were not deprecated in HTML 4/XHTML 1.
why the tags B and I have not been eliminated or at least not become deprecated in XHTML?
Nothing was deprecated in XHTML 1.0. It was designed to express HTML 4.01 in XML.
XHTML 1.1 only slightly tweaked it.
Next, I looked at http://www.w3schools.com/html5/html5_reference.asp
No. Not W3Schools. Please no.
and was surprised that the tag BIG somehow removed from the HTML5, and its logical equivalent SMALL - left!
The semantics of small have been redefined. It will (if not changed before HTML5 becomes a recommendation) mean "side comments" and not "a reduced font size".
Standards are more politics than logic reason.
Sign up to any w3 mailing list (personal favourite is public-html), sit back and enjoy(?) the reality soap.
I believe Hickson should stick to use "style" for changing font sizes, not using those "big" and "small" tags.
To maintain "small" and remove "big" is just so wrong.
Personally I'm happy with this state — there are some conventions (semantics) around "small print" and that tag works quite nicely for it. If I said "read the small print" in a conversation, that would make sense, but "read the big print" and you'd be thinking "what's 'big print'?" I'm happy to see big go (never use it) and small stay (use it often).
I don't personally use b, finding strong suits my needs there. But there are cases where you want text italicised but not emphasised. If it's emphasis, I use EM. If it's a citation, I use CITE. If it's some other italics convention, I don't want to misuse EM or CITE.
Wikipedia has some notes on when to use italics, and you'll find some notes here on the various HTML tags that could be used with those examples:
http://www.w3.org/html/wg/wiki/Guide/italics#General_Examples
Feel free to debate any or all examples. It was just my stab at it. Some are straightforward (e.g. use of EM), others are somewhat ambiguous. I prefer to use I for italics rather than choose (a) EM, where that would be misuse or (b) SPAN with font-style italic, which carries NO semantic meaning.
The fact is there are semantics attached to use of italic test (in English at least) and HTML does not provide custom elements to deal with all of them, nor does it need to imho. I is a suitable middle ground.
And for anyone who dislikes using it, you never have to! It's not mandatory :)
I think, part of the answer about <big> and <small> can be found in the spec:
The small element represents side comments such as small print.
Note: Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements.
So basically the semantics of <small> is “side comments” and “small print” (in the sense of disclaimers), which is encoded in HTML by an element named “small”. Maybe the naming should be better, of course.
Why is <small> still in HTML5, but <big> isn’t?
I’d assume <small> is still around because it’s often used for side comments, disclaimers, etc in practice, and there isn’t an existing HTML element suited to the task.
Ian Hickson tried to design HTML5 based on how HTML was used in practice: paving the cowpaths. Thus there are places where logic is sacrificed for practicability. (As it says on the WHATWG blog, “Please leave your sense of logic at the door, thanks!”.
If people are already using <small> for side comments, and aren’t using <big> for anything meaningful (I say “if” as there’s plenty of room to debate and/or research that), then why not enshrine the common usage of the former in the spec, and remove the latter?
Why are <b> and <i> still in HTML5 if they’re purely visual in effect?
<b> and <i> have been redefined to have meaning in HTML5, although it’s a very light form of meaning:
<i>: “a span of text in an alternate voice or mood”
<b>: “a span of text to which attention is being drawn for utilitarian purposes”
They’re now general purpose elements, to be used to distinguish runs of text for reasons not covered specifically by another tag.
Oh, the irony: "fine print" is metonimy for something purely presentational, usually carrying just-as-important information but made harder to read in order to decieve the reader into skipping it. Back in the day of print, it would have been a purely 'CSS' job.
Related
Is it only for screen reader software? because browser renders both type of tags semantic and presentational in same manner.
For example:
for browser for us and for css <strong> and <b> is same. what is the purpose to semantic tag over presentational tag.
is it for screen readers only or it's for better management of code?
if it's for developer strong and b both can produce same result on browser.
Semantic markup allows scripts to understand context. This may be beneficial for screen reader software, but it will also be beneficial for Google and other search bots.
According to HTML specs, <strong> and <em> communicate emphasis, whereas <b> and <i> simply mean "display bold" and "display italic". <b> and <i> should be used in instances where emphasis is specifically not desired. For example, when italicizing a book title.
When search bots are trying to gain semantic understanding of content, it is reasonable to assume they give greater preference to semantic tags.
<strong> and <b> is a poor example in this case, as they are just historically used in a wrong notion. A lot of people started marking everything bold with <strong>, thus destroying the original intent. My phone browser does not make <strong> bold for instance (although the standards suggests making it bolder on screen).
The idea behind semantic tags is to provide some description about the content. So <strong> tag for menu items does not make any sense, while it makes sense to use it to mark part of a sentence as if it was pronounced louder.
With HTML5 semantic tags make a lot more sense, because the content part of the page is clearly outlined, and every tag inside the content is a usable meta data. Search engines are already good at this, but everyone else isn't.
I suggest reading about the whole concept of Semantic Web.
In theory, an audio page reader could read <strong> text in a different, slower, more emphasized tone of voice. It wouldn't do that for just <b> because that's only a typographical hint for graphical presentation. A terminal-based browser could use underlining to reproduce <strong> as an alternative to bold if it's not an available effect on the terminal, where is principle it wouldn't make sense to do that for typographical <b>. A search engine could give more importance to <strong>ed words.
In practice, I don't think any of these examples actually happen — partly, as HeavyWave says, because decades of poor-quality markup have erased any difference between them that could usefully be drawn — but it demonstrates the philosophical difference.
4.2. Element and attribute names must be in lower case
XHTML documents must use lower case for all HTML element and attribute names. This difference is necessary because XML is case-sensitive e.g. <li> and <LI> are different tags.
Source : http://www.w3.org/TR/2002/REC-xhtml1-20020801/diffs.html#h-4.2
But is it also necessary for attributes, properties, values, class and ID for elements.
Upper case and came case should not be used.
What is the benefit of use lowercase for every thing?
What is the benefit of use lowercase for every thing?
There are a few good reasons:
simplifies implementation; you'll only have to look for one variant to match a tag, not all its case-sensitive variants, for example
easier to type, if needed; humans appreciate things that save them effort
one consistent way to do everything
lower cognitive overhead about whether this tag should be capitalized or not
The only real benefit is that your webpage will be XHTML compliant. Browsers are built on the philosophy of "Be conservative in what you emit and liberal in what you accept", and doing crazy capitalization things should not throw any of them (except maybe IE, but that's a whole other battle)
As for theoretical benefits, it saves time/effort for developers, but AFAIK, browsers don't care, so...
Shouldn't both be removed? Or does it mean we should use <small>? Why is <big> removed but <small> is not? What is the problem with <big> which does not apply to <small>?
http://www.w3schools.com/html5/html5_reference.asp
Remember, the tags are meant to be semantic, not presentational. There is such a thing in English as "fine print". This is what the small tag represents. There is no analogous concept of "big print" except for a header, which is already covered by seven other tags.
<small> is used more frequently, for footnotes and such...with <h1>, <h2> and <h3> there just wasn't a use for <big>, hence why it's removed.
The same logic that applies to small (as "fine print") is also just as true for big (as "warning"). Public postings, mostly, but also manuals or even contracts often have things written in bigger fonts that signify [so... semantics!] a warning.
It's not the same as emphasis, which has a meaning in context, but rather "whatever you skip in this text, this part you should read because it's not the usual blah blah but something with immediate and important consequences"
That's why I think big and small should both be out or both in.
Some purely presentational tags managed to slip through into the spec before but the 2 standards bodies have finally reached a concesus to remove all purely presentational tags in favour of using CSS. If something has no semantic value and is purely for visual apearance - it does NOT belong in the markup - it belongs in a stylesheet.
Does it matter <strong> in <em>
<p><strong><em>Some text</em></strong></p>
or <em> in <strong>?
<p><em><strong>Some text</strong></em></p>
Which is semantically correct and more accessible?
Update:
How screen reader would behave in both situation?
Syntactically correct but not semantically correct. <strong> is an "higher order" form, so to speak, of <em>. If you're looking for the effect of <b> and <i>, use CSS. Remember to not choose elements because of how they look but what they mean.
Both ways you have listed are perfectly correct markup-wise, as long as you're not mixing up the order of the closing tags. This would be incorrect:
<p><em><strong>Some text</em></strong></p>
If you care about semantic meaning, you should avoid having both em and strong on an element.
Strong: Renders as strong emphasized
text
(via)
If you care about valid HTML, both solutions are fine and valid.
According to w3 strong is strong emphasis. That means that em and strong should not be used together semantically as the strong is already an em.
If you believe that strong emphasis should be bold italic I think you should just add a css declaration in which you style the strong as bold italic.
In a visual effect perspective, it doesn't matter.
In semantic meaning, it matters since you're using emphasis and strong emphasis in the same element (Some text). It's the same as using h1 in some places just because you want big texts and not because they're titles.
EM: Indicates emphasis.
STRONG: Indicates stronger emphasis.
Source
The presentation of phrase elements
depends on the user agent. Generally,
visual user agents present EM text in
italics and STRONG text in bold font.
**Speech synthesizer user agents may
change the synthesis parameters, such
as volume, pitch and rate accordingly.
So beware. Use CSS to acomplish visual effects, not markup.
In (X)HTML5 the definitions/meanings are:
em: represents stress emphasis of its contents (changes meaning of sentence)
strong: represents strong importance for its contents (doesn't change meaning of sentence)
So these elements can be used together in principle.
To get an idea, think of reading a text out loud (depends on language, though): em might change the intonation (stress), strong might increase loudness.
I think semantically it makes no difference if you use <strong><em>foo</em></strong> or <em><strong>foo</strong></em>; at least I couldn't find anything related in the specification.
See list here:
http://www.w3schools.com/html5/html5_reference.asp
like <b> , <i>, <br>, <hr>, <small>?
Is it means no cons to use these? But what about content and presentation seperation?
Two reasons come to mind:
Because some people (not me, here is a primer about this opinion and here are the WHATWG FAQ about this) don't think of them as presentational. They argue, that <b> has semantics of its own, for example, where <strong> is not right and the text should be bold anyways (IMHO therefore we have <span>)
Because HTML5 has a pragmatic and backwards compatible approach: What worked in HTML4 should work too in HTML5. They argue, that this is why XHTML2 died.
First have a look what WHATWG says about it (this is also mentioned in the answer to the related question cited above).
It is said (as I thought, too) that <strong> and <em> provide an emphasis when using a screen reader, but according to this article by Harry Roberts, it turns out that in practice screen readers don't accentuate text marked this way.
And last, read the spec about <b> (it's already mentioned in the FAQ in the first link, above):
The b element represents a span of
text to be stylistically offset from
the normal prose without conveying any
extra importance, such as key words in
a document abstract, product names in
a review, or other spans of text whose
typical typographic presentation is
boldened.
and <i>:
The i element represents a span of
text in an alternate voice or mood, or
otherwise offset from the normal
prose, such as a taxonomic
designation, a technical term, an
idiomatic phrase from another
language, a thought, a ship name, or
some other prose whose typical
typographic presentation is
italicized.
Likewise, have a look at <small>, <hr> and <br> (there are examples there, too.)
They have also redefined the meaning and semantics of several of these elements. They realized the need for an element that does something like <b> and there was already an element, so they kept it, and preserved backwards compatibility, instead of introducing something new.