diff --git a/src/pages/blog/posts/browser-rendering-principles.md b/src/pages/blog/posts/browser-rendering-principles.md new file mode 100644 index 0000000..a1f2598 --- /dev/null +++ b/src/pages/blog/posts/browser-rendering-principles.md @@ -0,0 +1,100 @@ +--- +layout: "@/layouts/BlogPostLayout.astro" +title: "Browser Rendering Principles" +description: "This article details the seven stages of browser page rendering (HTML parsing, style calculation, layout, layering, painting, tiling, and rasterization) as well as the concepts of reflow and repaint, and why transform is efficient." +date: "2023-08-10" +image: "https://images.unsplash.com/photo-1510511459019-5dda7724fd87?q=80&w=1470&auto=format&fit=crop" +tags: ["Browser", "Frontend", "Rendering Principles"] +tagId: ["browser", "frontend", "rendering"] +category: "Frontend Development" +categoryId: "frontend" +readTime: "7 min read" +--- + +The browser rendering process can be divided into seven stages: + +### 1. HTML Parsing + +After receiving the HTML document from the server response, the browser first parses the HTML document to build a DOM tree. The DOM tree consists of DOM elements and attribute nodes, with the document object as the root of the tree. + +### 2. Style Calculation + +The browser parses CSS files and inline styles on elements to calculate the styles of DOM nodes. This process includes: + +- Converting CSS into a structure that the browser can understand +- Calculating the specific styles of DOM nodes + +### 3. Layout + +The layout phase calculates the geometric positions of visible elements in the DOM tree, a process called layout or reflow. + +### 4. Layering + +The browser divides the DOM tree into multiple layers based on the layout. This process is mainly to handle complex effects in the page, such as 3D transformations and page scrolling. + +### 5. Painting + +Based on the layers, the browser generates a paint list for each layer and submits it to the compositing thread. + +### 6. Tiling + +The compositing thread divides the layers into tiles, which are typically 256x256 or 512x512 in size. + +### 7. Rasterization + +The compositing thread prioritizes generating bitmaps for tiles near the viewport, a process called rasterization. During rasterization, tiles are converted into bitmaps. + +## Reflow and Repaint + +### Reflow + +When our modifications to the DOM cause changes in the geometric dimensions of DOM elements (such as modifying the width, height, or hiding elements), the browser needs to recalculate the geometric properties of the elements and then draw the results. This process is called reflow (also known as relayout). + +Operations that trigger reflow include: + +- Initial page rendering +- Changes in browser window size +- Changes in element dimensions or position +- Changes in element content (such as text quantity or image size) +- Changes in element font size +- Adding or removing visible DOM elements +- Activating CSS pseudo-classes (e.g., :hover) +- Querying certain properties or calling certain methods + +Some commonly used properties and methods that cause reflow: + +- clientWidth, clientHeight, clientTop, clientLeft +- offsetWidth, offsetHeight, offsetTop, offsetLeft +- scrollWidth, scrollHeight, scrollTop, scrollLeft +- scrollIntoView(), scrollIntoViewIfNeeded() +- getComputedStyle() +- getBoundingClientRect() +- scrollTo() + +### Repaint + +When our modifications to the DOM cause style changes but do not affect its geometric properties (such as modifying color or background color), the browser does not need to recalculate the geometric properties of the element and directly draws the new style for the element. This process is called repaint. + +Compared to reflow, repaint has a smaller performance overhead because repaint only redraws the appearance of the element without recalculating the position of the element. + +## Why Transform is Efficient + +Transform is implemented by creating a new composite layer, which is drawn separately and then composited with other layers. This way, when we use transform for transformations, only this composite layer needs to be redrawn, not the entire page. + +Using transform can avoid reflow and repaint because it does not affect the layout of the DOM, only the final rendering result. This is why using transform for animations is more efficient than directly modifying properties like top and left of elements. + +## Optimization Strategies + +To reduce reflow and repaint, we can adopt the following strategies: + +1. **Batch DOM modifications**: Use DocumentFragment or first set the element to display: none, then make multiple modifications, and finally display it. + +2. **Avoid frequent reading of properties that trigger reflow/repaint**: If you must read multiple times, cache the values. + +3. **Use transform and opacity for animation effects**: These two properties do not trigger reflow. + +4. **Use the will-change property**: This property can inform the browser in advance of changes that will occur to the element, allowing the browser to prepare optimization work. + +5. **Use absolute or fixed positioning**: Elements with absolute or fixed positioning only affect themselves when changed, not other elements. + +By understanding browser rendering principles and optimization strategies, we can write more efficient frontend code and improve user experience. \ No newline at end of file diff --git a/src/pages/blog/posts/docusaurus-v3-with-tailwindcss.md b/src/pages/blog/posts/docusaurus-v3-with-tailwindcss.md new file mode 100644 index 0000000..f48eebc --- /dev/null +++ b/src/pages/blog/posts/docusaurus-v3-with-tailwindcss.md @@ -0,0 +1,129 @@ +--- +layout: "@/layouts/BlogPostLayout.astro" +title: "Using Tailwind CSS in Docusaurus v3" +description: "This article details how to integrate and configure Tailwind CSS in Docusaurus v3, including installing dependencies, configuring tailwind.config.js, creating tailwind.css and postcss.config.js, and more." +date: "2023-11-05" +image: "https://images.unsplash.com/photo-1555066931-4365d14bab8c?q=80&w=1470&auto=format&fit=crop" +tags: ["Docusaurus", "TailwindCSS", "Frontend Framework"] +tagId: ["docusaurus", "tailwindcss", "frontend-framework"] +category: "Frontend Development" +categoryId: "frontend" +readTime: "4 min read" +--- + +## Installing Dependencies + +```bash +npm install tailwindcss +``` +## Configuring tailwind.config.js + +```js +/** @type {import('tailwindcss').Config} */ +module.exports = { + content: [ + "./src/**/*.{js,jsx,ts,tsx,md,mdx}", + "./docs/**/*.{md,mdx}", + ], + theme: { + screens: { + xs: '480px', + sm: '576px', + md: '768px', + lg: '998px', + xl: '1200px', + '2xl': '1400px', + }, + extend: { + fontFamily: { + sans: 'var(--ifm-font-family-base)', + firacode: 'var(--font-family-firacode)', + kaiti: 'var(--font-family-kaiti)', + }, + colors: { + 'font-color': 'var(--ifm-font-color-base)', + 'link-color': 'var(--ifm-link-color)', + 'link-hover-color': 'var(--ifm-link-hover-color)', + primary: 'var(--ifm-color-primary)', + 'primary-light': 'var(--ifm-color-primary-light)', + 'primary-lighter': 'var(--ifm-color-primary-lighter)', + 'primary-lightest': 'var(--ifm-color-primary-lightest)', + 'primary-dark': 'var(--ifm-color-primary-dark)', + 'primary-darker': 'var(--ifm-color-primary-darker)', + 'primary-darkest': 'var(--ifm-color-primary-darkest)', + }, + boxShadow: { + nysm: '0 0 2px 0 rgb(0 0 0 / 0.05)', + ny: '0 0 3px 0 rgb(0 0 0 / 0.1), 0 0 2px - 1px rgb(0 0 0 / 0.1)', + nymd: '0 0 6px -1px rgb(0 0 0 / 0.1), 0 0 4px -2px rgb(0 0 0 / 0.1)', + nylg: '0 0 15px -3px rgb(0 0 0 / 0.1), 0 0 6px -4px rgb(0 0 0 / 0.1)', + spread: '0 5px 40px rgb(0 0 0 / 0.1)', + }, + }, + }, + plugins: [], + darkMode: ["class", '[data-theme="dark"]'], + corePlugins: { + preflight: false, + }, + blocklist: ["container"], +} +``` +## Creating tailwind.css + +Create a `tailwind.css` file in the `src/css` directory and add the following content: + +```css +@tailwind base; +@tailwind components; +@tailwind utilities; +``` +**Note: After creation, you need to import tailwind.css in custom.css, otherwise the tailwind styles will not take effect** + +## Creating postcss.config.js + +Create a `postcss.config.js` file in the project root directory and add the following content: + +```js +module.exports = { + plugins: { + tailwindcss: {}, + autoprefixer: {}, + } +} +``` + +## Importing tailwind.css in custom.css + +Find the `src/css/custom.css` file in your project and add the following content at the top of the file: + +```css +@import './tailwind.css'; +``` + +## Using Tailwind CSS + +Now, you can use Tailwind CSS styles in your project. For example: + +```jsx +
+

