模态对话框弹出模态对话框_模态对话框驱动的没有javascript的网站

模态对话框弹出模态对话框

Continuing the theme of my last article, I wanted to cover how modal dialogs can be made without JavaScript. Using the following techniques major site functions and navigation can be simplified through their use.

继续上一篇文章的主题，我想介绍如何在没有JavaScript的情况下进行模式对话框。 使用以下技术，可以简化主要站点的功能和导航。

Once again, sites that use JavaScript for much of this — modal dialogs, menu dropdowns, “hamburger” style mobile menus — all tend to be utter and complete failures at usability and accessibility; particularly when it comes to their lack of graceful degradation.

再一次，在大多数情况下使用JavaScript的网站-模态对话框，菜单下拉菜单，“汉堡”式移动菜单-都在可用性和可访问性方面完全失败了。 特别是当他们缺乏优雅降级时。

Likewise many common “classical” navigation techniques — like dropdown menus — are a giant middle finger to users with accessibility needs. Repeatedly we’ve been told by places like NNGroup and essential guides like the WCAG not to use scripting for these things and how even non-scripted they are problematic.

同样，许多常见的“经典”导航技术(例如下拉菜单)对于有辅助功能需求的用户来说，是一个巨大的中指。 诸如NNGroup之类的地方以及诸如WCAG之类的基本指南一再告诉我们，不要为这些事情使用脚本，甚至不编写脚本也有问题。

CSS3 gives us all the tools we need to fix this problem! Typically in the same or even less code, in a way that non screen media devices — screen readers (software that reads the page aloud), braille readers, search engines, and so forth are able to digest the page just fine as if it were simply conventional navigation.

CSS3为我们提供了解决此问题所需的所有工具！ 通常，使用相同或更少的代码，可以使非屏幕媒体设备(屏幕阅读器(可大声读取页面的软件)，盲文阅读器，搜索引擎等)能够很好地消化页面，就像只需常规导航。

… and the magic of this comes from one simple pseudo-state. :target

……而其神奇之处就在于一个简单的伪状态。 :target

什么是CSS3 :target ？ (What is CSS3 :target?)

It lets us style elements that are currently the target of the hash part of the current page address. When that hash matches either the name on an <a>nchor tag, or when it matches any element with the same ID on the page, :target is true for said element.

它使我们可以为当前页面地址的哈希部分的目标对象设置样式。 当该哈希值与<a> nchor标记上的名称匹配，或与页面上具有相同ID的任何元素匹配时，：target对于该元素而言为true。

That latter use — targeting ID’s — for style is the one we want. If I have:

我们想要的是样式的后一种用途(定位ID)。 如果我有：

<div id="test">Some Text</div>

and this CSS:

和这个CSS：

#test:target { color:red; }

When the URI has the hash #test at the end, the text inside our DIV will be red, otherwise it will be the default colour.

当URI末尾有#test哈希值时，DIV中的文本将为红色，否则为默认颜色。

那么我们如何用它来做模态？ (So How Do We Use That To Make a Modal?)

When the element is not:target, hide it. When it is… well, show it. There’s your toggle state without getting scripting involved.

当元素不是目标时，将其隐藏。 当它...好吧，显示它。 您的切换状态没有涉及脚本。

标记 (The Markup)

If we were to hide the outer container of our modal by default, but then show it over our content when it is the :target, the result means that all we need to open our modal is:

如果默认情况下我们要隐藏模式的外部容器，但是当它是:target时在我们的内容上显示它，结果意味着我们需要打开模式的所有内容是：

<a href="#ourModal">Open Our Modal</a>

Whilst to close it, we can just put:

在关闭它的同时，我们可以输入：

<a href="#">Close Modal</a>

… inside the modal. By changing the hash to empty, the modal closes.

…在模态内。 通过将散列更改为空，模式将关闭。

After much tinkering, I’ve settled on this structure for the technique:

经过大量修改后，我为该技术确定了以下结构：

