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.
Related
I know it's wrong to put a block element inside an inline element, but what about the following?
Imagine this valid markup:
<div><p>This is a paragraph</p></div>
Now add this CSS:
div {
display:inline;
}
This creates a situation where an inline element contains a block element (The div becomes inline and the p is block by default)
Are the page elements still valid?
How and when do we judge if the HTML is valid - before or after the CSS rules are applied?
UPDATE: I've since learned that in HTML5 it is perfectly valid to put block level elements inside link tags eg:
<a href="#">
<h1>Heading</h1>
<p>Paragraph.</p>
</a>
This is actually really useful if you want a large block of HTML to be a link.
From the CSS 2.1 Spec:
When an inline box contains an in-flow block-level box, the inline box (and its inline ancestors within the same line box) are broken around the block-level box (and any block-level siblings that are consecutive or separated only by collapsible whitespace and/or out-of-flow elements), splitting the inline box into two boxes (even if either side is empty), one on each side of the block-level box(es). The line boxes before the break and after the break are enclosed in anonymous block boxes, and the block-level box becomes a sibling of those anonymous boxes. When such an inline box is affected by relative positioning, any resulting translation also affects the block-level box contained in the inline box.
This model would apply in the following example if the following rules:
p { display: inline }
span { display: block }
were used with this HTML document:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HEAD>
<TITLE>Anonymous text interrupted by a block</TITLE>
</HEAD>
<BODY>
<P>
This is anonymous text before the SPAN.
<SPAN>This is the content of SPAN.</SPAN>
This is anonymous text after the SPAN.
</P>
</BODY>
The P element contains a chunk (C1) of anonymous text followed by a block-level element followed by another chunk (C2) of anonymous text. The resulting boxes would be a block box representing the BODY, containing an anonymous block box around C1, the SPAN block box, and another anonymous block box around C2.
The properties of anonymous boxes are inherited from the enclosing non-anonymous box (e.g., in the example just below the subsection heading "Anonymous block boxes", the one for DIV). Non-inherited properties have their initial value. For example, the font of the anonymous box is inherited from the DIV, but the margins will be 0.
Properties set on elements that cause anonymous block boxes to be generated still apply to the boxes and content of that element. For example, if a border had been set on the P element in the above example, the border would be drawn around C1 (open at the end of the line) and C2 (open at the start of the line).
Some user agents have implemented borders on inlines containing blocks in other ways, e.g., by wrapping such nested blocks inside "anonymous line boxes" and thus drawing inline borders around such boxes. As CSS1 and CSS2 did not define this behavior, CSS1-only and CSS2-only user agents may implement this alternative model and still claim conformance to this part of CSS 2.1. This does not apply to UAs developed after this specification was released.
Make of that what you will. Clearly the behaviour is specified in CSS, although whether it covers all cases, or is implemented consistently across today's browsers is unclear.
Regardless if it's valid or not, the element structure is wrong. The reason that you don't put block elements inside inline elements is so that the browser can render the elements in an easily predictable way.
Even if it doesn't break any rules for either HTML or CSS, still it creates elements that can't be rendered as intended. The browser has to handle the elements just as if the HTML code was invalid.
The HTML and the CSS will both still be valid. Ideally, you wouldn't have to do something like this, but that particular bit of CSS is actually a handy (and syntactically valid but not semantically valid) way for getting Internet Explorer's double margin bug without resorting to conditional stylesheets or hacks that will invalidate your CSS. The (X)HTML has more semantic value than the CSS, so it's less important that the CSS is semantically valid. In my mind, it's acceptable because it solves an annoying browser issue without invalidating your code.
The HTML is validated independently of the CSS, so the page would still be valid. I'm fairly sure that the CSS spec says nothing about it either, but don't quote me on that one. However, I'd be very careful using a technique like this, as while it might render as intended in some browsers, you'd need to test 'em all—I don't see many guarantees being made.
Are the page elements still valid?
“Valid” in an HTML sense, yes; HTML knows nothing about CSS.
The rendering you get in the browser, however, is ‘undefined’ by the CSS specification, so it could look like anything at all. Whilst you could include such a rule in CSS hacks aimed at one particular browser (where you know how that browser renders this case), it shouldn't be served to browsers in general.
I don't know off the top of my head if this validates any rules but I would recommend using the W3C HTML Validator and the W3C CSS Validator to determine that. Hope this is helpful!
If there is a logic you follow and you end up implementing it like this, it's NOT WRONG. Working things are not "wrong" just because they're weird. Yes, it's quite unusual but it HELPS and it's not a mistake. It's intentional. HTML and CSS should serve you, not the other way around so don't ever listen to comments telling you not to do it just because it's ugly.
It's typical to call a solution "invalid" and suggest a long way around the block. Sometimes you can rethink what you did. But there can be many reasons for what you did and they don't consider them.
I do use blocks inside inlines regularly. It's valid and it's working - it's just not necessary in most cases. So what. Remember when XHTML told us to always put quotes around properties (and everyone yelled at you if you didn't!), now HTML5 allows to omit them if there's no space inside. What happened to that last slash after singular tags? "<br />" ? Come on. Standards change. But browsers keep supporting non-standard things as well. CENTER is deprecated; we're in 2013 and it still works. TABLE for vertical centering? Sometimes it's the only way. DIV inside A to make it hover as you planned? Just go ahead.
Focus on important things.
I think, (x)html is valid, css is valid. Is the result valid? Yes, if it is looking in the browser as You want.
No, It is not a wrong choice. We can use as per requirements.
Doing a code review, I noticed that a heading was using <span> tags instead of headings, so I suggested using an <h4> tag, to gain the semantic benefits. The context is a website footer, where there are various lists of links under different headings.
<span>Category 1 Links</span>
<ul>
<li>Link 1 in the footer</li>
<li>Link 2 in the footer</li>
<li>Link 3 in the footer</li>
<li>Link 4 in the footer</li>
<li>Link 5 in the footer</li>
</ul>
The counterargument was that <h4> is a "block-level" element, whereas an inline element was needed. Therefore he didn't think the element should be changed. (And yes, he knows CSS and is familiar with the display: inline; property.)
That sounds absolutely insane to me--goes against everything I always thought was best practice: separation of content and presentation, semantic web, the very purposes of HTML and CSS... yet in trying to formulate a response, I came across this section in the HTML 4.01 spec:
Certain HTML elements that may appear in BODY are said to be
"block-level" while others are "inline" (also known as "text level").
...
Style sheets provide the means to specify the rendering of arbitrary
elements, including whether an element is rendered as block or inline.
In some cases, such as an inline style for list elements, this may be
appropriate, but generally speaking, authors are discouraged from
overriding the conventional interpretation of HTML elements in this
way.
The alteration of the traditional presentation idioms for block level
and inline elements also has an impact on the bidirectional text
algorithm. See the section on the effect of style sheets on
bidirectionality for more information.
So here is the question: does this section make the issue sufficiently vague for there to be valid difference of opinion here, or is it (as I had thought) pretty clear in one way or the other? If this section is open to interpretation, are there any other W3C guidelines that are more concrete?
I don't want to get into opinions on this, I just want to make sure I'm understanding the spec and the W3C guidelines correctly: is there true ambiguity here, or not?
W3C specifications allow display: inline on heading elements. In general, HTML specifications do not restrict what you can do in CSS, and vice versa.
The section Block-level and inline elements that you quoted contains a recommendation (“discouraged”). It is a “should not”, not a “shall not” statement, i.e. not a conformance criterion. The motivation for the recommendation is not given, but generally such ideas are based on the fact that HTML documents may be processed by software that ignores style sheets, or may have author style sheets overridden, or otherwise gives preference to the defined meanings of elements rather than their CSS styling.
Even though the possibility of making a heading an inline element (in the sense of setting display: inline) is not mentioned here, doing so is part of one way of creating “run-in headings” (headings that appear inline at the start of a paragraph, rather than on a line of its own). Nowdays a better way to achieve that is display: run-in, as exemplified in the CSS basic box model WD. The basic point is still the same: it’s OK to turn a heading element from its default display: block to inline-like presentation.
Regarding the specific case presented, I don’t quite see why an inline element would be needed. The next element is ul, causing a line break (and vertical spacing) by default. And if the rendering of the ul is changed to inline with CSS, it is difficult to see why you could not do the same to an element that is logically a heading for the list.
First of all, the quoted section is indeed from the 14-year old HTML 4.01 specification. I do not remember ever reading anything of the type in the HTML5 specs. I personally think it was deemed a good remark at the time but has since been obsoleted by experience. Don't forget that HTML4 was the one to actually properly separate HTML and CSS, and as such contains 'mistakes' like the quoted remark that were later 'corrected'.
In essence, there should not be any implicitly locked relationship between your semantic markup and your styling. Like the hX elements, a div is also a block level element, but only because of the way it interacts with other elements, most specifically which elements it can contain - an inline element must not contain a block element while a block element can contain both inline and block elements, bar explicitly defined relationships such as ul > li and table > tr > td. Essentially the separation of semantics and presentation should be kept so strict that the specifications of the markup language HTML should never even mention the existence of the concept of stylesheets - stylesheets can be applied to anything, not just HTML, and HTML feeds so many more technologies than just browsers.
From a web developer's perspective, you are absolutely right. The block nature of a h4 element merely implies its relationship with potential child elements, and its default representation in the browser's default stylesheet. What the CSS developer then wants to do with his stylesheet is his own choice - for all you care he applies a display:table-cell rule to it if that properly fits his design.
TL;DR: There is no ambiguity, and you should always write your CSS to conform to how you want to display your HTML, not adapt your HTML to the requirements of the CSS. Using a span where an h4 is required is just plain wrong from a semantic (and SEO) perspective.
In my opinion, any typographic convention that you have ever seen in a book or other printed media is fair game for modeling a web page.
For example, I have seen text books with several columns, each with a header, and one could achieve this effect by using display: inline to a h4 tag.
In this example, whether h4 is on a stand-along block or part of a horizontal sequence will depend on the content and how you are trying to communicate ideas to your readers.
Consider how your page would render in a text-only browser that does not support CSS, would the raw ordering of the text make any sense? If so, then, your choice of HTML are probably valid.
On the other hand, if you took table tags and turned them into headers or list items, then you are probably going to get HTML that would not sound right if the page were read by some type of audio browser (think visually impaired people using a page reader).
Let semantics dictate the tags that you use and use CSS to get the visual layout that you need.
I passed a style sheet with the following to the W3C validator and it passed:
a {
display: block;
}
So want to make sure, is it valid markup to use an inline element as a block one?
I know it will work but is it valid?
Thanks
Yes, it's completely valid. And useful too.
One small note (since the above answer is very short), this method of styling normally inline elements as block elements is quite common. For example, when creating a horizontal navigation menu from a list, you'll often see <a> elements styled with display:block in order for the links to be able to take up the full width and height of the parent list item.
Yes it's valid but also you can use inline-block to use an inline element while keeping the block properties.
Yes, it is valid.
There are elements, as you know, that are inline or block by default. But it is completely valid to then go and override this in CSS.
Yes, it is valid. However, if you really don't want to do that, you could wrap the a in a div. That would be useless though, because it is completely valid; that's why the display attribute is there.
The style sheet is valid, in the sense that it conforms to the CSS specifications. This is a purely formal thing. In CSS, the selector a has no special meaning, it is just an identifier; CSS has no information about the meaning of a in HTML, such as being an inline element, and the style sheet could in fact be used to style an XML document, where a means something completely different.
HTML validity, on the other hand, does not depend on CSS at all. It is a formal thing about markup, and style sheets aren’t markup.
Whether it is “valid” in some other, informal sense (like “good practice” or “useful” or “conforming to a style guide”) is a different issue, and a debate issue rather than a technical question. Anyway, it is common usage to set display: block on an a element to make it possible to set its dimensions the way we can do for blocks (e.g., to make a link fill a table cell).
I understand all these tags have different semantic meanings, like article is for a story that stand apart; section is for self-contained part of the page...
They are good and useful tags, in many ways. But, are they just syntax sugar? Because I didn't see any style differences among them. When not applied by any CSS rules, they are just like divs.
Hope some webkit/gecko experts can clarify it on the code level.
Mostly yes. They're not actually divs, but block level elements (subtle but different).
http://diveintohtml5.info/semantics.html#new-elements
There are several new elements defined in HTML5 which are block-level elements. That is, they can contain other block-level elements, and HTML5-compliant browsers will style them as display:block by default.
So yes, for now they are just there for shortening your code length and creating cleaner markup, but that's what block level elements do. If you remove the default styling from a <p> tag isn't it just like a <div>?
I didn't see any style differences among them. When not applied by any CSS rules, they are just like divs.
Each browser has it's own native stylesheet that is applied to the page content. This is why we commonly use CSS reset stylesheets - to normalize everything between different browser stylesheets. Style and content are two completely separate things, what something looks like has no bearing on what it is, therefore you should not be marking up your page based on how you want it to appear.
Some day, it may be common for browsers to add default style to certain HTML5 elements, like some padding on <section>s, but it doesn't matter (and is actually unlikely).
Are they just syntax sugar?
Not at all. While there may not seem to be much of a difference, it allows your content to be understood by, for example, screen readers or search engines, in a more meaningful way.
As Grillz's answer mentions, the elements in question are all block level elements, so in that respect - they are basically rendered like divs, but have semantic value and aren't meant to be used as generic container elements.
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