WARNING: and IMPORTANT: admonitions are barely noticeable in HTML rendering

[jerstlouis]

They don't get any kind of box or background color, or even bold on the WARNING / IMPORTANT.

CAUTION: gets a very nice box. It would be nice that each of these get a different color. WARNING: should probably be a bit more red-orange than CAUTION:? IMPORTANT: could be a nice pale green box?

In the PDF rendering, they all render with a blue box (and are therefore all quite visible), but different colors would be nice such as orange for warning / cautions, and perhaps again green for IMPORTANT?

[opoudjis]

Pretty sure I've done this with other flavours. Will investigate what I've done elsewhere, but will need approval from OGC leads of our colour choices, and whether we should introduce them. @Intelligent2013 we should have consistent choices too.

[Intelligent2013]

In the PDF rendering, they all render with a blue box (and are therefore all quite visible), but different colors would be nice such as orange for warning / cautions, and perhaps again green for IMPORTANT?

@Intelligent2013 we should have consistent choices too.

I need the exactly RGB color for each admonition type, and I'll update the XSLT for PDF.

[ronaldtse]

@Intelligent2013 what are the colors we use right now for the OGC theme? I wonder if we can keep the HTML / PDF color definitions aligned.

[Intelligent2013]

@Intelligent2013 what are the colors we use right now for the OGC theme? I wonder if we can keep the HTML / PDF color definitions aligned.

• rgb(79, 129, 189) - for all admonitions (text and border around it)
• for design element like crossing lines, 1st level clause numbers, lines, etc.
  • rgb(0, 177, 255), if document date >= 20211108
  • rgb(237, 193, 35) and rgb(246, 223, 140), if document date < 20211108
• rgb(252, 246, 222) and rgb(254, 252, 245) for table's rows
• rgb(33, 55, 92) for 1st level clause's titles
• rgb(88, 89, 91) for document text
• rgb(249, 235, 187) for PREFERRED label, rgb(237, 237, 238) for DEPRECATED label, rgb(223, 236, 249) for ADMITTED label background

[ronaldtse]

@Intelligent2013 can we change the document date < 20211108 thing to a new layout for OGC? i.e. legacy layout vs new layout (202x?)

[ronaldtse]

We need assistance from @ghobona and @gbuehler here on defining the OGC colors on behalf of DocTeam.

[Intelligent2013]

@Intelligent2013 can we change the document date < 20211108 thing to a new layout for OGC? i.e. legacy layout vs new layout (202x?)

@ronaldtse do you mean to use the document attribute :document-scheme: legacy instead of hard-coded date 20211108? Yes, will do so.

[ronaldtse]

@Intelligent2013 Correct.

[ghobona]

Please stick with the colors of the current OGC theme. You can use contrast to emphasise a block such as a warning, but please stick with the colors of the current OGC theme.

[jerstlouis]

@ghobona The problem is that right now:

• In the PDF, everything is in a blue box (important and warning/caution alike)
• In the HTML, only Caution has an orange background... everything else doesn't have a box/color

So the OGC theme is missing colors... I like @ronaldtse 's suggestiong of keeping HTML / PDF colors aligned.

Any new colors added should fit with the existing OGC color scheme.
Could the metanorma team maybe suggest / show what the new colors could look like and @ghobona and @gbuehler could review / approve it? Thanks all.

[opoudjis]

Inject colour palette into Presentation XML as metadata; OGC colour theme is being revised in brand guidelines.

We are to suggest complementary palette. Base off PDF.

[opoudjis]

So the following statements in the PDF XSLT:

<xsl:variable name="color_main">rgb(88, 89, 91)</xsl:variable>
	<xsl:variable name="color_design">
		<xsl:choose>
			<xsl:when test="$layoutVersion = '2022'">rgb(0, 177, 255)</xsl:when>
			<xsl:otherwise>rgb(237, 193, 35)</xsl:otherwise>
		</xsl:choose>
	</xsl:variable>
	<xsl:variable name="color_design_light">
		<xsl:choose>
			<xsl:when test="$layoutVersion = '2022'">rgb(0, 177, 255)</xsl:when>
			<xsl:otherwise>rgb(246, 223, 140)</xsl:otherwise>
		</xsl:choose>
	</xsl:variable>
	<xsl:variable name="color_dl_dt">rgb(215,243,255)</xsl:variable>
	<xsl:variable name="color_dl_dd">rgb(242,251,255)</xsl:variable>
	<xsl:variable name="color_blue">rgb(33, 55, 92)</xsl:variable>
	<xsl:variable name="color_background_blue">rgb(33,60,107)</xsl:variable>

and the inline instances:

<xsl:choose>
					<xsl:when test="$kind = 'preferred'">rgb(249, 235, 187)</xsl:when>
					<xsl:when test="$kind = 'deprecated'">rgb(237, 237, 238)</xsl:when>
					<xsl:when test="$kind = 'admitted'">rgb(223, 236, 249)</xsl:when>							
				</xsl:choose>

are to be migrated into Presentation XML metadata. I will code them as rgb() statements; HTML CSS will be able to cope with them, but I am going to assume that Word CSS will not, so

  red = color_json[:red].to_i
  green = color_json[:green].to_i
  blue = color_json[:blue].to_i
  color_value = sprintf("#%02x%02x%02x", r, g, b)

[opoudjis]

For the distinction between deprecated and admitted: I see that in Presentation XML, both are labelled "AdmittedLabel". I will change deprecated to be labelled "DeprecatedLabel", to simplify the test; I had not been differentiating them until now.

