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.

prefers-reduced-motion

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.

prefers-color-scheme

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

Conclusion

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容器查询

原文链接

黑苹果opencore2021和win11做朋友

这一篇文章我是为了自己做一份装黑果教程的备份,同时发布到Hexo上去。也是给看到这一篇博客的人有一点的帮助吧

一、逛贴吧、论坛、研究自己的配置、弄个能翻山越岭的网(很多东西都是GitHub下载,慢的要命)

有下面几个问题

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

你的电脑配置:
首先,你的电脑是台式机吗?还是笔记本

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

之后,了解你的配置(这一点是很重要的,会让你知道你的设备能不能装黑苹果)
下面会放几个链接,链接到opencore官网,要求你能基本的看个懂,不过我相信我在这里提示链接是干什么的,你打开链接后应该能明白个七七八八

我放下我的配置:

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

通过上面的链接,如果发现你的配置不符合,我劝你要么换配置,要么win11

继续阅读

ncm网易云小插件发布

npm

为了拓展博客的小组件,且边看博客边听歌。完成了一个网易云音乐小组件

在侧边栏可以看到

完成这个组件有两点

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

获取数据使用的fetch,异步。因为hexo渲染页面在渲染post之前,所以不能将获取数据放到挂载的钩子下。因此只能异步获取数据并写入到一个json文件,使用的时候直接同步读取这个json文件

使用数据则为dom的相关操作。

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

React速查

React速记,分为3个部分。每一个部分由简短且精悍的知识点组成。开发忘记可查看,初见学习可常翻

基础

一、JSX

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

JavaScript和UI代码的结合

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

{}包裹表达式(js表达式,变量)

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

一个可运行的React Hello World例子

继续阅读

vBanner插件发布

完成了一个hexo的美化插件,可以添加4:1比例的图片,给这个插件使用

npmGithub

效果如上图所示,已经发布到了npm

可以直接用安装npm包命令

npm i hexo-vtuber-banner

支持Hexo 3.0以上的版本

默认的banner的页面注入位置为<header></header>标签之中,默认会注入到Hexo的所有页面之中。可以配置默认注入的页面

国内可访问gitee仓库

如果你觉得还不错,请给我一个小星星吧!

webpack速览知识

1. webpack是什么

 按照官方的定义:webpack是一种静态资源的打包器。比如说有两个模块都通过CJS或者是ESM引入了一些js库,通过webpack就可以将引入的这些js库打包到bundle中去。再比如,要通过require的方式引入一个非js的文件,也可以通过webpack来转换为可以让其直接引用的模块

继续阅读

Linux中的||和&&

如果在shell中执行这样的命令输出是什么呢?

假设下面命令中的两个文件都存在

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

答案:鼠标移动到下方的黑条处或点击下方黑条即可查看答案

会输出file1的内容

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

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

同样还是file1和file2,如果执行下面的命令

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

答案:鼠标移动到下方的黑条处或点击下方黑条即可查看答案

会输出file1和file2的内容

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

记一次老友的Linux服务器被恶意程序入侵并解决的过程

首先放一个老友的连接:http://yuyy.info
恶意程序名称:javaUpdate

前言

最近的日子正是毕业的日子,也是最忙的日子。老友给我发了条信息,说他服务器中招了

通过ssh登录老友的服务器,发现登录的时候要卡很久,通过强制中断ctrl+c才能看见用户提示符

用top命令查看下现阶段运行进程情况,top命令简单说就是监控Linux中运行的进程的在系统中情况

继续阅读

大头菜价格完全攻略

原文链接:https://xw.qq.com/cmsid/20200403A0S9X500

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

一、基础价格:为玩家在周日所购入的大头菜价格,在模型预测中占有重要地位。大头菜的购入价格必在(90,110)的区间中乱数决定,即大头菜价格一定是90-110铃钱。举例:周日跟曹卖买大头菜1颗100铃钱,从明天(周一)起至周六的基础价格皆为100铃钱。不会因为你跑去别人岛上买较便宜的大头菜而改变,直到下周日曹卖再次出现才会改变。

二、售价模型:

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期。

三、各模型细节以下模型解释中,各种举例为方便计算我们假设基础价格为100铃钱。1.波型波型中我们可以把价格变动区分成2大阶段,分别为下跌阶段上涨阶段每周皆固定会有2次的下跌阶段与3次的上涨阶段各阶段的持续时间表(以下为方便理解我们将1期称为1个半天)

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

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

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

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

各阶段的价钱算法表

此模型重点没有重点,块陶TIPS此模型开始与三期型一模一样,第8个半天(礼拜四下午)还没涨的话请赶快想办法卖掉。3.四期型虽然不像三期型那么爽,但也不失为一个赚钱的好机会。各阶段的持续时间表

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

此模型重点相当平均的模型,容易在早期发现,也可以卖到上限2倍买价的钱,不错。TIPS只要第1个半天(周一上午)跌超过15%就一定是四期型,虽然机率低但也有万一一开始就近入上涨阶段,会与波型十分相似,分别重点是第3个半天(周二上午),如果有涨超过1.4倍则必为四期型,请务必等到上涨阶段的第4个半天将大头菜卖掉。四、结论从以上讨论可以得知大头菜的买价必为90-110铃钱且可以预测并在最好的时机将菜卖出,也可以得知大头菜最好与最坏的收购价。最好:三期型,基础价格110,股神有机会卖到一颗660铃钱。最差:四期型,基础价格90,有可能惨到一颗9铃钱,但四期型一定会涨回来,无须担忧。