My problem
I am using the tachyons.io framework to style an HTML page. I would like to emphasize a single word in a sentence with italics fonts, without discontinuing the sentence flow by a line break.
The manual
The manual suggests using <p class="i"></p>, but using p adds a line break.
What have I tried
Apart from reading the manual, I tried using an internal p class="i" or class="i". The former broke the sentence with a new line, the latter did not change the word style.
My question
How can I emphasize a single word with italics in tachyons.io, without breaking the sentence with a newline?
Use a <span>: <span class="i"> ... </span>.
(or, alternatively, an <i>.)
Example:
<link href="https://cdnjs.cloudflare.com/ajax/libs/tachyons/4.9.1/tachyons.css" rel="stylesheet"/>
<p>
Only one <span class="i">word</span> is in Italics here.
</p>
<p>
Can also use <i>plain HTML</i> for that.
</p>
Related
I have following MD code for one of my GitHub page.
<p align="justify">
Text Text Text.
</p>
<p align="justify">
**Text** Text Text.
`Text` Text.
</p>
While the first paragraph tag works Okay as there is no Markdown editing done inside it, text inside second paragraph tag is not Formatted as it should be. (No Bold, no quotes)
Why is it so?? And how to use Markdown editing inside paragraph then?
The Markdown rules plainly state:
Note that Markdown formatting syntax is not processed within block-level HTML tags. E.g., you can’t use Markdown-style *emphasis* inside an HTML block.
That said, GitHub Pages uses Kramdown to parse Markdown, and Krandown has a slightly different behavior which gives you more flexibility. In fact, Kramdown's documentation states:
If an HTML tag has an attribute markdown="1", then the default mechanism for parsing syntax in this tag is used.
In other words, do this:
<p align="justify" markdown="1">
**Text** Text Text.
`Text` Text.
</p>
And you will get the following output:
<p align="justify">
<strong>Text</strong> Text Text.
<code>Text</code> Text.</p>
Kramdown is smart enough to recognize that you are inside a <p> tag, and does not wrap the individual lines in new <p> tags, which would be invalid HTML. If you actually want each line to be a separate paragraph, then you should use a <div> to wrap everything. Like this:
<div align="justify" markdown="1">
**Text** Text Text.
`Text` Text.
</div>
Which results in this output:
<div align="justify">
<p><strong>Text</strong> Text Text.</p>
<p><code>Text</code> Text.</p>
</div>
For completeness, it should be noted that GitHub READMEs and Gists do not use the same Markdown parser. Instead they use an extended Commonmark parser, which handles Markdown in raw HTML differently that the two ways described above. In Commonmark, whether the content of a raw HTML block is parsed as Markdown or not depends on whether the content is wrapped by blank lines. In that case, the proper way would be to do this:
<div align="justify">
**Text** Text Text.
`Text` Text.
</div>
However, as GitHub will strip out the align attribute, there isn't any point it doing that on pages hosted on github.com (such as READMEs). There is also the problem that Commonmark is not smart enough to detect that the wrapping raw HTML tag is a <p> tag, and wraps each line in another <p>, resulting in invalid HTML. Therefore, you must use a <div> in that case.
While the use-blank-lines method of telling the parser to parse the contents as Markdown is a more elegant solution that markdown="1", it is only supported by Commonmark parsers, which Kramdown is not. Therefore, as long as GitHub Pages uses Kramdown, you need to follow Kramdown's rules.
I have a bug that results from actual line-breaks in my html markup. I'm trying to find documentation that supports what I'm seeing. This does not have to do with <br> or CSS, but instead the newlines within the actual markup. Basically, this:
<h4 class="condensed-title-wrap">
<span class="condensed-title">Here is the title text</span> <i class="icon-icon-navigation-mobile-arrow-right"></i>
</h4>
Renders differently than this:
<h4 class="condensed-title-wrap">
<span class="condensed-title">Here is the title text</span>
<i class="icon-icon-navigation-mobile-arrow-right"></i>
</h4>
What I'm asking for is language and maybe some documentation that this is true.
The invisible carriage returns and line feeds that occur at the end of the lines count as whitespace (different from non-breaking whitespace such as ). HTML requires that certain sequences of whitespace are condensed into a single space character. In your second example, the text breaks on the section just before which include the previous line break and leading spaces.
This is mentioned in several places in the spec, one of which is quoted here:
When a user agent is to strip and collapse whitespace in a string, it
must replace any sequence of one or more consecutive space characters
in that string with a single U+0020 SPACE character, and then strip
leading and trailing whitespace from that string.
This issue is often seen when trying to get a pair of inline-block formatted elements to place side-to-side, instead ending up with a (often 4 pixel) gap between the elements.
This code produces such a gap:
<div>
<span>left block</span>
<span>right block</span>
</div>
While this code does not:
<div>
<span>left block</span><span>
right block</span>
</div>
The reason for the gap is the whitespace between the end of one span and the beginning of the next. The solution moves the whitespace from between the span elements to the beginning of a string where it is ignored rather than condensed.
Let's suppose I have the following paragraphs:
<p>one two </p> <p> three </p><p> four five </p>
Now let's suppose I want to style the words two, three, and four green, in place, without having any other effect on the document's structure or other layout. I basically want a <span> that transcends block level elements like <p>s. How can I accomplish this most simply? I could
<p>o <span>t</span></p><p><span>t</span></p><p><span>f</span> f</p>
But that makes things really messy due to the fact that I employ a markdown parser and have my own custom preprocessing code. What could I do so that there's only one "style begin" mark, and only one "style end" mark per contiguous length of green text?
You can have your text wrapped in a single <p> </p> and have a <span> inside that wrapping around the text you want to style, so:
<p>one <span>two three four</span> five</p>
http://jsfiddle.net/asbd9rdj/
edit
To target specific words in your multiple <p></p> tags, use a <span></span> as an inline element so you can attach styles to it.
<p>one <span>two</span></p>
<p>three <span>four</span></p>
example here: http://jsfiddle.net/79be8L6L/
"Interleaving" HTML tags is invalid. You should use 3 separate <span> tags, like in your second example.
Making your HTML generator handle this is unfortunately a necessary complexity in order to produce proper HTML.
You can see my problem in this jsFiddle.
I tried usingcode tags to distinguish special content, but this quickly backfired on me (as you can see in the above link). When I use Firebug to look at the content, this:
<p>
This is a sample paragraph with a code block:
<code>
<p> Some line of code </p>
<p> Another line of code </p>
</code>
</p>
has turned into this:
<p>
This is a sample paragraph with a code block:
<code> </code>
</p>
<p>
<code> Some line of code </code>
</p>
<code>
<p> Another line of code </p>
</code>
Now, this can be solved by changing <code> to <div class="code"> (as seen in this jsFiddle), but why did the browser do this in the first place, and why did it do it only to the first section in each paragraph?
Firefox, Opera, Chrome, Internet Explorer, Safari - all of them do this, but I'd really like to know why. Does it happen with code only, or will it do this with other tags? And why would browsers move tags around like that?
HTML places certain restrictions on which elements can be nested in which other elements. Sometimes browsers will happily construct a nonsensical DOM out of certain nesting scenarios, such as a <div> directly in a <ul>. Other times, they absolutely can't because of other written or unwritten parsing rules, such as <p> elements never containing any other block elements, not even other <p> elements (this is implied by the spec), so they have to work around it by changing the DOM to something that they can work with, resulting in the behavior you observe.
Because you cannot nest <p> elements within one another at all, what's happening here is that this element:
<p> Some line of code </p>
is causing this other element to be terminated:
<p>
This is a sample paragraph with a code block:
<code>
Since there's an empty <code> tag in there, it's closed, and the containing <p> closed as well, because a subsequent <p> start tag will automatically close a preceding <p> start tag:
<p>
This is a sample paragraph with a code block:
<code> </code>
</p>
At this point a browser has to deal with the fact that the <code> and <p> tags are now effectively in the wrong order, but still nested. To compensate for the restructuring of the first "outer" <p> element, and the fact that there was going to be a <code> tag before the second "inner" <p>, it inserts <code> tags into the second <p>, turning its contents into code:
<p>
<code> Some line of code </code>
</p>
Since browsers do seem to allow <p> within <code> for whatever reason (note that at this point the <code> is still not yet explicitly terminated with a </code>), the browser builds the rest of the DOM as follows, before continuing on its way:
<code>
<p> Another line of code </p>
</code>
This is probably consistent across browsers for legacy and cross-browser compatibility reasons; some of these legacy parsing rules have been retconned into sections of the HTML5 spec as well. Unfortunately, I'm not a browser implementer so I can't list out all possible scenarios; on the other hand, it's unwise to rely on such details considering the markup you're writing is invalid in the first place.
And, finally, today's highly relevant xkcd (of course):
I have always used either a <br /> or a <div/> tag when something more advanced was necessary.
Is use of the <p/> tag still encouraged?
Modern HTML semantics are:
Use <p></p> to contain a paragraph of text in a document.
Use <br /> to indicate a line break inside a paragraph (i.e. a new line without the paragraph block margins or padding).
Use <div></div> to contain a piece of application UI that happens to have block layout.
Don't use <div /> or <p /> on their own. Those tags are meant to contain content. They appear to work as paragraph breaks only because when the browser sees them, and it "helpfully" closes the current block tag before opening the empty one.
A <p> tag wraps around something, unlike an <input/> tag, which is a singular item. Therefore, there isn't a reason to use a <p/> tag..
I've been told that im using <br /> when i should use <p /> instead. – maxp 49 secs ago
If you need to use <p> tags, I suggest wrapping the entire paragraph inside a <p> tag, which will give you a line break at the end of a paragraph. But I don't suggest just substituting something like <p/> for <br/>
<p> tags are for paragraphs and signifying the end of a paragraph. <br/> tags are for line breaks. If you need a new line then use a <br/> tag. If you need a new paragraph, then use a <p> tag.
Paragraph is a paragraph, and break is a break.
A <p> is like a regular Return in Microsoft Office Word.
A <br> is like a soft return, Shift + Return in Office Word.
The first one sets all paragraph settings/styles, and the second one barely breaks a line of text.
Yes, <p> elements are encouraged and won't get deprecated any time soon.
A <p> signifies a paragraph. It should be used only to wrap a paragraph of text.
It is more appropriate to use the <p> tag for this as opposed to <div>, because this is semantically correct and expected for things such as screen readers, etc.
Using <p /> has never been encouraged:
From XHTML HTML Compatibility Guidelines
C.3. Element Minimization and Empty Element Content
Given an empty instance of an element whose content model is not
EMPTY (for example, an empty title or
paragraph) do not use the minimized
form (e.g. use <p> </p> and not <p />).
From the HTML 4.01 Specification:
We discourage authors from using empty P elements. User agents should ignore empty P elements.
While they are syntactically correct, empty p elements serve no real purpose and should be avoided.
The HTML DTD does not prohibit you from using an empty <p> (a <p> element may contain PCDATA including the empty string), but it doesn't make much sense to have an empty paragraph.
Use it for what? All tags have their own little purpose in life, but no tag should be used for everything. Find out what you are trying to make, and then decide on what tag fits that idea best:
If it is a paragraph of text, or at least a few lines, then wrap it in <p></p>
If you need a line break between two lines of text, then use <br />
If you need to wrap many other elements in one element, then use the <div></div> tags.
The <p> tag defines a paragraph. There's no reason for an empty paragraph.
For any practical purpose, you don’t need to add the </p> into your markup. But if there is a string XHTML adheration requirement, then you would probably need to close all your markup tags, including <p>. Some XHTML analyzer would report this as an error.