Text-decoration line-through misaligned only on Safari/Mac - html

I'm trying to add a line-through, in all browsers it works fine, except Safari.
It gets misalignment.
I'm not even using css, just an stag inside the html
<span class="price--old">
<s>{value}</s>
</span>

There is an issue with the line through and del
they both are't working in safari
I came up with an solution
.price--old {
width: 25px;
display: flex;
align-items: center;
}
.price--old::before {
content: "";
flex: 1 0 10px;
border-top: 1px solid #111;
}
.old-price {
margin-left: -25px;
}
<div class="price--old"><span class="old-price">200</span></div>
its working completely fine in safari and chrome

Every browser interprets CSS differently. I believe the reason it's not working is because the <s> tag "renders a horizontal line through the vertical center of the text," so I assume it's finding an odd "vertical center."
Per Apple's dev library:
s
Deprecated. Defines a block of text in strikethrough style. Use del to indicate document edits.
Discussion
The content inside the s element is rendered with a horizontal line through the center. The del element is more appropriate to show text that was removed. Styles should be more finely tuned using CSS instead of using HTML style elements when possible.
Availability
The s element has been deprecated in the HTML 4.01 standard.
Try using the <del> tag instead
<p>Let's try <del>this</del></p>
And let me know if that doesn't work. It looks ok on my computer in Safari, but I have some weird settings on my Safari for a work project rn.
A little more research shows that there is a semantic difference between del and s: What is the difference between <s> and <del> in HTML, and do they affect website rankings?
<s> and <del> both still exist in the HTML specification.
The <del> element represents a removal from the document.
The <s> represents contents that are no longer accurate or no longer relevant.
That is to say that they actually represent different things
semantically. Specifically would be used if you had an existing
document and wanted to indicate text that was in the document, but has
been removed. This would be different than text in a document that is
no longer accurate, but that has not been removed (you could use
for that).
You should not use or depend on either for styling even though most
browsers do have them strike-through by default. You should only rely
on CSS for presentation.

Related

Why does this element not render in Firefox?

The following HTML/CSS code is rendering in IE (Version 8) but not in Firefox (Version 25)
Any reason why?
HTML:
<img class="buttonmini" id="btn_Actual_Effort" onclick="showEffortDetail()" disabled="disabled">
CSS:
.buttonmini
{
background: url(../newimages/effort_calendar.gif) no-repeat;
height: 16px;
width: 16px;
font-family: Verdana; /*font-size: 8pt;*/
cursor: pointer;
}
Short answer:
It can be fixed if you add a display: inline-block in your css.
Longer answer:
It also renders in Webkit based browsers (Chrome and Safari at least).
This seems to occur because Firefox does not interpret image tags the same way as other browsers.
The <img> tag is defined by w3 as an inline-block element.
When the image's source is included in the tag (e.g. <img src="thisIsMyImage.jpg">), Firefox interprets it correctly (as an inline-block element).
However, when there is no src available immediately in the tag, Firefox appears to interpret it solely as an inline element. This means you cannot define it's width or height.
Check out this jsfiddle for some experimentation with different ways of getting the background of an <img> tag to display.
In an img element, the src attribute is required by HTML specifications. If you omit it, the rendering and behavior of the element is undefined. (It may work with some browsers the way you want, and you might trick some other browsers to do the same, but any new version of a browser could break things down.)
Thus, use a content image (an img element with src attribute and adequate alt attribute), instead of a background image on an img element.

content attribute of img elements

