Dependabot couldn't resolve your project's dependencies as it couldn't access vue-zoomer.

You can grant Dependabot access to vue-zoomer by adding the repository here. We'll automatically close this issue and kick off another update run once permission is granted.

View the update logs.

I've seen on our codebase that the components in homeday-blocks have scoped styles. For instance: https://github.com/homeday-de/homeday-blocks/blob/develop/src/components/HdToast.vue#L71

However, on Vue styleguide says:

• Component libraries, however, should prefer a class-based strategy instead of using the scoped attribute.
• This makes overriding internal styles easier, with human-readable class names that don’t have too high specificity, but are still very unlikely to result in a conflict.

Since we are using BEM, this could namespace our styles, and with this, we will avoid using v-deep in our other protects: https://github.com/homeday-de/customer-app/blob/f170f72fc484dbf6e0500611a24b8326c94b1df4/src/components/buyer-feedback/slides/Finance.vue#L57

getShade() ( in styles/_colors.scss) works on the lightness property of the passed color (in a HSL way). This means that the same variation value generates different results for different colours. Other than that, getShade() could also shot an error. Example:
getShade($crusta-orange, 29)
generates

We could solve this

• using SCSS lighten method, but then we have to change how we measure the variations
• force $new-lightness to be alwasy >= 0 with an if .

For the HdResponsive component, right now we rely on the resize event to check and update the matching breakpoints. It's throttled so there is no huge performance hit, but we could instead set up listeners on each media query, which fire only once (when the change happens).

More docs here: https://developer.mozilla.org/en-US/docs/Web/API/MediaQueryList/addListener

It is well supported in all browsers we care about. The only "complexity" is that the recommendation is to use addEventListener instead of addListener, but addEventListener is not available in Safari. This can be solved by checking for existence and calling the appropriate one. Their functionality is the same.

We are currently using <button> with primary class inside <HdDynamicForm>. It would be nice to replace it by <HdButton> with primary type instead and keep consistency cross components.

Currently HdLink supports router-link and it would be interesting to have nuxt-link support as well.

Bootstrap Vue supports something similar and even custom ones if needed: https://github.com/bootstrap-vue/bootstrap-vue/blob/5bf6733595091cc204d3acc0641f8f0301bcbe9c/src/components/link/link.js#L66

I think we don't need something that fancy but that is how they select the tag to be used: https://github.com/bootstrap-vue/bootstrap-vue/blob/5bf6733595091cc204d3acc0641f8f0301bcbe9c/src/utils/router.js#L90-L105

We can adopt a similar strategy or make router-link/nuxt-link by default only and add others if needed in the future.

On a required HdInput instance, a value made of just spaces like is considered to be valid and fulfilling the requirement. This allows the submission of empty data.

We should be using rem instead of pixels

• We should be using rem instead of pixels
  • Summarizing em vs. rem difference:
  • When to Use Em vs. Rem
  • Tip
  • References

Pixels vs. Relative Units in CSS: why it’s still a big deal makes an amazing job explaining why this is important. I'll quote a couple of important points:

The most important reason for using responsive and unitless values in our CSS is for supporting our users that rely on zooming. If you read the Web Content Accessibility Guidelines, our users need to be able to zoom the viewport without loss of content or functionality, or restrictions imposed by CSS values or viewport scaling settings.

Design systems and threads of consistency
As someone who works on the O’Reilly Media Design System, weaving threads of consistency across brand, style, and UI components is a top priority. Consistency across a system empowers designers and developers to craft great app experiences for the end-user. That said, the most important thread that connects all elements of a design system tapestry is established accessibility best practices — for colors, typography, components, patterns.

Summarizing em vs. rem difference:

• The translation of rem units to pixel value is determined by the font size of the HTML element. This font size is influenced by inheritance from the browser font size setting unless explicitly overridden with a unit not subject to inheritance.

• The translation of em units to pixel values are determined by the font size of the element they’re used on. This font size is influenced by inheritance from parent elements unless explicitly overridden with a unit not subject to inheritance.

Note: For me, this makes rem more predictable than em, therefore, I prefer rem over em.

When to Use Em vs. Rem

This Comprehensive Guide: When to Use Em vs. Rem makes a great guideline for sizing units. I'm going to copy their bullet-point recap:

• rem and em units are computed into pixel values by the browser, based on font sizes in your design.

• em units are based on the font size of the element they’re used on.

• rem units are based on the font size of the HTML element.

• em units can be influenced by font size inheritance from any parent element

• rem units can be influenced by font size inheritance from browser font settings.

• Use em units for sizing that should scale depending on the font size of an element other than the root.

