[Pro] 19999px

Freeway
1

This is the second website where FWP6 begins having “weird” problems when an inline element reaches/exceeds 19999px in length. The entire containing element may collapse - and when forced back begins not showing selection handles for lower page items (usually clicking an item name in Site inspector takes you to the item, but not after this happens). Items lower down may “disappear” or appear garbled. The page stops growing to fit content, and length must be added manually.

The reason I’m focusing on 19999px is that is where my inspector was pegged after the first collapse, after adding lots of content. Any ideas solutions, etcetera. If SP is aware of this as an issue, or if I’m making a first report.

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

2

Wow. That is indeed weird.

The only behavior I’ve seen from FWP6 that’s even close to this is occasionally it’ll get confused and replace whatever width I have with a ridiculously high number. I’m not sure if it’s 19999, but I do recall that it has a lot of 9’s in it.

Sorry I couldn’t be more helpful.

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

3

As a follow up, here is another screenshot to show another aspect of the
issue:

Scrolling down on a long page “bunches” the visual representation of the
content - there is nothing wrong with the actual contents, but in every
case - whether one inflow item is stretched by content longer than 19999px
or the page length itself is stretched beyond some point, these visual
display problems become unavoidable.

As a practitioner of semantic inline or inflow construction in FWP, I would
prefer to have my page content be contained and identified in a single
container. However, I am not completely opposed to splitting up the content
into sections - as long as there is a semantic reason to justify this - and
which I have now done in this case, which seems to have ameliorated the
issue for now.

I could also adjust the way I work to minimize the impact of this issue,
however, I am loathe to adjust my design philosophy if the sole reason is
as a workaround for the software’s deficiency - which is what I believe
this must be. You can make pages and items longer than 19999px but I am
experiencing such diminishment in function as to discourage the use of the
software. As I know one other user who has had this problem with
long-content pages, it can’t be just me.

–
Ernie Simpson

On Tue, Jun 25, 2013 at 7:48 PM, The Big Erns email@hidden wrote:

Length Limits FWP6

This is the second website where FWP6 begins having “weird” problems when
an inline element reaches/exceeds 19999px in length. The entire containing
element may collapse - and when forced back begins not showing selection
handles for lower page items (usually clicking an item name in Site
inspector takes you to the item, but not after this happens). Items lower
down may “disappear” or appear garbled. The page stops growing to fit
content, and length must be added manually.

The reason I’m focusing on 19999px is that is where my inspector was
pegged after the first collapse, after adding lots of content. Any ideas
solutions, etcetera. If SP is aware of this as an issue, or if I’m making a
first report.

Length Limits FWP6

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

4

Sorry I couldn’t be more helpful.

Thanks for even looking Kelly… you speak of strange widths, but let me be
clear that I am speaking only in the vertical dimension. Specifically,
inline or inflow containers that approach or exceed 19999px in the working
area or working “page” areas that exceed that neighborhood. That this has
happened to me and 1 other user that I know of indicates that it is a
repeatable issue, just not yet a predictable one.

I’d love to do more testing to chase down all the particulars, but my
Softpress R&D budget is already overdrawn.

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

5

I’m resurrecting this thread because now I have had time to replicate the
issue and think I understand it better.

See this first - thebigerns.com

I’ve had a couple of major websites with this issue now. Both have serial
content which explosively grew beyond their original scope. Ideally, I
should have fallen back (pushed forward?) to a managed content system - but
before y’all start battering me with those comments, can we just focus on
the FWP issue?

This example (as my other actual sites) are all inline or inflow
construction (“box model construction” to some of you). Within my main
content element, I would have serialized product containers (HTML5
articles). They served as templates for items that were added. Items that
are deleted are simply select and delete. So when the business activity for
these clients began growing, so did the number of available products. My
FWP pages got longer and longer, and as they did I began encountering
strange problems.

Problem #1 - the “garbled screen” problem

The closer a FWP workspace “page” gets to 19,999 px, the screen begins
doing strange things. Scrolling after some point down the workspace results
in a garbled screen. On a long enough page it is unavoidable, inevitable.
If you open my FWP document and use the Site pane as a shortcut to the page
bottom, say, selecting the 14th article item – and then try any scrolling
method to continue down, the screen bunches up. Check it out.

