Created attachment 60642 [details]
user's visual web app to demonstrate the issues

There are suntie Vs designtime time rendering problem.
Assigning to peter for further evaluation.

I mean to say "runtime Vs designtime time"

Looking into it.

Yes, there is a difference between runtime and designtime... investigating.

This is not a bug in the designer (nor runtime). It is only a bad component layout achieved, i.e. the layout used
depends on the size of font used.

The difference is visible because different sizes (widths) of the textfields in this particular layout. The sizes of the
textfields depend on the actual font size used.

In runtime:
In the browser you can try to change the size of the font (in Firefox Ctrl and minus, or Ctrl and plus), and you can see
you can get the same layout like in the designer.

In the designtime:
You can change the default font size: Tools | Options | VisualWeb | Default Font Size. After you change it refresh the
page. When playing with it, you will find out you can achieve the same positions like in the browser.

In sum. The problem in this issue is the layout used. The positions among the components depend on the size of font,
which is not a good layout. Please, fix the layout, then you won't get the surprises like this in your app.

Tried as suggeated. However, the problems can't be resolved. 

For the problems 1 and 2, please refer to the screenshot 133815_1.jpg.

For the problem 3, changing font size in visual editor can't move the label position to the middle in designtime. 
Refer to 133815_2.jpg.

For the problem 5, refer to 133815_3.jpg.

Created attachment 60677 [details]
more screenshots to demonstrate the problems

Examining the last comments.

It seems it is as I said before. I think you misunderstood a bit. Let me try to explain.

The demonstration which I described above, is not there in order to get the current layout fixed. It merely demonstrates
that the layout is done incorrectly.

I.e. you used grid layout panel, which is OK to be used with components with fixed sizes. That is not true with
components which sizes are not fixed (as in your example). In that case, when you change the sizes of text, the sizes of
components change, and the layout gets worse (or better). That you need to avoid in the app.

There are minor thing, like if you have a look, for one texfield you specified its label (Name:), but for the other one
you rather created new label component for it (age:). It means that when you change the text size, the position of the
first textfield will change (adjust), but the other one not, and it will produce bad result.
(For that case I suggest to have also separate label component (Name:) and align the textfields accordingly.

However bigger issues is that the panel (My info), is fixed (absolute layout, and fixed size).  That means, when you
change the sizes of inner text components, their sizes will change (they can grow or shrink), but the size of the panel
(My info) won't adjust.

For that I suggest to remove the fixed size of the panel (and also add there some padding). But that is not enough,
because as long as you have the inner components absolutely positioned the content components, the size won't adjust.
The simplest would be to put the components into some table (with labels and textfields in it) instead of it, and
position the table.

The spaces in the text area, depend on the font used (spacing in it), I guess. The designer (in IDE) and browser are two
different independent applications (so is each browser impl from each other), and each one uses different fonts (all is
adjustable by user + there is also Java fonts difference). So those a bit different spaces depend on font currently used.


Well, I am sorry that the grid panel is not very useful in this layout. The absolute positioning also doesn't work well
in this case.
There is a plan to provide some templates in the future, but at this moment.
For now you need to do some code changes to achieve better layout. Please, try out the suggestions above.

So in sum, this is not a bug, it is more that there is not a better support to solve this kind of issues (but that is
common for other tools, because of the complexity of the positioning schemes).

Thank you for your words. 
I think it's diffcult to solve it but we need a solution for it. The table control is not available in netbeans. I would
like to how to do?

Hi, sorry for later reply. You can just switch to the jsp source and add any html elements into it (like the <table>
etc.)... also there are standard elements, in the palette under "Standard", and its called "Data Table". Please, try one
of those approaches.

*** Issue 134747 has been marked as a duplicate of this issue. ***

*** Issue 134748 has been marked as a duplicate of this issue. ***

I think these two way are not well.

1. html elements <table>,<tr>,<td>
This is not visual, these will be more trouble if using pure HTML elements. In order to adjust position, we will need 
guess. What's more, the HTML elements have no same Look&Feel(css) with VWP element. 
2. Data Table
This element also is data table not layout table. The Look & Feel also is different with VWP element.

I only provided those as examples. The <table> can be used as for layout, but it is not recommended mostly. Instead you
can use <div> (or <span> elems).
Yeah, the data table might not be a good example in case you won't different look.

Anyway, those I provided only as examples, clues.
Basically you need to achieve layout which positions of the labels and textfields won't change (relatively to each
other) when the size of font does.

