Lost paragraphs, gradient and scroll

LaRetta · October 15, 2016

I'm placing a web viewer on a layout in place of a regular note text field to provide User a scroll bar in long notes. However, when I do so, I lose paragraphs and all data runs together into a single paragraph block. Is there a way I can adjust this so paragraphs are preserved?

web viewer paragraph.png

Also, I just noticed that, although it scrolls fine on laptop, it does not allow scrolling on ipad. Is there a way to do this? We do not need to modify the field, only scroll it. Thank you!

Edited October 17, 2016 by LaRetta
added more info to the subject

doughemi · October 15, 2016

Try

Substitute(cas_NOT_Note::description; "¶"; "<br>")

LaRetta · October 15, 2016

Thank you! I shall try that! Also, it now allows scrolling on ipad; not sure why it didn't when I first opened it. Much appreciated!

That works perfectly, thank you so much.

I have one other issue ... I get a white background no matter how I set the style. I had saved a snipet awhile back from Brian Schick which said:

"data:text/html," &

"<html style= \"background: #" & hexColor & ";\">" &

GetAsCSS ( fieldName ) &

"</html>"

... however, it will not take the hexColor (saying it is invalid). I suppose it was a custom function? Would anyone know how to make it work here? I've tried some things I've found through Googling, such a <div> (class="transbox") but nothing I try works.

comment · October 15, 2016

26 minutes ago, LaRetta said:

I get a white background no matter how I set the style.

Uhm ... what color do you want it to be?

doughemi · October 16, 2016

Use the Color Picker in the Inspector to set up the color you want (using the "other color" button). Then copy the hex number and paste it, replacing "hexColor".

Edited October 16, 2016 by doughemi

LaRetta · October 16, 2016

The popover it is on is gradient so I'd like transparent but if not, I would like RGB 240:240:240 ( hex color F0F0F0 )

Thank you both! I hope this is correct - at least it works!

"data:text/html," &
  "<html style= \"background: #" & "F0F0F0" & ";\">" &

Substitute ( GetAsCSS ( cas_NOT__Note::description ) ; "¶"; "<br>" ) &

"</html>"

comment · October 16, 2016

I don't think a web viewer can be transparent. For a fixed color, try:

"data:text/html;charset=utf-8,<body style='background-color:rgb(240, 240, 240);'>"
&
Substitute ( YourTable::YourField ; ¶ ; "<br>" )
&
"</body>"

It's also possible to have a gradient background, but it will be difficult to match it exactly against your existing one.

Edited October 16, 2016 by comment

doughemi · October 16, 2016

Gradient's a little tougher. See this page.

Note that you will not be enclosing the background statements in a .gradientbox { }; you are covering that with the style="" construct.

doughemi · October 16, 2016

Using the example code on the page I referenced, I got a pretty good match like this:

Copy the web viewer code and paste it into bbedit or other editor.

Using the magnifying glass in the color picker, choose the color of the background at the top of the web viewer (use a temporary graphics block for this) . Find and replace the first hex number in the Gradient() statements with the hex number in the color picker.

Repeat with the color at the bottom of the web viewer and the second hex number in the Gradient() statements.

Copy and paste the code into the web viewer.

Edited October 16, 2016 by doughemi
added image

LaRetta · October 16, 2016

I got this working nicely using Comment's example and it looks great on iPad but we can slightly see the color difference on Mac. I just got your last response, Doug, so I am willing to try the gradient but I am unsure how to incorporate it into the current code. It looks like I would need to include all lines so it is completely compatible with older browsers, right?

What portion of Michael's code do I replace with the .gradient section? I will bet that Comment is correct about it being difficult to match but I want to give it a try anyway. :-)

Michael's code:

"data:text/html;charset=utf-8,<body style='background-color:rgb(232, 232, 232);'>"
&
Substitute ( cas_NOT__Note::description  ; ¶ ; "<br>" )
&
"</body>"

Gradient values:

