I'm working on a web project. In the last two weeks I was having my semester examinations so I'd to take a break from it. Now, since they are over, I've resumed my work; but I find that some of my web elements (like button,span) have shifted by some pixels on Chrome (not on IE and Mozilla). What could be the reason behind this? How do I overcome this problem?
ORIGINAL CODE: http://jsfiddle.net/p22L15vs/15/embedded/result/
The left margin (for button) for chrome was originally:
-webkit-margin-start:620px;
Now the same code causes the button to enter a new line.
Another example of span:
ORIGINAL CODE: http://jsfiddle.net/vbpasx1j/
The text shown in the fiddle was placed in a span tag. Two weeks ago it required only two lines. Now it requires three lines.
Hello and welcome to the community!
First off, in your provided link the -webkit-margin-start: of the button is set to 620px, not 166.
That, combined with the width of your menu div <div id="div_element"> as well as the padding around your elements exceeds your original #wrapper width of 1006px, making the button element jump to the next row.
Here's a demo to a top-of-my-mind solution: http://jsfiddle.net/kqxmbcdt/
Reduce the -webkit-margin-start: to 619px and you're good to go.
Always be on the lookout for unaccounted margins and paddings when positioning elements, as you can see, sometimes 1px is all it takes to break a layout.
This is to due the headline change in Chrome 37 ,the introduction of DirectWrite support for Windows.
Check this link for further details:
http://www.omgchrome.com/google-chrome-37-arrives-improved-font-rendering-windows/
This feature has caused a similar issue for various developers.
In order to restore to your previous font, the solution is to disable this new feature in your browser. You need to follow the following steps:
1> Enter chrome://flags/ in your address bar.
2> In the Disable DirectWrite Windows section click on Enable (actually disables it).
3> Click on Relaunch Now at the bottom.
4> Restart your browser.
Your original page design remains unchanged. :)
Related
If you navigate to https://basis.now.sh and hit Tab 3 times, you'll notice that the div that contains the sidebar navigation becomes focused (or the document.activeElement).
Looking at the HTML, there is no special attributes like tabindex on the div.
What causes this div to become focusable, and how would you make it non-focusable?
Tested on:
Chrome Version 83.0.4103.106
macOS 10.15.4
I found the offender in chrome://flags. I had this enabled:
After disabling it, the div isn't get focused anymore.
I made this website for my dad's business and you can see a contact form if you scroll a bit down. I'd like us to go to the Mobile View of the page through Google's DevTool (F12 and then Ctrl+Shift+M; or left besides "Elements"). I will show you what's wrong.
If you go to where it says "Treibstoff", try selecting the 4 different options. You will notice that you can't select the bottom two, "Diesel" and "Elektro".
Well, you can actually. If you press slightly above of the end of the word, but you can't select it like one usually does.
If we inspect the elements (Ctrl+Shift+C), we see that the box of "Typenscheinnr." is overlapping "Diesel" and "Elektro" (Inspect a bit above "Typenscheinnr.", not directly on it). A fix I found for this is: Inspect click the big overlapping box of "Typenscheinnr.", scroll down under Styles until you see that multilayered box, set upper margin to 45 with doubleclick.
This should fix it, but I don't know how to make this change go live. I did some research and all I got were solutions similar to "do !important" and then some code. Those were also for the whole site or something like that ...
Anyway, any help would be appreciated and I'm again sorry if this question is stupid. If there's more information you'd like to know, by all means just ask me.
Thanks for reading!
Just use clear: both
If you place a <div style="clear: both"></div> right before the end of the Treibstoff: <p> tag, the behavior will be the expected one.
This happens because you are using float
We wanted some numbered lists and found this cool counter thing you can use in you css to have the browser calculate numbers for you:
ol.instructions {counter-reset:instructions-section;}
ol.instructions > li:before {
content:counter(instructions-section);
counter-increment:instructions-section;
}
The html we're making contains pages of instruction sets, each set numbered from 1,2,3 and so on. Only one set is visible at a time, when you click a header you show that set and hide the others.
It worked like a treat and we were sitting there with smiling faces until someone thought of testing it in Internet Explorer 8, where we ran into some epic Microsoft-style weirdness. When a set was brought up by clicking, all the numbers were zero (0).
I googled around and found this page - it describes the problem fairly well (it's a combination of using :hover and css counter logic used in hidden content), but gives a solution that is less than satisfactory - I would love to be able to keep using the css counters and just implement some ie8-specific hack that somehow makes the page update the numbers. I'm having a hard time finding other stuff on the internet about this problem.
My particular page will describe zeroes until I move the mouse pointer into the div that contains the numbered list, at which point the numbers will magically fix themselves. Is there something I could to "nudge" the page into believing that a mouse is hovering over the element? Or is there a more proper solution?
Ive had the same issue. I was able to fix it by using JavaScript to apply inline CSS of padding-left 0 (there was already no left padding) once the element was visible. This seems to make IE 'redraw' the element.
If, as is suggested, the "hidden" is causing a problem then you could try "hiding" the content by instead moving it off screen with this piece of CSS:
.hide {
position:absolute;
left: -1000px;
}
I've used the code example from the linked to document to show a possible solution here: http://codepen.io/akademy/pen/LDhGl
I've been working with contenteditable recently within a HTML5 page and encountering bugs when using it with certain elements, and I'd like to know where and how I can actually safely use it.
I've discovered that making a span element contenteditable results in some buggy behaviour in both Firefox1 and Chrome2. However, making a div or section contenteditable appears completely safe3.
A guideline a couple of people have mentioned is that only block-level elements should be made contenteditable. However, the Mozilla Developer Network lists the heading elements h1 through to h6 as block-level elements, and making a heading element contenteditable is buggy in Firefox4 and can crash the page in Chrome5.
I'd like to be able to use more than just divs and sections, but I'm not clear on what elements I can actually safely make contenteditable. By safely, I mean that using the element under normal conditions, I should be able to perform normal editing tasks without it doing unexpected or buggy things. I should be able to write in it, delete content, cut, copy, paste, and move my text cursor about and highlight text without unexpected or strange behaviour.
So, which elements can I really make contenteditable safely? Is there a specific category? Are there certain criteria the safely-contenteditable element must match?
Bug notes:
Firefox 21 w/ span: Element loses focus if the text cursor is brought to the beginning or end of the element, but not if it got there by deleting content. Highlighting part of the element, cutting and then pasting will split the element in two at that point then insert a blank element between the two parts - without actually putting the text you were trying to paste anywhere.
Chrome 27 w/ span: If the span covers multiple lines e.g. by being wordwrapped, cutting and pasting content will often insert a linebreak after the pasted content.
Unless you make the div display:inline, in which case it can still lose focus as in 1, but apparently only if you bring the text cursor to the end. I don't consider this "normal" usage of the element though.
Firefox 21 w/ heading: Selecting part of the content then cutting and pasting will, similarly to 1, split the heading element in half at that point, and insert a third heading element between the two halves. It will, at least, have your pasted content inside it, but now you have three heading elements where there was originally one.
Chrome 27 w/ heading: Select some content and cut and paste. The page crashes. You get an "Aw snap!" message. That's it.
Demo code
Here's a demo for reproducing the above. It's pretty simple, though at the moment the only thing it isn't reproducing is the lose-focus bug.
[contenteditable=true] {
border: 1px dotted #999;
}
<article style="width: 100px">
<h1 contenteditable="true">Heading</h1>
<p>
<strong>Some adjacent content</strong>
<span contenteditable="true">Span! This is long enough it will spread over multiple lines.</span>
</p>
<div style="display: inline" contenteditable="true">An inline div also with multiple lines.</div>
</article>
In my opinion, I'd say div is the safest bet across the board. Any element you wish to truly edit (be it a span, header, etc), you can place inside the div and edit as if it were just that element. Also, to account for the display:inline issue you mentioned, you could always use float:left or float:right on your editable div to give it an "inline feel" without having it actually be inline.
Hope that helps!
Since this is an evolving feature with, apparent, low priority from the browser vendors support has been sketchy and regressions not uncommon. The current state of affairs is evolving, so check the Googles, CanIUse etc and make sure support is there for your sites visitors, everything else is moot ...
Support in Firefox seems to be solid, at least for some elements, now https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content
It works well in Chrome as well as far as my testing goes.
And CanIUse looks good: http://caniuse.com/#feat=contenteditable
There are a number of different bugs related to the feature in the different browsers though, but for simple use cases it should be ok now, as of August 2016.
Does anyone know how to fix (or what causes) the page up/down bug in FF when contentEditable is present on a div?
See an example
Navigate to contentEditable article with FireFox (3 or 3.5) and use the Page Up/down arrows on your keyboard. You should be unable to scroll to the bottom of the page, and it should appear to flicker and jump back up.
I think it's a bug of Firefox which even exists in the newest version, 3.6.8.
For the sample page there are 2 ways to make the page up/down buttons work:
Change all the three DOM node's contenteditable="true" to false.
Find the id="main-content" node, and delete the style float: left;.
Seems the problem for Firefox is contenteditable="true" conflict with the style float:left;.
The only way i can see is to use an iframe... like TinyMCE and CKEditor WYSIWYG editors, they both use iframes. However content loaded in an iframe does not posses the styling rules of its parent. Therefor has to be adapted ... the reason to herald the contentEditable div in the first place.
Since no one answered i'm going to sulk and play with matches