The new responsive: Web design in a component-driven world 新的响应式-组件驱动

Responsive Design Today

Today, when using the term: "responsive design", you are most likely thinking about using media queries to change layout when resizing a design from mobile size, to tablet size, through to desktop size.

But soon, this perception of responsive design may be considered as outdated as using tables for page layout.

Viewport-based media queries give you some powerful tools, but lack a lot of finesse. They lack the ability to respond to user needs, and the ability to inject responsive styles into components themselves.

When referring to components for the sake of this article, this means elements, including elements that are made up of other elements, like a card or sidebar. Those components make up our web pages.

You can use global viewport information to style your components, but they still don't own their styles, and that doesn't work when our design systems are component-based and not page-based.

The good news is, the ecosystem is changing, and it's changing pretty rapidly. CSS is evolving, and a new era of responsive design is right on the horizon.

We see this happen about every 10 years. 10 years ago, around 2010-2012, we saw a huge change with mobile and responsive design, and the emergence of CSS3.

So it works out that, yet again, the ecosystem is ready for some pretty big changes to happen to CSS. The engineers at Chrome and across the web platform are prototyping, speccing, and starting the implementation for the next era of responsive design.

These updates include user-preference based media features, container queries, and media queries for new screen types, such as foldable screens.

Responsive to the user

New user preference media features, give you the ability to style web experiences that align with the user's own specific preferences and needs. This means that preference media features allow you to adapt your user experiences to your user's experiences

These user preference media features include:

  • prefers-reduced-motion
  • prefers-contrast
  • prefers-reduced-transparency
  • prefers-color-scheme
  • inverted-colors
  • And more

Preference features pick up on the preferences a user has set in their operating system, and help to build a more robust and personalized web experience, especially for those with accessibility needs.


Users who have set operating system preferences for reduced motion, are requesting fewer animations when using their computer in general. Therefore, it's likely that they wouldn't appreciate a flashy intro screen, card flip animation, intricate loader, or other flashy animations while using the web.

With prefers-reduced-motion you can design your pages with reduced-motion in mind, and create a motion-enhanced experience for those who don't have this preference set.

This card has information on both sides. The baseline reduced-motion experience is a crossfade to show that information, while the motion-enhanced experience is a card flip.

Prefers-reduced-motion shouldn't mean "no motion", since motion is so critical to conveying information online. Instead, provide a solid baseline experience that guides your users without unnecessary movement, and progressively enhance that experience for your users without those accessibility needs or preferences.


Another preference media feature is prefers-color-scheme. This feature helps you to customize your UI to the theme which your user prefers. In their operating system, whether it's on desktop or mobile, users can set a preference for light, dark, or auto themes, which change depending on the time of day.

If you set up your page using CSS custom properties, swapping color values is made straightforward. You can quickly update your color theme values, such as backgroundColor and textOnPrimary to dynamically adjust to the new theme within the media query.

To make it easier to test some of these preference queries out, you can use DevTools for emulation instead of opening up your system preferences each time.

Designing for dark theme

When designing for a dark theme, it's not just about inverting background and text colors or dark scrollbars. There are a few considerations you might not realize. For example, you might need to desaturate colors on a dark background to reduce visual vibration.

Instead of using shadows to create depth and draw an element forward, you may want to use light in the element's background-color to draw it forward. This is because shadows won't be as effective on a dark background.

Dark themes not only provide a more customized user experience, but they can also improve battery life significantly in AMOLED screens. Those are the screens we're seeing in newer high-end phones, and they're becoming increasingly popular across mobile devices.

A 2018 Android study on dark themes showed a power draw savings of up to 60%, depending on the screen brightness and overall user interface. The 60% statistic came from comparing the Youtube play screen with a paused video at 100% screen brightness using dark theme for the app UI vs a light theme.

You should always provide a dark theme experience for your users whenever possible

Responsive to the container

One of the most exciting emerging areas in CSS is container queries, also frequently called element queries. It's hard to understate what the shift from page-based responsive design to container-based responsive design will do to evolve the design ecosystem.

Here's an example of the powerful abilities that container queries provide. You can manipulate any of the card element's styles, including the link list, font sizes, and overall layout based on its parent container:

This example shows two identical components with two different container sizes, both taking up space in a layout created using CSS Grid. Each component fits its unique space allotment, and styles itself accordingly.

This amount of flexibility is something that is not possible with media queries alone.

Container queries provide a much more dynamic approach to responsive design. This means that if you put this card component in a sidebar or hero section or within a grid inside of the main body of a page, the component itself owns its responsive information and sizes according to the container, not the viewport

This requires the @container at-rule This works in a similar way to a media query with @media, but instead, @container queries the parent container for information rather than the viewport and user agent.

