For some reason elements are added to my html code and the text is rendered as italic.
http://109.72.95.174/astudio/sites/lancelmaat/performanceinstallation?tid=22(see bottom lines, or content of menu "Contact")
I'm using CKEditor in Drupal for the input of some text areas.
But it is strange, because the elements are added only for specific pages...
Also, I cannot see the elements in Safari Developer bar (I only see style: italic), but I think this is a smaller detail.
thanks
One of your nodes ("a live library") has on unclosed <em> in the message body, near the sentence that says "Voorjaar 1998 werd ik uitgenodigd doo..."
This is (accidentally) incorrect HTML, but different browsers react differently -- some add extra <em>s to straighten things out and italicize the rest of the page, some ignore the error, etc.
Diagnosis and Solutions:
This is happening because the node has HTML, and the maximum length in your display happens to break inside of an italic block for that node.
This is could be caused by one or more of the following. (Tough to tell witch without knowing how you set up the page, but all should be easy for you to check)
1) The node's HTML is incorrectly written. (Solution: fix the code so that all tags are correctly closed)
2) The "Preview" of the node is left to be determined automatically. If you're using Full HTML in a node, you should always set the teaser manually so you don't get orphaned tags in the preview.
3) In Views, you have the "Trim this field to a maximum length" checked. If so, you should also use the "Field can contain HTML" option, since this forces Drupal's built-in HTML corrector to run
4) You have another module that's doing something similar to the options described above. That module might have it's own HTML correction options, or you can use Drupal's built-in corrector (admin/settings/filters/%your-filter)
Related
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 am working on a Wordpress website in which I need to use the musical "flat" symbol. To figure out what might be a good way to handle this, I checked out what is used on Wikipedia, in the corresponding article (https://en.wikipedia.org/wiki/Flat_(music)).
I know how to find the HTML entity code and use that, and I know I can just copy the symbol from somewhere else and just paste it directly into my post. But when doing that, there is extra padding around the symbol, so it displays incorrectly, like this: D ♭ . (It's actually not doing it here on SO, so I had to add spaces on each side to simulate it.) It looks like the problem is handled on Wikipedia by the following code, which appears everywhere the flat symbol is used:
<span class="music-symbol" style="font-family: Arial Unicode MS, Lucida Sans Unicode;">♭</span>
So I used the same code and I created a "music-symbol" class in the CSS file, in which I set padding to 0. I couldn't find the corresponding class on Wikipedia, but I guessed that that's what it contained. I honestly don't know why this works (I'm a noob) but it does seem to work, assuming I specify the font using the style tag as shown. When I say "it works", I mean that it makes the flat symbol appear right next to the note name, as it should, without extra space, like this: D♭.
However, when I view the same site on my Android, the spacing is still there. Can anyone explain why, and how I should address this?
Also, is there a better or more straightforward way of handling special symbols like the flat? I don't get why I was able to paste it in directly here on SO and have the spacing be correct without having to use the extra class reference and style tag.
As far as I can see within the styles on that particular site there is no additional styling for the music-symbol class. From what I can tell the additional white space is inherit to the element and font(s) being used. Padding will not be what you are looking to alter, you would be wanting to adjust the margin of the span element where the symbol is placed.
See class definition below for styling a span with the music-symbol class
span.music-symbol {
margin-left: -2px;
}
In general I like the pretty option. I like my html to be readable and pretty helps. But there are times when it gets in the way. For example.
x.do-not-care-about-spaces It can go either way here.
y.please-no-spaces These
y.please-no-spaces Should
y.please-no-spaces Touch
What I'd like to see is:
<x class="do-not-care-about-spaces">It can go either way here.</x>
<y class="please-no-spaces">These</y><y class="please-no-spaces">Should</y><y class="please-no-spaces">Touch</y>
But what I do see is
<x class="do-not-care-about-spaces">It can go either way here.</x>
<y class="please-no-spaces">These</y>
<y class="please-no-spaces">Should</y>
<y class="please-no-spaces">Touch</y>
I know there are several ways to work around this (with css, by putting html in the jade file), but what I'm hoping for is a jade-y way of doing it.
EDIT: Updated example with example tags, rather than divs. I am asking specifically about controlling spaces between DOM nodes in jade's HTML output, not the visual space between elements on a rendered web page.
There is a similar question on the github repo and the essential comment is:
No, it is not currently possible to force only part of the document into pretty/normal mode. The general recommendation for this is to use the normal (non-pretty) mode which is the default for exactly this reason. You can explicitly add white space using = ' ' (on its own line) when actually needed for the formatting of the page.
A <div> element takes up the whole row, so it makes sense that it's rendered as such too.
I think what you need are <span> tags
span.no-space These
span.no-space Will
span.no-space Touch
<span class="no-space">These</span><span class="no-space">Will</span><span class="no-space">Touch</span>
BTW there's also the inline #[…] syntax which makes more sense if you're putting tags in one line
#[span.no-space These]#[span.no-space Will]#[span.no-space Touch]
Note that this syntax will not however make divs appear in one line though, you still have to use spans.
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.
I have a named anchor tag:
<table id="search_results" name="search_results">
I am linking to this like so:
pagename.php#search_results
This is working in Firefox and chrome, but not IE (8).
I have tried using an <a> tag as suggested in some other posts. I have also tried to give the search results table the css:
display: inline-block
as suggested by one of the commenters on this article. My table always has content as well, which the article suggests can be the reason for IE rejecting it.
I'd be grateful for any suggestions.
Many thanks
That's how I was motivated to search for a different solution:
Added text was inappropriate for the display and the non-breaking space caused an extra line space to appear between the paragraphs. This could have been corrected, but the multi-MB pages would have required a lot of manual work.
The pages, developed with iPage, can be viewed here: www.theUB.org
I've been told by several professionals that such long pages are usually avoided in web site design, but these pages (with many named anchors and a "point & click" Table of Contents) seem to work well for this 2000-page public domain text.
One more disadvantage of the non-breaking space solution:
This online text needed to be read correctly by computer screen readers. Some people have commented on other blogs that screen readers voice the non-breaking space (or added text).
(Note the added decimal point after the paragraph numbers - this was necessary to prevent screen readers from voicing the merged paragraph number and first word of paragraph.)
Couple things:
IE8 does not support inline-block ;)
When you tried the a anchor, which is probably best, was your code something like
<a name="search_results"></a>
<table name="search_results" id="search_results">
</table>
The <a name=""> method is pretty much universally supported.
Firstly, using named anchors to navigate the page does what it says. You have you use a named anchor (<a> tag) to do it. Some browsers support it on non-anchors, but this is not universal and should not be relied upon - as you have discovered.
Secondly, are you sure you page is long enough? If the thing you are trying to link to is right at the bottom of the page, it won't display at the top of the viewport as you might expect, since there is nothing below it to display at the bottom of the page.
Thirdly, check that you did the named anchor correctly. You should be doing something like this:
<a name="search_results"></a>
<table name="search_results">
...
Regarding named anchors that do not require text:
Others have suggested this "workaround" for IE8: insert a "non-breaking space" character if no text is required ( ).
However, I also discovered that resetting my IE8's View/Zoom from 125% to 100% also activated the anchors that were not corrected with the "non-breaking space" solution. IE8's View/Text Size is not part of this problem.
Note: Large, text only, HTML pages were being tested: (font face="Verdana" size="+1"). These HTML pages displayed correctly in Firefox 15.01 without regard to View/Zoom,Text Size settings.
I've got this working by adding some text inside the anchor, like:
<a name="search_results"> </a>
This appears to be another solution to the IE large file load delay: create a smaller HTML file which links via HREF to the large file (or to a bookmark (named anchor) in that file).
This test has been tried multiple times with the IE direct load of the large file always causing a long delay, but not when the user clicks the link in the small file to go to the large file.
Perhaps, IE is analyzing the primary file to see if it had already been loaded into the cache.
Note: This HTML file being tested is 11 MB (an entire book with many bookmarks and links to those bookmarks from other parts of this very long HTML page).
I faced the same problem on IE, Edge and chrome,
and I think the problem is because the encoding and decoding on the name attribute
so I did a workaround solution, take a look
anchorElem.on("click",function() {
var href = $(this).attr('href');
var scrollEle = $(".tocContent").find('a[name="' + href.substr(1) + '"]' + ', a[name="' + decodeURIComponent(href).substr(1) + '"]');
if (scrollEle.length > 0) {
$('html, body').animate({
scrollTop: scrollEle.offset().top
}, 0);
return false;
}
})
hope this help you
and happy solving browser compatibility issues