<div id="ourModal" class="modal">
  <a href="#" class="modalClose" hidden aria-hidden="true"></a>
  <div><section>
    <a href="#" class="modalClose" hidden aria-hidden="true"></a>
    <h2>Our Modal</h2>
    <div>
      <p>
        A Sample Modal
      </p>
    </div>
  </section></div>
<!-- #ourmodal.modal --></form>

As always trying not to take a piss on the markup with “classes for nothing” and instead allowing semantics and DOM structure do most of the work.

与往常一样，不要对“无为之类”的标记大惊小怪，而是允许语义和DOM结构完成大部分工作。

The outer DIV’s purpose is obvious, it will be our “fixed” container set to full screen. Using display:flex; with align-items:center; and justify-content:center; will center the contents, but if you have any experience with flex or center, you know that it screws over scrolling. Overflow:auto on flex containers is fragile, unreliable, and often just plain broken. Hence rather than setting flex on the outer wrapper, we set it on that first DIV tag inside DIV.modal.

外部DIV的目的很明显，它将是我们的“固定”容器设置为全屏显示。 使用display:flex; 与align-items:center; 和justify-content:center; 将使内容居中，但是如果您有使用flex或center的经验，那么您会知道它会使滚动变得麻烦。 溢出：flex容器上的auto易碎，不可靠，并且经常被破坏。 因此，我们没有在外包装上设置flex，而是在DIV.modal内部的第一个DIV标签上进行了设置。

We have two a.modalClose. These got classes because we may need or want them in places where structurally selecting them is inconsistent. The first one is for a full screen close, that way if you click outside the actual content area it will close the modal. The second is for generated content to add an obvious close button to make a clear visual spot to close it, and for when the screen is too small to have an area around the actual content <section>.

我们有两个a.modalClose。 之所以选择这些类，是因为我们可能需要或希望它们在结构上选择它们不一致的地方。 第一个是全屏关闭，这样，如果您在实际内容区域之外单击，它将关闭模式。 第二个是为生成的内容添加一个明显的关闭按钮，以使其清晰可见，以将其关闭；以及当屏幕太小而无法在实际内容<section>周围保留区域时。

Both of these anchors are set to hidden and aria-hidden=”true” so that non-screen media UA’s ignore both elements. Screen readers (software that reads the page aloud), braille readers, search engines, and the like will pretend these anchors do not exist. They won’t focus them when keyboard navigating, they won’t try to read their contents. They don’t exist in any modern UA unless we target them to be shown by changing their display state with CSS. Therefore if we use media=”screen” on our stylesheet <link> we can turn them on just for screen media devices.

这两个锚均设置为hidden和aria-hidden=”true”以便非屏幕媒体UA忽略这两个元素。 屏幕阅读器(大声读取页面的软件)，盲文阅读器，搜索引擎等将假装这些锚点不存在。 他们不会在键盘导航时集中精力，也不会尝试阅读其内容。 除非我们通过使用CSS更改其显示状态来将它们显示为目标，否则它们在任何现代UA中都不存在。 因此，如果我们在样式表<link>中使用media =” screen”，则可以仅针对屏幕媒体设备将它们打开。

Side node, 99% of the time you see a <link> or <style> that lacks media=”” or is set to media=”all”, you’re looking at those pesky 3i of web development: Ignorance, incompetence, and ineptitude. That’s why media queries that say “screen and” in an external stylesheet are equally ignorant trash. But then, the same could be said of <style> or style=”” in the majority of usage cases.

侧节点，在99％的时间中，您看到的<link>或<style>缺少media =””或设置为media =” all”，您会看到网络开发中令人讨厌的3i：无知，无能，和无能。 这就是为什么在外部样式表中显示“屏幕和”的媒体查询同样是无知的垃圾。 但是，在大多数使用情况下，<style>或style =””也可以这样说。

Because DIV are semantically neutral, and because we hide the anchors, non-screen UA’s — and this includes search — will actually treat the above markup as:

因为DIV在语义上是中立的，并且因为我们隐藏了锚点，所以非屏幕UA(包括搜索在内)实际上会将上述标记视为：

