This question already has answers here:
What are alternatives to the span-element? [duplicate]
(3 answers)
Closed 9 years ago.
Here is an example.
<span id="s1">Hello</span>
<span id="s2">world</span>
<span id="s3">this</span>
<span id="s4">is</span>
<span id="s5">a</span>
<span id="s6">sentence.</span>
Basically, I have a script that separates words of a sentence into a span. Is there a better approach of doing this? Perhaps an alternative to span that I don't know about? I thought of using something like <u> because it is short, then removing default underlining. Also <p> wont work because it is a block element.
Any ideas?
For semantics reasons, I'd advise against using other elements, unless there's some real need for you to have shorter element names. <span>s are semantically neutral elements, so they'd be ideal for this situation.
This is probably exactly what you should be doing if you really need to style each word differently. It's a meaningless tag used to group inline elements (in this case, words).
The span element .. doesn't mean anything on its own ..
The span element is the only element in HTML that has been defined as not meaning anything as such, so it is the element to be used when you wish to make e.g. a word an element in order to manipulate it, without assigning any meaning to it.
However, an a element without an href attribute is also “semantically” empty and with no default rendering rules. Some people have used <a id=foo>...</a> instead <span id=foo>...</span>. However, some programs may process such an a element in some special way (as if it were link-like anyway), and people may write style sheets in a manner that expects all a elements to be links. So such use of a is risky with no benefit beyond shortness. It also makes the source code less legible, since such use is not common.
In practice, you could, up to a point, use a custom tag, like z (with document.createElement('z') in JavaScript to make old versions of IE treat it as styleable). Browsers would treat it as unknown element, letting you handle it in scripting and (with the caveat) in CSS. But imagine what happens if some future version of HTML, or HTML as recognized by some browser, contains an element with the name you selected, with some fancy meaning and effect (like “don’t display this element” or “blink this text”).
I would agree with the answers Nightfirecat and imjared posted. <span> is probably the best element to use in this case as it denotes a neutral inline element.
However, if you really had to stretch a hack, you could try <em> since you are emphasising each word in its own way.
Related
I am working on a website where users can post comments. I intend to use the <ins>-element herefore. When comments are inaccurate, they will be marked as deleted using the <del>-element.
My first question is whether I use the semantics of these elements correctly?
It surprised me when I saw at W3C that these two elements can contain block-level-elements inside it since that is usually not the case for text-elements who are set to display: inline; (cannot have a width, height etc.). I checked the computed browser value which is definately display: inline; for both <del> and <ins>.
So my second question is how the browser makes this special behavior to work? (Or is it even special? - am I missing something?)
Try not to confuse styling (CSS) with the HTML content model. These are deliberately separate and orthogonal concepts. The only link is that some HTML elements have a consistent default styling.
Although ins and del could be used the way you describe in HTML4, HTML5 makes this separation much more distinct, because it does not use the terms "block" and "inline". These terms are left to CSS. HTML5's content model uses separate categorization, including "flow", "phrasing", and important in this case, "transparent"
The content model is used to assist a document content's meaning. But browsers do not care about the meaning, only how to render it.
CSS provides clear rules about how to render block elements inside inline elements, completely regardless of HTML's content model restrictions. See this answer: Is it wrong to change a block element to inline with CSS if it contains another block element? .
So, no the behaviour isn't "special", and browsers do not have to do anything except use the normal CSS rules to handle it.
As for your first question, it's hard to tell whether "inaccuracy" should imply use of <del>. If the commenter intends to withdraw that inaccuracy, then <del> would be appropriate, otherwise probably not.
This question already has answers here:
Should I use <i> tag for icons instead of <span>? [closed]
(7 answers)
Closed 9 years ago.
If you review the examples for font-awesome, you will see that they consistently use the i element. I would have thought that the span element would be a more appropriate choice, since the i element was intended to modify a "span of text.", but what I want to do is place a glyph on the page, not modify existing text.
You could make the case that the span element was also intended to modify a span of text (hence the name), but the W3C definition leaves it wide open--simply stating that span "can be useful when used together with other attributes."
However, my question is not focused on the semantics of the two tags, but on the user experience implications of one tag over the other. In my testing, the span works just as well as i. Are there any concrete reasons why one is preferable over the other? Examples of concrete reasons include:
One element being handled reasonably by accessibility software (e.g., screen readers), and the other not.
User agent support (e.g., one element behaves consistently across user agents, the other doesn't).
I've never experienced a difference in user experience between the i element or a span with a css style that makes the text italics.
The reason why you might want to prefer the span element is just semantic (separation of content and style).
This question already has answers here:
Can you target <br /> with css?
(16 answers)
Closed 7 months ago.
Is the following valid HTML?
<br class="something">
As an HTML element I can't see why it wouldn't be, but I don't think I've ever seen it in use.
Yes.
See the specification.
The class attribute applies to "HTML Elements" (which includes br elements).
One application I can think off is adding using it with pseudo-elements, such as :before or :after, for instance adding some text beneath a horizotal line:
hr.something:after { content: "Some text" }
Yes, is valid.
Specification tells that br accepts global and event attributes, and class is a global one.
Note that if you target HTML4 and below, there's an specific attribute for br named clear, which defines where to put the new line, as stated here, but now is deprecated and unless your DOCTYPE lets you, you should not use it anymore.
Yes, it's valid statement. you could use something like.
<br style="height: 100px; margin-top: 10000px;">
But instead using div element is recommended.
Yes you can, from the w3c specification : http://dev.w3.org/html5/markup/br.html
<br> element can make use of global attributes, and class is one of them.
It is valid in HTML 4.01, because the class attribute is allowed for the br element. It is also valid in HTML5 in HTML serialization, because the class attribute is allowed for all elements. It is not valid XHTML without a matching </br>.
Yes, you can add a class attribute to a <br> element. id as well if you want.
Sure, it's valid. A useful example would be if you wanted to visually add a little space after a line-break, without ending the paragraph. Or perhaps apply a background image. All sorts of styling options.
a br tag doesn't produce a CSS box and hence little can be done with it.
Only practical case is clear. i believe drupal used it at some time. interestingly CSS 1 spec. refrained from doing anything to br. http://www.w3.org/TR/REC-CSS1/#br-elements. no doubt applying some css on it doesn't invalidate the code but will cause little effect.
this https://stackoverflow.com/a/899359/1043824 is a good discussion on the topic.
For poetry in single line lyrics you can use br class="hanging" to cause the line to wrap only on a narrow screen such as a phone, but not on wider widths, thus preserving the line breaks of the poet, which really really matters to them, while still allowing text to flow freely, which matters to me
It does come handy when you want to omit the linebreak.e.g in a Headline when having a responsive layout and certain breakpoints.
Note: I am NOT talking about the display - I understand why they have different defaults. I'm talking about the functional differences between blocks and inline elements, esp. in regards to things like nesting
I've been told time and again that HTML is about describing content, what things do and what things are, not what they look like (beyond default stylistic elements associated with tags, that can be changed).
As such, it seems like the division between "block"-level tags and "inline"-level tags (not the display of those tags, but the inherent difference in those tags), something that trips up and complicated a great many neophyte and even more experience page designers, is arbitrary and... seemingly against principle, if you would. This sort of behaviour seems like something that should by controlled stylistically, not exist as a built-in element of a block. And in some ways, it IS controlled stylistically - we all know there is CSS that can make a span look like a div, and vice-versa.
So what is the point of having the functional distinction between blocks and inlines? Why aren't they just like any other nested element? Why isn't everything a "block" with "inline" elements simply set to "display: inline"? Is it just for, say, backwards compatibility, or is there a benefit to this seemingly arbitrary division that I'm just not seeing?
Note, this might be better as a community wiki question, since it's unlikely to have a single clear answer, but I'm not exactly sure on the details.
As an example, from what I understand, the following would be invalid html:
<label style="display:block">
<h4>Name</h4>
<span class='sub'>Whether legal, pseudonymous, or made up</span>
<input id="name"></input>
</label>
Why?
Why isn't everything a "block" with "inline" elements simply set to "display: inline"?
Well, it almost kind of is; just the inverse. Rather, everything is "inline" with "block" elements set to "display: block".
But that would be really annoying, if for every page you create, you need to tell it that div tags should be treated as block elements. So for that reason, default styles are assumed, best illustrated at http://www.w3.org/TR/CSS2/sample.html
This question already has answers here:
Which is more correct: <h1><a>...</a></h1> OR <a><h1>...</h1></a>
(9 answers)
Closed 8 years ago.
I'm wondering which of the following two orders is semantically correct in HTML:
1. <h1><a>Header</a></h1>
2. <a><h1>Header</h1></a>
<h1><a>Header</a></h1>
<h1> is a block-level element and <a> is not, it is syntactically invalid HTML to have block level elements inside inline elements (at least until HTML5) which is how the other way would be.
This answer on a duplicate question is better than mine: https://stackoverflow.com/a/7023551/20578
But, for posterity:
Semantically, there’s no difference. Remember, “semantic” just means “related to meaning”, and meaning is just something agreed between humans (because computers don’t natively do meaning, that’s a human brain thing). No-one’s got time to agree that one of these virtually identical options means something different to the other :)
Surprisingly, they’re actually both valid as well, as of the current HTML spec, because <a>’s content model is defined as “transparent”, i.e. the same as its parent.
See:
http://www.pauldwaite.co.uk/test-pages/5341451
And:
http://html5.validator.nu/?doc=http%3A%2F%2Fwww.pauldwaite.co.uk%2Ftest-pages%2F5341451%2F&showsource=yes
(That assumes that <a>’s parent can have an <h1> as its child)
However, it’s not valid under previous versions of HTML:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.pauldwaite.co.uk%2Ftest-pages%2F5341451&charset=%28detect+automatically%29&doctype=HTML+4.01+Transitional&group=0
From a semantic perspective: both (or neither).
(From a structural perspective, OTOH, before HTML 5 an anchor cannot contain a heading, and since browsers aren't all HTML 5 capable yet you should avoid the new form of the construct where possible)
If you are creating a link target, then <h1 id="target_name"> is preferred to <h1><a name="target_name"> anyway.
If you are creating a hyperlink, then having the most important heading on the page link somewhere else is somewhat dubious from a semantic point of view.
I'd say <h1><a>, because <h*> are block elements and <a> is inline element, so it seems more natural to keep the inline element inside a div block, not the other way round.
The header should be first in my opinion but I doubt that search engines would really mind what way round they are, inside the H1 just seems cleaner to me...
Since h1 does not directly correspond to a viewable object they both are correct.