RFR: 8294158: HTML formatting for PassFailJFrame instructions
Alexey Ivanov
aivanov at openjdk.org
Tue Sep 12 14:14:41 UTC 2023
On Tue, 12 Sep 2023 13:49:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:
>>> Probably `trim()` and `toLowerCase()` could be useful here.
>>
>> Could be… On the other hand, in post XHTML era, the elements are usually in lower-case. Thus we should stick with it and use lowercase HTML elements anyway.
>>
>> I think `startsWith("<html>")` covers the scenario well.
>>
>> Although neither `<html>` nor `<body>` are required, I prefer to always add them. These two elements don't add much overhead, do they?
>>
>>> Do we consider adding adding one more builder method to force enable html rendering? (e.g. when we just want to highlight only few words/sentences with `<b>` without adding `<html>` tag)
>>
>> I don't think it's needed. If you want the instructions rendered as HTML, you'll have to format them as HTML.
>>
>> Forcing HTML rendering on plain text which highlights a couple of words with `<b>` will render the text unreadable: line ends are ignored by HTML, so you'll have to use `<br>` element to force line breaks. (A similar thing often happens in javadoc where a blank line is added as if to start a new paragraph, but without the explicit `<p>` element the text continues on the same line / paragraph.)
>>
>> It is possible to wrap such instructions into `<html><body><pre>` but what stops you from doing it explicitly if it's what you want? (Note, however, the `<pre>` element disables line wrapping.)
>>
>> I'd rather keep it simple.
>
>> Could be… On the other hand, in post XHTML era, the elements are usually in lower-case. Thus we should stick with it and use lowercase HTML elements anyway.
>
> https://www.w3schools.com/html/html_elements.asp
>
>> HTML is Not Case Sensitive
>>
>> HTML tags are not case sensitive: `<P>` means the same as `<p>`.
>>
>> The HTML standard does not require lowercase tags, but W3C recommends lowercase in HTML, and demands lowercase for stricter document types like XHTML.
>>
>> At W3Schools we always use lowercase tag names.
>
> So this is still a recommendation, not a requirement (we don't use XHTML).
> But I agree that this can be helpful for a certain amount of consistency across tests(they can still use other tags in uppercase).
>
>
>> Although neither <html> nor <body> are required, I prefer to always add them. These two elements don't add much overhead, do they?
>
> It is a matter of personal taste.
> Normally, I prefer to indent a content of such tags by extra spaces, andThis can create additional formatting difficulties under the 80(120) character limit per line.
> In those cases, I would prefer to omit those tags.
I know HTML is *not case sensitive*. It's just HTML tags are always in lower case in recent years.
> But I agree that this can be helpful for a certain amount of consistency across tests(they can still use other tags in uppercase).
Yep! In a way, this will enforce `<html>` in lower case, and I hope all other tags in the instructions.
> > Although neither nor are required, I prefer to always add them. These two elements don't add much overhead, do they?
>
> It is a matter of personal taste.
Yes, it is… which could create inconsistencies.
> Normally, I prefer to indent a content of such tags by extra spaces, and
> This can create additional formatting difficulties under the 80(120) character limit per line.
> In those cases, I would prefer to omit those tags.
I don't expect too many nesting levels in instructions. However, I agree it could be problematic…
In the sample in #15661, I keep `<html><body>` and the content on the same level.
Now that I looked at it again, I realised that I didn't follow the indentation consistently: first-level `<li>` aren't indented but third-level `<li>` are. I should correct this.
Because `<pre>` is used to format pieces of code, I decided not to indent the first-level `<li>` elements to avoid indentation of the code inside.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/15660#discussion_r1323108124
More information about the client-libs-dev
mailing list