I have multiple paragraphs of text in an HTML document. Also, at various points, some of the text is wrapped in <h6></h6> tags, which is meant to apply certain font effects. In my CSS, the h6 tag is set to display:inline; so the paragraph keeps going continuously without a line break. This works except for the first instance of h6 on each page it is used: there is always a line break before the first element. Does anyone know why/how to prevent this?
CSS:
h6 {
font-family:'Courier New',Courier,'Nimbus Mono L',monospace;
font-size:125%;
display:inline;
}
HTML:
As expected, not a lot was accomplished (in this plane) over a
five-day weekend when much of it was devoted tot he college
process. However, I'm down to only a handful of HTML-validation
errors. A couple of which are going to be particularly problematic,
dealing with my new <h6>Lytebox JavaScript</h6> I talked about
earlier: to enable Lytebox on an image, you give it a CSS tag
<h6>data-lyte-options</h6>...
The second essence of h6 works fine, but there is a line break before the first.
Heading elements can't be contained inside paragraphs, because inherently they're treated as block-level elements hence browsers break paragraphs when they get to a block-level element like heading.
Your particular HTML gets changed to this by browsers:
<p>
As expected, not a lot was accomplished (in this plane) over a
five-day weekend when much of it was devoted tot he college
process. However, I'm down to only a handful of HTML-validation
errors. A couple of which are going to be particularly problematic,
dealing with my new
</p> <!-- browsers end a paragraph here!!!!! -->
<h6>Lytebox JavaScript</h6>
I talked about earlier: to enable Lytebox on an image, you give it a CSS tag
<h6>data-lyte-options</h6>
...
<p></p>
I found a reference to this fact in HTML specification:
The P element represents a paragraph. It cannot contain block-level elements (including P itself).
And another reference that talks about block-level elements:
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.
Solution?
The problem is that you're using headings as usual paragraph text (with its own style). You should be using SPAN elements instead to make your HTML valid.
If all you'd like to do is to format your text to be displayed as code then you can also use CODE element which should be used exactly for this purpose.
You want the element to be inline and apply special font formatting right?? Then you can enclose them in a 'span' tag
As expected, not a lot was accomplished (in this plane) over a five-day weekend when much of it was devoted tot he college process. However, I'm down to only a handful of HTML-validation errors. A couple of which are going to be particularly problematic, dealing with my new <span>Lytebox JavaScript</span> I talked about earlier: to enable Lytebox on an image, you give it a CSS tag <span>data-lyte-options</span>
span { font-family:'Courier New',Courier,'Nimbus Mono L',monospace;font-size:125%;}
Why not create a unique class and apply it to your <p> tags as needed. You mention some are wrapped in h6 tags to apply styles. That can be done with <p class="onestyle"></p> and yet you can still have <p></p> regular p tags.
Then with your h6, you can float them left instead of using display:inline or do inline-block, just about the same affect with all. Then apply padding margins as you need to all your styles.
Try using CSS selectors to specifically target that instance. Not 100% sure this will fix it, but worth a try.
h6:first-child { display:inline; }
Related
In general, I try to use semantic html to improve accessability. However, I'm working in an existing codebase and noticing that a lot of single-line text used in the layout is placed directly in <div> tags, to avoid the bottom margin that comes with <p> tags.
<div>Team Average is 20%.</div>
Does this have direct accessibility implications, and if so, what are they? Will using <p> tags and adding a style rule to each one to get rid of the bottom margin produce distinct accessibility benefits? (I realize I could just set p elements to have no padding via CSS, but as this is an existing codebase, that isn't an option.)
I also realize I should use more semantic html where possible; this is just in situations where nothing more specific applies.
In my experience, assistive technology will function better, and the page will be more understandable when text is placed in paragraph tags, as opposed to divs.
Divs seem to be treated more like raw text. If the div uses line breaks to simulate paragraphs, then the visitor will be unable to easily skip paragraphs or move between paragraphs without listening to the contents of the entire div.
Using divs instead of paragraph tags is definitely sub-optimal. Whether or not it's a failure of WCAG 1.3.1 is debatable. If it's relatively easy to change this out, it would be better to do so.
W3Cschools said "Any sort of content can be put inside the tag!" (https://www.w3schools.com/tags/tag_div.ASP) and in my experience there's no accessibility issues related to this.
DIV are for a division of space and it's no rules about their content however it's best for design to have html elements inside of if.
If you are concerned about accessibility rules i suggest you to check your website with some tools like the following ones:
aXe
Wave
Google Lighthouse
Valmolà
If it's a single-line text, then it will not be a problem.
If the text has more than 1 paragraph, then you should use <p> tags.
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.
I have read many articles on the display:block property.What it does it make your element behave like paragraph tag or block element to be exact.My worry is that then why don't we just use paragraph tag there since it already is a block level element and we can also use id(once) and class(many times) attributes on it.Similarly on observing many CSS structure i found that on first or second line following is done more often than not.
header,section,nav,figure,..etc{
display:block;
}
Same question why don't just use paragraph tag and useful nomenclature for figures,nav,footer and header inside .Following is my solution
<p class="mainNavigation"> </p>
<p class="MainNavfigures"> </p>
<p class="footer"> </p>
<p class="bodyContent"> </p>
So the whole argument is this "Why to invent more tags when P was already there for us?"
Semantics:
mainNavigation is not a paragraph
MainNavfigures is not a paragraph
footer is not a paragraph
bodyContent is likely one or more paragraphs, with other things too.
...but you've told us in your code that each of these items is a paragraph.
Machines (search engines!) reading code won't know what your class-names mean and will not know to handle your content accordingly.
Humans reading your code will be understandably confused as well.
Yes, feel free to use a tag that already behaves as close as possible to what you want, unless there is a reason to use a different tag. A div tag is often more natural to use as a general-purpose block element rather than p, as the paragraph has margin by default.
Sometimes, there isn't a tag available with both the style and functionality that you need. For example, if you want a link that is a block tag, that doesn't exist. You use an a tag and style it with display:block.
For SEO reasons, you should use some specific elements for certain things. The web crawlers simply expect to find some things in certain elements. There should for example be a h1 tag on the page that contains a headline describing the contents. The h1 element is a block element with large and bold text, and a lot of margin, so often you want to style it to fit into the layout.
What is the difference between <p>, <div> and <span>?
Can they be used interchangeably?
Because I am facing problem that, for <span> margin not working but for the <div> and <p> it's working..
p and div elements are block level elements where span is an inline element and hence margin on span wont work. Alternatively you can make your span a block level element by using CSS display: block; or for span I would prefer display: inline-block;
Apart from that, these elements have specific semantic meaning, div is better referred for a block of content having different nested elements, p which is used for paragraphs, and span is nothing but an empty element, hence keeping SEO in mind, you need to use right tag for right thing, so for example wrapping the text inside div element will be less semantic than wrapping it inside a p
A <p> should contain paragraghs of text, a <div> is to layout your page using divisions and a <span> allows markup to be styled slightly different, for example within a <p>
This is how they should be used semantically, the styling of them however using CSS is up to you.
As a web developer, I can't help but feel all these guidelines are incredibly misleading in the year 2015.
Sure, a "p" tag was at one point designed for paragraph use... but in 100% of my applications, designs, and just day-to-day general development, we've encountered nothing but limitations imposed by the "p" tag... it offers no benefit in today's internet.
I would say yes, "p" is a descriptive element, and for that reason if that's all it did; "describe something", I'd be all for it... but it DOESN'T just describe the content, it straight up ALTERS the content, which while already being a limitation in itself, isn't all it does, it also LIMITS the content. Why anyone in their right mind would purposefully embrace a limiting building block when it comes to web development is beyond me. From a design standpoint it doesn't make sense. From a structural standpoint it doesn't make sense. From any from of DOM manipulation PERIOD, it doesn't make sense.
We've all-together stopped using the "p" tag except where we are absolutely forced to (client WordPress post implementations, silly things like that, for example). There is no excuse as to why we can't describe nearly everything with well-named classes and ID's, so we see zero reason to have to bow to "standards" that add no benefit whatsoever, and in fact HINDER every piece of the puzzle. The "p" tag is of no help to the developer, the end-user, nor to modern search engines. In a nutshell... "p" tag is all but deprecated in even remotely complicated implementations (and with very good reason), don't let the comments of these standard's nazi's control how you display your content!
Even on this very site, a site oriented towards developers at it's core, has at the VERY TOP of it's own page a little pop-in piece that could have used a "p" tag as it contains enough text to run around to a second line, but is entirely captured in a DIV (and only a div, not a div -> p) for a nearly infinite number of reasons... foremost being that today, "p" SUCKS compared to any well described block created from DIVs, that is as-well-described (moreso... I say) as a paragraph "p" with the very descriptive id="blurb".
From Stack Overflow:
<div id="blurb">Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.</div>
I say down with
<p>I suck</p>
and long live
<div class="p">I rock</div>
And yes, I do appreciate our current web standards, and things like <span> still have their place, even offering up abilities to do things with some modern browsers you can't accomplish with a <div> container, but it's just that this one in particular, the broken element "p", as a piece of a restructured and modernized HTML... should have been left in the grave where it belongs... this is a generation of web where paragraphs aren't even paragraphs forever anymore... the blocks literally change... it's just plain outdated and impractical.
As others have answered… div and p are “block elements” (now redefined as Flow Content) and span is an “inline element” (Phrasing Content). Yes, you may change the default presentation of these elements, but there is a difference between “flow” versus “block”, and “phrasing” versus “inline”.
An element classified as flow content can only be used where flow content is expected, and an element classified as phrasing content can be used where phrasing content is expected. Since all phrasing content is flow content, a phrasing element can also be used anywhere flow content is expected. The specs provide more detailed info.
All phrasing elements, such as strong and em, can only contain other phrasing elements: you can’t put a table inside a cite for instance. Most flow content such as div and li can contain all types of flow content (as well as phrasing content), but there are a few exceptions: p, pre, and th are examples of non-phrasing flow content (“block elements”) that can only contain phrasing content (“inline elements”). And of course there are the normal element restrictions such as dl and table only being allowed to contain certain elements.
While both div and p are non-phrasing flow content, the div can contain other flow content children (including more divs and ps). On the other hand, p may only contain phrasing content children. That means you can’t put a div inside a p, even though both are non-phrasing flow elements.
Now here’s the kicker. These semantic specifications are unrelated to how the element is displayed. Thus, if you have a div inside a span, you will get a validation error even if you have span {display: block;} and div {display: inline;} in your CSS.
<p> and <div> are block elements by default. <span> is an inline element.
Block elements start and end with a new line in the browser while inline elements do not. "Inline" means they are part of the current line.
With today's complex web designs the purpose of these distinctions are less obvious but if you think back to the early days of HTML (where these tags come from) where documents were basically embellished text with images, the distinction becomes clearer.
Either way, with CSS you can override basically any property of a tag. So if you want a <span> to behave like a <div> or a <p> then all you need to do is add:
span
{
display: block;
}
With this code, you will be able to set the vertical margins as well as the horizontal ones.
1) div element is designed to describe a container of data.
div tag can contain other elements---div is Block Level
2)p element is designed to describe a paragraph of content---para is Block Level
3)span element Usually used for a small chunk of HTML.---span is Inline
4)block-level elements begin on new lines,
inline elements do not.
5)Most browsers insert a blank line between any two block-level elements.
Ex: There will be blank line between para and para and header and para and between two headers,between a paragraph and a list, between a list and a table,
etc
I more thought that,p and div elements are block level element on the other side, span is an inline element. but when you write p in your code it will take space top and bottom but div behavior not like that. Check out this experiment on JS fiddle:
https://jsfiddle.net/arifkarim/9wcef1c3/
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.