• Use rem units for sizing that doesn’t need em units, and that should scale depending on browser font size settings.

• Use rem units unless you’re sure you need em units, including on font sizes.

• Use rem units on media queries.

• Don’t use em or rem in multi-column layout widths - use % instead.

• Don’t use em or rem if scaling would unavoidably cause a layout element to break.

Tip

When creating layouts it’s often easier to think in pixels but output in rem units. You can have pixel to rem calculations done automatically via a preprocessor like Sass, or a postprocessor like PostCSS with the PXtoRem plugin.

References

• EM vs REM vs PX – Why you shouldn't “just use pixels”
• CSS units for font-size: px | em | rem
• PX, EM or REM Media Queries?
• Rem-Calc Function from Foundation
• Mixins for Rem Font Sizing

Sentry Issue: MEINHOMEDAY-4GC

You have included the Google Maps JavaScript API multiple times on this page. This may cause unexpected errors.

See ticket:

• https://homeday.atlassian.net/browse/VIEW-734

Currently HdInput has some extra logic on top to handle password type. It could be extracted into another component to make it clear and don't overwhelm HdInput with logic.
We're currently developing also HdInputFormatter that should be possible to handle formatting inside HdInput but it is build on top of HdInput to not add extra logic layer into it.

I cloned the repo and installed the dependencies. When I run the unit test, it fails.

Summary of failing test:

 FAIL  tests/unit/components/notifications/HdNotifications.spec.js
  ● HdNotifications › fires the heightChange event when height of the notifications changes

    expect(received).toBeTruthy()

    Received: undefined

      46 |     await wrapper.vm.$nextTick();
      47 | 
    > 48 |     expect(wrapper.emitted('heightChange')).toBeTruthy();
         |                                             ^
      49 |   });
      50 | });
      51 | 

The full color .btn (--primary --secondary ...) have no border. So if I use a button with a transparent bg and I change the class to color it (homeday homepage header ctas) the button looks like it is moving.

We currently use Travis and it has a new DPL which is giving us some warnings as we're still using v1: https://travis-ci.com/homeday-de/homeday-blocks/jobs/291825040/config

We should migrate to accommodate the new version.

Travis warnings could be addressed following:

• https://docs.travis-ci.com/user/deployment-v2#cleaning-up-the-git-working-directory
• https://docs.travis-ci.com/user/deployment-v2#how-to-opt-in-to-v2

Reference: https://homeday.atlassian.net/browse/FET-145

As stated in the title, the styles from flickity ( used i. e. in HdTabsMenu), may override the stiles for flickity used somewhere else in the project.

It would be nice if the HD-Blocks flickity styles would be specific for the usage in HD-Blocks.

Currently the modifiers are hard coded inside the component and replicated inside the story itself.
We should follow the approach from HdButton where we expose those modifiers via Object and reuse them to create all available stories.

We currently map a lot of properties from HdInput to <input>: https://github.com/homeday-de/homeday-blocks/blob/develop/src/components/form/HdInput.vue#L12-L28

For some of them it might make sense as they are transformed or have some other usage inside the component, as the required property, for example.

The problem is: if we need to forward new attributes that won't need any transformation or will be used inside the component, we need to add a new property and attach it to <input>.

To avoid this problem, a good approach is to forward all the attributes from HdInput to <input>.

Without HdIcon we could use an svg asset like this:

<template>
  <img
    src="@/assets/img/icons/some.svg"
    width="16"
    height="16"
    alt="Some alt text to describe image"
  >
</template>

With HdIcon we can make it inline the svg with the following code:

<template>
  <hd-icon
    :src="someIcon"
    width="16px"
    height="16px"
  />
</template>

<script>
import { HdIcon } from 'homeday-blocks';
import { someIcon } from 'homeday-blocks/src/assets/small-icons';

export default {
  name: 'componentName',
  components: {
    HdIcon,
  },
  data() {
    someIcon,
  },
};
</script>

This is awesome! This gives us a lot of versatility and styling power. And the best part is that we are getting the icons directly from the design system.

The downside of using the component HdIcon on this case is that we lose the accessibility on the image. I believe that we should make a11y a first-class citizen on Homeday Blocks.

I suggest we implement accessibility on HdIcon adding the props:

• title: string, optional, if not provided could work as an empty alt attribute.
• id: string, optional, if not provided could be autogenerated
• description: string, optional

I add a couple of screenshots from this accessible svgs post describing how could accessibility be implemented 😁.

Reference:

• https://css-tricks.com/accessible-svgs/
• https://getbootstrap.com/docs/4.0/getting-started/accessibility/#interactive-components
• https://developer.mozilla.org/en-US/docs/Learn/Accessibility/HTML