I have long text that gets hidden if it exceeds 300 characters. Hiding is done with a <span> that has style="display:none;" set.
Basically, after the 300th caracter the rest of the content in wrapped inside that display:none span.
The algorithm is clever enough not to break text in the middle of a tag, so the invisible span will always occur after ending a tag.
The problem I have only happens in Mozilla and that's when the 300th caracter happens to be in the middle of a UL or OL. The rest of the browsers behave properly, hiding the part of the list that's outside the span and showing the other part, but Mozilla doesn't.
Any idea how I can fix this please?
UPDATE:
Code:
<ul><li>a</li><li>b</li><li><span style="display:none;">c</li></ul></span>
I know it's invalid markup because of the overlapping tags.
Thank you.
Fix your markup. If you properly close the span tag inside the <li>, it should work correctly.
<ul><li>a</li><li>b</li><li><span style="display:none;">c</span></li></ul>
Closing the <span> outside the list may be convenient, but for the browser to properly parse it, you need to use proper markup where possible. If you can't figure out how to close it within the <li>, maybe you need to re-think your code.
Related
I'm using Tailwindcss to working with nextjs, I met a issue that recorded <p> tag cannot contain any element in middle of the text. It will breakline right before the element show up
It shouldn't breakline on the element on normal <p> tag. I disabled all the attribute can be find in the style console but it wasn't fix the problem. Only disable base class import in tailwind.css lead <p> run correctly, but it shouldn't be fixed like that
Are you talking about "#tailwind base;" in application.tailwind.css? You shouldn't disable this as it might get issues in other designs.
Instead, what you can try is to wrap your text in the "span" tag and see whether it works. Hope I understood your question... For this, you'll have to use multiple span tags wrapping up your text only.
The pre tag is used for defining block of preformatted text in order to preserve the tab, text space, line break e.t.c.
But I don't really know while this is not working for me. Am having excess WhiteSpace in all my blog posts.
I have provided a screenshot for view as well as a live url to see the effect of what am trying to explained.
I tried this:
.pre-blog{white-space:pre-line;white-space:-moz-pre-line;white-space:-pre-line;white-space:-o-pre-line;word-wrap:break-word;word-break:keep-all;line-height:1.5em; display:inline;margin:0}
But no luck with it cos it couldn't solve the issue.
Here is one of the blog posts that you can access and see what I am trying to explain.
Screenshot:
the whitespace you show in the screenshot is the space between li items. This is default styling applied for these html elements.
Easiest way to get rid of the space would be to apply display: flex and flex-direction: column to the parent, which is the ol element
You seem to be trying to put <div>s and other elements inside the <pre>. As far as I know that's not how <pre> works; it's only meant to contain plaintext that you want preformatted in a certain way as described here. It's usually used for displaying things like computer code that need all their indentation preserved.
Your screenshot and linked web page seem to be ordinary formatted text. I'm not sure what exactly you're trying to achieve, but <pre> is not the right way to do it; you'll have better luck with proper use of <p> and <br> tags and CSS styling with properties like margin, padding, and line-height. (Depending on your use-case, if you want to avoid manually typing tags, you might want to consider something like Markdown to automatically add the formatting tags for you).
I suggest you replace your <pre> with a <div>, and then post a different question regarding the whitespace if you're not able to figure it out yourself.
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.
The problem that i'm having is that I've specified some rollover buttons, and some div id's to control my image positions. however when i make a new div called Text and put some in, this also seems to trigger my rollover buttons? like its using code from the div above it, even though I've used the <div> tags:
http://jsfiddle.net/bq5MR/2/
Your example doesn't display the images.
You haven't closed your <a> tags which may result in the effect area being larger than you expect.
http://validator.w3.org/ - a free HTML validator which can help pinpoint invalid HTML and potential issues.
You're not closing your second 'a' tag. Try closing it and see if that fixes the problem.
For some reason my paragraphs are displaying line breaks when there is no <br/> tag being used! So if I type content into the HTML and hit return a few times it gets formatted that way.
How can I prevent that? Can I not just get it to flow?
Browsers will automatically render paragraph tags to have some padding unless you explicitly style it not to... is this the problem?
If so, p {padding: 0; margin:0;}
If not, try giving us some of your code and a better explanation of exactly what the problem is.
Put this into your stylesheet:
p {white-space:normal;}
The <pre> tag will cause white space to display. So will a CSS rule like this:
p {white-space: pre;}
Could either of those be the problem?
If the text is being broken to make it fit, you cannot / should not try to stop the text from breaking. However, if your problem is that the text is breaking at an undesirable point and you would rather have it break at a more appropriate point, use the following:
<nobr>... Unwanted break point here ...</nobr>
enclose the unwanted break point with nobr tags.
And, add the following at the appropriate break point:
... some text ... Text on next line