云適配獲千萬美金B輪融資，將開發移動端企業安全瀏覽器

論是打車，買菜，交水電費，乃至于按摩，現在幾乎你能想到的消費行為都能通過移動端進行操作——事實已經證明移動端的對消費者服務是個大市場。那么對企業移動端的服務的市場又怎樣呢？至少近日晨興創投和 IDG 資本對云適配千萬美元級的投資能告訴我們，風險資本覺得這個市場正在變好。

云適配創立于 2012 年，主要業務是通過網頁內容的抓取和適配，將PC端的網頁自動轉化為適合移動端的網頁。通過這項名為跨屏云 Xcloud 的服務，企業用戶不用修改任何網頁的前端設計便能把讓本不支持移動端瀏覽的網頁獲得適應移動端排版和布局。三年來，云適配的技術被用在了超過 30 萬的企業網站上，其中包括中國政府網，北京大學官網，聯想海信的官網等。

大部分企業用戶的網頁再適配都是在公有云完成，這部分服務云適配免費提供。不過一些對信息安全極為重視的客戶，比如政府和金融企業等，會選擇將跨屏云部署在自己的私有云上，云適配會向這些用戶收取一定的費用。

除了網頁適配外，云適配的另一項服務是開源的 HTML 5 前端框架 Amaze UI。Amaze UI 是一款類似 Bootsrap 的前端模塊庫，相較于 Twitter 馳名天下的 Boostrap，Amaze UI 做了更多針對中文和國內主流瀏覽器的優化。目前Amaze UI 在 GitHub上有 4000 多的收藏和 1000 多的fork。利用 Amaze UI，開發者能使用和修改現成的 HTML 5 模塊，從而加速開發。

當然，一個僅僅是現金流良好的自動化網頁適配公司并不需要千萬美元級的 B輪融資。云適配正在開發一款移動安全瀏覽器，試圖利用跨屏云帶來的用戶基礎進入更深層的企業服務市場。這款安全瀏覽器支持緩存數據沙盒化，以及VPN 網絡沙盒化等功能，從而在網頁端提供一個安全的移動互聯網辦公環境。目前這款瀏覽器尚在開發中，預計今年九月發布。

對于這次的融資，云適配的創始人，前微軟 IE 工程師陳本峰說道，“因為我自己是 HTML 5 的中國區布道師，所以我覺得我們這次融資不僅是對這個企業，也是市場對 HTML 5 在更寬廣的應用前景上的認可。”

原創文章，作者：甘源

文為翻譯本文譯者為 360 奇舞團前端開發工程師
原文標題：CSS in Micro Frontends 原文作者：Florian Rappl 原文地址：https://dev.to/florianrappl/css-in-micro-frontends-4jai

我被問得最多的問題之一是如何在微前端中處理 CSS。畢竟，樣式始終是任何UI片段所需要的東西，然而，它也是全局共享的東西，因此它是潛在的沖突來源。

在這篇文章中，我想回顧一下現有的不同策略來馴服 CSS 并使其擴展以開發微前端。如果這里的任何內容對您來說聽起來合理，那么也可以考慮研究“微前端的藝術”。

本文的代碼可以在github.com/piral-samples/css-in-mf找到。請務必檢查示例實現。

CSS 的處理是否會影響每個微前端解決方案？讓我們檢查可用的類型來驗證這一點。

微前端的類型

過去我寫了很多關于存在哪些類型的微前端、為什么存在以及何時應該使用什么類型的微前端架構的文章。采用 Web 方法意味著使用 iframe 來使用來自不同微前端的 UI 片段。在這種情況下，沒有任何限制，因為無論如何每個片段都是完全隔離的。在任何其他情況下，無論您的解決方案使用客戶端還是服務器端組合（或介于兩者之間的東西），您最終都會得到在瀏覽器中評估的樣式。因此，在所有其他情況下，您都會關心 CSS。讓我們看看這里有哪些選項。

無特殊處理

好吧，第一個也許是最（或根據觀點，最不）明顯的解決方案是不進行任何特殊處理。相反，每個微前端都可以附帶額外的樣式表，然后在渲染微前端的組件時附加這些樣式表。

理想情況下，每個組件僅在首次渲染時加載所需的樣式，但是，由于這些樣式中的任何一個都可能與現有樣式沖突，我們也可以假裝在微前端的任何組件渲染時加載所有有問題的樣式。

這種方法的問題在于，當給出諸如div或之類的通用選擇器時div a，我們還將重新設計其他元素的樣式，而不僅僅是原始微前端的片段。更糟糕的是，類和屬性也不是故障保護措施。類似的類.foobar也可以用在另一個微前端中。您將在引用的演示存儲庫中找到兩個沖突的微前端的示例，網址為solutions/default。