Hello Tailwind CSS

+

This is a paragraph styled with Tailwind CSS

+
+``` + +## Notes + +1. Since Docusaurus already has its own CSS styles, we disabled `preflight` in the Tailwind CSS configuration to avoid style conflicts. + +2. We used the `darkMode: ["class", '[data-theme="dark"]']` configuration to make Tailwind CSS's dark mode consistent with Docusaurus's dark mode. + +3. We added some variables in `theme.extend.colors` that use Docusaurus's CSS variables, making Tailwind CSS colors consistent with Docusaurus theme colors. + +4. We added `container` to the `blocklist` because Docusaurus already has its own container styles, and we don't want Tailwind CSS's container styles to override them. + +## Summary + +Through the above steps, we have successfully integrated Tailwind CSS into Docusaurus v3. Now, we can use all the features of Tailwind CSS while maintaining consistency with the Docusaurus theme. + +I hope this article has been helpful to you! If you have any questions, feel free to leave a comment. \ No newline at end of file diff --git a/src/pages/blog/posts/git-commit-convention.md b/src/pages/blog/posts/git-commit-convention.md new file mode 100644 index 0000000..9fef573 --- /dev/null +++ b/src/pages/blog/posts/git-commit-convention.md @@ -0,0 +1,152 @@ +--- +layout: "@/layouts/BlogPostLayout.astro" +title: "Git Commit Convention" +description: "This article details the Git commit convention, including the specific content and usage rules of the Header, Body, and Footer sections, helping team members better understand and follow a unified commit standard." +date: "2023-10-20" +image: "https://images.unsplash.com/photo-1618401471353-b98afee0b2eb?q=80&w=1476&auto=format&fit=crop" +tags: ["Git", "Convention", "Version Control"] +tagId: ["git", "convention", "version-control"] +category: "Development Tools" +categoryId: "dev-tools" +readTime: "5 min read" +--- + +### Why We Need Commit Conventions + +In team collaboration, if Git commit messages are precise, they become traceable during later collaboration and bug handling. Project development can quickly generate development logs based on standardized commit messages, making it easier for developers or users to track project development information and feature updates. + +### Structure of Commit Messages + +A commit message consists of three parts: Header, Body, and Footer. + +``` +
+ + + +