.gradientBox {
background: #f0f0f0; /* Older browsers */
background: -moz-linear-gradient(top,  #f0f0f0 0%, #e8e8e8 100%); /* FF3.6+ */
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#f0f0f0), color-stop(100%,#e8e8e8)); /* Chrome,Safari4+ */
background: -webkit-linear-gradient(top,  #f0f0f0 0%,#e8e8e8 100%); /* Chrome10+,Safari5.1+ */
background: -o-linear-gradient(top,  #f0f0f0 0%,#e8e8e8 100%); /* Opera 11.10+ */
background: -ms-linear-gradient(top,  #f0f0f0 0%,#e8e8e8 100%); /* IE10+ */
background: linear-gradient(top,  #f0f0f0 0%,#e8e8e8 100%); /* W3C */
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#f0f0f0', endColorstr='#e8e8e8',GradientType=0 ); /* IE6-9 */
}

I also realized that I want an overflow scroll so I'll need to include this part and I do not know where that would go.

div {
    width: 700px;
    height: 500px;
    overflow: scroll;
}

This all makes me feel like I did when I first saw complex FM calculations and didn't understand how the syntax of the various functions fit together.

I really appreciate both your help on it! :wink3:

doughemi · October 16, 2016

HTML5 is indeed heavily laced with WTH.

See if this helps.

gradientWebViewer.fmp12

EDIT: This code will make any HTML coder shudder, but the bottom line is, it works in the web viewer. Best practice is you're supposed to keep the CSS (the style="" stuff) separate from the HTML stuff.

1 hour ago, LaRetta said:

I got this working nicely using Comment's example and it looks great on iPad but we can slightly see the color difference on Mac.

Different screen color calibrations will do that.

Edited October 16, 2016 by doughemi

comment · October 16, 2016

You are mixing two different ways to specify a style. The so called in-line style is specified in a style attribute of the HTML element being styled (that would be body in my example). The other way you show:

div {
    width: 700px;
    height: 500px;
    overflow: scroll;
}

is a CSS stylesheet (which can be either external or internal). And it wouldn't do anything in your example, unless you had a div element in your HTML code.

To specify a gradient using in-line style, try:

"data:text/html;charset=utf-8,
<body  style='
background-color: #e8e8e8; /* fallback */
background: linear-gradient(to bottom, #e8e8e8, #cecece); /*standard*/
background: -webkit-linear-gradient(top, #e8e8e8, #cecece); /* Safari 5.1 */
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr=\"#e8e8e8\", endColorstr=\"#cecece\"); /* IE 5.5 - 9.0 */
'>"
&
Substitute ( Table::Description ; ¶ ; "<br>" )
&
"</body>"

I am not sure how much support for the older versions is required; is it even possible to have them on a system that supports the .fmp12 format?

To add that div wrapper you have mentioned, you could do:

"data:text/html;charset=utf-8,
<body  style='
background-color: #e8e8e8; /* fallback */
background: linear-gradient(to bottom, #e8e8e8, #cecece); /*standard*/
background: -webkit-linear-gradient(top, #e8e8e8, #cecece); /* Safari 5.1 */
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#e8e8e8', endColorstr='#cecece'); /* IE 5.5 - 9.0 */
'>
<div style='width: 700px; height: 500px; overflow: scroll;'>"
&
Substitute ( Table::Description ; ¶ ; "<br>" )
&
"</div></body>"

But I don't see what this is supposed to achieve; I am getting a weird result showing another scroll bar within the web viewer that already has a scroll bar.

Edited October 17, 2016 by comment

LaRetta · October 16, 2016

16 hours ago, comment said:

I am getting a weird result showing another scroll bar within the web viewer that already has a scroll bar.

Please forgive the detail of this response but (to me) it is important to understand this inconsistency. Testing with FMPA14 on 10.11.6 and Go14 ...

Using the calculation with scroll from either Doug or Comment (on laptop):

The web viewer size is 705pt wide x 505pt high, I get the double, ugly scroll as seen in WithScroll_Larger.png. I put those numbers into the WV calculation. Scroll still will not show on iPad. Increasing the numbers larger than the WV always shows the ugly double scrolls.

When I reduce the WV calculation numbers to 650pt wide x 450pt high, the second scroll disappears as in WithScroll_smaller.png - and it looks nice! But still, scroll does not appear on iPad.

The final shot is without div wrapper WithoutScroll.png.

Since scroll disappointingly isn't showing on iPad, and since it looks just as nice without scroll specified on desktop, I'll leave the div wrapper off and use Comments first calculation (in his last post). But the gradient looks perfect on iPad although when I change the size of the popover, it changes the gradient and I do not want to correct it all the time for various popovers so it will never be perfect. Still, it looks better than (and isn't as obvious as) solid color.

I had captured the colors just at the WV field itself, but I just realized that the gradient shift is over the span of the popover and not just the WV so to get closest match of gradient, I need to capture the color at the top of the popover and then bottom of the popover. wrong ... must capture colors right at the WV itself.

Thank you both for helping me with this issue. Maybe scroll only appears on iPad if it is a regular data field which is enterable. Overall, I'm quite pleased. :smile3:

Added: It appears that file names do not appear. First shot is WithScroll_Larger, second is WithScroll_Smaller and third shot is WithoutScroll.

Edited October 16, 2016 by LaRetta
crossed out incorrect sentence about capturing color

comment · October 16, 2016

13 hours ago, LaRetta said:

it is important to understand this inconsistency.

The only thing I know for sure is that the iOS Safari browser is different from the MacOS Safari browser. So inconsistencies are to be expected.

Earlier I asked what do you expect to achieve by adding the div wrapper. I believe you have two options here: either let the text wrap to the width of the web viewer object, or let it be wider than that and let the web viewer have a horizontal scroll bar, in addition to the vertical one. For the first option, you do not need to add anything. If you want the second option, I think this should work (I have no way to test it):

"data:text/html;charset=utf-8,
<body style='width: 2000px; overflow: scroll;
background-color: #e8e8e8; /* fallback */
background: linear-gradient(to bottom, #e8e8e8, #cecece); /*standard*/
background: -webkit-linear-gradient(top, #e8e8e8, #cecece); /* Safari 5.1 */
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr=\"#e8e8e8\", endColorstr=\"#cecece\"); /* IE 5.5 - 9.0 */
'>"
&
Substitute ( YourTable::YourField ; ¶ ; "<br>" )
&
"</body>"

Note the 2000px value: it determines the maximum width a text line can be before it wraps. IOW, it controls how much you have to scroll horizontally. If you make it less that the width of the web viewer itself, text will wrap before it reaches the right border of web viewer.

Edited October 17, 2016 by comment

LaRetta · October 16, 2016

1 hour ago, comment said:

Earlier I asked what do you expect to achieve by adding the div wrapper.

We have the native WV scroll which is automatically displayed for Users on desktop, to scroll the long note if more than will fit on screen. The only thing left that I cannot achieve is showing the scroll in same way when on iPad. There is no indication that there is more text than will display AND if a User simply flicks the field in an attempt to scroll it, it does not scroll. The User must first tap the field and then they can flick it to scroll.

I was hoping that, by displaying a scroll bar if there is more text than fits (like it does on desktop without div or overflow scroll) that it would be simpler for iPad users.

All I meant about 'inconsistency' is when it displayed TWO ugly scrolls and that only happens when we set the calculation width wider (or taller) than the actual web viewer field. Thank you for explaining how to control the scroll width (using 2000px as example). This is all good information for future. Since no methods display scroll on ipad, I will stick with calc which drops the scroll and let the native WV scroll itself handle it for desktop. Ipad Users are simply SOL. :-)

comment · October 16, 2016

33 minutes ago, LaRetta said:

Since no methods display scroll on ipad,

That seems like a bug. I wonder if it could be traced to the critical factor. Surely you can scroll if you point the web viewer to a site, say here?

LaRetta · October 17, 2016

I changed to WV to point to this link here.

On iPad, it does not display the scroll when I first open the popover. And it will not scroll by swishing it (the WV). There is no indication that there is more data off-screen below. I must tap the web viewer and then it will allow me to swish (scroll) up or down. Once I have scrolled once, a scroll (tiny bar) appears on the right which is silly since I can't slide it - I can only swish up or down on the WV field. And it disappears again anyway after I stop swishing.

If I leave the popover and go back in, I must again tap into the field before it will allow scrolling. If I swish it before tapping, it will not scroll. Maybe that is normal but I find it unintuitive. Is this what you mean by 'critical factor'? I Googled it and it seems to be similar to PEBKAC; meaning me.

comment · October 17, 2016

6 minutes ago, LaRetta said:

Once I have scrolled once, a scroll (tiny bar) appears on the right which is silly since I can't slide it - I can only swish up or down on the WV field. And it disappears again anyway after I stop swishing.

But that's how browser scrolling works on iOS in general. Just open this page in Safari (not in a web viewer) and see how it scrolls there.

9 minutes ago, LaRetta said:

Is this what you mean by 'critical factor'?

I meant if there were a difference between how a "regular site" scrolls and how your web viewer scrolls (or doesn't), then we should find the one thing that causes the difference. But now I think there is no difference.

flyjar · October 17, 2016

The workaround that I've used for the iOS "tap then scroll" issue is to have a script trigger that goes to the webviewer object. If it's in a popover, you could trigger the script when the popover opens. It's not perfect, but will work most of the time. If the webviewer loses focus, the user will need to tap it again before scrolling.

Hope this helps.

Sent from my iPhone using Tapatalk Pro

flyjar · October 17, 2016

One other note I'll add...

When you set the background of the a webviewer's body to be a gradient, the gradient will stretch to the length of the content and will scroll with the content. If you want the gradient to be fixed to the height of the webviewer and have the content scroll over it, you need to add this after all of the various gradients in the body style tag:

background-attachment: fixed;

With this, the gradient will fit the visible height of the body and the content will scroll while leaving the background in place.

comment · October 17, 2016

4 hours ago, flyjar said:

If you want the gradient to be fixed to the height of the webviewer and have the content scroll over it, you need to add this

Ah, that's a good point. I was so excited to see the gradient scrolling, I didn't even think this might not be the wanted result.

Another fix: this part:

filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#e8e8e8', endColorstr='#cecece'); /* IE 5.5 - 9.0 */

needs to be changed to:

filter: progid:DXImageTransform.Microsoft.gradient(startColorstr=\"#e8e8e8\", endColorstr=\"#cecece\"); /* IE 5.5 - 9.0 */

LaRetta · October 17, 2016

Hi Flyjar,

I have object-named the WV and attached a trigger OnObjectEnter to the popover which goes to the object. That solves the issue that the field is not scrollable, thank you!! I have also modified by adding the additional background line; much appreciated.

Hi Michael,

I've made the additional 'filter:' change you've indicated. Since iOS will not display the scroll like default desktop, I've dropped that portion from the code. The final then, looks like this (I hope I've adjusted everything properly):

"data:text/html;charset=utf-8,
<body style='
background-color: #f0f0f0; /* fallback */
background: linear-gradient(to bottom, #f0f0f0, #e8e8e8); /*standard*/
background: -webkit-linear-gradient(top, #f0f0f0, #e8e8e8); /* Safari 5.1 */
background-attachment: fixed;
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr=\"#e8e8e8\", endColorstr=\"#cecece\"); /* IE 5.5 - 9.0 */
'>"
&
Substitute ( cas_NOT__Note::description ; ¶ ; "<br>" )
&
"</body>"

I have one final question and it probably isn't possible but I'd like to check since I'm not very familiar with web viewers:

Does the web viewer know that there is more data than will fit in the field? It must somehow know since it will scroll if so but not scroll if not needed. It also must know since on desktop, it produces the default scroll if more than will fit. If the web viewer knows, is there any way that WE can glean that information?

I sure appreciate everyone's help.

Added: I want to know if more than will fit so I can place text below the web viewer with "scroll for more" but use Hide calculation if not.

comment · October 17, 2016

1 hour ago, LaRetta said:

If the web viewer knows, is there any way that WE can glean that information?

It should be possible, for example by calculating (in Javascript) the difference between the height of the body and that of the window. However, I don't know if these methods are implemented in Safari Mobile, and it would be cumbersome to get the result out of the web viewer in order to control the visibility of a layout object.

Perhaps a more practical solution would be to force the scroll bars to appear. I was directed to: http://simurai.com/blog/2011/07/26/webkit-scrollbar. I tried to adapt it to your situation, but I have no easy way of testing it, so this is "blind":

"data:text/html;charset=utf-8,
<html>
<head>
<style>
body {
    background-color: #f0f0f0; /* fallback */
    background: linear-gradient(to bottom, #f0f0f0, #e8e8e8); /*standard*/
    background: -webkit-linear-gradient(top, #f0f0f0, #e8e8e8); /* Safari 5.1 */
    filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#f0f0f0', endColorstr='#e8e8e8'); /* IE 5.5 - 9.0 */
    background-attachment: fixed;
}

::-webkit-scrollbar {
    -webkit-appearance: none;
    width: 7px;
}
::-webkit-scrollbar-thumb {
    border-radius: 4px;
    background-color: rgba(0,0,0,.5);
    box-shadow: 0 0 1px rgba(255,255,255,.5);
}
</style>
</head>
<body>"

&
Substitute ( cas_NOT__Note::description ; ¶ ; "<br>" )
&

"</body>
</html>"

LaRetta · October 17, 2016

The demo in that link is exactly what I want! I copy/pasted it into my WV and, although when I DO scroll on ipad the thin short scroll which displays has increased to three-times its length, it does not stay displayed nor does it display when I first open the popover (when too much text).

I really appreciate you trying, Michael. It would be helpful if iOS would allow control of scroll display, but I'm pleased with the results anyway.

LaRetta · October 17, 2016

Another thing I am going to do is to make the field height so that, if there is more text than can show, only the top half of the text shows so Users know to scroll.

Sign In

Lost paragraphs, gradient and scroll

Recommended Posts

Create an account or sign in to comment

Create an account

Sign in

Similar Content

Important Information