擺脫這種痛苦的一個好方法是進一步隔離組件————就像 Web 組件一樣。

Shadow DOM

在自定義元素中，我們可以打開一個shadow root來將元素附加到專用的迷你文檔，該迷你文檔實際上與其父文檔相互隔離。總的來說，這聽起來是一個好主意，但與這里介紹的所有其他解決方案一樣，并沒有強制要求。

理想情況下，微前端可以自由決定如何實現組件。因此，實際的 Shadow DOM 集成必須由微前端完成。

使用 Shadow DOM 有一些缺點。最重要的是，雖然 Shadow DOM 內部的樣式保留在內部，但全局樣式也不會影響 Shadow DOM。乍一看，這似乎是一個優勢，但是，由于整篇文章的主要目標只是隔離微前端的樣式，因此您可能會錯過諸如應用某些全局設計系統（例如 Bootstrap）之類的要求。link要使用 Shadow DOM 進行樣式設置，我們可以通過引用或標簽將樣式放入 Shadow DOM 中style。由于 Shadow DOM 是無樣式的，并且外部的樣式不會傳播到其中，因此我們實際上需要它。除了編寫一些內聯樣式之外，我們還可以使用捆綁器將.css（或者類似的東西.shadow.css）視為原始文本。這樣，我們只會得到一些文本。

piral-cli-esbuild對于 esbuild，我們可以配置如下的預制配置：

module.exports = function(options) {
  options.loader['.css'] = 'text';
  options.plugins.splice(0, 1);
  return options;
};

這會刪除初始 CSS 處理器 (SASS) 并為.css文件配置標準加載器。現在，shadow DOM 中的某些樣式的工作方式如下：

  import css from "./style.css";
  customElements.define(name, class extends HTMLElement {
    constructor() {
      super();
      this.attachShadow({ mode: "open" });
    }
    connectedCallback() {
      this.style.display = "contents";
      const style = this.shadowRoot.appendChild(document.createElement('style'));
      style.textContent = css;
    }
  });

上面的代碼是一個有效的自定義元素，從樣式的角度來看它將是透明的（display: contents），即只有其內容會反映在渲染樹中。它托管一個包含單個style元素的Shadow DOM。style 的內容設置為style.css文件的文本內容。

您將在引用的演示存儲庫中找到兩個沖突的微前端的示例，網址為solutions/shadow-dom。

域組件避免使用Shadow DOM 的另一個原因是，并不是每個 UI 框架都能夠處理Shadow DOM 中的元素。因此，無論如何都必須尋找一種替代方案。其中一種方式是轉而使用一些 CSS 約定。

使用命名約定

如果每個微前端都遵循全局CSS約定，那么就可以在根上避免沖突。最簡單的約定是在每個類前面加上微前端的名稱。例如，如果調用一個微前端shopping，并調用另一個微前端checkout，則兩者都會將其active類分別重命名為shopping-active/ checkout-active。

這同樣適用于其他可能存在沖突的名稱。例如，如果有一個名為 shopping 的微前端，那么我們可以將主按鈕的ID從 primary-button 改為 shopping-primary-button。如果因某種原因需要為一個元素添加樣式，我們應該使用后代選擇器，例如 .shopping img，來為 img 標簽添加樣式。這樣會應用于具有 shopping 類的元素內部的 img 元素。這種方法的問題在于 shopping 微前端可能還會使用其他微前端的元素。如果我們看到 div.shopping > div.checkout img，即使通過 checkout 微前端引入的組件承載/集成了 img，它仍然會受到 shopping 微前端 CSS 的樣式影響。這并不理想。

您將在引用的演示存儲庫中找到兩個沖突的微前端的示例，網址為https://github.com/piral-samples/css-in-mf/tree/main/solutions/default。

盡管命名約定在一定程度上解決了問題，但它們仍然容易出錯并且使用起來很麻煩。如果我們重命名微前端會怎樣？如果微前端在不同的應用程序中獲得不同的名稱怎么辦？如果我們在某些時候忘記應用命名約定怎么辦？這就是工具幫助我們的地方。

CSS Modules

自動添加前綴并避免命名沖突的最簡單方法之一是使用 CSS 模塊。根據您選擇的打包工具，這可能是開箱即用的功能，或者通過更改一些配置實現。

  // Import "default export" from CSS
  import styles from './style.modules.css';

  // Apply
  <div className={styles.active}>Active</div>