Problem #2 - the “hidden selection” problem

On longer pages, after some point individual items no longer display
selection “handles” - the only way I can tell if an item is selected is by
the visual feedback of the Site/Item pane. Worse, longer documents will
also stop showing the text-selection highlight so there’s no way to know
where your insert cursor is, what text you’ve selected, and so forth. Not
impossible to do, and almost as fun as having an icepick repeatedly jabbed
into your eye sockets. Go to the article15 item and try selecting any child
box or item.

Problem #3 - the “auto-growth” problem

As I duplicate or add more items to my FWP construction, Freeway Pro will
grow the workspace page length to accommodate the new content. UNTIL the
page reaches 19,999px in length. Exceeding this dimension will cause your
inline construction to collapse - get used to X’s in the Site/Item pane. At
This point, FWP will no longer grow the page length for you - you must
manually expand the workspace yourself - from 19,999px to 32,767px
(Freeway’s self-imposed maximum length).

…

I can only assume the previous silence on this issue has been because of
inexperience with it. Yippee, I’m a pioneer! What I would really like to
hear from Softpress about this is A) Yes, we know about this… and B) This
is what we plan to do or not do about it.

And of course from any Freewayers who’ve had similar issues, or who have
played with my files and come up with solutions – like, for example, that
the whole screen-garble thing can be held at bay by NOT placing the
serialized items into a single big container… Yes, while I cannot say how
long a container can get without causing problems, I’ve found that a
temporary solution was to break up long containers into smaller ones. This
seems to have gotten me past much of the garbled screen issue, but not the
hidden selection problem.

–
Ernie Simpson

On Wed, Jun 26, 2013 at 4:51 AM, Ernie Simpson email@hidden wrote:

Sorry I couldn’t be more helpful.

Thanks for even looking Kelly… you speak of strange widths, but let me be
clear that I am speaking only in the vertical dimension. Specifically,
inline or inflow containers that approach or exceed 19999px in the working
area or working “page” areas that exceed that neighborhood. That this has
happened to me and 1 other user that I know of indicates that it is a
repeatable issue, just not yet a predictable one.

I’d love to do more testing to chase down all the particulars, but my
Softpress R&D budget is already overdrawn.

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

6

Keith at Softpress Support sent this helpful reply:

Hi Ernie

I think you will find that all web design apps have a max limit for page height, and I believe this was once a universal value of around 16,000 pixels. Since then many of the others have upped this to 32,000 pixels, but Freeway’s max limit remains at around 16,000 - though I’ve heard talk of it being increased some day. When that might be is something I’m afraid I can’t answer.

The reason for the limit was probably due to the time taken for very long pages to load (and other general bandwidth issues), which would possibly explain why it has been extended to double that limit since faster speeds are becoming the norm on the internet. The jury is still out, however, on whether extremely long pages are particularly user-friendly and many designers choose to spare mobile device users getting blisters from excessive swiping, while others - especially those who build pages which have regular articles added - see nothing wrong with pages of 20,000-plus pixel pages.

The problem of the display glitches and other odd behaviour has been passed on to our developers. Interestingly, FW5.5 and earlier incarnations of Freeway often simply chose to carry on working fine well past the max limit, which meant that some users would only report problems when they found that Freeway had stopped publishing past a certain point. Although the max limit is stated to be “around 16,000 pixels” it can vary a little depending on the vagaries of font size rendering in various browsers.

As you correctly point out, the max limit does not apply to content management system pages and sites which are populated dynamically.

Often it is as helpful to know the weaknesses of a software as it is to know it’s strengths. Although it is often near-to-impossible to get anyone to reveal the limits.