<h2>Our Modal</h2>
<p>
  A Sample Modal
</p>

And nothing more. Even better alternative navigation will let the links to the modal navigate to these subsections, without our fancy visuals, just like any other normal on-page hash link! The links even end up in the browser history, so “back’ will also close the modal and/or lead non-visual users back to where they were before they clicked on the “modal” link.

仅此而已。 甚至更好的替代导航也可以使模式对话框的链接导航到这些小节，而无需花哨的视觉效果，就像其他任何普通的页面哈希链接一样！ 这些链接甚至出现在浏览器历史记录中，因此“后退”还将关闭模式，并且/或者将非可视用户引导回他们单击“模式”链接之前的位置。

Note that because these section/nav are fully qualified content sections, structurally you should be starting them with a H2 as top level sections.

请注意，由于这些部分/导航是完全合格的内容部分，因此从结构上讲，您应该从H2作为顶层部分开始。

This is ideal! This solves every last possible accessibility issue on-page modals could create.

这很理想！ 这解决了页面模式可能创建的每一个可能的可访问性问题。

Remember, THE H1 (singular) is THE heading (singular) that everything on the entire site is a subsection of. Like the title at the top of every fold-pair in a book or newspaper. H2 mark the start of major subsections of the page, H3 mark the start of subsections of the H2 preceding them. H4 mark the start of subsections of the H3 before them… care to guess what H5 and H6 are for? Even lowly HR means a change in topic or section, NOT “draw a line across the screen”.

请记住，H1(单数)是头部 ING(奇异)对整个网站 ，一切的小节。 就像书或报纸中每对折页顶部的标题一样。 H2标记页面主要小节的开始，H3标记页面前面主要小节的开始。 H4标志着它们前面的H3子节的开头……要猜猜H5和H6是做什么用的？ 即使是较低的人力资源，也意味着主题或章节的改变，而不是 “在屏幕上划一条线”。

Which is why you don’t willy-nilly skip down to a depth 5, or start a document with a H4, or all the other reasons the morons, quacks, and fools who create and maintain “frameworks” like tailwind and bootcrap aren’t qualified to flap their blasted yap about writing HTML, much less develop tools for others to do so!

这就是为什么您不会故意跳过深度5或以H4开头的文档，或是其他所有创建和维护“框架”(例如顺风和靴子)的白痴，庸医和傻瓜的原因。有资格扑灭有关编写HTML的狂妄言论，更不用说开发其他工具了！

其他事宜 (Other issues)

One problem with creating modals is that the BODY scrollbar if present cannot be overlapped by the modal. This can result in a pointless scrollbar when the modal is open, or even multiple confusing scrollbars when the window is smaller than the modal content.

创建模态的一个问题是，BODY滚动条(如果存在)不能被模态覆盖。 当模式打开时，这可能导致无意义的滚动条，或者当窗口小于模式内容时，甚至导致多个混乱的滚动条。

To get around this an extra DIV acting as a faux body that is sibling to our modals is the easiest answer; but as mentioned above scrolling via overflow:auto; screws with flex (or is it the other way around?) so an extra inner containing DIV gets added to get us around this problem. This way we can also make our layout be 100% min-height via flex.

要解决这个问题，最简单的答案就是为我们的模态提供同级的额外DIV作为人造物体。 但如上所述，通过溢出滚动： 带挠性的螺钉(或者是相反的方法？)，因此添加了一个额外的包含DIV的内部组件，以使我们能够解决此问题。 这样，我们还可以通过flex使我们的布局最小高度为100％。

<div id="fauxBody"><div id="fauxInner">
<!-- page Content here -->
<!-- #fauxInner, #fauxBody --></div></div>

Notice how I place the closing comment before the actual tags. This avoids rendering bugs in some browser engines where comments between sibling level elements or between closures can be treated as content or trigger “double render” bugs. Whilst a non-issue in most modern browsers, it’s far better practice than putting your comments after the close.