導入的模塊是一個生成的模塊，將原始類名（例如 active）映射到生成的類名。生成的類名通常是CSS規則內容與原始類名混合后的哈希值。這樣，生成的類名應該盡可能唯一.

例如，讓我們考慮一個使用esbuild構建的微前端. 對于esbuild，您需要一個插件(esbuild-css-modules-plugin)和相應的配置更改來包含 CSS 模塊。

使用Piral我們只需要調整已有的配置piral-cli-esbuild。我們刪除標準 CSS 處理（使用 SASS）并替換為插件：

const cssModulesPlugin = require('esbuild-css-modules-plugin');

module.exports = function(options) {
  options.plugins.splice(0, 1, cssModulesPlugin());
  return options;
};

現在我們可以像上面展示的那樣在我們的代碼中使用 CSS 模塊了。

您將在引用的演示存儲庫中找到兩個沖突的微前端的示例，網址為solutions/css-modules。

使用 CSS 模塊會帶來一些缺點。首先，它引入了幾個語法擴展來區分我們想要導入的樣式（因此需要進行預處理/哈希）和應保持原樣的樣式（即稍后無需導入即可使用的樣式）另一種方式是將 CSS 直接引入到 JS 文件中。

CSS-in-JS

CSS-in-JS 最近的名聲很差，但是，我認為這是一個誤解。我也更喜歡將其稱為“CSS-in-Components”，因為它為組件本身帶來了樣式。一些框架（Astro、Svelte 等）甚至允許通過其他方式直接執行此操作。經常被提及的缺點是性能問題，這通常是由于在瀏覽器中編寫 CSS 造成的。然而，這并不總是必要的，在最好的情況下，CSS-in-JS 庫實際上是構建時間驅動的，即沒有任何性能缺陷。

然而，當我們談論 CSS-in-JS（或 CSS-in-Components）時，我們需要考慮現有的各種選擇。為簡單起見，我只包含三個：Emotion、Styled Components和Vanilla Extract。讓我們看看它們如何幫助我們在一個應用程序中將多個微前端整合在一起時避免沖突。

Emotion

Emotion 是一個非常棒的庫，它為諸如React之類的框架提供了輔助功能，但并不要求將這些框架設置為先決條件。Emotion可以很好地優化和預先計算，并允許我們使用各種可用的 CSS 技術。

使用“pure”Emotion相對來說很簡單；首先安裝包：

  npm i @emotion/css

現在您可以在代碼中使用它，如下所示

  import { css } from '@emotion/css';

  const tile = css`
    background: blue;
    color: yellow;
    flex: 1;
    display: flex;
    justify-content: center;
    align-items: center;
  `;

  // later
  <div className={tile}>Hello from Blue!</div>

css 助手允許我們編寫 CSS，將其解析并放置在樣式表中。返回值是生成的類名。

如果我們特別想使用 React，我們還可以使用Emotion 中的 jsx 工廠（引入一個名為 css 的新標準屬性）或 styled 助手：

  npm i @emotion/react @emotion/styled

現在感覺很像樣式是 React 本身的一部分。例如，styled助手允許我們定義新組件：

  const Output = styled.output`
    border: 1px dashed red;
    padding: 1rem;
    font-weight: bold;
  `;

  // later
  <Output>I am groot (from red)</Output>

相反，css助手屬性使我們能夠縮短表示法：

  <div css={`
    background: red;
    color: white;
    flex: 1;
    display: flex;
    justify-content: center;
    align-items: center;
  `}>
    Hello from Red!
  </div>

總而言之，這生成的類名不會沖突，并提供了避免樣式混亂的強大性能。特別是 styled 助手深受流行的 styled-components 庫的啟發。

您將在引用的演示存儲庫中找到兩個沖突的微前端的示例，網址為:solutions/emotion。

Styled Components

styled-components庫可以說是最受歡迎的CSS-in-JS解決方案，而且往往也是這類解決方案聲譽不佳的原因。從歷史上看，它實際上是關于在瀏覽器中組合CSS，但在過去幾年中，它們確實在這方面取得了巨大進展。現在，您也可以對所使用的樣式進行一些非常好的服務器端組合.

與emotion相比，styled-components庫（對于React）需要安裝一些少量的包。唯一的缺點是類型定義是事后添加的，因此您需要安裝兩個包以獲得完整的TypeScript支持：

npm i styled-components --save
npm i @types/styled-components --save-dev

安裝后，該庫就已經完全可用：

import styled from 'styled-components';

const Tile = styled.div`
  background: blue;
  color: yellow;
  flex: 1;
  display: flex;
  justify-content: center;
  align-items: center;
`;