In this case, it is a relief to know exactly what is causing my headaches so that creative me can design a different construction method around the problem. So, what are these pitfalls to avoid?

  1. Long Content Containers – It’s been my habit for a long while now to use specific containers to designate content. I still think that’s the right way to go, but if I’m to continue using FWP as a construction tool, then I have to be careful about letting them become too long. 16,000px Y factor for single containers should avoided, and pages longer than 19,999px should be carefully considered and closely monitored.

  2. Page lengths between 19,999px and the FWP maximum of 32,767px – there seems no way to avoid the selection issues that I’ve noted… so avoiding those page length extremes in Freeway Pro is how to resolve that. Managed content and dynamic systems resolve that by using the browser to assemble pages – and the browser in this respect seems so much more robust than Freeway. I’ve already a lot of pressure to work this way from the start, this may just be the straw that forces that inevitability.

I’ve avoided that direction simply because I enjoy using Freeway Pro, and CMS solutions are Frankensteinishly bolted on and controllable through mostly use of fire and threats of violence. Dynamic systems require more brainpower than I am able to generate for very long, but either case is doable - although perhaps more easily without FWP.

Well, next step is up to me, how to figure this out. Wish me luck*.

(*) most people forget that luck comes in two flavors - good and bad. If you’re gonna wish me luck, please remember to specify which kind. It’s my personal belief this omission explains much about my life in general. :slight_smile:

On 14 Jul 2013, 10:24 pm, The Big Erns wrote:

I’m resurrecting this thread because now I have had time to replicate the
issue and think I understand it better.

See this first - thebigerns.com

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

7

My God Man, what kind of CMS have you been trying? Besides Wordpress that is. You may need to test the waters again, they aren’t all as ugly and difficult as you seem to think. Besides, that kind of talk will scare the natives.

Todd

I’ve avoided that direction simply because I enjoy using Freeway Pro, and CMS solutions are Frankensteinishly bolted on and controllable through mostly use of fire and threats of violence. Dynamic systems require more brainpower than I am able to generate for very long, but either case is doabl

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

8

My God Man, what kind of CMS have you been trying? Besides Wordpress that
is. You may need to test the waters again, they aren’t all as ugly and
difficult as you seem to think. Besides, that kind of talk will scare the
natives.

Lol, it’s the natives posting their own experiences here that scare me and
have me thinking “Boy am I glad that I’m not the unlucky soul having to
figure THAT one out!”

But you are right, and I expect Walter to join you any minute with a
well-earned “I told you so”. Sigh.

While you may be the CMS Whisperer around here, I’m still bringing my
cattle prod to the party :stuck_out_tongue:

Any recommendations? What i’ve needed to serialize are simple, small
product descriptions with at least an image – like here:

http://industrialmarketing.com.au/drillrigs.html

http://pensbylarry.com/index.html

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

9

CMS Whisperer? Now I’m laughing. You would be amazed at how much I struggle with some CMS. If a CMS were a watch then sometimes I feel like I’m trying to repair it while wearing oven-mitts.

Well, Pulse and of course WebYep have proven great simple options that work a treat with FW. Personally I think Pulse has a better “feel” but that’s me.

Todd

While you may be the CMS Whisperer around here, I’m still bringing my
cattle prod to the party :stuck_out_tongue:

Any recommendations? What i’ve needed to serialize are simple, small
product descriptions with at least an image

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

10

Something this structured could be done in almost any CMS, but if I were doing it, I would just write something site-specific. You have a picture, a product id and name, and a description. This is a job for MiniActiveRecord or similar, and a very small amount of simple PHP code.

Walter

On Jul 15, 2013, at 11:56 AM, Ernie Simpson wrote:

Any recommendations? What i’ve needed to serialize are simple, small
product descriptions with at least an image – like here:

http://industrialmarketing.com.au/drillrigs.html

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

11

For what it’s worth, I thought I’d resurrect this old thread to say that I’m having the exact same behavior that Ernie has so clearly outlined at the beginning of this thread w/ FW 7.1.

The page where I experienced the problem was this one.

As Ernie discussed above, long web pages are not ideal, but for a variety of reasons, sometimes they are necessary or something we need to deal with. At the vary least, it’s good to know FW’s limitations. Hopefully, at some point, these limitations can be expanded/eliminated.

Doty

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

12

Opps, I forgot to add, on the link I referenced to above login/password WEB/developer will get you in!

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options