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.