// later
<Tile>Hello from Blue!</Tile>

原理與相同emotion。因此, 讓我們探討另一種嘗試從一開始就實現零成本的選擇, 而不是事后添加的.您將在引用的演示存儲庫中找到兩個沖突的微前端的示例，網址為: solutions/styled-components

Vanilla Extract

我之前提到的利用類型接近組件并避免不必要的運行時成本的方法正是最新一代的CSS-in-JS庫所涵蓋的。其中最有潛力的庫之一是@vanilla-extract/css。它允許你在JavaScript中直接編寫CSS，并靜態提取類名，從而減小打包大小，提高性能。這是一種有前途的選擇，可以以類型安全和高效的方式管理樣式。使用該庫有兩種主要方式：

與你的打包工具/框架集成
直接使用 CLI 在這個例子中，我們選擇了第一種方式———— 通過與 esbuild 集成。為了使集成正常工作，我們需要使用該@vanilla-extract/esbuild-plugin包。現在我們將其集成到構建過程中。使用piral-cli-esbuild配置, 我們只需要將其添加到配置的插件中即可：

const { vanillaExtractPlugin } = require("@vanilla-extract/esbuild-plugin");

module.exports = function (options) {
  options.plugins.push(vanillaExtractPlugin());
  return options;
};

為了使 Vanilla Extract 正常工作，我們需要編寫.css.ts文件而不是普通文件.css或.sass文件。這樣的文件可能如下所示：

import { style } from "@vanilla-extract/css";
export const heading = style({
  color: "blue",
});

這是有效的 TypeScript 代碼。最終我們將獲得一個類名的導出————就像我們從 CSS modules、Emotion 等中獲得的那樣。因此，最終，上述樣式將會應用如下：

import { heading } from "./Page.css.ts";

// later
<h2 className={heading}>Blue Title (should be blue)</h2>

這將在構建時完全處理，不會有任何運行時成本。

您將在引用的演示存儲庫中找到兩個沖突的微前端的示例，網址為:solutions/vanilla-extract。

您可能會感興趣的另一種方法是使用 CSS 實用程序庫，例如 Tailwind。

CSS 實用程序，例如 Tailwind

這是一個獨立的類別，但考慮到Tailwind是該類別中的主導工具，我只會介紹Tailwind。Tailwind的主導地位甚至到了一些人問“你是寫CSS還是Tailwind？”這樣的地步。這與2010年左右jQuery在DOM操作領域的主導地位非常相似，當時人們會問“這是JavaScript還是jQuery？”

無論如何，使用CSS實用庫的優勢在于樣式是基于使用而生成的。這些樣式不會沖突，因為它們始終由實用庫以相同的方式定義。因此，每個微前端只需提供所需的實用庫部分，以按預期顯示微前端。

如果使用 Tailwind 和 esbuild，我們還需要安裝以下軟件包：

npm i autoprefixer tailwindcss esbuild-style-plugin

esbuild的配置比以前略微復雜一些。esbuild-style-plugin本質上是esbuild的一個PostCSS插件，所以必須正確配置

const postCssPlugin = require("esbuild-style-plugin");

module.exports = function (options) {
  const postCss = postCssPlugin({
    postcss: {
      plugins: [require("tailwindcss"), require("autoprefixer")],
    },
  });
  options.plugins.splice(0, 1, postCss);
  return options;
};

在這里，我們移除了默認的CSS處理插件（SASS），并用PostCSS插件替代它——同時使用autoprefixer和tailwindcss這兩個PostCSS擴展。現在我們需要添加一個有效的tailwind.config.js文件：

module.exports = {
  content: ["./src/**/*.tsx"],
  theme: {
    extend: {},
  },
  plugins: [],
};

這本質上是配置 Tailwind 的最低要求。它只是提到tsx應該掃描文件以了解 Tailwind 實用程序類的使用情況。然后找到的類將被放入 CSS 文件中。

因此，CSS 文件還需要知道生成/使用的聲明應包含在哪里。作為最低要求，我們只有以下CSS內容：

@tailwind utilities;

還有其他@tailwind指令。例如，Tailwind自帶一個重置和基礎層。但是，在微前端中，我們通常不關心這些層。這屬于應用程序 shell 或編排應用程序的關注范圍，而不是領域應用程序的關注點。

然后，CSS將被來自Tailwind中已經指定的類所替代：

<div className="bg-red-600 text-white flex flex-1 justify-center items-center">Hello from Red!</div>

您將在引用的演示存儲庫中找到兩個沖突的微前端的示例，網址為solutions/tailwind。

比較

