Generated HTML and CSS could be compared against a snapshot. Complicated somewhat by the fact that application .css files have to first pass through guui-css-loader.js. We'd therefore need a reliable way of intercepting .css imports

Frontend implemented microdata across the site using itemprops. While we have implemented some Schema.org JSON LD across the site, it isn't very verbose, and we should start filling it out.

Some of our most search friendly pieces are interactives, e.g. election results so we should always ensure this is applied across templates, especially the interactive template.

Documentation.

We should keep the SEO team up to date when we make any changes to this.

reported by: Oliver Lloyd
via: Pagerduty
on: 21 Feb 2022

Going to check here first, but this blob of JSON:
https://www.theguardian.com/film/2022/feb/21/young-afraid-review-norwegian-documentary-mental-health.json?dcr=true

If you search blocks[0].elements[2].url it's blank.

That's fed from here response.content.blocks.body[0].elements[1].videoTypeData.url == "":
https://content.guardianapis.com/film/2022/feb/21/young-afraid-review-norwegian-documentary-mental-health?show-blocks=all&api-key=KEY

So it looks like CAPI doesn't have the right data. Wondering where to go next to see why that's the case?

What is this?

Just a snapshot on where we are with our lighthouse scores with and without the commercial bundle. Hopefully this is useful as a comparison when testing any future improvements in this area.

On desktop

With	Without

On mobile

With	Without

How was the bundle removed?

Simply by commenting out the line to add the script in document.ts

    const priorityScriptTags = generateScriptTags(
        [
            { src: polyfillIO },
            { src: 'ophan.js', module: true },
            // CAPI.config && { src: CAPI.config.commercialBundleUrl },
            { src: 'sentry.js', module: true },
            { src: 'dynamicImport.js', module: true },
            { src: 'react.js', module: true },
        ].filter(Boolean),
        'defer',
    );

SCSS is more standardised than the Emotion API, more widely recognised, easier to find documentation on.

We could use transpile the SCSS down to CSS and then use this code to transform CSS into Emotion styling in the Webpack loader (or some future Babel plugin)

Byline, date and share buttons should left align with the bullet points above

https://trello.com/c/exoFBmVf/495-font-weights-in-pasteup

On dotcom-rendering we support a subset of font weights for each font family, one reason we do this is because this limits the amount of font files a user might potentially download.

font-weights can be represented by numbers eg. font-weight: 700. font-weight: 700 is also equal to font-weight: bold.

We should however discourage the use of string values such as font-weight: bold in favour of an API exposed by pasteup that maps weight values (thin, regular, bold for example) to our own mappings of font-weight numbers/files, this will give us the flexibility to adjust the bold font file in the future.

There are two things to consider:

• Font weights applied to headlines - should we apply consistently even if it means changing the design?
• Font weights that are applied to textSans as a design feature - how do we handle these?
• Strong having font-weight applied directly - should we apply this globally?

