In the testing of the HTML in Chat option, I noticed an impact on a Text Label that also shows in v3.3.3.-beta1.
The text label in the HTML Chat variant ignores the font size and text colour settings of the Text Label trait, as can be seen from this comparison:
[attachment=1]HTML in Chat - compare text label outputs.jpg[/attachment]
Here is the Text Label trait definition:-
[attachment=0]HTML in Chat - text label definition.jpg[/attachment]
The Text Label value ($prompt$) uses HTML; the value displaying in the text field is :-
<html><p style=text-align:center;> Click on<br> Deck Choice <br>to start<br>or<br>Click HERE to<br>access the board</html>
I gather that $prompt$ is a property that you are generating elsewhere in the module and putting that HTML into it?
This would be one of those situations that led us to put in the “Enable HTML in Chat Log” preference and require either modules or players to opt in to it. So you could simple leave that option as it presently defaults, meaning there would not be any HTML in the chatter (what did the chatter display BEFORE for those text labels? I would have guessed a bunch of html tags, given that’s what the documentation says would happen).
OR you could put “span” tags into $prompt$'s HTML which manually set the stylings you want, which would then cause it to be displayed the same way in the chatter. (possibly bigger than you actually want it in the chatter).
OR you could define your piece name strings (or your reports to the chatter) to not use $prompt$ (e.g. use $BasicName$ and followed up by $nonHTMLversionofprompt$.
Do those make sense?
Brian,
From your reply, I think I’ve given you the impression that the html is in the Chat Log. It is not, it is in a Text Label that displays via a piece on the map. They work fine under v3.3.2 - scroll through the screenshots above to see before and after appearances (screenshots show only the text label not the overall map, which is maybe how I’ve confused you).
It makes no difference what the “HTML in Chat” preference setting is. However, the first and only other time that I have seen this issue was when I responded to your invitation to do some testing of the HTML chat functionality on a special pre-beta build (…-156 ??)
$prompt$ equals this value in both of the example screenshots:
Click on
Deck Choice
to start
or
Click HERE to
access the board
Adding a
before the closing makes no difference.
What does make a difference is to explicitly set font-size in the HTML, the text will then change accordingly. This may provide a workaround but it is not great if Text Label has stopped being as useful as it was before. The impact will depend on how widely HTML is used in the values displayed in a text label; it may not be common but it is highlighted as a capability in the user guide.
It is as though something in v3.3.3 has triggered the Text Label to ignore its own settings for the text; both colour and size, at least. In my example the piece concerned does have two prior values for $prompt$ that display similarly but do set explicit font-size and colour in HTML. I wonder if this triggers the issue, albeit only under Vassal v3.3.3.
I’ve noticed another (possibly) HTML related issue that shows itself in the command bar. I will log a separate thread for that.
Regards,
Mark
Okay thanks for the further information - sounds like something with Text Label has broken so we will need to look into that.
Hi Mark – Could you make us a “minimum demonstration module” that would repro this bug for us? I have a couple ideas about how to fix it, having looked into the Text Label code, but a demo module would help me know for sure. Brian
Here is the demo module requested:
[attachment=0]html text issue.vmod[/attachment]
Label 1 shows expected appearance of the text label albeit without centering (works under all Vassal versions).
Label 2 shows what happens when the text is centered using HTML in the text value.
It displays correctly in released versions prior to v3.3.3-beta1 but thereafter the HTML interferes with font-size and color.
Label 3/3a illustrates a workaround - specify all required attributes in HTML.
Label 4 shows a minor quirk, that may well be expected HTML and applies to v3.3.2 anyway.
Press meta-R (Command on MacOS) to get a report of the text value for each label.
Thanks Mark! So this seems to repro on Windows for me, at least if you agree that the below screenshot is more or less what you’re seeing on Windows.
So you’re saying that having that styled paragraph USED to “work” (use the text label’s colors and stuff) before something new along the way disrupted it?
And that “basic HTML” isn’t broken (still shows up in right color), it’s just that if you “touch it” at all with a style then it forgets all about the other stuff? (I wonder if that’s a JDK change between 8 and 11/14?)
[attachment=0]htmlthing.png[/attachment]
Possibly a CSS scoping issue. Like any CSS now means the label styling is no longer honored.
I’m guessing it could be fixed if we “boxed up” the whole label inside a
where we placed the styling from the Text Label. That’s what I do in the HTML Chatter. But these Text Labels seem to include/require “” tags, which means we’d have to parse for them to get the right place to put our boxing-up div (ugh). Or maybe there’s something else in the little “BasicHTML” library thing that will help out.
Eureka. Fixed it. Will try to get a test build shortly.
After fix:
[attachment=0]htmlthing2.png[/attachment]
Sorry for missing the party but yes, Brian, your before and after screenshots are what I was seeing with the bug (3.3.3) and without (3.3.2).
Joel is making a test build with this + his fix for the Toolbar thing. Up soon for you to test.
Works for me in Joel’s test build, VASSAL-3.3.3-SNAPSHOT-bug13319-61cafd3b4 .
Excellent - thanks so much, by the way, for all your loyal testing work!