请注意，我如何在实际标签之前放置结束语。 这样可以避免某些浏览器引擎中的渲染错误，在这些浏览器引擎中，同级元素之间或闭包之间的注释可以视为内容，也可以触发“双重渲染”错误。 尽管在大多数现代浏览器中没有问题，但比起在结束时发表评论要好得多。

We also will likely want to use the same modal techniques for the main menu. However, this would only be done in a media query so that “normally” it’s not a modal. Thus the markup for that would go something like this:

我们也可能希望对主菜单使用相同的模态技术。 但是，这只能在媒体查询中完成，因此“通常”不是模态查询。 因此，其标记将如下所示：

<header id="top">  <h1>
    Modal Site Demo
  </h1>
  <div id="mainMenu">
    <a href="#" class="modalClose" hidden aria-hidden="true"></a>
    <div><nav>
      <a href="#" class="modalClose" hidden aria-hidden="true"></a>
      <ul>
        <li><a href="#submenu">Sub Menu</a></li>
        <li><a href="#search">Search</a></li>
        <li><a href="#login">Log In</a></li>
      </ul>
    </nav></div>
  <!-- #mainMenu --></div>
  <a href="#mainMenu" class="mainMenuOpen" hidden aria-hidden="true"></a>
 <!-- #top --></header>

I give the header the id of #top as a hook for “back to top” links. The outer DIV gets an ID so our a.mainMenuOpen can point at it. We use NAV instead of SECTION, we can just use the UL instead of an extra wrapping DIV, and all the modal related anchors again get that same hidden and aria-hidden=”true” so that screen readers ignore them.

我给标头ID #top作为“返回顶部”链接的钩子。 外部DIV获得一个ID，因此我们的a.mainMenuOpen可以指向它。 我们使用NAV代替SECTION，我们可以仅使用UL代替额外的包装DIV，并且所有与模式相关的锚点都再次具有相同的hidden和aria-hidden =“ true”，因此屏幕阅读器将忽略它们。

风格 (The Style)

For our screen media stylesheet the first thing we want to do is turn all those anchors back on, and we might as well kill the default underscores whilst at it.

对于我们的屏幕媒体样式表，我们要做的第一件事是重新打开所有这些锚点，我们不妨在此期间取消默认的下划线。

.modal .modalClose {
 display:inline; /* undo hidden */
 text-decoration:none;
}

Then we need to place all of our modal related containers, including #fauxBody.

然后，我们需要放置所有与模式相关的容器，包括#fauxBody。

.modal,
.modal > .modalClose,
#fauxBody {
  position:absolute;
  top:0;
  left:0;
  width:100%;
  height:100%;
  overflow:auto;
}

Normally you’d think to use position:fixed, but that can actually cause problems in webkit with scrolling and positioning. I’m not sure why it’s a problem, but since these are all children of BODY, and are all full screen size, and ALL our content will go inside these containers, position:absolute can fulfill the same function!

通常，您会考虑使用position：fixed，但这实际上可能会导致webkit中滚动和定位出现问题。 我不确定为什么会出现问题，但是由于这些都是BODY的子级，并且全屏显示，并且我们所有的内容都将放在这些容器中，所以position：absolute可以实现相同的功能！

From there we want to hit-up our modals.

在这里，我们想了解我们的模态。

.modal {
  left:-100vw;
  opacity:0;
  padding:1em;
  transition:opacity 0.3s, left 0s 0.3s;
  background:radial-gradient(
    hsla(220, 100%, 100%, 0.8) 20%,
    hsla(220, 100%, 85%, 0.95) 100%
  );
}

Because they’re width:100% and overflow:auto all we need to do to hide them is slide them off the left side of the screen by viewport-width. Boom, they’re hidden. DO NOT USE DISPLAY:NONE; OR VISIBILITY:HIDDEN; FOR THIS!!! That will prevent search engines looking for content-cloaking abuse being able to see the content of these elements!