[opoudjis]

We import _coverpage.scss into htmlstyle.scss as import. We apply Liquid to populate the htmlstyle.scss; that does not extend to _coverpage.scss, so the Liquid imported from _coverpage.scss is illegal.

I'm going to work around that by importing the colours into the font-header of the SCSS as SCSS variables.

[opoudjis]

i will circulate the current PDF, and four versions of the HTML:

• Current colouring
• Colouring brought in line with PDF, and using only PDF colours. (It's a LOT less colourful)
• Colouring and using only PDF colours, but applying more background colours for block types
• Colouring and using PDF colours + complementary colours to the definition description pastel colour #fdf2ff, as the most inobtrusive background colours. (Tetradic gives us #fdf2ff, #fff6f2, #f4fff2.)

I've done the second.

[opoudjis]

@ghobona @gbuehler This is where I've got to. Please provide feedback.

I do need to note that I don't do front end (as you already know), and the notion of picking colours throws me into panic. If you don't like any of the alternatives, I will need you to suggest colours.

So, in the attached:

• a1.pdf is the current PDF for various block types
• a1.0.html is the current HTML, which has completely different colours
• a1.1.html is the HTML brought in line with the PDF colours for blocks (except that I've kept the background colour of the page). I am treating the PDF colours as the OGC theme colours.
• a1.2.html is the same, but some of the PDF colours are being used to accent block types
• a1.3.html uses some new complementary colours to accept warnings; I've also switched the block background colour from definition-term to the paler definition-description

Archive 3.zip

[opoudjis]

Debugged: class "Adminition.Warning" in CSS should have been "Admonition Warning"

[opoudjis]

@ghobona @gbuehler Because this involves coordinating PDF and HTML, could we ask for some in principle feedback of which HTML you hate least? We can always tweak the colours later on.

I am worried that the background colour is going to wash out the theme colour pastels (since they were designed for a PDF white background); but I didn't want to change the HTML background colour to white without you giving go-ahead.

[jerstlouis]

@opoudjis

My suggestion is to have the different hues/tints as in a1.3.html, and to synchronize that with the PDF, but for the HTML to use a darker shade and the nice even darker thick top border as in a1.0.html.

The all blue everything as in the current PDF and a1.1.html (and similar a1.2.html) is problematic, and while the pastels and boxes of a1.3.html might look nice in the PDF, I agree they are problematic for the HTML.

So while the hues could be in sync between HTML & PDF, I think it's good if the HTML uses the darker color and the top-border as opposed to the pastels and the simple box for the PDF.

This would not introduce any major change (no background color change), except where things currently feel broken (all admonition types blue in the PDF, and borders completely missing for most admonition types in the HTML).

But I realize you're not asking me ;) Maybe @ghobona and @gbuehler will find time to chime in.

[ghobona]

@opoudjis Yellow on a white or grey background is difficult to see.

So I very much prefer the colour scheme on the current HTML (a1.0.html).

[jerstlouis]

@ghobona I much prefer the darker shades and thick top border of a1.0.html as well, but the problem with a1.0.html is that the IMPORTANT and WARNING have nothing at all, and the Hello: Tip, Editor, and Todo have an orange "caution" color not appropriate for them.

Would it be fine if those had the same tints as in a1.3.html, but a darker shade of them (like the Caution box in a1.0 corresponds to a darker shade of the pastel orange in a1.3), and the thick top border as in a1.0 rather than the simple thin blue box?

Essentially, the ideal solution is a mix of a1.0 and a1.3.

Thanks!

[opoudjis]

Well, this is a problem.

a1.0.html is NOT what you are getting in the PDF. a1.1.html is. So if you prefer a1.0.html to a1.1.html, and if we have to keep PDF and HTML colours aligned, then the colours in the PDF would have to change.

I think @jerstlouis is right, that the PDF and HTML don't have to use identical colours: PDF can use lighter tones than HTML. I will try dropping the yellow, and doing something darker; we can discuss further on Monday. (Note that I am really not front-end, and would rather someone else be doing this, but oh well...)

[opoudjis]

a1.4.html.zip

I am trying to make all parties happy with this, but I'm not going to keep iterating this.

[jerstlouis]

@opoudjis That looks great, but the orange could be exactly like it used to be (which is a bit of a darker shade), and the other tints could perhaps be similarly darker. But please wait for the docteam feedback. I'll have a go at updating this with proposed colors.

I'm suggesting something like this for the HTML:

a1.5.html.zip

And the PDF could be something like a1.3, perhaps with the exception of the Warning / Safety a bit less pink and more red, and the TODO yellow rather than red.

[opoudjis]

Pending DocTeam meeting in Nov. 2024.

[opoudjis]

As interim measure, will merge the Presentation XML changes to capture consistent colours between HTML and PDF; but I will ignore the colours in the HTML.

[ghobona]

OGC Staff discussed this Issue on 2024-09-09 and agreed that the colors used by the templates could not be changed because they are part of the OGC Brand which was launched a couple of years ago.

This GitHub Issue can therefore be closed.

[jerstlouis]

@ghobona

Does this mean that the IMPORTANT admonition that was fixed to now have a box will be broken again?

e.g. see the box right above https://docs.ogc.org/DRAFTS/21-038.html#rc_data-ubjson section 15.3

Before, this had no box at all and was barely noticeable.

This fix is great.

This issue was never about changing the OGC brand color themes.