No NO. I need what is not fixed positions but same position between design time and run time. 

The pure HTML elements,<table>,<div>,<span>,etc, is not <b>visual</b> and different Look & Feel, so we cann't switch 
it.

If there is no way to solve it now, I think, let's keep this topic open. I think it's solved sooner or later.

After all, it's real trouble for customers, if the issue is marked to solved, no one know it.

Thanks!

We probably misunderstand each other a bit.
It is not an issue of designer, i.e. there is not real difference between the designtime and runtime. 
The difference is shown only when you use different sizes of the fonts (and from that that there are also slight font
differences among the applications, which is natural). That is the same kind of difference when you compare among
different browsers (and play with the font sizes).

To realize the above is true, try to play with the sizes of the font you use in the browser and designer and you find
out you can achieve the similar look as long as you use the same size.

In sum, there is only a confusion the designer shows it other way then the browser. It does not.
The real problem is that the layout depends on the font size, which is not good, but that can't be fixed by any change
in the designer, rather in the code itself.
Such layout is bad because when user in the browser adjusts the size of font so it is easier to read for her, then the
layout gets misplaced.

Therefore I am closing it, because there isn't anything I can fix in the designer.

I hope it is more clear now.

I understand that it would be much easier, if there are better components or predefined layouts available, which would
allow this kind of positioning easier, but we don't have them yet. I hope we will have them later. But that is about
different task, not this issue. 
Unfortunately all boils down to CSS layout, which is quite tricky, and when there are issues with it sometimes one needs
to deep dive into it and fix it at that level. Please try to do it too.

Whether or not it is relevance with fonts, it's need seem as bug NOT confusion. Because it's real issue to bring 
customer trouble. What's more, there is no way to escape this type thing.

If the font size is origin source, the solution is simple to change design's font size to same with browse.

In fact, the reason is not font size but different render between designer and browse. I think there must has way to 
let design's render following browse(IE/FF).

So, I hope this topic keep open to wait be solved.

I explain it further.

You said, that if the problem is the font then the font of designer should be the same as the font of browser.
Yes, that would exactly be the solution. Unfortunately that is not possible, it doesn't work that way.

To explain, the browser and the designer (in IDE) are two separate applications. And in both of them the user can adjust
the font and its size accordingly, independently on the other app. Similarly, you can have more browser apps running,
each font set to different one.
That is the reason the designer can't fix it.

Regardless of how I adjusted font size, I cannot get the same position in browse with designer. pls upload the effect 
in browse after adjusted font size.

Two applications, designer and browse, will not be able to guarantee the same render, why? pls try to use dreamweaver! 

It's no good thing to closed this topic only if you cann't fixed it. If we cannot solved it now, it's no matter. Keep 
it open and wait to be solved!

Well, we have some disconnect here. I checked again and I can achieve the same effect in browser and designer when
decreasing/increasing the font size, pretty easily.
I don't understand what it could be that you can't. 
I believe it should be same with Dreamviewer if you put there exactly same produced HTML code.

Please, understand, I am not closing it because I don't want to fix it, but because it is not an issue of the designer
(it is not possible to fix it by changing the designer rendering).
But OK, I leave this open for now, thinking of how to progress. I'd like to get you to understand the problem first.

Peter,
  From the comments below, it looks like grid panel doesn't satisfy the user's needs. There are two possible ways, one
is for us to expose HTML elements so that they can't be used in a Visual JSF page or write a JSF custom component. The
former is within our scope but the latter is not. (It is for component authors or the user). My suggestion would be the
change the subject of the issue along these lines and change it to an enhancement or a feature.

thanks.

OK, Jayashri, I am changing this to enhancement (and also the issue summary)