因为它们的width：100％和overflow：auto，要隐藏它们，我们需要做的就是将它们从屏幕的左侧滑动视口宽度。 繁荣，他们被隐藏了。 请勿使用显示：无； 或可见性：隐藏； 为了这！！！ 这样可以防止寻找内容隐瞒滥用行为的搜索引擎看到这些元素的内容！

The transition is some fun magic, as we just delay the left transition when it’s not :target so that our opacity animation can show. We remove that delay:

过渡是一些有趣的魔术，因为我们只是延迟了不是：target时的左过渡，以便可以显示不透明度动画。 我们消除了这一延迟：

.modal:target {
  left:0;
  opacity:1;
  transition:opacity 0.3s, left 0s;
}

When we show it. There’s the big functionality implementation. Left:0 to show it, and an opacity fade-in to make the appearance “pretty”.

当我们展示它时。 有很大的功能实现。 左：0以显示它，不透明度淡入以使外观“漂亮”。

With the inner DIV:

使用内部DIV：

.modal > div {
  display:flex;
  align-items:center;
  justify-content:center;
  min-height:100%;
}

We just apply our flex to center our SECTION or NAV. Which then:

我们只是应用flex来使我们的SECTION或NAV居中。 然后：

.modal > div > section,
.modal > div > nav {
  position:relative;
  overflow:hidden;
  width:100%;
  max-width:24em;
  background:hsl(220, 100%, 95%);
  border:1px solid #0484;
  border-radius:0.5em;
  box-shadow:0 0.25em 1em #0006;
  transform:scale(0);
  transition:transform 0.3s;
}

Get whatever styling we want them to have. I use transform:scale animated so that when the modal is targeted, they “zoom” into focus.

获得我们希望他们拥有的所有样式。 我使用transform：scale动画，以便当以模态为目标时，它们“放大”成为焦点。

.modal:target > div > section,
.modal:target > div > nav {
  transform:scale(1);
}

The inner .modalClose

内部.modalClose

section .modalClose,
nav .modalClose {
  position:absolute;
  top:0;
  right:0.325em;
  font-size:1.75em;
  color:#C00;
  transition:transform 0.3s;
}section .modalClose:after,
nav .modalClose:after {
  content:"\1F5D9";
}section .modalClose:focus,
section .modalClose:hover,
nav .modalClose:focus,
nav .modalClose:hover {
  transform:scale(1.2);
}

Get generated content of the UTF-8 cancellation X, which we then absolute position into place over our H2.

获取UTF-8取消X的生成内容，然后我们将其绝对定位在H2上。

From there it’s all just normal styling of the components.

从那里开始，所有的只是组件的正常样式。

The main menu has to go inside a media query, and as such we have to copy most of the same code. This sucks since it’s doubling down on the same thing, but there’s no real way around this. (if only CSS3 “empty” and general sibling selector worked on generated content!)

主菜单必须位于媒体查询内部，因此，我们必须复制大多数相同的代码。 这很糟糕，因为它在同一件事上加倍，但是没有真正的解决方法。 (如果只有CSS3“空”和常规的同级选择器可以处理生成的内容！)

First we can make the “hamburger” by simply using generated content and borders.

首先，我们可以通过简单地使用生成的内容和边框来制作“汉堡包”。

  .mainMenuOpen {
    display:block;
    padding:0.25em;
    text-decoration:none;
    border-radius:0.5em;
    transition:transform 0.3s;
  }
  .mainMenuOpen:focus,
  .mainMenuOpen:hover {
    transform:scale(1.2);
  }
  .mainMenuOpen:before,
  .mainMenuOpen:after {
    content:"";
    display:block;
    width:1.75em;
    height:0.325em;
    border:solid #000A;
    border-width:0.325em 0;
  }
  .mainMenuOpen:after {
    border-top:none;
  }

Then we need to target its .modalClose to be visible.

然后，我们需要将其.modalClose定位为可见。

  #mainMenu .modalClose {
    display:inline; /* undo hidden */
    text-decoration:none;
  }

Same positioning as for .modal