While inspecting the Chrome Dev tools, I noticed the following CSS fragment:
img {
content: url(image-src.png);
}
which works perfectly in Chrome (see Screenshot below).
This allows me to define the src attribute of an <img> tag via CSS. Doesn't work in Firefox. Until now I thought that is not possible to directly modify the src attribute via css and I have not found anyone talking about this. So, is this just a proprietary addition in Chrome or is Chrome implementing a W3C draft or something comparable I am not aware of?
The content property as defined in CSS 2.1 applies to :before and :after pseudo-elements only. By CSS rules, you can specify any property for any element, but specifications have limitations on what properties “apply to” (i.e., have effect on) various elements.
The CSS3 Generated and Replaced Content Module, a Working Draft, describes the content property as applying to all elements. It has an example of replacing the content of an h1 element by an image, and surely the same could be done to an img element.
But it’s just a Working Draft. The usual resources on CSS implementation status, QuirksMode.org CSS info and Caniuse.com, do not indicate the situation; they only describe the support to content for :before and :after (which is rather universal except IE 7 and earlier.
Now you can do that: http://chabada.esy.es/tests/0004.html
<style>
.redcross {
background: transparent url('redcross.png') no-repeat;
display: block;
width: 24px;
height: 24px;
}
</style>
<img class="redcross">

Why is text placed differently in <input>s than <span>s or <textarea>s?

I’m trying to build a jQuery plugin that fakes the HTML5 placeholder attribute (like What is the most accurate way to emulate the "placeholder" attribute in browsers that don't support it natively?). To do this I’m inserting a <span> before the appropriate <input> or <textarea> and duplicating the styling.
Unfortunately, I’ve discovered that browsers magically place the text differently in <input>s than <span>s or <textarea>s, as demonstrated by http://jsfiddle.net/63zcD/1/—the text is vertically centered in the <input>, even though Web Inspector says the styling is identical across all three. The effect appears in Safari, Chrome, and Firefox.
Tricks that haven’t worked:
vertical-align: middle;, vertical-align: text-bottom;
display: inline-block;
Twitter’s login page fakes the placeholder attribute, but they get around this problem by wrapping the <span> and <input>/<textarea> in a containing <div> and manually styling the <span> for a visual match, which isn’t an option for a plugin that needs to run automatically.
Assigning a line-height that is equal to the element height should work. See this fork of your original fiddle, so to speak: http://jsfiddle.net/pygPs/.
A quick browser check showed it rendering properly in IE 9, IE 6, as well as the latest Mac versions of Firefox, Chrome, and Safari. I didn't change any of the existing CSS from the original link, just added one line:
height: 26px;
line-height: 26px; /*added this line*/

Html layout with <DIV> work on html editor but not on brownser

And in my html editor looks just fine:
alt text http://img441.imageshack.us/img441/7348/bien.png
But when i see it on the browser (Chrome & Firefox) looks like this:
alt text http://img59.imageshack.us/img59/642/malhh.png
Im very new to layout with tag, any idea of what im making worng?
put "margin: auto;" in the style of div contenido and usuario. Then add padding-top: 58px; in div usuario (as you are trying to put that div 58px lower.)
Oh! of course remove those margin-top styles from every where and use padding style instead.
What's wrong? You're relying on the rendering engine of your HTML editor and you shouldn't.
Only use a recent version of Firefox, Safari, Chrome or Opera for testing (edit: I forgot IE8 and I shouldn't have; it's support of CSS2.1 is good. It just lacks dozens of extensions but that's another story), then the other browsers including IE and forget your not-so-awesome rendering tool.
I believe your specific issue is being caused by the lack of trailing semicolons at the end of your style properties. That will often cause bad rendering.
margin-top: 1px" >
should be
margin-top: 1px;" >
Also, you should definitely take the advice of #Christian Mann and put the CSS in the of your document or, even better, in an external stylesheet. Inline CSS styles should be avoided.

What could cause this HTML/CSS rendering issue in Firefox?

The styles:
h2 {
color: #71D0FF;
font-size: 11px;
font-weight: bold;
margin: 0px 0px 5px 0px;
}
a.box {
color: #FFFFFF !important;
cursor: pointer;
display: block;
padding: 10px;
text-align: justify;
}
a.box:hover {
background-color: #0C0C0C;
}
a.box span.down {
display: block;
color: #D04242;
float: right;
font-size: 11px;
margin-left: 5px;
}
a.box span.up {
display: block;
color: #71D013;
float: right;
font-size: 11px;
}
span.noob {
color: #FFA142;
}
span.pro {
color: #A142A1;
}
The HTML (this is basically repeated for each link):
<a href="/library/blaze" class="box">
<span class="down">-0</span>
<span class="up">+0</span>
<h2><span class="noob">NOOB</span> BLAZE</h2>
HAS CREATED 0 MAPS, WON 0 BATTLES, AND LOST 0 MAPS
</a>
What I'm not understanding is why it renders differently in Firefox occasionally. Sometimes it shows up like it's supposed to and sometimes it shows up in this weird format as seen here:
I've never had anything like this happen before, does anyone know what's causing it? Does it even do this for anyone else? Like I stated before, sometimes it loads just fine (exact same HTML, CSS, and everything) and sometimes it doesn't. It seems kind of random. It loads just fine in IE with no weird problems at all.
Interesting. I can definitely reproduce it on FF3.6, actually I'm getting the broken version more often.
I can't get my head around it right now, but looking at it in Firefox, there is something broken with the link. If you open "inspect element" in Firebug, you will notice that the rendered DOM definitely changes between the intact and broken view. Firebug will also add _moz-rs-heading to the link, which is sort of explained here.
The first step should definitely be making the markup W3C valid and checking whether it still occurs.
I am a bit surprised that it doesn't act up more than it does.
You have put a block element (h2) inside an inline element (a). The markup is broken, and different browsers will do different things to try to make the best of it. One thing that can happen is that the browser adds an ending tag for the link before the block element.
Us an inline tag instead of the h2 tag, and use CSS to style it to look the way you want.
I'm having the same problem.
http://www.jameshughbanks.com/
I've narrowed it down to this. It ONLY happens when I put a link around multiple elements (in my case it involves one (or more) block element(s) and one (or more) in-line elements.
It is very odd as in it seems to only affect "every other" "error" you create using the method I described above. It will modify the first and third div output but not the 2nd. (at first it affected the 2nd one only, but I partially fixed the problem (it used to mess up the H2's also, but putting the link around the h2's only removed them from getting the error.
So it comes down to only being able to put a link around 1 block element, I haven't tested the error with more than 1 block element, only the mis-match of a block element and multiple in-line elements.
If anyone has any work-arounds for this issue in firefox please let me know. It does not appear to happen in IE, Opera, or Chrome.
Also for those that think this is bad markup, it is included to be valid in the next revision of html5, and it is the only way (without javascript/etc) to do these types of links. Firefox is obviously coded to show this markup properly but for some reason has some type of bug that makes it render it differently sometimes due to unknown reasons. Regardless it needs to be fixed or a work-around developed, I could make each element its own individual block and probably fix it, but that's a lot of extra unnecessary code.
Works fine for me in Safari, Chrome, and Firefox 3.5.
I've tried refreshing repeatedly. No luck in duplicating your problem. Have you tried clearing your cache?
Inspecting the element in Safari or Web Developer (FF plugin) does not reveal anything unusual either.
Is N00B BLAZE always the one that messes up every time you see an issue or is it random?
For me, sometimes Firefox doesn't properly load CSS, it's usually all of it, not partially like it's happening to you. For me tho it's loading correctly. Have you recently changed it by any chance and didn't allowed to properly refresh?
When I buzzed your site, the problem occurred for me in FF3.6. Using Firebug to peek at the HTML, the problem was that the lines that display incorrectly have an extra <a> wrapped around the text, within the <span>. Maybe some HTML included in your DB where it should only be text?