.card {
  contain: size layout;

@container (max-width: 850px) {
  .links {
    display: none;

  .time {
    font-size: 1.25rem;

  /* ... */

First, set containment on the parent element. And then, write a @container query, to style any of the elements within the container based on its size, using min-width or max-width.

The code above uses max-width, and sets the links to display:none, as well as decreasing the time font size when the container is less than 850px wide.

Container query cards

In this demo plant website, each of the product cards, including the one in the hero, the sidebar of recently viewed items, and the product grid, are all the exact same component, with the same markup.

There are no media queries used to create this entire layout, just container queries. This allows for each product card to shift to the proper layout to fill its space. The grid for example, uses a minmax column layout to let the elements flow into their space, and re-layout the grid when that space is too compressed (which means that it hit the minimum size).

.product {
  contain: layout inline-size;

@container (min-width: 350px) {
  .card-container {
    padding: 0.5rem 0 0;
    display: flex;

  .card-container button {
    /* ... */

When there is at least 350px of space in the grid, the card layout goes horizontal by being set to display: flex, which has a default flex-direction of "row".

With less space, the product cards stack. Each product card styles itself, something that would be impossible with global styles alone.

Mixing Container Queries with Media Queries

Container queries have so many use cases—one being a calendar component. You can use container queries to re-layout the calendar events and other segments based on the available width of their parent.

This demo container queries to change the layout and style of the calendar's date and day of the week, as well as adjusting the margins and font size on the scheduled events to help them better fit the space.

Then, use a media query to shift the entire layout for smaller screen sizes. This example shows how powerful it is to combine media queries (adjusting the global, or macro styles) with container queries (adjusting the container's children, and their micro styles).

So now we can think of Macro and Micro layouts within the same UI component to allow for some really nice nuanced design decisions.

Using container queries today #
These demos are now available to play with behind a flag in Chrome Canary. Go to about://flags in Canary and turn on the #enable-container-queries flag. This will enable support for @container, inline-size and block-size values for the contain property, and the LayoutNG Grid implementation.

Scoped styles

Scoped styles allow for pass-through and component-specific styling to avoid naming collisions, something that many frameworks and plugins like CSS modules already enable us to do within frameworks. This spec would now allow us to write encapsulated styles natively for our components with readable CSS without the need to adjust the markup.

/* @scope (<root>#) [to (<boundary>#)]? { … } */

@scope (.tabs) to (.panel) {
  :scope { /* targeting the scope root */ }
  .light-theme :scope .tab { /* contextual styles */ }

Scoping would allow us to create "donut shaped" selectors, where we can specify where to keep a style encapsulated, and where to break out of that scoped style to refer back to a more global style.

An example of this would be a tab panel, where we'd want the tabs to get the scoped style, and the panel within the tabs to get a parent style.

Responsive to the form factor

The next topic in our conversation about the new era of responsive design is a shift in form factors, and the growing possibilities of what we'll need to be designing for as a web community (such as shape-shifting screen or virtual reality).

Foldable or flexible screens, and designing for screen spanning is one example of where we can see a form factor shift today. And screen-spanning is yet another spec being worked on to cover these new form factors and needs.

An experimental media query for screen-spanning could help us here. It currently behaves like this: @media (spanning: ). The demo sets up a grid layout with two columns: one has a width of --sidebar-width, which is 5rem by default, and the other is 1fr. When the layout is viewed on a dual screen that has a single vertical fold, the value of --sidebar-width is updated with the environment value of the left fold.

:root {
  --sidebar-width: 5rem;

@media (spanning: single-fold-vertical) {
  --sidebar-width: env(fold-left);

main {
    display: grid;
    grid-template-columns: var(--sidebar-width) 1fr;

This enables a layout where the sidebar, the navigation in this case, fills the space of one of the folds, where the app UI fills the other. This prevents a "crease" in the UI.

You can test out foldable screens in the Chrome DevTools emulator to help debug and prototype screen spanning directly in the browser


Exploring UI design beyond a flat screen is yet another reason why container queries and scoped styles are so important. They give you the opportunity to silo component styles from page layout and global styles, and user styles, enabling more resilient responsive design. This means you can now design macro layouts using page-based media queries, including screen-spanning nuances. At the same time using micro layouts with container queries on the components, and add user-preference based media queries to customize user experiences based on their unique preferences and need.

It's combining macro layout with micro layout, and on top of all of that, it's taking user customization and form factor into account.

Any of these changes alone would constitute a considerable shift in how we design for the web. But combined, they signify a really big shift in how we even conceptualize responsive design. It's time to think about responsive design beyond viewport size, and start considering all of these new axes for better component-based and customized experiences.

The next era of responsive design is here, and you can already start to explore it yourself


基本来讲,以后的响应式网站的设计不单单再是一个div或者容器这些元素根据viewport视口大小来仅改变size。比如说现在流行的黑暗模式,使用的是媒体查询media queries(prefers-color-scheme)响应用户的需求。
第二来讲,响应式的元素有时不是根据视口来响应,是根据包在外层的容器来响应的,要使用container quieries容器查询






  • 知道基本的安装系统,系统如何设置BIOS
  • 大概知道黑苹果和装win的不同
  • 知道黑苹果相较白苹果体验上会有缺失
  • 你有足够的耐心吗
  • 你会英语吗


  • 台式机:我很赞成去装黑苹果,比笔记本的事情少多了
  • 笔记本:如果你就是为了去用黑苹果当主力,我建议你去用win11。如果是学习,建议备份好原来系统,之后试一试,最后还是用win



  • CPU:AMD Ryzen 锐龙 3600
  • GPU:RX480 XFX OC
  • 主板:MSI微星 B450m 迫击炮max
  • 无线网卡:高通 AR 9565
  • 有线网卡:Realtek Gbyte
  • 硬盘:西数 SN550








  • 获取数据
  • 使用获取的数据



网易云的资源会禁止同一个IP多次的访问,因此资源的地址也不断的变化。只能多使用hexo g来更新资源地址了





const element = <h1>Hello, world!</h1>;


const element = <h1>Hello, {name}</h1>;


const element = <img className={imgClass} src={user.avatarUrl} />;
  • class`属性写为`className
  • 属性用小驼峰语法
const element = <h1>Hello, world!</h1>;

一个可运行的React Hello World例子







npm i hexo-vtuber-banner

支持Hexo 3.0以上的版本





1. webpack是什么






root@ali_server:~# cat file1||cat file2   



为什么会这样呢?“||”的意思不是或者吗,没错,但是在Linux中是先执行||前面的命令也就是例子中的cat file1如果执行失败会执行后面的cat file2,并且都要先执行第一个命令,无论成功或者失败

cat a成功后就执行第一个cat a
a1不存在,但是也会执行这个命令,之后执行后面的cat a


root@ali_server:~# cat file1&&cat file2



“&&”代表并且,也就是“都”的意思,所以就是既cat file1又cat file2










先上个曹卖图首先以下说明全部都是NS动森(Animal Crossing: New Horizon)解包出来的数据,与版上有人PO的3DS数据只有少许出入,如果你已经看过3DS版也不想多花时间的话,可以直接跳过这篇说明了。再来要感谢Ninji将这次控制大头菜价格的code解包出来(推特链接)有兴趣的可以进去看大头菜价格是怎么写的。tl;dr: 直接用以下链接计算预测大头菜价格即可(由Reddit网友/u/mikebryantuk制作)大头菜价格预测工具以下正文是根据网友/u/Edricus写的Breaking Down the Stalk Market翻译并根据解包code修正内文的错误之处最后是这篇是写给像我这种边缘人看的,有朋友的话直接到有好价钱的朋友岛上卖出即可。正文开始(只想看判断方式与简表的话可以直接跳到四,晚点补上)



1.模型种类本次大头菜价格波动共有4种模型,分别为0 – 波型(Random)1 – 三期型(Large Spike)

2 – 递减型(Decreasing)

3 – 四期型(Small Spike)每周玩家皆会被系统指派一种售价模型,直到下次曹卖出现才会再次更动模型,为期7天。并且玩家本周的售价模型会影响下周的售价模型机率,具体如下

举例:如果玩家本周价格模型为三期型,下周将有50%机会变为波型、5%机会变三期型、20%机会变为波型、25%机会变为四期型。2. 期(Phases)每周我们可以把每次价格变动时间区分开来,一天2期一周共可分为14期。每期的长度为12小时。每天的12AM与12PM会进入下一期并更新卖价。因为商店是从8AM开到10PM,所以一天实际上能卖的期间只能分为上半期(8AM-12PM)4小时,与下半期(12PM-10PM)10小时。有趣的是周日的两期虽然无法卖菜,但在代码中是有给予售价的,都是卖0铃钱,实际上能卖菜的只有12期。


各阶段发生的时序固定为上涨阶段1 – 下跌阶段1 – 上涨阶段2 – 下跌阶段2 – 上涨阶段3各阶段的价钱算法表(以下所有与铃钱有关计算皆为计算后无条件进位至下个整数)

此模型重点最好价格为买价的1.4倍,最差价格为买价的0.9倍以基础价格100铃钱来说,就是140与90铃钱TIPS如果发现是波型请赶快在价格好时售出虽然机率很低,但最坏情况有可能都不会超过买价。2. 三期型最刺激好赚的模型,要发大财就要靠这个各阶段的持续时间表

各阶段发生的时序固定为下跌阶段 – 暴涨阶段 – 暴跌阶段 – 乱数下跌阶段各阶段的价钱算法表

此模型重点此模型可以算出收购大头菜的最高价为110*600% = 660铃钱TIPS此模型开始与递减型一模一样,也与第四期很相似如果发现开始涨价,并且开始涨价的第2个半天涨超过140%请务必在下个半天卖掉。3.递减型最浅显易懂的模型,一定不会赚钱。各阶段的持续时间表



各阶段发生的时序固定为下跌阶段1 – 上涨阶段 – 下跌阶段2各阶段的价钱算法表