与.modal相同的定位

  #mainMenu,
  #mainMenu > .modalClose {
    position:absolute;
    top:0;
    left:0;
    width:100%;
    height:100%;
    overflow:auto;
  }  #mainMenu {
    left:-100vw;
    opacity:0;
    padding:1em;
    transition:opacity 0.3s, left 0s 0.3s;
    background:radial-gradient(
      hsla(220, 100%, 100%, 0.8) 20%,
      hsla(220, 100%, 85%, 0.95) 100%
    );
  }  #mainMenu:target {
    left:0;
    opacity:1;
    transition:opacity 0.3s, left 0s;
  }

etc, etc, etc…. you should get the idea by now. One fun thing we can do to the menu is that instead of our H2 heading, we can use generated content to add a faux-heading.

等，等等，等等。 您应该现在就知道。 我们可以对菜单做的一件有趣的事情是，我们可以使用生成的内容来添加伪标题，而不是H2标题。

#mainMenu nav:before {
    content:"Main Menu";
    display:block;
    padding:0.4em 2.8em 0.4em 0.8em;
    font-size:1.25em;
    background:#0482;
    border-bottom:1px solid #0484;
  }

Providing visual consistency.

提供视觉一致性。

现场演示 (Live Demo)

You can view it live here:

您可以在此处实时查看：

As with all my examples the directory:https://cutcodedown.com/for_others/medium_articles/modalSite/

与我所有的示例一样，目录为： https : //cutcodedown.com/for_others/medium_articles/modalSite/

Is wide open for easy access to the gooey bits and pieces. I have placed a .txt of the markup in there for those gun-shy of “view source”, and a .rar of the entire shebang.

敞开式设计，方便拿取粘糊糊的碎屑。 我在其中放置了标记的.txt文件，以备不时之需“查看源代码”，并在其中放置了整个shebang的.rar文件。

It’s all slapped into one of my standard stock templates to show off what it can do.

所有这些都放入我的标准库存模板之一中，以展示其功能。

利弊 (Pros and Cons)

As always, I’ll start with the problems first.

和往常一样，我将从问题开始。

缺点 (Disadvantages)

1. If you open and close them a lot, it will fill up the browser history.
   如果您经常打开和关闭它们，它将填充浏览器的历史记录。
2. For consistency you should follow the markup outside of the innermost DIV exactly. This could be considered “fragile markup”.
   为了保持一致性，您应该完全遵循最里面的DIV之外的标记。 这可以被认为是“脆弱的标记”。

3. The selectors in the CSS can seem complex, especially if you’ve bought into the BALD FACED LIE that selectors slow down the “render”.

   CSS中的选择器可能看起来很复杂，尤其是如果您已经购买了BALD FACED LIE ，选择器会减慢“渲染”速​​度。

4. You end up with extra markup around the content. Mind you if you’re doing a min-height layout you likely would already have that anyways!

   最后，您将在内容周围添加额外的标记。 请注意，如果您要进行最小高度的布局，那么您可能已经拥有了！

5. It relies upon browser features that do not exist in certain legacy browsers. IE in particular can be problematic. But with even bootstrap at this point telling all versions of IE to go suck an egg, we’re probably safe on that. If it really matters, don’t send CSS to IE and just let them deal with the vanilla markup appearance!

   它依赖于某些旧版浏览器中不存在的浏览器功能。 IE尤其可能成问题。 但是，即使此时引导程序告诉所有版本的IE都无法胜任，我们对此还是很安全的。 如果真的很重要，请不要将CSS发送到IE，而应让它们处理原始标记外观！

优点 (Advantages)

1. The use of semantics, hidden, and aria-hidden makes the page 100% meet accessibility minimums. In fact conventional page navigation is maintained in such a way that non-screen users won’t even know we have all this fancy stuff for the sighted!
   使用语义，隐藏和aria-hidden可使页面100％满足可访问性最低要求。 实际上，常规页面导航的维护方式使得非屏幕用户甚至都不知道我们拥有这些花哨的东西！