We should work with the @guardian/design-system team to consolidate these (there's 75 font-weight applications in dotcom-rendering).

Here's a few examples (in code):

Update button in liveblogs

Sidebar navigation

Standfirst

Byline

Article body

And so on...

Misbehaving advert on DCR liveblog? https://www.theguardian.com/world/live/2022/feb/16/covid-news-live-south-korea-reports-record-number-of-cases-china-tells-hong-kong-to-stabilise-outbreak?dcr=&filterKeyEvents=false

steps to reproduce

go to https://amp.theguardian.com/gnm-archive/2019/nov/06/from-new-media-to-guardian-unlimited-records-of-the-guardians-first-years-online on iOS safari

actual results

'show caption' text is visible on top of icon

expected results

'show caption' text is visually hidden
CC @nicl @SiAdcock

Hi 👋

Just read https://www.theguardian.com/info/2019/dec/08/migrating-the-guardian-website-to-react and noticed that is unintended horizontal overflow. Notice the horizontal scrollbar at the bottom of the window:

From some very brief debugging (and being unfamiliar with your codebase). I believe the issue may stem from the following:

If I change width: 100vw to width: 100% the horizontal scrollbar disappears. This causes the layout of this section to change slightly so obviously other styles here would need to be adjusted to keep the section visually unchanged.

To avoid these sorts of issues going undetected in stuff I work on, I set Show scroll bars: Always in MacOS general preference pane

Thanks for the article and hope this helps

News tone seems a bit dark and Culture has not yet been set

reported by: Akash
via: chat https://chat.google.com/room/AAAAG9rU0m0/kiqbu5di_qU (internal)
on: 19 Feb 2022

Hi, I've spotted a bug. The links in the header seem a little wonky:

• Subscriptions goes to jobs.theguardian.com (rather than subscribe.theguardian.com?)
• Search jobs goes to profile.theguardian.com

I'm signed in via Google with my @guardian.co.uk account.

Visiting profile.theguardian.com, incorrectly, triggers a new sign-in flow, but I don't think that's related.

The behaviour is seen on pages from all sections, but the URL in the video is https://www.theguardian.com/football/2022/feb/19/west-ham-newcastle-premier-league-match-report

The article url that is used to generate the labs fixture no longer contains the original article but instead a notice that the page has been removed.

This causes the following error when make gen-fixtures attempts to generate the fixture for labs (all other fixtures are generated fine):

FetchError: invalid json response body at https://www.theguardian.com/with-you-all-the-way/2021/mar/16/secret-games-travelling-shows-and-pioneering-players-the-history-of-womens-football.json?dcr reason: Unexpected token < in JSON at position 7

A while back I followed approach used in app/aws/aws-metrics.ts and app/aws/aws-parameters.ts to connect to S3 from manage-frontend (see guardian/manage-frontend#167).

At the time @adamnfish suggested I use AWS.CredentialProviderChain rather than overriding the AWS_PROFILE environment variable, at the time I couldn't get it working but left rough code commented out ( 😱) - anyway, after a suggestion from @AWare recently (to change the order of items in the provider chain) it now works nicely, without the need to override any environment variables which was a bit nasty.

I would've raised a PR for this repo but know nothing of the codebase, and there might be reasons you don't want to change things.

Here's some example code to create S3 client, which is easily adaptable to your metrics and parameter store use case...

const REGION = "eu-west-1";

const PROFILE = "membership";

const CREDENTIAL_PROVIDER = new AWS.CredentialProviderChain([
  () => new AWS.SharedIniFileCredentials({ profile: PROFILE }),
  ...AWS.CredentialProviderChain.defaultProviders
]);

export const S3 = new AWS.S3({
  region: REGION,
  credentialProvider: CREDENTIAL_PROVIDER
});

I think raising a PR to show this is probably more useful but initially I wanted to question whether we should support multiple sites. At the moment I'd just like to document my thoughts and share them.

As far as I can tell the pros of our sites approach are:

• helps others bootstrap quicker due to easy set up (i.e. all the webpack, linting, etc. is built-in)
• helps promote common standards for the same reason as above
• single repo makes sharing code easier (no need for publishing packages)

The cons are pretty big though:

• distracts from our mvp/core aim of articles
• adds a fair bit of complexity/overhead
• can confuse the separation of concerns and introduces significant coupling

These are all pretty major in my opinion.

I really think in terms of shared code, Guui is where we will add value. The sites mechanism adds stuff that is more subjective (linting, etc.), likely to change, and may not be appropriate for all projects. I don't think a future where all/several of our node apps are tightly coupled in terms of code is a good thing in a medium-sized org with multiple teams and diverse aims.

I would prefer separate projects which only share code through published packages/dependencies - in particular Guui. So the approach would be:

• Guui - purely for shared components (pasteup should just be subsumed into this unless I have missed some of its purpose, which is quite possible)
• Frontend - purely for our site
• other sites, live elsewhere

Not being able to use Guui directly (except as npm module) may seem painful but I think a good workflow would be to develop components in dotcom (or in other teams' projects) first, and then when confirmed useful and in more than one place, genericise and place in guui.

reported by: Rhys Mills (@rhystmills)
via: Dotcom chat channel
on: 22 Feb 2022

Some inconsistent rendering in the Credit Suisse series:
https://www.theguardian.com/news/2022/feb/21/switzerland-at-risk-of-eu-blacklist-after-credit-suisse-leak

note the black text on dark grey background

Applies to old dotcom too (but there the highlight is brand-yellow):

[URL]

reported by: David Furey
via: chat https://chat.google.com/room/AAAAG9rU0m0/Wdp9ONJNnxA [not public]
on: 15 Feb 2022

mentioned that our developer blog posts aren't responsive at mobile breakpoints - e.g. https://www.theguardian.com/info/2022/feb/01/creating-pinned-posts-on-our-live-blogs

My guess is that code blocks have a minimum size. The audience for these pieces is small, but arguably the impact on potential candidates is quite high.

It seems embed.ly returns "" as the url in the oembed response for vimeo. This is odd, as you can see a more expected result for youtube.

https://embed.ly/docs/explore/oembed?url=https%3A%2F%2Fvimeo.com%2F539597768
https://embed.ly/docs/explore/oembed?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DW8HVOBzg2pE

Composer uses this response directly, so bubbles down the pipeline to frontend.

We have raised a support ticket with embed.ly.

Blending Emotion with Styletron is a premature optimisation at this stage and is adding too much complexity. We should remove Styletron until we can be more certain that it would add value.

Currently there are two issues stopping us from getting green checks when @dependabot opens a dependency bump chore PR.

Snyk

• Needs access to a env var SNYK_TOKEN
• Can't run @dependabot PRs on push as that runs in read mode. See the error here.

Chromatic

• Needs access to CHROMATIC_APP_CODE env var

See dependabot secrets for the env vars.

TODO

• remove CHROMATIC_APP_CODE once there are no PRs reliant on it see: #3898

Reported by Jack Podmore via the dotcom email:

The commercial data team were asked earlier about the clicks on sponsor logos on our Ocado-supported content. I've looked into it and I think the issue may be that the GA sponsor logo tracking doesn't fire on DCR. I can't see any events being sent to GA when the logo is clicked on article pages.

E.g. On this article, nothing registers in dev tools when clicking the sponsor logo. However, everything works fine on this series page:

Everything also seems to be fine on this sponsored podcast page.

The article pages on this series and this series both show the same behaviour, so I don't think it's specific to any one campaign.

Looking at the long term trend in GA suggests we've gradually been losing sponsor clicks over the past two years:

With them fully vanishing from articles around the 25th of June 2021 - when this pull requests switches paid content over to DCR.

While this appears to be a long-standing problem and has only recently been noticed, GLabs report this number to clients and it's kind of important that we have an accurate figure.

We've had reports from discussion moderators about inconsistent sign in behaviour:

”As a moderator I need to sign into our commenting account to post information for other commenters. Myself and other >mods have found that once we've signed in, it takes you back to the homepage and not the page with the discussion we >were on previously, and then when we do find the discussion box again, we're still logged out? And I will try this a few times >and it will be the same issue. After a while I might be let in, but there does appear to be a glitch.”

We've been able to replicate this issue so suggest investigating the root cause.

Using a Babel plugin to perform Emotion-parsing logic, rather than a Webpack loader, would make guui more flexible and easier to test

e.g.: https://transform.now.sh/css-to-emotion/

from: Dotcom team
via: standup
on: 23 Feb 2022

More info coming soon

reported by: Lucy
via: chat https://mail.google.com/chat/u/0/#chat/space/AAAAG9rU0m0/GfZTOAKQyx8 (internal)
on: 16 Feb 2022

when DCR rolled out on articles, did anything substantial change in how we display comments?

we've seen a huge drop in the number of clicks to the "read more" comments button

at around the time of the initial roll out

do we possibly display it less now or?

Which features do we support/not support.

Because it is AMP and mobile, we can probably be a bit more aggressive here than for the main site.

We can also make our lives easier by targeting a non-responsive design, as the current AMP does - i.e. no media-queries!

I.e. at least the following rules:

• CSS bundle must be <50kb (this is part of the AMP standard)
• no media-queries, target mobile breakpoint only
• other AMP restrictions (https://www.ampproject.org/docs/design/responsive/style_pages) - these are actually not onerous and include helpful restrictions like no !important allowed
• use flex and grid for layout over floats and tables

Is this sensible? Can we expand these rules?

caniuse seems broken for me at the moment unfortunately but I'll update when it's loading with browser support for flex/grid on mobile devices. But maybe @SiAdcock or @GHaberis know what's sensible here?

cc @AWare @MatthewJWalls @philmcmahon!?

Update: main concern for css grid support is Opera mini which is at 2.33% globally (although probably a lot less than that in our key markets) but also iOS Safari 10.2 (which is 1.27% in the UK).

On the other hand, flex is near universally supported so we could just use that in a lot of cases.

There are projects like safe-env and dotenv-safe that do this, or we could implement our own version of that. Having the variables defined in the README is good, but it’s likely to go out of date.

Inspired by #4118

Onward journeys tablet and desktop breakpoint have 30px margin-left. Should be 20px

There is padding-top:4px; on this time stamp. Please can we remove it

In the MatchNav component, we use svgs to display the score using fancy looking numbers. But we only have svgs for numbers up to ten so if a team scores above that, we will still just show 10.

Whilst it's true that no team in the premiership has ever scored more than 10 goals, there was a case where a team scored 31 goals in a world cup qualifier so it's not impossible that a match report would be written for a game where one of the teams did really, really well.

Ways we could be better

1. If we used the existing range of svg numbers from 0-9 but made them smaller and positioned them alongside each other, we could compose all the possibilites up to 99 goals. They would need some styling so they still fit inside the circle.

2. Another option is to just create lots more svgs. It's true this clutters the codebase with files but it's very simple.

The Comments and replies option under My account is hard coded to a user with id 123 but should be real

https://help.github.com/en/articles/about-github-package-registry

@guardian/design-system @guardian/dotcom-platform

reported by: Nikhita Chulani
via: email "Re: Immersive video"
on: 15 Feb

This lovely feature of the Novak interview on the BBC website made me want to raise this issue again: is there any chance we could introduce making videos bigger on the website?

I think it would be brilliant if this is something we could add and I find at least one example a day. I think it could make an article look better and have a great impact.

Additionally, we have had desk editors tell us they haven't wanted to embed video for the aesthetic alongside immersive images.

https://docs.npmjs.com/misc/developers#keeping-files-out-of-your-package

I think that the relevance the beacon is minimal.

As @rtyley pointed out, this was introduced in 2013 with guardian/frontend#2562 to confirm that our analytics made sense. Nowadays the results are not actively monitored.

If we remove beaconUrl from DCR, it can be removed from the configuration entirely. We will deprecate its use in frontend with guardian/frontend#23708.

We have a dependency on shelljs via pm2, which has a high severity issue.

This will hopefully be fixed in [email protected], so let's keep an eye on this and, when v0.9 is released, ensure pm2 is updated accordingly.

Alternatively, we can encourage pm2 to move away from shelljs to execa which apparently does not have the same vulnerability.

Reported by: Harry Fischer @HarryFischer
On: Feb 21 or 22
Via: Direct chat

The logo should be the same colour as the timestamp. Follow-up on #4046

csd

Hello 👋

Noticed that the apps-rendering articles seem to be missing some margin above the upgrade button compared to the older templates.

mobile-apps-article-templates	apps-rendering

The build is currently being reported as slow by us, but also by our colleagues that are clients to our platform 🐌 .

There are a number of areas where we can try to make changes to improve this.

We need to have some visibility into where there might be issues (#3848).

From here we can

• fix any immediately obvious bottlenecks
• fix any memory leaks
• investigate using different build systems

On this article https://www.theguardian.com/lifeandstyle/2022/jan/11/to-all-the-bosses-ive-begged-for-a-job-comic?utm_term=Autofeed&CMP=twt_gu&utm_medium&utm_source=Twitter#Echobox=1641893210

Can't see it on desktop but in the Twitter iOS window and in Chrome iOS they're blue as above.

@OllysCoding @oliverlloyd @rcrphillips

Speedcurve shows that the bundle size shot up by 68%. We should investigate the root cause for this (it's also impacting time to interactive).

We aim to keep this repo approachable and easy to maintain. Narrow types are a TypeScript feature which allows us to has get types beyond the JS primitives–boolean, null, undefined, number, bigint, string, symbol. One such feature is template literal types, which allow the compiler to check whether a string matches a specific shape.

When introducing these narrower types–such as in #4033–we need to ensure that this does not come at a high cost for approachability or maintainability.

from MDN: JavaScript data types and data structures

The set of types in the JavaScript language consists of primitive values and objects.

• Primitive values (immutable datum represented directly at the lowest level of the language)
  • Boolean type
  • Null type
  • Undefined type
  • Number type
  • BigInt type
  • String type
  • Symbol type
• Objects (collections of properties)