I am having issues wrapping some words in the item list.
I have converted item list into XSLT page. Tried setting column width to some value but it gets overridden and stretched out as cells contain some long words without spaces. I tried adding word-wrap: break-word; as inline styling, but it is instantly marked red with message:
This property is marked invalid because it's not supported by the
current schema.
If I save the page anyways it works how it's supposed to work, but if I navigate somewhere else from current list, everything resets and I am back to square one.
How do I fix this? Is there some global CSS which would enable the use of word-wrap? In essence, I want word wrapping in cells of standard view. Even of long space-less words.
Related
I have added a HTMLDelegate to a QTreeView instance I'm tinkering with (see How to make item view render rich (html) text in Qt), so I can present its contents with rather simple rich text (HTML). The hits are presented as
<headerstyle>result type</headerstyle><br>
%d results of this type
where "headerstyle" is either a single tag (say ) or a combination of such tags.
That I'd like is to add underlining to the 1st line that spans the entire width of the QTreeView. Checking existing suggestions on here make it seem doubtful that this will be possible, but maybe I'm overlooking something?
I tried adding <span style="border-bottom: 1px solid"> but no borders are ever drawn. That may be a limitation in the HTMLDelegate, but it probably wouldn't work anyway. does work but only applies to the actual text, not the entire first line. I guess what I'd need is a right-aligning tab character...?
Current actual code: https://github.com/RJVB/audacious-plugins/blob/RJVB-MP-Qt/src/search-tool-qt/search-tool-qt.cc#L166
I need to determine minimum width adequate for displaying a possibly wrapped dynamic HTML string. Without word-wrapping this is simple: create a span, set its innerHTML and read offsetWidth. However, I'm not sure how to force linebreaks... Easiest incomplete approach I see is to replace all spaces by <br/>, but lines can be wrapped not only on spaces but also e.g. on hyphens.
So, basically, I want a browser to lay out sth. like
Max.
word-
wrapped
string
<----->
somewhere off-screen to measure width of the longest contained word. Is there a generic way to do that?
EDIT
I.e., for no line wraps:
function computeWidth (str) { // code to make it off-screen and caching omitted
var span = document.createElement ('span');
document.body.appendChild (span);
span.innerHTML = str;
return span.offsetWidth;
}
How would I write a similar function which forces line breaks on str, presumably playing with span.style?
You can use CSS work-break / word-wrap and programmatically inserted soft-hyphens (, but I'd advise you to read up on cross browser problems regarding soft hyphens, as there are quite a few - I normally us the unicode for a soft hypen (U+00AD), but your mileage may vary), and then determine the width with javascript using the range object and measuring cursor offset from the left.
I'm suggesting the use of soft-hyphens, because even the same browser will normally break words differently depending on the OS / which dictionary (on OSX) is used. If that's not an issue for you, you can do it without soft hyphens.
Afaik there is no generic way to get what you want in html/js (it's different if you were using something like flash).
Range object:
https://developer.mozilla.org/en-US/docs/Web/API/range
A different approach would be using the canvas object, but you would probably not get exact results there, as there is just too much factors influencing text rendering in browsers nowadays (font, size, kerning, tracking, ...)
Again another approach would be using <pre> tags / whitespace: pre-wrap, setting the font to what you normally use, and then either emulate breaking words by inserting linebreaks or copying them from still another span/div/whatever set up with word wrap - I haven't tested this yet, but if it works, it might be easer than iterating with the range object.
Edit: Just so it's not only in the comments, still another solution:
Start your container with width 1px, then increase the width, checking the height every time ; when the height decreases, go back one step, and you got your width. Simplest implementation would use 1px increase/1px decrease, but you could of course optimize it to using something like a binary search algorithm, e.g. starting with 1px, then 2px, then 4px increases, then the same backwards, and forwards again and so on till you have a result at a 1px step. But that's only if the 1px inc/dec sollution is too slow ;)
Use the CSS word-break rule:
The word-break CSS property is used to specify how (or if) to break lines within words.
Normal
Use the default line break rule.
break-all
Word breaks may be inserted between any character for non-CJK (Chinese/Japanese/Korean) text.
keep-all
Don't allow word breaks for CJK text. Non-CJK text behavior is same as normal.
<p style="word-break:break-all;">
Max.word-wrapped string<----->
</p>
(source)
Try to play with the word-break Property.
More here: http://www.w3schools.com/cssref/tryit.asp?filename=trycss3_word-break
You should try:
word-break: break-all;
Add it to the CSS like in this fiddle, or read here.
I have the following div in UIWebView:
<div contenteditable="true"></div>
If the user inserts new line (using the return key in the visual keyboard), and when he is done he clicks on done in the previous/next/done grey visual keyboard, it combines the lines to one line.
How can I avoid it?
Perhaps this JSFiddle can shed some light onto what's happening within your application. If you type some lines in the top DIV (gray background color), the HTML code that you get as the return value of its innerHTML property will first display in a textarea field below it (including HTML tags formatting). As you will soon see it's not merely what you'd expect to handle in your application ('line one' + CRLF + 'line two'...), but it also contains HTML elements separating lines one from another. That's how browsers are able to display contenteditable DIVs as if they're 'memo' type controls - by parsing their HTML (that's what browsers do). This HTML formatted text is also how your application receives user submitted text, and there you have to decide what to do with this formatting. You can either strip them away (which is, I suspect, how you set that object's property and it deals with that for you) replacing HTML elements like <DIV></DIV> and so on with a space character, or choose (with your control's property, or in code) to handle this formatting whichever way you'd like them to be handled. I'm not familiar with UIWebView though, and you'll have to find on your own how to retrieve complete HTML formatted values that you want to apply to the next DIV element that you're displaying (or same one that you're assigning new values to).
UPDATE: After searching the web for UIWebView reference, I've actually stumbled across one related thread on SO that shows how to retrieve innerHTML value of an element in your underlying HTML document:
//where 'wView' is your UIWebView
NSString *webText = [wView stringByEvaluatingJavaScriptFromString:#"document.getElementById('inputDIV').innerHTML"];
This way you'd be able to retrieve the whole innerHTML string contained within the contenteditable DIV that you use in a webText string variable and parse its HTML formatted text to whatever suits your needs better. Note though, that different browsers format contenteditable DIVs differently when Enter Key is pressed and some will return the next line enclosed in a new DIV, while others might enclose it in paragraph P and/or end the line with a break <BR> or <BR />, when shift+enter were used together to move to the next line. You will have to account for all these possibilities when processing your input string. Refer to the JSFiddle script I wrote using your UIWebView component to check what formatting applies.
Of course, in your case, it might be simpler to replace your contenteditable DIV with a textarea that will return more commonly formatted \n end-of-line (CR+LF). DIVs however are easier to design, so choose whichever suits your needs better.
Cheers!
I don't believe there's a solution to this from the objective-c side of the stack. The standard HTML- element only delivers a single string. It might be possible to achieve through some javascript magic or similar on the web-end of things.
My HTML-skills are not up to scratch but if you also control that end perhaps changing the to a textArea might help?
Alright, So I have an issue that is a bit weird. I am using a RichTextEditor and have allowed the user to re-size it. All the controls have been stripped away to a main toolbar such that the RichTextEditor just looks like a box with text in it. I have an issue where when I save the htmltext generated by the editor and then re-render it later it always adds an extra line break at the end of the text. I've found that this is due to the paragraph tag, and since I want the user to be able to align text I have to keep it. Does anyone know how to strip this last line break without stripping all the formatting?
I hacked a fix for this, basically involves stripping the last closing paragraph tag </P>. RichTextEditor is ugly :(
This is absolutely a bug, and it is triggered by setting the "htmlText" property instead of the "text" property. This occurs whether you assign it in code, or cause the designer to set "htmlText" instead of "text" by checking the "render as html" button in the properties for the text field. Also of note, this only occurs on "input" type TextFields. And if you start with a "dynamic" type textfield and subsequently set "type" to "input" (also have to set "selectable" to true or cursor will be invisible (another bug)), you will see the extra line appear right in front of your eyes. Again, this does not effect dynamic text fields, just those in input mode.
Despite the fact that the htmlText property is identical in both cases whether you assign a string like "Hello" to text or htmlText (the htmlText value generated is identical for either), the extra line only appears when setting the htmlText property.
Specifically, it occurs when you set htmlText to a string that actually contains html paragraph tags. If you just assign htmlText some text like "Hello", the problem will not occur. On the other hand, if you assigned htmlText <p>Hello</p> or you assigned htmlText to itself (which you need to do to preserve the html and force the internal metrics to update immediately), then the problem occurs. Someone mentioned, if you omit the closing </p> tag, the problem won't occur, and that's true. It's also true that assigning something like <a>Hello</a> won't trigger the problem.
So in summary, this problem occurs only when one sets the htmlText property of an auto-sized, multiline, input type text field to a value that contains <p></p> tags. It does not occur with dynamic text fields, nor does it occur on input text fields that are not autosized, nor does it occur on those who are autosized but not assigned <p> tags to htmlText.
To reproduce this problem, set up a text field in the designer and make sure the background and outline is turned on so you can see the size of the field, then it will be a single line high (multiline text field) as expected (assuming it's wide enough). If you then go to the code and set txtfld.htmlText = txtfld.htmlText (set it to itself), this mere assignment of htmlText property (to it's own same value) causes an additional line to be added. And the value of htmlText is in fact the same, it hasn't actually snuck in an extra <p> tag or anything... it just displays this trailing return that shouldn't be there. As expected, the same thing occurs when you check "render as html" in Flash properties for the text field, which seems to cause it to set htmlText instead of text, and causes the problem to appear.
It's unlikely that there are actually two rendering modes, since it technically always renders htmlText (i.e. htmlText always has a value, and you could always set the text format of some segment of the text with setTextFormat, which was originally assigned with "text", and that doesn't trigger some kind of switch to "html rendering mode" or anything like that.
The behavior seems to strictly come as a result of assigning htmlText property.
The only way to avoid it (aside from setting htmlText, reading back the value, stripping the last </p> tag off, and reassigning it), is to just initialize all your text fields as plain "text", and then manually apply the formatting through calls to setTextFormat( TextFormat, beginIndex, endIndex).
The true catastophe of this bug, as mentioned in the original problem post, is that you cannot save and restore the htmlText value of a TextField, because setting htmlText to a string containing html (specifically the p tag), causes this extra line to be added, compounded by the fact that if you specifically want the textfield to be sized right, you'll probably have autosize turned on, and that's specifically when this problem creeps up and ensures the size is NOT right.
I had a similar headache with flex html text components. Flex does not have proper support for many html cases. You'll see extra padding for <p> and <li> all the time. Heck, there isn't even support for the <ul> tag. If there is a line break in a normal text, flex appends extra padding at the end of the tags and removing this line break will remove the extra padding.
However, you might want to use something like this: http://code.google.com/p/flex-htmlfilter/
I'm new on this particular project, and I've been tasked with resolving an issue that's appearing in IE8.
If you check http://funds.ft.com/ETFHomepage.aspx, There's a section called "News". In that section, there's a column called "Most Popular ETFs". This should be the same width as the "Recently Viewed ETFs" column.
For reference, this page is appearing correctly in Firefox. Can somebody please point out what I can do with CSS or (some other means)* to resolve this?
*I know the best way to resolve this issue is to scrap the terrible design and implement it correctly!! :-) -- we're actually doing that right now. It's a big job, so it's taking a long time. In the mean time however, we have to fix the bugs as they appear. Thanks
Update: just to note what I've said to Hristo, "I think the problem is with the table (rather, nested tables) on the left. The table in the center has its width defined by the image, and the table on the right doesn't have an image so it gets crushed"
Well the reason this is happening is because of the url you have under the "Alphaville: Overcoming the Volcker rule, with ETFs" header. Since the url has no whitespace in it, the table tries to give it space. So there are a couple of ways to fix this problem:
Plain text urls aren't very becoming on a webpage (especially when they're not in anchor tags so you can click on them.) Could you update the content so that you don't have a raw url in your content?
If you must be able to handle long lines of text with no whitespace then you need to figure out how to change the layout of the page so it forces the text to either wrap or clip to fit the container. Try playing around with putting "table-layout: fixed" on your tables to force the column widths to be sized based on the table's specifications only (instead of content). Firefox seems to be wrapping on dashes and slashes in the url whereas IE only wants to wrap on the dashes in the url.
I would say your layout is fine, and you just need to fix the content generation so it doesn't include any long plain text urls (option 1 above)
EDIT: If you do decide to go with option 2 above, then look into the css rule "word-break: break-all". It is IE only and it forces the text to break as soon as it reaches the end of the container. Not good for words, but it works for url's. So you couldn't apply this to the whole news table, but you could to just the cell that contains the url.