https://github.com/microsoft/playwright/releases/tag/v1.40.0

assertion 추가

• expect(locator).toBeVisible()
• expect(locator).toHaveValue(value)
• expect(locator).toContainText(text)

import { test, expect } from '@playwright/test';

test('test', async ({ page }) => {
  await page.goto('https://playwright.dev/');
  await page.getByRole('link', { name: 'Get started' }).click();
  await expect(page.getByLabel('Breadcrumbs').getByRole('list')).toContainText('Installation');
  await expect(page.getByLabel('Search')).toBeVisible();
  await page.getByLabel('Search').click();
  await page.getByPlaceholder('Search docs').fill('locator');
  await expect(page.getByPlaceholder('Search docs')).toHaveValue('locator');
});

API 추가

• page.close(), browserContext.close(), 그리고 browser.close()에 reason 옵션이 추가되었습니다.
  • 클로저에 의해 중단된 모든 작업에 대한 클로즈 이유가 리포트됩니다.
• browserType.launchPersistentContext(userDataDir)에 firefoxUserPrefs 옵션이 추가되었습니다.

기타

• 실패하거나 취소된 다운로드에 대해 download.path()와 download.createReadStream() 메소드가 오류를 throw합니다.
• Playwright 도커 이미지에는 이제 Node.js v20이 포함되어 있습니다.

// " 글꼴 크기를 10픽셀로 전역 재설정 " 하려면 아래처럼 하세요~
html {
    font-size: .625em;
}

이렇게 하면 브라우저의 기본 글꼴 크기인 16픽셀을 10픽셀로 축소합니다. 이 방법은 우리의 계산을 간단히 해줍니다.

어떻게?

디자이너가 글꼴을 14픽셀로 만들라고 하면 머릿속으로 10으로 나누고 1.4 rem을 입력하면 상대 단위를 계속 사용하면서 쉽게 계산할 수 있습니다. (참 쉽죠?)

처음에는 이 방법이 편리할 수 있지만 이 방법에는 두 가지 문제가 있습니다.

1. 중복된 스타일을 많이 작성해야 합니다.

10픽셀은 대부분의 텍스트에 비해 너무 작기 때문에 페이지 전체에 걸쳐 덮어써야 합니다. p 태그을 1.4rem로, aside 태그 을 1.4rem로, a 태그를 1.4rem로 설정하는 등의 작업을 수행하게 됩니다. 이렇게 하면 오류가 발생할 수 있는 곳이 더 많아지고 코드가 변경되어야 할 때 접점이 더 많아지며 스타일시트의 크기가 커집니다.

2. rem/em 을 쓰면서도 픽셀 단위로 생각하는 개발자

두 번째 문제는 이렇게 할 때 여전히 픽셀 단위로 생각한다는 것입니다. 코드에 1.4rem을 입력해도 머릿속에서는 여전히 "14픽셀"로 생각하고 있는 것입니다.

반응형 웹에서는 "상대적인" 값에 익숙해져야 합니다. 1.2rem이 몇 픽셀로 평가되는지는 중요하지 않으며, 상속된 글꼴 크기보다 조금 더 크다는 것만 알면 됩니다. 그리고 화면에서 원하는 대로 보이지 않으면 변경하면 됩니다.

이 작업에는 약간의 시행착오가 필요하지만 픽셀로 작업한다고 해서 시행착오가 없을까요? 마찬가지입니다.

이 두 값이 정반대라는 것이 직관적이지 않은 것처럼 보이지만 그 이유는 간단함. padding 의 두 값은 "요소의 주변값"을 시계방향으로 나열한 것의 축약임. 반면, background-position 의 두 값은 Cartesian grid를 의미함.

CSS 설계 방식을 아래처럼 이해해봅시다~

가로/세로 모서리 두 개의 측정값을 지정하는 속성으로 작업하는 경우 "XY축 좌표계"를 생각하면 됩니다. 요소 주위의 각 변에 대한 측정값을 지정하는 속성으로 작업하는 경우 "시계"를 생각하면 됩니다.

padding: 10px 20px 30px 40px;
margin: 10px 20px 30px 40px;

순서가 기억안나는 트러블.. T RouB Le ... top right bottom left!

TRouBLe Top > Right > Bottom > Left

text

color, font, font-family, font-size, font-weight, font-variant, font-style, line-height, letter-spacing, text-align, text-indent, text-transform, white-space, word-spacing

typography 시스템 관리 필요에 따라 mixin 으로 묶어 선언하기도 합니다.

list

list-style, list-style-type, list-style-position, list-style-image

table border

border-collapse, border-spacing

The cascade is the reason this order matters: given the same specificity, later styles override earlier styles. If two or more of these states are true of one element at the same time, the last one can override the others. If the user hovers over a visited link, the hover styles take precedence. If the user activates the link (that is, clicks it) while hovering over it, the active styles take precedence.

Pseudo 선택자는 명시도가 같습니다. 명시도에 대해 Pseudo 선택자를 쓸 땐, 선언 순서가 중요해집니다. 일반적인 케이스의 인터랙션 스타일링 시 LoVe / H Ate 순서로 선언해줍시다.

Link > Visited > Hover > Active

사용자가 방문한 링크(:visit) 위로 마우스를 가져가면 :hover 스타일이 우선합니다. 사용자가 링크 위에 마우스를 올려놓은 상태(:hover)에서 링크를 활성화(:active)하면 활성화된 스타일이 우선합니다.

a:link {
  color: blue;
}

a:visited {
    color: purple;
}

a:hover {
    color: yellow;
}

a:active {
    color: red;
}

Pseudo-class selectors (for example, :hover) and attribute selectors (for example, [type="input"]) each have the same specificity as a class selec- tor. The universal selector (*) and combinators (>, +, ~) have no effect on specificity.

Pseudo 클래스 선택자(예: :hover)와 attribute 선택자(예: [type="input"])는 각각 클래스 선택자와 동일한 명시도(specificity)를 갖습니다. Universal 선택자(*)와 Combinators(>, +, ~)는 명시도(specificity)에 영향을 미치지 않습니다.