<span style="color: #21584b;"><p>Text</p></span>
That's an example of some code I have in my website. The colour is a dark green and it displays normally on my PC as well as on my Android phone. But, when viewed on an iPhone or an iMac the text is within the <p> tag appears white. I don't have any CSS in the stylesheet targeting just a <p> or a <span>. All of the CSS in the stylesheet has an additional class or an id.
I've removed the <span> tags wrapping the <p> one, but I have no way of testing it since I don't own any Apple devices myself.
So, the question is, will elements inherit inline CSS, like I've put here if they don't have any classes or ids overriding them?
Do it the other way round (span inside p), that's valid HTML and will overrule any previous properties for p:
<p><span style="color: #21584b;">Text</span></p>
Yes. If the value of a property is inherit then it will copy the value from the parent element regardless of how it was applied to the parent element.
That said, a <p> may not be a child element of a <span> element. The differences you are experiencing are likely due to different browsers recovering from your invalid HTML in different ways.
Related
I am well aware of CSS specificity rules (I have gone through this page: https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity), but I have an example where specificity of two elements should NOT be equal, and yet CSS rules are being applied differently depending on the nesting ordering of the html elements.
h4 small {
color: red;
}
<!-- will be red -->
<h4>
<a href="www.example.com">
<small>test</small> .
</a>
</h4>
<!-- will be blue -->
<h4>
<small>
test
</small>
</h4>
Reproduced here: https://jsfiddle.net/u39zsmx1/
h4 small should be more specific than a, yet, when the a element is the most inner nested element, its style wins. Why?
How does the nesting ordering of HTML elements affect CSS specificity?
It doesn't.
h4 small should be more specific than a, yet, when the a element is the most inner nested element, its style wins. Why?
h4 small matches the <small> element. It doesn't match the <a> element. Specificity only matters when multiple rules match the same element.
The a is blue (or purple depending on if it is visited or not). This comes from the CSS rules in the browser stylesheet.
The small is red. This comes from the CSS rules in the author stylesheet.
The text node is the colour of the element it is a child of.
After a little more digging in https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity, it turns out that while ordering is not taken into account, what matters is which elements are being targeted.
Specificity is not calculated if one of the CSS rules directly targets an element and the other does not. Inheritance is not applied in such a case.
There is web-site for Nodeclipse FOSS project http://www.nodeclipse.org/
I am not quick at web development and styles, and there is problem I don't know how to approach:
On the main page http://www.nodeclipse.org/index.html there is <pre> element (source line)
and after it style is always different than at pragraph start.
I guess there's something to be in applied http://www.nodeclipse.org/pipe.css" (source), but what to look for? (As it is not about pre element but what happens after it)
FOSS project needs help with web.
As you can see, <pre> tag usage inside <p> tag breaks the DOM structure
So the text after pre tag are not enclosed inside the <p> tag.
It is not advised to use pre tag to display a content that doesn't lose it's meaning if not pre-formatted.
So use a <a> tag or some other suitable tags like span (if you don't want it to be a clickable link) to display the url and style it accordingly.
Is there a way to have blank HTML tags or in other words, tags that do nothing? For example <p> turns the inclosed text into a paragraph, <b> turns the text bold, <div> creates a box. I'm looking for a tag that has no effect on the text or it's environment. I want this so that I can customise it myself with css or js.
I am <x class="FancyText">king</x> of the world.
There are no “blank HTML tags”. What come closest are span and div, but the latter causes line breaks before and after (block rendering) by default and cannot be used in inline context, and the former does not allow any block-level elements inside it.
In practice, you can use a made-up element, like <foo>...</foo>, though with some problems on older versions of IE. This is widely regarded as a bad move, though; using span or div, as appropriate, with a class attribute is recommeded.
Consider explaining what you are really trying to achieve, instead of referring to fictional HTML tags expected to do nothing.
For this you'd use either the div or span element. From the HTML5 editor's draft:
The div element has no special meaning at all. It represents its children.
The span element doesn't mean anything on its own. ... It represents its children.
The difference between them is that the div element should be used where flow content is expected (that is to say, sections on a page), whereas the span element should be used where phrasing content is expected (within text).
In the example you've given, you'd want to use the span element:
I am <span class="FancyText">king</span> of the world.
You can do the following:
<div></div>
This will do nothing unless you add a class or id.
Or,
<span>Some text</span>
This will do nothing unless you add a class or id.
if you want to use <x ...> txt </x> as a place holder,
than any officially-unused set of chars will do fine.
I use <a> ... </a> for that
So you've tried to center the <small> HTML element with the CSS property text-align: center (or right) and it doesn't work?
Well, that could be because your HTML/CSS looks something like this. There's an easy CSS solution...
If you set a small { display: block } property like this then it works like a charm:
Horay!
But you can probably tell something's not right... and why does it work anyway?
Well, <small> is basically an inline element and the text-align property is to be applied to block elements and passed down to child inline elements (or strings inside).
By making small into a block element we are allowing the text inside it to be styled.
Also, the W3 spec defines the <small> element to be used inside a phrasing context — similarly to elements like <strong>, <b>, <span>, <a>, and so on — which would do the same thing in this case.
W3 wiki examples suggest to put the <small> inside <p> tags and style that — I guess that's the more semantic solution, and here's the code if you need to see it.
Why is this a bit confusing?
Well, some 3rd party resources on the web don't mention it, or at least not explicitly. For example, the HTML5 Doctor's example uses the small element without a block element container around it.
Hope that clarifies things! As always, please let me know if I missed anything. (And I think I did.)
Are both <h1><a ...> ... </a></h1> and <a ...><h1> ... </h1></a> valid HTML, or is only one correct? If they are both correct, do they differ in meaning?
Both versions are correct. The biggest difference between them is that in the case of <h1><a>..</a></h1> only the text in the title will be clickable.
If you put the <a> around the <h1> and the css display property is block (which it is by default) the entire block (the height of the <h1> and 100% of the width of the container the <h1> resides in) will be clickable.
Historically you could not put a block element inside of an inline element, but this is no longer the case with HTML5. I would think that the <h1><a>..</a></h1> approach is more conventional though.
In the case where you want to put an anchor on the header, a better approach than <a id="my-anchor"><h1>..</h1></a> would be to use either the id or the name attribute like this: <h1 id="my-anchor">..</h1> or <h1 name="my-anchor">..</h1>
In pre HTML 5 this one
<a><h1>..</h1></a>
will not validate. You can use it in HTML 5.
However, i would use this:
<h1><a>..</a></h1>
unless you need to add more than < h1 > inside the < a >
<a><h1></h1></a> is not W3C valid... Basically, you can't put block elements inside inline elements
<h1><a>..</a></h1> and <a><h1>..</h1></a> have always behaved almost the same, when style sheets do not affect the rendering. Almost, but not quite. If you navigate using the tab key or otherwise focus on a link, a “focus rectangle” appears around the link in most browsers. For <h1><a>..</a></h1>, this rectangle is around the link text only. For <a><h1>..</h1></a>, the rectangle extends across the available horizontal space, since the markup makes the a element a block element in rendering, occupying 100% width by default.
The following shows how a focused <a href=foo><h1>link</h1></a> is rendered by Chrome:
This implies that if you style elements e.g. by setting a background color for links, the effects differ in a similar manner.
Historically, <a><h1>..</h1></a> was declared invalid in HTML 2.0, and subsequent HTML specifications followed suit, but HTML5 changes this and declares it as valid. The formal definition has not affected browsers, only validators. However, it is remotely possible that some user agents (probably not normal browsers, but e.g. specialized HTML renderers, data extractors, converters, etc.) fail to handle <a><h1>..</h1></a> properly, since it has not been allowed in the specifications.
There is seldom a good reason to make a heading or text in a heading a link. (It’s mostly illogical and bad for usability.) But a similar question has often arised when making a heading (or text in a heading) a potential destination for a link, using e.g. <h2><a name=foo>...</a></h2> versus <a name=foo><h2>...</h2></a>. Similar considerations apply to this (both work, there may be a difference since the latter makes the a element a block, and before HTML5, only the former is formally allowed). But in addition, both ways are outdated, and using the id attribute directly on the heading element is now recommended: <h2 id=foo>...</h2>.
H1 elements are block level elements, and anchors are inline elements. You are allowed to have an inline element within a block level element but not the other way around. When you consider the box model and the HTML spec this makes sense.
So in conclusion the best way is:
<h1>Link</h1>
do you want to use a hyperlink <a href="…">/a:link, or do you want to add an anchor to your heading? if you want to add an anchor, you can simply assign an id <h1 id="heading">. you can then link it as page.htm#heading.
if you want to make the heading clickable (a link), use <h1><a></a></h1>/h1 > a – blocklevel elements first, and inline elements inside
Also, there is style hierarchy differences. If you have it as <h1>Heading here</h1>, The styles of the anchor will overrule the styles of the h1 element. Example:
a {color:red;font-size:30px;line-height:30px;}
WILL OVERRULE
h1 {color:blue;font-size:40px;line-height:40px;}
I think the <h1>text</h1> is the least problematic with weak or old browsers, but modern browsers and powerful search engines are supporting both it and <h1>text</h1>; So it's a good freedom and useful to use both to improve our web page.
«Hope that could be useful»
Both are correct. They depend on the sizing of the anchor tag which you want and how you want your website laid out.
You can do <h1>Home Page</h1>, in which case it would return: Home Page But with an Anchor.
Or you can do <h1>Home Page</h1> and it would return a H1 hyperlink instead of just heading an anchor to the H1, like so:
Home Page
However, mostly you cannot add links within H1 because it will just render it as an anchor onto the h1 rather than adding a hyperlink. However, I think I'm right in saying that you could see a difference in behaviour for this on different browsers.
But correct me if I am wrong. :)