2. No JavaScript needed. In addition to removing the accessibility hassles it also results in the triggered actions feeling smoother and cleaner. Unlike how many JavaScript “frameworks” go about it with their broken timer based “calculations”. Lands sake, let CSS do the heavy lifting!

   无需JavaScript。 除了消除可访问性的麻烦之外，它还导致触发的动作感觉更流畅，更干净。 与有多少个JavaScript“框架”使用基于中断计时器的“计算”不同。 着眼吧，让CSS担当重任！

3. Use of consistent structure makes it easy to just copypasta the existing examples into new designs
   使用一致的结构可以轻松地将现有示例复制到新设计中

4. Excess classes are kept to a minimum resulting in better leveraging of caching models. Remember, saying what things look like has no business in your markup: be it your tags, id’s, or classes! Say what things ARE!!! The more presentation you put in the markup — even as classes — the slower the page will be. That’s why the claims of slopping classes at everything such as via BEM somehow magically making the page “faster” or “better” is 100% grade A farm fresh prairie pies!

   多余的类保持在最低限度，从而更好地利用了缓存模型。 请记住，说的看起来与标记没有关系：是您的标签，ID还是类！ 说什么东西！ 您放入标记中的演示文稿越多(甚至作为类)，页面的速度就越慢。 这就是为什么在所有内容(例如通过BEM)上倾斜课程的说法，以一种神奇的方式使页面“更快”或“更好”是100％的A级农场新鲜大草原馅饼！

5. As it’s all CSS driven, it’s very easy to switch-up your animations however you like. Just play with transform, transition, and positioning.
   由于它是所有CSS驱动的，因此可以根据自己的喜好轻松切换动画。 只需进行变换，过渡和定位即可。

增强功能？ 增强！！！ (Enhancement?Enhancement!!!)

Now, we’ve gone out of our way up to this point to avoid using JavaScript, but that does not mean we can’t or shouldn’t.

现在，我们已经走了我们的方式到这一点，以避免使用JavaScript，但这并不意味着我们不能或不应该。

For example, we might not care for how it fills up the browser history. You could hook all the .modalClose anchors to say that if the previous hash is empty but it’s the same page, do window.history.back() instead of letting the anchor fire.

例如，我们可能不在乎它如何填充浏览器历史记录。 您可以挂钩所有.modalClose锚点，以说如果先前的哈希为空，但它是同一页，请执行window.history.back()而不是让锚点触发。

That’s fine, then you dive for the JavaScript. But only then. Make it work as much as you can without JavaScript first. Focus on normal pageloads and normal navigation of your content FIRST!

很好， 然后您开始学习JavaScript。 但是只有这样。 首先使它在没有JavaScript的情况下也可以工作。 首先关注正常的页面加载和内容的正常导航！

When it comes to JavaScript, learn to keep it in your pants!

当涉及到JavaScript时，请学习将其保留在裤子里！

As I said in another article, quality JavaScript should enhance an already working page, NOT be your only means of providing said functionality! At least if you care in the slightest about usability, accessibility, and just plain sane and rational front-end development. This is why frameworks like React and Angular empty their bladder on accessibility from so on-high you’d think it was Tom Hanks in that scene from “A League of Their Own”. People using such scripting take zero time to think what happens when scripting is blocked, unavailable, or even irrelevant in the user agent. When you do that, that’s when you get in trouble.

就像我在另一篇文章中所说的那样，高质量JavaScript应该增强一个已经在工作的页面，而不是您提供所述功能的唯一方法！ 至少，如果您丝毫不关心可用性，可访问性，而只是简单而理性的前端开发。 这就是为什么像React和Angular这样的框架从如此高的空缺中抽空他们的可访问性的原因，您会以为是《自己的联盟​​》中汤姆·汉克斯的作品。 使用这种脚本的人花了零时间思考当脚本在用户代理中被阻止，不可用甚至不相关时会发生什么。 当您这样做时，便会遇到麻烦。

麻烦？ 来自JavaScript？ 说不！ (Trouble? From JavaScript? Say Not So!)

