The dependency uglify-js was updated from 3.6.1 to 3.6.2.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

uglify-js is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

Use the new s-q-item__subtitle sophie class once https://github.com/nzzdev/sophie-q/pull/5/files is merged and released

We need to track the events when a user changes the visible image. best thing is to dispatch a CustomEvent. See this as an example:

https://github.com/nzzdev/Q-quiz/blob/master/script_src/quiz.js#L20-L28

CustomEvent needs to be polyfilled for IE11. So it should be added to the polyfills array returned in rendering-info.

Tasks

• Add a property called variants of type array to the schema
• A variant has a file and a minWidth property
• The image will be choosen based on the minWidth property
• Variants should only be visible to users with expert-imageslider role

The goal with responsive images is to load the smallest image possible based on the real-world size on screen or display resolution of the device. There are different strategies to achieve this. In this issue I want to explain the once which work for the usecase of imageslider.

Use Case 1: The width is known

If we know that the image is gonna have a fixed width (article on desktop) we can allow the browser to choose an image with the appropriate resolution for the device. So if the device accessing the page has a standard resolution (1x) the 320w.jpg image will be loaded. If the device has a high resolution (2x) the 640w.jpg image will be loaded. The width provided by LivingDocs will be chosen as the 1x value.

<img srcset="320w.jpg 1x,
  480w.jpg 1.5x,
  640w.jpg 2x"
  src="640w.jpg">

Use Case 2: The width is not known

If the element is embedded on other pages than the main page or shown on a mobile device, we don't know the width of the image upfront. In this case a client-side script will measure the width and set the srcset and src tag to the measured width.

Picture element

Browsers support different image formats. The picture element allows to define image sources with different image formats. The browser will choose the one it can render. For old browsers if will fall back to jpg.

<picture>
  <source type="image/webp" srcset="https://image.com/500.png 1x,  https://image.com/1000.png 2x">
  <source srcset="https://image.com/500.png 1x, https://image.com/1000.png 2x">
  <img src="https://image.com/1000.png">
</picture>

Approach which doesn't works

There exists an approach to let the browser choose an image base on the device width. There are two attributes. With srcset we tell the browser the different available versions and the width of them. And with in the sizes string we declare how much space the image will take on the different viewports. The browser will then choose the appropriate image based on the available space.

<img srcset="320w.jpg 320w,
  480w.jpg 480w,
  800w.jpg 800w"
  sizes="(max-width: 320px) 280px,
              (max-width: 480px) 440px,
              800px"
  src="800w.jpg">

The problem with this approach is that the media conditions (screen widths) defined in the sizes attribute are always based on the viewport. But the imageslider is not always as wide as the entire viewport. Thats why this approach doesn't work for the imageslider.

I tested what happens if the sizes attribute is not defined. In this case the browser will choose the image assuming it will be shown on 100% of the viewport.

• The base URL of the proxy should be configurable via ENV variable.
• The service running is imaginary https://github.com/h2non/imaginary
• Images should be delivered with a reasonable number of pixels for the size they are displayed in
• Images should be delivered in double resolution only to users width a high dpi screen
• user agents understanding webp should load the images in webp format

image resizing service is running at http://img.st-staging.nzz.ch for everything uploaded from staging or dev. For production there will be a CDN in front, thats the reason why this URL needs to be configurable by ENV variable.

An example of a resized image request:
https://img.st-staging.nzz.ch/resize?url=https://nzz-q-assets-stage.s3.eu-west-1.amazonaws.com/2018/01/15/a39f19db-d0ca-47a2-9c60-69f2b883a75c.jpeg&width=500&nocrop=true

• Calculate padding-bottom for each image separately so it fails better if one of the images is taller then the other

Introduction

At the moment we calculate the paddingBottom value only for the tallest image. This is a workaround for the case if images have different heights. We are starting to use the imageslider more and more for graphics where its more common to have images with different heights.

Possible solution

The paddingBottom value should be calculated foreach image separately and set when switching between the images. This could result in jumping of the text below. On mobile the user probably doesn't notice the jumping as its not visible, but its a problem on desktop.

The dependency @hapi/inert was updated from 5.2.1 to 5.2.2.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@hapi/inert is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

The dependency @hapi/joi was updated from 15.0.0 to 15.0.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@hapi/joi is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

Task

We made changes to the configuration format of dynamicEnums and availabilityChecks. The schema and corresponding routes need to be adjusted as following (more details on the config format can be found here):

DynamicEnums

Current:

"dynamicEnum": {
  "type": "ToolEndpoint",
  "withData": true,
  "endpoint": "dynamic-enum/selectedColumn"
}

New:

"dynamicEnum": {
  "type": "ToolEndpoint",
  "config": {
    "endpoint": "dynamic-enum/selectedColumn",
    "fields": ["options", "data"]
  }
}

Additionally the /dynamic-enum now receives an object containing the item and optionally and options property. The route needs to be adjusted to this.

AvailabilityChecks

Current:

{
  "type": "ToolEndpoint",
  "withData": true,
  "endpoint": "option-availability/invertColors"
}

New:

{
  "type": "ToolEndpoint",
  "config": {
    "endpoint": "option-availability/invertColors",
    "fields": ["options", "data"]
  } 
}

Additionally the /option-availability now receives an object containing the item and optionally and options property. The route needs to be adjusted to this.

The dependency @hapi/hapi was updated from 18.3.2 to 18.4.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@hapi/hapi is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

The dependency @hapi/joi was updated from 15.0.2 to 15.0.3.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@hapi/joi is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

What we want:

• Consistent code formatting without many changes on existing codebase

Possible tools:

• Prettier - Does only code formatting (JavaScript, SCSS, JSON and more)
• ESLint - Can do both code formatting and linting, everything configurable
• StandardJS - Uses a ESLint configuration to format and lint code, doesn't allow any configuration on purpose

Prettier

• Only code formatting
• Uses predefined configuration (can be extended)
• Supports most common languages such as JavaScript, SCSS and JSON without adding additional dev-dependencies
• Pro: Formatting on save with VS Code Extension

ESLint

• Allows to configure everything
• There are popular ESLint configuration such as Airbnb's Javascript Styleguide ect. which all try to do code formatting and linting in one
• Cons: For each language a plugin needs to be added to dev-dependancies

StandardJS

• Tries to end the discussion around formatting conventions
• Provides a "standard" configuration for code formatting and linting
• Differs from our current code style (without semicolon)
• Pro: No configuration files
• Con: Possibly a lot of code changes in older repo's

My Opinion

• Its a good thing to separate code formatting and linting
• Prettier does one thing well and lets us format code on save
• Code linting can be added separately using ESLint for example

• Currently it is possible to create an imageslider using zero or one image. This shouldn't be possible

The dependency @hapi/joi was updated from 15.0.1 to 15.0.2.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@hapi/joi is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