I just have a simple
<div>, created and delivered by the web designer guys, to be used as a panel like so:
<div id="REGPanPasswordStrength" style="margin-top: 0px; text-align: center; width: 30%; background-color: green; color: white;"></div>
Design time panel props are
First Problem: When the form gets rendered, the color style is gone and the caption displays in the parent color, not clWhite!
Then later in the code I do:
PanPasswordStrength.Color := clRed;
PanPasswordStrength.Font.Color := clWhite;
<div> styles remain unchanged! I hunted this down to here:
if IsLinked then
// do nothing!!
So, if I'm right, this means whenever the panel is linked to an HTML Element, most of the properties can no longer be changed using the regular control properties? Is this a bug or by design? Should instead all style properties be set directly by setting the HTML element style props? What are the best practices here?
This by design, when the linking is done, TMS WEB Core assumes CSS is applied to set properties instead. Either you choose to style the component via properties (Pascal way), or you choose to style the div via CSS.
Hm, I see, but does this aproach really meet the typical use case? Isn't web development almost always a cooperation between web designers and programmers? The designers deliver the basic design and the programmers bring it to live. The designers design the traffic light and the programmers make it show green/yellow/red when needed. There should at least be an option weather to use CSS or Properties. And in fact there already are some, but not working as expected from a Delphi perspective.
As a Delphi developer, I would excpect that setting properties just works as usual. At design time as well as at runtimne.
Well then, of course it's still possible to change properties like so:
With PanPasswordStrength do
But this is really not what I would expect as a Delphi RAD user...
We provided a way to link both worlds together. Someone can set properties the RAD way as well as link it to CSS. When the ElementID is set, it ties to the element and then you can set properties via CSS, or via the setProperty. A more finetuned control could be helpful so we'll see what is possible.
In a HTML first approach, it is the HTML / CSS that controls the look & feel of the HTML elements. When you link a control to a HTML element, you use HTML first and thus its visual aspects are controlled by HTML / CSS. This is expected and by design. If you expect your graphic designer to come up with some specific design and your control border or color setting overrules this designer setup, this is not what is expected.
If you want to programmatically want to override visual characteristics, you can do so with control.ElementHandle.style.setProperty()
Otherwise, you do not link to HTML elements and have full control over look & feel via the control properties.
I fully understand, but I think it is arguable to a point. The web designers provide an initial design, like in my example above, maybe for a traffic light. But it is the program that actually makes it switch on/off the colors to show the lights. It is not the static HTML code or CSS that switches the lights.
So, maybe, it's worth considering to have both worlds available.
So, where will the line be drawn?
Only color? What about border settings, font settings, ... ?
It will become highly overcomplicated to introduce options for every possible setting, hence the choice, either it is HTML first (linked) or it is designer first (not linked) but not a mix.
Hm, OK, but why draw a line at all? Why actively disallow the props (If Islinked then no-worky)? Why not just leave them working? What would be the downside if they just keep working, even if the control is linked? Just trying to understand...
That decision would come down to no HTML/CSS based control anymore, every control setting would override it anyway.
For allowing HTML/CSS based control, either the line is drawn or for every possible visual controlling property, there would need to be a setting to let it impact the HTML element or not. Clearly, that would inflate the number of properties, would make the component setup overly complex and is unwanted.
Please accept this as my final answer.
Of course accepted! Hey, it's YOUR product! Just tried to undestand. So thank you for commenting on this!