The Basics of Anchor Positioning
17 points by outervale
17 points by outervale
Great work on the visualizations.
The first problem strikes as a bit odd to me though.
You might need to restructure the HTML, which is not ideal.
Why? If you want to render a node based on the position of another node, why not just make it that node’s child? With the way the author implemented it, you now have multiple elements that are visually clumped together but live in different areas of the DOM. That seems like an anti-pattern to me.
One case is seen in the first example. img is a void element, so it can’t have children. If you wanted to have the category tag presented on the image as it describes, you’d have to wrap it in a non-semantic div. Have 100 of those cards on your page, and now you have an extra 100 divs. It means that you end up with more code than is necessary, and HTML for the purpose of style, not structure, which violates your separation of concerns. Nesting things like that can also mean you end up with items in an order that is confusing for screen reader users.
imgis a void element, so it can’t have children.
In the example code, it’s already wrapped by a div of which it’s the only child. That’s the anchor element. I don’t see an extra cost in moving the tag inside that div.
and HTML for the purpose of style, not structure, which violates your separation of concerns. Nesting things like that can also mean you end up with items in an order that is confusing for screen reader users.
A more coherent structure is exactly what I’m arguing for. By nesting the tag under the image wrapper we get better colocation. I don’t see how that’s not better for users with screen readers. That way the image and the tag are next to each other both visually and structurally.