I have been attempting to dissect some of the css on the behance.net site. I've looked through it in the chrome inspector pretty thoroughly, but some things I just don't understand.
On the top navigation bar, there is text that says "Discover", "Galleries", "Jobs". I notice that "Discover" is a div inside of an anchor tag. I was under the impression that block level elements could not inhabit inline level elements. But this is a pretty professional looking site, and they're doing it. Does it not break in some browsers?
<a class="nav-link" href="/"><div class="nav-text nav-sprite nav-sprite-discover">Discover</div></a>
Thanks!
As per the HTML5 documentation, <a> elements have a transparent content model, which means they're allowed to contain block level elements.
In HTML4 and below, <a> elements were inline elements, which could not contain block content.
If Behance were using a HTML5 doctype, this would be valid (as zzzzBov says, a elements have a transparent content model in the current draft of the HTML5 spec, meaning they can contain block-level elements).
However, as they're using an XHTML doctype, their usage in this context is invalid. It won't break on (most) browsers, but it's not strictly correct and I wouldn't emulate it.
Related
From the W3C standard's definition of pseudo-elements https://www.w3.org/TR/selectors-3/#pseudo-elements:
Pseudo-elements create abstractions about the document tree beyond those specified by the document language. For instance, document languages do not offer mechanisms to access the first letter or first line of an element’s content. Pseudo-elements allow authors to refer to this otherwise inaccessible information.
(My emphasis.)
Why excatly does the document language allow for detection of the first child element (so that :first-child is a css pseudo-class) but not of the first letter (so that ::first-letter is a css pseudo-element)? How should this "document language" be understood?
In essence the question is: Why is there a difference in picking the first element in contrast to the first letter? Why can the document language retrieve one but not the other?
I am not asking to the general difference between pseudo classes and pseudo elements, but rather I am asking specifically about why a first letter is conceptually different from a first child element. Other pseudo elements are less confusing: that ::after and ::before for example are pseudo elements is fairly obvious, as they relate to a "space" that isn't defined in the html structure. But the first letter is, so therefore the question of why such first letter is still treated differently.
The document language refers, in the most typical CSS use case, to HTML. The document tree (as referred to throughout Selectors) refers to the DOM tree that is constructed from the markup.
A pseudo-element is something that is generated based on an existing layout. That is, a layout must first be constructed and rendered based on CSS that's applied to elements in a DOM tree. This cannot be accomplished with the document language, the markup, alone.
You'll notice that the ::first-letter pseudo-element only applies to block container boxes, for example. There's no way to know whether an element (or its descendant) will have a ::first-letter pseudo-element until it's determined to be a block container box (the only kind of box that can directly contain a flow of inline content), and that is determined by CSS, not by HTML. As a more concrete example:
<p>Hello world!
By default, a p element is display: block. This results in a block box, which is a kind of block container box. But even so, this default is implemented using CSS. And if you were to override that default with the following CSS rule:
p {
display: inline;
}
this element then becomes an inline box, and p::first-letter will no longer have any effect on it.
Intuitively, it still seems trivial to determine the first letter of an inline box compared to a block box (or any other type of box), but things get pretty complicated once you have several inline boxes in the same inline formatting context all interacting with one another.
::first-line is much more clear-cut: not only is it impossible to know how long the first formatted line of an element's text is until you format the line, but the contents and length of this line can also change as you resize and/or reflow the element and its contents.
In contrast, a tree-structural pseudo-class such as :first-child matches elements in the DOM independently of the layout. Without having to render anything, the browser can tell right off the bat which of the elements is the first child of its parent. All you need is the DOM tree of elements, which means all the information you need can be retrieved from the document language, the markup. For example, the first child of the ol in the following fragment is always the same no matter what CSS you apply to it:
<ol>
<li>First
<li>Second
<li>Third
</ol>
Well, what the title says.
I really couldn't find any detailed information on it, the MDN documentation is also rather sparse if not useless..
Can you possibly give examples and tips when one is preferred over the other?
(https://developer.mozilla.org/en-US/docs/Web/CSS/::backdrop)
This pseudo-element is a box rendered immediately below the element
(and above the element below the element in the stack, if any), within
the same top layer.
As you see in the documentation you mentioned, it will add a new element between your actual element and the element after.
With ::after you can insert content after the content of your selected element (so the content is still add to the same element), see this example.
Pseudo element after documentation:
Insert content before, or after, the content of an element
Over that, there is a difference in what browsers can render the pseudo elements: Backdrop vs. After. As you can see, today (2016-02-19) you can use ::backdrop only in chrome, opera and android browser.
This question already has answers here:
Is putting a div inside an anchor ever correct?
(16 answers)
Closed 8 years ago.
I'm making a website that utilizes spans with a background-image:(so basically a picture) with a span nested in that that will display text over the picture.
The text and picture spans are both links that would go to the same place. I want my users to be able to click anywhere on the text or picture to navigate away from the page.
Instead of using using two tags that will link to the same thing in the same line of code, I noticed that I can put two spans, both the picture and the text, inside of the same tag and Chrome allows it.. but I don't know how support is on this kind of thing in other browsers.
Here's an example of what I'm doing:
<a href="https://theartofmikeyjoyce.com/">
<span class="cell E4">
<span class="text">MIKEY<br/>
<p>IN THE CLUB II</p>DIGITAL COLLAGE
</span>
</span>
</a>
Now normally I'm aware that anchor tags shouldn't have inline elements so I set display:inline-block' on the span tags. I'm also using HTML5, and the documentation I found on this was vague at best. The code seems to work on all modern browsers I've tested, but is this really canon?
HTML and CSS are two separate things. HTML5 defines which elements may and may not be nested in which other elements, and while it also suggests how they should be displayed, how this display is implemented is specified by CSS.
Changing the CSS display mode of an element does not change where it may appear in an HTML document, since HTML doesn't know how an element is being displayed using CSS (if at all).
In HTML 4, the a element may only contain other inline elements. Note that HTML 4 has its own definition of "inline" and most if not all inline elements correspond to display: inline in CSS, but again, the two languages are separate.
In HTML5, the a element has a transparent content model, which means any element can appear as a child of the a element provided that element can appear as a child of the parent of the a element. So for example, while a section > a can have a div as a child, a p > a cannot, because a div may appear within a section, but never within a p.
These are rules given by the HTML standard, but as you can see they say nothing about whether an inline element can contain inline-block elements. You will find that information in the CSS standard instead.
In summary, inline-block elements are similar to block boxes, except that they are laid inline, just like regular inline elements. That's all there is to it. Assuming your a element is an inline element, browsers should have no problem rendering inline-blocks along the same line(s) as the a element (as its children, of course).
On the other hand, if your a element were to contain block-level elements (i.e. display: block), the behavior, while still pretty well-defined, becomes less predictable thanks to browsers like Chrome.
I think this is what you are looking for.
HTML 5 states that the element "may be wrapped around entire paragraphs, lists, tables, and so forth, even entire sections, so long as there is no interactive content within (e.g. buttons or other links)".
Usually no, but if set to display: inline you should be fine.
I've seen this quite a few times now. When people want to assign a CSS property to the whole window/document, they sometimes do
html, body {
myCSSProperty: someValue;
}
For example, see the answer I accepted here, or see this article.
I am wondering if assigning CSS properties to both html and body is to overcome browser bugs, required for all browsers, a purely psychological thing, a common misconception or misunderstanding of the tags html and body, or something else.
I would be glad if someone could demystify the situation for me, separating the cases where CSS properties need to be assigned to html or body, or both, with specific examples and explanations.
This article has great information about the <html> and <body> tags in terms of CSS. The short of it is this (taken from the top of the article):
The html and body elements are distinct block-level entities, in a parent/child relationship.
The html element's height and width are controlled by the browser window.
It is the html element which has (by default) overflow:auto, causing scrollbars to appear when needed.
The body element is (by default) position:static, which means that positioned children of it are positioned relative to the html element's coordinate system.
In almost all modern browsers, the built-in offset from the edge of the page is applied through a margin on the body element, not padding on the html element.
I have used CSS pseudo-element selectors like many others, mainly just to say I've used them.
But I am racking my brain and struggling to come up with a reason for their place alongside markup.
Take the following example:
<p>Hello</p>
p::after {
content: "*";
}
What is the advantage of using this over using <span> tags?
Am I missing the point of ::before and ::after? Is there some rock solid reason for using them over pre-existing semantic markup?
The CSS2.1 spec says this about generated content:
In some cases, authors may want user agents to render content that does not come from the document tree. One familiar example of this is a numbered list; the author does not want to list the numbers explicitly, he or she wants the user agent to generate them automatically. Similarly, authors may want the user agent to insert the word "Figure" before the caption of a figure, or "Chapter 7" before the seventh chapter title. For audio or braille in particular, user agents should be able to insert these strings.
Basically the purpose is to minimize pollution of the content structure by "content" that is otherwise more suited as presentational elements, or better to be automated.
If you're talking about :before and :after: They're used as presentational elements for cases where adding more elements into the actual document would be mixing structure with appearance. A few cases I've seen:
Bullets in bulleted lists
Quotes around q elements
Stylish shadows
Decorations and the beginning or end of text
These particular pseudo-elements are designed to add “content” that’s actually just a visual aid.
The prime example is adding quote marks around the <q> element, which Firefox does using these selectors in its default stylesheet. Some people also use them to clear floats.
You shouldn’t use them for actual content, despite the name of the CSS content property, as non-visual user-agents (i.e. screen readers) should ignore them.
I’ve never come up with much use for them, although I did once use them to add little Unicode icons to hovered links on a personal site — like you, pretty much just to say I’d used them.
Honestly, the only worthwhile useage is to force elements to have the correct size in the dom. Use this code for example:
<div class="container">
<div>this div is floated left</div>
<div>this div is floated left</div>
</div>
Typically you would have to specify an exact or min height for the .container div. if you were to apply ":after" with some very simple css, any background you applied to the .container would actually show up (in almost every browser) properly, with few to no shims.
.container:after{
content:'.';
height:0;
line-height:0;
display:block;
float:left;
visibility:hidden;
}
Now try that example, applying a background color or image, and you'll see that the .container div always has the appropriate height (which would be the total combined height of the inner contents) even if all the inner html is floated (as is the case in most ul/li css buttons).
I also use an after on every div that I wrap all my content in per html page. This is due to the possibility that all of the content on a given page could be floated, and I want to make sure that my content div always has the correct size/padding with the appropriate background.
CSS3 Pseudo Selectors also include essential ones like :link, :hover, :active, :focus, :first-child, :nth-child. It's impossible to make a useful site without most of these.
As for the less commonly used pseudo-selectors like :after and :before, they're useful in certain cases where the content is dynamically generated and you want to insert something before a specific element or tag.