到目前為止，所提出的幾種方法都是微前端的可行選擇。總的來說，這些解決方案也可以混合使用。一個微前端可以采用Shadow DOM方法，而另一個微前端可以使用Emotion。第三個庫可能會選擇Vanilla Extract。最重要的是所選擇的解決方案不會產生沖突，并且沒有（巨大的）運行時成本。雖然有些方法比其他方法更高效，但它們都提供了所需的樣式隔離性。

性能影響在很大程度上取決于實現方式。例如，對于CSS-in-JS，如果解析和組合都在運行時完成，可能會產生很大的性能影響。如果樣式已經預解析，只在運行時組合，則可能性能影響較小。對于類似Vanilla Extract這樣的解決方案，幾乎沒有任何性能影響。

對于 Shadow DOM，主要的性能影響可能是 Shadow DOM 內部元素的投影或移動（本質上為零）以及標簽的重新評估style。然而，這是相當低的，甚至可能會產生一些性能優勢，給定的樣式總是切中要害，并且僅專用于要在Shadow DOM 中顯示的某個組件。在示例中，我們有以下捆綁包大小：

對于Emotion和Styled Components，這些數字僅供參考，因為運行時可能（并且很可能應該）被共享。此外，給定的微前端示例確實很小（所有UI片段的總大小為3KB）。對于一個更大的微前端，增長肯定不會像這里描述的那樣成為問題。

Shadow DOM解決方案的大小增加可以解釋為我們提供的簡單實用腳本，用于將現有的React渲染輕松包裝到Shadow DOM中（而不創建新的樹結構）。如果這樣的實用腳本在中心共享，那么其大小將更接近于其他更輕量級的解決方案。

結論

在微前端解決方案中處理CSS并不需要變得困難，只需要從一開始就以有結構、有序的方式進行處理，否則就會出現沖突和問題。通常情況下，建議選擇 CSS 模塊、Tailwind 或可擴展的 CSS-in-JS 實現等解決方案.

作者:楊亞林

來源:微信公眾號:奇舞精選

出處:https://mp.weixin.qq.com/s/nGQiCuk3VEoAQwdxNNSa4g

發生重大哀悼事件時候，需要緊急將網站變灰以示哀悼，在此蟲蟲給大家總結了幾種方法，通過簡單修改一下站點樣式即可實現。

修改源碼

另外主要方便快捷的方法是使用CSS樣式的grayscale()方法。

grayscale() : 對圖片進行灰度轉換，grayscale是 <filter-function> 的子屬性，當100%參數時候的效果如下：

最簡單地把頁面的<html>開始標簽中間之間加：

style="-webkit-filter: grayscale(100%);"

或者修改站點CSS樣式

html {-webkit-filter: grayscale(100%);filter:progid:DXImageTransform.Microsoft.BasicImage(graysale=1);}

將上述代碼添加加到CSS最頂端就可以實現。

為了兼容多種瀏覽器標準，可以增加一下樣式：

html {
-webkit-filter: grayscale(100%);
-moz-filter: grayscale(100%);
-ms-filter: grayscale(100%);
-o-filter: grayscale(100%);
filter:progid:DXImageTransform.Microsoft.BasicImage(grayscale=1);
_filter:none;
}

如果網站后臺無法定義CSS樣式，這需要在站點模板頁的head標簽中間插入style標志位：

<style>
html{-webkit-filter: grayscale(100%);}
</style>

對于一些老的網站，為了支持該函數需要修改html標頭，將其修改為最新標準標頭才可以：對一些使用Flash（不在建議使用）的老站點，起顏色可能也不支持CSS濾鏡變灰，則需要在可以在FLASH代碼的<object …>和之間插入：

Nginx代理

對于一下沒有辦法修改源站代碼的情況下，也可以在Nginx站點代理無服務器上，通過sub_filter指令來實現。

受限確保nginx支持http_sub_module模塊，如果不支持需要重新編譯安裝Nginx，自愛安裝時候添加build參數—with-http_sub_module

然后在Nginx的http模塊增加如下代碼：

sub_filter '</head>' '<style type="text/css">html{ -webkit-filter: grayscale(100%);filter:progid:DXImageTransform.Microsoft.BasicImage(grayscale=1);}</style>';sub_filter_once on;

然后nginx -t測試配置正常無誤

nginx -s reload 重啟nginx即可

在線咨詢

上一篇：千鋒武漢Web前端培訓詳解：HTML5與Web前端的區別
下一篇：C# 將HTML轉為XML

您的項目需求

*請認真填寫需求信息，我們會在24小時內與您取得聯系。

整合營銷服務商