Yes trouble! LEGAL trouble in some industries… and basically all businesses at this point are under the gun; since Beyonce and Domino’s got dragged through the courts. If high-profile big budget big names with the best lawyers can be roasted in the depths of a sloar, what chance do common shubs and zuul’s like us have when some snot-nosed assistant DA or ambulance chaser comes a knocking?

是的，麻烦！ 某些行业的法律麻烦 ……基本上所有企业在此刻都处于破产状态； 自从碧昂丝(Beyonce)和多米诺(Domino)被拖入法庭以来。 如果可以在一个臭名昭著的大人物中烤出高调，预算高昂，有最好律师的大牌人物，那么当一些鼻涕的助手DA或救护车追赶者来敲门时，像我们这样的普通小家伙和zuul会有什么机会呢？

We can’t keep slopping out presentational markup with presentational classes like the worst of the 1990’s browser wars. You HAVE to use proper semantics and logical document structure. You HAVE to keep in mind what happens images off, scripting off, even CSS off. You HAVE to remember that CSS has media targets (screen, print, speech, etc) that if you fail to use when you use <link> or <style> or send to “all” may be creating accessibility issues — or even just wasting bandwidth.

我们不能不像1990年代最糟糕的浏览器之战那样，通过展示性类不断扩展展示性标记。 你必须使用正确的语义和逻辑文档结构。 你必须记住发生了什么图像关闭，关闭脚本，CSS甚至关闭。 你要记住，CSS有媒体目标(屏幕，打印，言语等)，如果你失败了，当你使用的<link>或<STYLE>或发送到“所有”可以创建可访问性问题使用-甚至只是浪费带宽。

Likewise it’s a speed race, and if you’re using some giant JS framework with a half dozen k of custom scripting to do what four to six k of CSS can do all on its own, well… /FAIL/ at web development. Even some clients are starting to focus on things like “meaningful paint” times in tools like lighthouse, and bloated slow scripting and massive “frameworks” can really put the kabosh on that.

同样，这是一场速度竞赛，如果您使用带有六个k自定义脚本的巨型JS框架来完成4至6 kCSS可以自己全部完成的工作，那么…/ FAIL /在Web开发中。 甚至有些客户也开始在诸如灯塔之类的工具中关注“有意义的绘画”时间，而肿的缓慢脚本编写和庞大的“框架”确实可以使之陷入困境。

As Web Professionals we NEED start thinking along these lines. Using techniques like this to not just improve the user experience, but to avoid being raked over the coals for failing to meet accessibility minimums.

作为Web专业人员，我们需要按照这些思路进行思考。 使用这样的技术不仅可以改善用户体验，而且还可以避免由于无法满足可访问性的最低要求而陷入困境。

结论 (Conclusion)

By avoiding JavaScript and leveraging CSS3 features, we can make pages that beautifully gracefully degrade for non screen users, whilst still providing all that fancy screen candy. Thanks to modern browser features it’s far simpler and more useful to just write semantics first, add a few div, target your stylesheet for screen media, and then use selectors and pseudo-states to trigger behaviors than it is to waste time on writing scripts to handle this.

通过避免使用JavaScript和利用CSS3功能，我们可以使非屏幕用户可以优雅地降级页面，同时仍然提供所有精美的屏幕提示。 得益于现代的浏览器功能，先浪费时间编写脚本，然后添加一些div，将样式表定位到屏幕媒体，然后使用选择器和伪状态来触发行为，比浪费时间编写脚本要简单得多，也更有用。处理这个(事情。

Again, separation of concerns. Strange as it might sound if you look at the semantic navigation when screen CSS isn’t applied modals — at least implemented this way — aren’t behavior. This is presentation… and presentation is CSS’ job!

同样，关注点分离。 如果您没有在屏幕CSS上应用模态(至少是通过这种方式实现)时的语义导航就不是行为，这听起来可能很奇怪。 这是演示文稿…，演示文稿是CSS的工作！

翻译自: https://levelup.gitconnected.com/modal-dialog-driven-websites-without-javascript-16e858615780

模态对话框弹出模态对话框