• 关于

    html a标签内联

    的搜索结果

回答

LZ混淆了Doctype定义下分类各个标签的块级、内联概念和CSS的块级、内联概念。Doctype定义中的inline/block第一个跟Doctype定义有关,你看到的这个规则,是XHTML Strict中定义的。那么这个语境下的inline和block是什么意思呢,它们是对html标签进行的分类(比如p、div、form都属于block,而span、a则属于inline),而和它们最终的CSS属性一点关系都没有(你可以把p的display改为inline,浏览器不会打死你,但是接替你的页面重构可能会)。这个在Doctype里定义的规则直接导致了浏览器parse整个文档的时候构建成的树是什么样子的。这里有一篇非常棒的关于元素嵌套规则及其对文档结构影响的说明,你可以读一下。总结:Doctype这个语境下面,inline和block指的是一种分类各个标签的方法,这个方法由各个标签的语义和默认的展现形式得来,区分它们主要是因为它们在不同的doctype里面会有不一样的嵌套约束,会影响到浏览器生成的文档结构。CSS的block和inlineLZ第二个代码规范的建议和CSS中高宽计算模式有关系:1.块级只包含块级的时候,进入的模式是块级∈块级模式,相关计算规则大致是 内层宽自适应于外层的content-box的宽; 外层的content-box自适应于内部所有块级容器的高; 等等等等。2.块级只包含内联元素的时候,进入的模式是内联∈块级模式,相关的规则大致是: 内联构成line-box,line-box的高由内联元素的高、line-height和vertical-align决定; 通过断行算法,内联元素组成N个line-box,line-box的宽由块级元素的content-box的宽决定; 各个line-box撑高块级; 等等等等。3.块级元素同时包含块级元素和内联元素的时候,会为每个内联元素创建匿名块,从而拆解问题为块级/匿名块∈块级模式和内联∈块级/匿名块模式,回到规则1,2去计算各个元素的最终宽、高。LZ第二个代码规范可以这样解释:由于第三个规则的存在,所以为了能够在所有时候都能完美的控制块级元素的高和宽,内联元素和块级元素并列时,在内联元素外包裹一层块级元素。总结:在CSS属性这个语境下面,inline和block指的是元素最终的display属性,区分它们主要是因为它们会导致不一样的高宽计算模式。
杨冬芳 2019-12-02 02:47:45 0 浏览量 回答数 0

问题

这样写css符合w3c标准吗:报错

即关于html标签嵌套的问题。感觉网上很多介绍说的很模糊,或者说不严谨! 有一个常识性的东西可能大家都知道,即内联元素不能嵌套块级元素! 但,如一个内联元素转...
kun坤 2020-06-14 08:26:48 0 浏览量 回答数 0

回答

方式一:Coding JavaScript <!--[if lt IE 9]> <script> (function() { if (! /*@cc_on!@*/ 0) return; var e = "abbr, article, aside, audio, canvas, datalist, details, dialog, eventsource, figure, footer, header, hgroup, mark, menu, meter, nav, output, progress, section, time, video".split(', '); var i= e.length; while (i--){ document.createElement(e[i]) } })() </script> <![endif]--> 如果是IE9以下的IE浏览器将创建HTML5标签, 这样非IE浏览器就会忽视这段代码,也就不会有无谓的http请求了。 第二种方法:使用Google的html5shiv包(推荐) <!--[if lt IE 9]> <script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script> <![endif]--> 但是不管使用以上哪种方法,都要初始化新标签的CSS.因为HTML5在默认情况下表现为内联元素,对这些元素进行布局我们需要利用CSS手工把它们转为块状元素方便布局 /*html5*/ article,aside,dialog,footer,header,section,footer,nav,figure,menu{display:block} 但是如果ie6/7/8 禁用脚本的用户,那么就变成了无样式的"白板"网页,我们该怎么解决呢? 我们可以参照facebook的做法,即引导用户进入带有noscript标识的 “/?_fb_noscript=1”页面,用 html4 标签替换 html5 标签,这要比为了保持兼容性而写大量 hack 的做法更轻便一些。 <!--[if lte IE 8]> <noscript> <style>.html5-wrappers{display:none!important;}</style> <div class="ie-noscript-warning">您的浏览器禁用了脚本,请<a href="">查看这里</a>来启用脚本!或者<a href="/?noscript=1">继续访问</a>. </div> </noscript> <![endif]--> 这样可以引导用户开启脚本,或者直接跳转到HTML4标签设计的界面。
a123456678 2019-12-02 02:21:18 0 浏览量 回答数 0

阿里云高校特惠,助力学生创业梦!0元体验,快速入门云计算!

建个炫酷的简历网页,制作一个浪漫的表白网页,打造个人专属网盘,多种动手场景应用免费学!!!

问题

脚本附加到头部并从内联js调用时未定义函数

我创建了这个jsbin并演示了我的问题。 var textFromHTTPRequest = '<html>' + '<head>' + ...
游客ufivfoddcd53c 2020-01-04 14:14:40 0 浏览量 回答数 1

问题

Web开发者不可不知的15条编码原则

HTML已经走过了近20的发展历程。从HTML4到XHTML,再到最近十分火热的HTML5,它几乎见证了整个互联网的发展。但是,即便到现在,有很多基础的概念和原则依然需要开发者高度注意...
技术小菜鸟 2019-12-01 21:19:56 2473 浏览量 回答数 1

问题

【分享】WeX5的正确打开方式(2)

    我的上篇文章介绍了WeX5中基本的页面布局和交互事件写法,有人私信我为什么源码中的js要那样写,HTML源码的结构是怎样的之类。那今天就总结一下Hello World的源码结构,才识有限&#...
小太阳1号 2019-12-01 21:17:14 3935 浏览量 回答数 1

回答

XSS 攻击有两⼤要素: 攻击者提交恶意代码。浏览器执⾏恶意代码。 针对第⼀个要素:我们是否能够在⽤户输⼊的过程,过滤掉⽤户输⼊的恶意代码呢? 输⼊过滤 在⽤户提交时,由前端过滤输⼊,然后提交到后端。这样做是否可⾏呢? 答案是不可⾏。⼀旦攻击者绕过前端过滤,直接构造请求,就可以提交恶意代码了。 那么,换⼀个过滤时机:后端在写⼊数据库前,对输⼊进⾏过滤,然后把“安全的”内容,返回给前端。这样是否可⾏呢? 我们举⼀个例⼦,⼀个正常的⽤户输⼊了 5 < 7 这个内容,在写⼊数据库前,被转义,变成了 5 < 7 。 问题是:在提交阶段,我们并不确定内容要输出到哪⾥。 这⾥的“并不确定内容要输出到哪⾥”有两层含义: ⽤户的输⼊内容可能同时提供给前端和客户端,⽽⼀旦经过了 escapeHTML() ,客户端显示的内容就变成了乱码(5< 7)。 在前端中,不同的位置所需的编码也不同。 当5 < 7 作为 HTML 拼接⻚⾯时,可以正常显示: <div title="comment">5 < 7</div> 当5 < 7 通过 Ajax 返回,然后赋值给 JavaScript 的变量时,前端得到的字符串就是转义后的字符。这个内容不能直接⽤于 Vue 等模板的展示,也不能直接⽤于内容⻓度计算。不能⽤于标题、alert 等 所以,输⼊侧过滤能够在某些情况下解决特定的 XSS 问题,但会引⼊很⼤的不确定性和乱码问题。在防范 XSS 攻击时应避免此类⽅法 当然,对于明确的输⼊类型,例如数字、URL、电话号码、邮件地址等等内容,进⾏输⼊过滤还是必要的 既然输⼊过滤并⾮完全可靠,我们就要通过“防⽌浏览器执⾏恶意代码”来防范 XSS。这部分分为两类: 防⽌ HTML 中出现注⼊防⽌ JavaScript 执⾏时,执⾏恶意代码 预防存储型和反射型 XSS 攻击 存储型和反射型 XSS 都是在服务端取出恶意代码后,插⼊到响应 HTML ⾥的,攻击者刻意编写的“数据”被内到“代码”中,被浏览器所执⾏。 预防这两种漏洞,有两种常⻅做法: 改成纯前端渲染,把代码和数据分隔开。对 HTML 做充分转义。 纯前端渲染 纯前端渲染的过程: 浏览器先加载⼀个静态 HTML,此 HTML 中不包含任何跟业务相关的数据。然后浏览器执⾏ HTML 中的 JavaScript。JavaScript 通过 Ajax 加载业务数据,调⽤ DOM API 更新到⻚⾯上。 在纯前端渲染中,我们会明确的告诉浏览器:下⾯要设置的内容是⽂本( .innerText ),还是属性( .setAttribute ),还是样式( .style )等等。浏览器不会被轻易的被欺骗,执⾏预期外的代码了。 但纯前端渲染还需注意避免 DOM 型 XSS 漏洞(例如 onload 事件和 href 中的 javascript:xxx 等,请参考下⽂”预防 DOM 型 XSS 攻击“部分)。 在很多内部、管理系统中,采⽤纯前端渲染是⾮常合适的。但对于性能要求⾼,或有 SEO 需求的⻚⾯,我们仍然要⾯ 对拼接 HTML 的问题。 转义 HTML 如果拼接 HTML 是必要的,就需要采⽤合适的转义库,对 HTML 模板各处插⼊点进⾏充分的转义。 常⽤的模板引擎,如 doT.js、ejs、FreeMarker 等,对于 HTML 转义通常只有⼀个规则,就是把 & < > " ' / 这⼏个字符转义掉,确实能起到⼀定的 XSS 防护作⽤,但并不完善: 所以要完善 XSS 防护措施,我们要使⽤更完善更细致的转义策略。 例如 Java ⼯程⾥,常⽤的转义库为 org.owasp.encoder 。以下代码引⽤⾃ org.owasp.encoder 的官⽅说明。 <!-- HTML 标签内⽂字内容 --> <div><%= Encode.forHtml(UNTRUSTED) %></div> <!-- HTML 标签属性值 --> <input value="<%= Encode.forHtml(UNTRUSTED) %>" /> <!-- CSS 属性值 --> <div style="width:<= Encode.forCssString(UNTRUSTED) %>"> <!-- CSS URL --> <div style="background:<= Encode.forCssUrl(UNTRUSTED) %>"> <!-- JavaScript 内联代码块 --> <script> var msg = "<%= Encode.forJavaScript(UNTRUSTED) %>"; alert(msg); </script> <!-- JavaScript 内联代码块内嵌 JSON --> <script> var __INITIAL_STATE__ = JSON.parse('<%= Encoder.forJavaScript(data.to_json) %>'); </script> <!-- HTML 标签内联监听器 --> <button onclick="alert('<%= Encode.forJavaScript(UNTRUSTED) %>');"> click me </button> <!-- URL 参数 --> <a href="/search?value=<%= Encode.forUriComponent(UNTRUSTED) %>&order=1#top"> <!-- URL 路径 --> <a href="/page/<%= Encode.forUriComponent(UNTRUSTED) %>"> <!-- URL. 注意:要根据项⽬情况进⾏过滤,禁⽌掉 "javascript:" 链接、⾮法 scheme 等 --> <a href='<%= urlValidator.isValid(UNTRUSTED) ? Encode.forHtml(UNTRUSTED) : "/404" %>'> link </a> 可⻅,HTML 的编码是⼗分复杂的,在不同的上下⽂⾥要使⽤相应的转义规则。 预防 DOM 型 XSS 攻击 DOM 型 XSS 攻击,实际上就是⽹站前端 JavaScript 代码本身不够严谨,把不可信的数据当作代码执⾏了。 在使⽤ .innerHTML 、 .outerHTML 、 document.write() 时要特别⼩⼼,不要把不可信的数据作为 HTML 插到⻚⾯上,⽽应尽量使⽤ .textContent 、 .setAttribute() 等。 如果⽤ Vue/React 技术栈,并且不使⽤ v-html / dangerouslySetInnerHTML 功能,就在前端 render 阶段避免innerHTML 、 outerHTML 的 XSS 隐患。 DOM 中的内联事件监听器,如 location 、 onclick 、 onerror 、 onload 、 onmouseover 等, 标签的 href 属性,JavaScript 的 eval() 、 setTimeout() 、 setInterval() 等,都能把字符串作为代码运⾏。如果不可信的数据拼接到字符串中传递给这些 API,很容易产⽣安全隐患,请务必避免。 <!-- 内联事件监听器中包含恶意代码 --> ![](https://awps-assets.meituan.net/mit-x/blog-images-bundle-2018b/3e724ce0.data:image/png,) <!-- 链接内包含恶意代码 --> <a href="UNTRUSTED">1</a> <script> // setTimeout()/setInterval() 中调⽤恶意代码 setTimeout("UNTRUSTED") setInterval("UNTRUSTED") // location 调⽤恶意代码 location.href = 'UNTRUSTED' // eval() 中调⽤恶意代码 eval("UNTRUSTED") </script> 如果项⽬中有⽤到这些的话,⼀定要避免在字符串中拼接不可信数据。 其他 XSS 防范措施 虽然在渲染⻚⾯和执⾏ JavaScript 时,通过谨慎的转义可以防⽌ XSS 的发⽣,但完全依靠开发的谨慎仍然是不够的。 以下介绍⼀些通⽤的⽅案,可以降低 XSS 带来的⻛险和后果。 Content Security Policy 严格的 CSP 在 XSS 的防范中可以起到以下的作⽤: 禁⽌加载外域代码,防⽌复杂的攻击逻辑禁⽌外域提交,⽹站被攻击后,⽤户的数据不会泄露到外域禁⽌内联脚本执⾏(规则较严格,⽬前发现 GitHub 使⽤)禁⽌未授权的脚本执⾏(新特性,Google Map 移动版在使⽤)合理使⽤上报可以及时发现 XSS,利于尽快修复问题 输⼊内容⻓度控制 对于不受信任的输⼊,都应该限定⼀个合理的⻓度。虽然⽆法完全防⽌ XSS 发⽣,但可以增加 XSS 攻击的难度。 其他安全措施 HTTP-only Cookie: 禁⽌ JavaScript 读取某些敏感 Cookie,攻击者完成 XSS 注⼊后也⽆法窃取此 Cookie。验证码:防⽌脚本冒充⽤户提交危险操作。 过滤 Html 标签能否防⽌ XSS? 请列举不能的情况? ⽤户除了上传 <script>alert('xss');</script> 还可以使⽤图⽚ url 等⽅式来上传脚本进⾏攻击 <table background="javascript:alert(/xss/)"></table> <img src="javascript:alert('xss')"> 还可以使⽤各种⽅式来回避检查, 例如空格, 回⻋, Tab <img src="javas cript: alert('xss')"> 还可以通过各种编码转换 (URL 编码, Unicode 编码, HTML 编码, ESCAPE 等) 来绕过检查 <img%20src=%22javascript:alert('xss');%22> <img src="javascript&#58alert(/xss/)">
前端问答 2019-12-23 12:43:05 0 浏览量 回答数 0

回答

白屏时间=页面开始展示的时间点-开始请求时间点。 开始请求时间点可以通过Performance Timing.navigation Start 。那么页面开始展示的时间点怎么获取呢。已经知道渲染过程是逐步完成的,而且页面解析是按照文档流从上至下解析的,因此一般认为开始解析body的时间点就是页面开始展示的时间。所以可以通过在head标签的末尾插入script来统计时间节点作为页面开始展示时间节点。但是这种方式需要打点,因此也有很多项目为了简化白屏时间的获取会选择忽略head解析时间直接用Performance Timing.dom Loading 来表示页面开始展示的时间,即使用domloading-navigation Start来表示白屏时间。 首屏时间=首屏内容渲染结束时间点-开始请求时间点。 同样开始请求时间点可以通过Performance Timing.navigation Start获取。首屏内容渲染结束的时间点通常有以下几种方法获取: (1)首屏模块标签标记法 适用于于首屏内容不需要通过拉取数据才能生存以及页面不考虑图片等资源加载的情况。通过在 HTML 文档中对应首屏内容的标签结束位置,使用内联的 JavaScript 代码记录当前时间戳作为首屏内容渲染结束的时间点。 (2)统计首屏内加载最慢的图片的时间 通常首屏内容加载最慢的就是图片资源,因此可以把首屏内加载最慢的图片加载完成的时间作为首屏时间。由于浏览器对每个页面的 TCP 连接数有限制,使得并不是所有图片都能立刻开始下载和显示。因此在 DOM树 构建完成后会通过遍历首屏内的所有图片标签,并且监听所有图片标签 onload 事件,最终遍历图片标签的加载时间获取最大值,将这个最大值作为首屏时间。 (3)自定义首屏内容计算法 由于统计首屏内图片完成加载的时间比较复杂。所以在项目中通常会通过自定义模块内容,来简化计算首屏时间。例如忽略图片等资源加载情况,只考虑页面主要 DOM;只考虑首屏的主要模块,而不是严格意义首屏线以上的所有内容。 可交互时间=用户可以正常进行事件输入时间点-开始请求时间点。 PerformanceTiming有一个domInteractive属性,代表了DOM结构结束解析的时间点,就是Document.ready State属性变为“interactive”
游客p7wlo4q4jr4va 2020-05-23 12:54:57 0 浏览量 回答数 0

回答

浏览器渲染机制 浏览器采用流式布局模型(Flow Based Layout)浏览器会把HTML解析成DOM,把CSS解析成CSSOM,DOM和CSSOM合并就产生了渲染树(Render Tree)。有了RenderTree,我们就知道了所有节点的样式,然后计算他们在页面上的大小和位置,最后把节点绘制到页面上。由于浏览器使用流式布局,对Render Tree的计算通常只需要遍历一次就可以完成,但table及其内部元素除外,他们可能需要多次计算,通常要花3倍于同等元素的时间,这也是为什么要避免使用table布局的原因之一。 重绘 由于节点的几何属性发生改变或者由于样式发生改变而不会影响布局的,称为重绘,例如outline, visibility, color、background-color等,重绘的代价是高昂的,因为浏览器必须验证DOM树上其他节点元素的可见性。 回流 回流是布局或者几何属性需要改变就称为回流。回流是影响浏览器性能的关键因素,因为其变化涉及到部分页面(或是整个页面)的布局更新。一个元素的回流可能会导致了其所有子元素以及DOM中紧随其后的节点、祖先节点元素的随后的回流。 <body> <div class="error"> <h4>我的组件</h4> <p><strong>错误:</strong>错误的描述…</p> <h5>错误纠正</h5> <ol> <li>第一步</li> <li>第二步</li> </ol> </div> </body> 在上面的HTML片段中,对该段落(p标签)回流将会引发强烈的回流,因为它是一个子节点。这也导致了祖先的回流(div.error和body – 视浏览器而定)。此外,h5和ol也会有简单的回流,因为其在DOM中在回流元素之后。大部分的回流将导致页面的重新渲染。 回流必定会发生重绘,重绘不一定会引发回流。 浏览器优化 现代浏览器大多都是通过队列机制来批量更新布局,浏览器会把修改操作放在队列中,至少一个浏览器刷新(即16.6ms)才会清空队列,但当你获取布局信息的时候,队列中可能有会影响这些属性或方法返回值的操作,即使没有,浏览器也会强制清空队列,触发回流与重绘来确保返回正确的值。 主要包括以下属性或方法: - offsetTop、offsetLeft、offsetWidth、offsetHeight - scrollTop、scrollLeft、scrollWidth、scrollHeight - clientTop、clientLeft、clientWidth、clientHeight - width、height - getComputedStyle() - getBoundingClientRect() 所以,我们应该避免频繁的使用上述的属性,他们都会强制渲染刷新队列。 减少重绘与回流 CSS 使用 transform 替代 top使用 visibility 替换 display: none ,因为前者只会引起重绘,后者会引发回流(改变了布局)避免使用table布局,可能很小的一个小改动会造成整个 table 的重新布局。尽可能在DOM树的最末端改变class,回流是不可避免的,但可以减少其影响。尽可能在DOM树的最末端改变class,可以限制了回流的范围,使其影响尽可能少的节点。 避免设置多层内联样式,CSS 选择符从右往左匹配查找,避免节点层级过多。 <div> <a> <span></span> </a> 对于第一种设置样式的方式来说,浏览器只需要找到页面中所有的 span 标签然后设置颜色,但是对于第二种设置样式的方式来说,浏览器首先需要找到所有的 span 标签,然后找到 span 标签上的 a 标签,最后再去找到 div 标签,然后给符合这种条件的 span 标签设置颜色,这样的递归过程就很复杂。所以我们应该尽可能的避免写过于具体的 CSS 选择器,然后对于 HTML 来说也尽量少的添加无意义标签,保证层级扁平。 - 将动画效果应用到position属性为absolute或fixed的元素上,避免影响其他元素的布局,这样只是一个重绘,而不是回流,同时,控制动画速度可以选择 requestAnimationFrame,详见探讨 requestAnimationFrame。 - 避免使用CSS表达式,可能会引发回流。 - 将频繁重绘或者回流的节点设置为图层,图层能够阻止该节点的渲染行为影响别的节点,例如will-change、video、iframe等标签,浏览器会自动将该节点变为图层。 - CSS3 硬件加速(GPU加速),使用css3硬件加速,可以让transform、opacity、filters这些动画不会引起回流重绘 。但是对于动画的其它属性,比如background-color这些,还是会引起回流重绘的,不过它还是可以提升这些动画的性能。 2. Javascript - 避免频繁操作样式,最好一次性重写style属性,或者将样式列表定义为class并一次性更改class属性。 - 避免频繁操作DOM,创建一个documentFragment,在它上面应用所有DOM操作,最后再把它添加到文档中。 - 避免频繁读取会引发回流/重绘的属性,如果确实需要多次使用,就用一个变量缓存起来。 - 对具有复杂动画的元素使用绝对定位,使它脱离文档流,否则会引起父元素及后续元素频繁回流。
九旬 2020-05-24 11:22:47 0 浏览量 回答数 0

回答

$ 我们经常使用向 $ 内传入一个字符串的方式来选择或生成 DOM 元素,但如果这个字符串是来自用户输入的话,那么这种方式就是有风险的。 先看一个 DEMO: http://jsbin.com/duwuzonife/1/edit?html,js,output $("<img src='' onerror='alert();'>"); 当用户输入的字符串是像这样的时,虽然这个 <img> 元素不会马上被插入到网页的 DOM 中,但这个 DOM 元素已经被创建了,并且暂存在内存里。而对于 <img> 元素,只要设置了它的 src 属性,浏览器就会马上请求 src 属性所指向的资源。我们也可以利用这个特性做图片的预加载。在上面的示例代码中,创建元素的同时,也设置了它的属性,包括 src 属性和 onerror 事件监听器,所以浏览器会马上请求图片资源,显然请求不到,随机触发 onerror 的回调函数,也就执行了 JavaScript 代码。 推荐阅读 $ 的官方文档: http://api.jquery.com/jQuery/ 类似的其他方法 .after() .append() .appendTo() .before() .html() .insertAfter() .insertBefore() .prepend() .prependTo() .replaceAll() .replaceWith() .unwrap() .wrap() .wrapAll() .wrapInner() .prepend() 以上这些方法不仅创建 DOM 元素,并且会马上插入到页面的 DOM 树中。如果使用 <script> 标签插入了内联 JS 会立即执行。 不安全的输入来源 document.URL * document.location.pathname * document.location.href * document.location.search * document.location.hash document.referrer * window.name document.cookie document 的大多数属性都可以通过全局的 window 对象访问到。加 * 的属性返回的时编码 (urlencode) 后的字符串,需要解码才可能造成威胁。 不安全的操作 把可以被用户编辑的字符串,用在以下场景中,都是有隐患的。总体来说,任何把字符串作为可执行的代码的操作,都是不安全的。 1.通过字符串创建函数 (1)eval (2)new Function (3)setTimeout/setInterval 2.跳转页面 location.replace/location.assign 修改 <script> 标签的 src 属性 修改事件监听器 总结 如果发生在用 jQuery 时被 DOM-XSS 攻击的情况,大多是因为忽视了两个东西: 1. 在给$传参数时,对参数来源的把控。 2. 用户的输入途径不只有表单,还有地址栏,还可以通过开发者工具直接修改 DOM ,或者直接在控制台执行 JS 代码。 答案来源网络,供参考,希望对您有帮助
问问小秘 2019-12-02 03:05:01 0 浏览量 回答数 0

问题

前端开发中的字符编码详解

前端开发过程中会接触各种各样的编码,比较常见的主要是UTF-8和HTML实体编码,但是web前端的世界却不止这两种编码,而且编码的选择也会 造成一定的问题,如前后端开发过...
技术小菜鸟 2019-12-01 21:34:35 5214 浏览量 回答数 1

回答

创建一个包含模板间共享布局的模板,通常这样的模板包含: 页面头部、导航栏、脚部、内容展示区域。 Layout.html <!DOCTYPE html> <html xmlns:layout="http://www.ultraq.net.nz/thymeleaf/layout"> <head> <title>Layout page</title> <script src="common-script.js"></script> </head> <body> <header> <h1>My website</h1> </header> <section layout:fragment="content"> <p>Page content goes here</p> </section> <footer> <p>My footer</p> <p layout:fragment="custom-footer">Custom footer here</p> </footer> </body> </html> 注意事项: 1. html标签上附上命名空间 2. section与脚部p标签上使用layout:fragment属性 这些是布局中的插入候选槽点,通过匹配内容模板中片段进行替换。 创建一些内容模板: Content1.html <!DOCTYPE html> <html xmlns:layout="http://www.ultraq.net.nz/thymeleaf/layout" layout:decorate="~{Layout}"> <head> <title>Content page 1</title> <script src="content-script.js"></script> </head> <body> <section layout:fragment="content"> <p>This is a paragraph from content page 1</p> </section> <footer> <p layout:fragment="custom-footer">This is some footer content from content page 1</p> </footer> </body> </html> html标签中的layout:decorate说明哪一个布局模板使用这个内容模板进行装饰。内容模板定义自身标题与脚本、content与custom-footer片段。custom-footer片段处于footer元素内部,这其实是不必要的,但是可能会是很方便的,如果想要做内容模板的静态模板,这是一开始使用Thymeleaf的原因之一。 在一个模板内片段名称必须唯一,否则可能会出现片段不匹配,各种各样的可笑事情会接踵而至。 不管如何,一旦告知Thymeleaf处理Content1.html,最终的页面会是这样子: <!DOCTYPE html> <html> <head> <title>Content page 1</title> <script src="common-script.js"></script> <script src="content-script.js"></script> </head> <body> <header> <h1>My website</h1> </header> <section> <p>This is a paragraph from content page 1</p> </section> <footer> <p>My footer</p> <p>This is some footer content from content page 1</p> </footer> </body> </html> 内容模板装饰Layout.html,结果是布局的组合,加上内容模板的片段(两个模板的<head>元素,来自内容模板的<title>元素替换布局文件内的,所有的元素来自布局文件,但是由所有指定的内容模板进行替换) 想了解更多可以如何控制<head>元素合并,参看<head>元素合并一小节。 装饰进程重定向处理从内容模板至布局,将layout:fragment部分从内容模板中挑选出来,因为布局需要它们。正因如此,任何在layout:fragment之外的东西实际从未得到执行,这说明在内容模板中不能这样做: <div th:if="${user.admin}"> <div layout:fragment="content"> ... </div> </div> 如果布局模板想要’内容’片段,那么会得到那个片段,不顾任何所在条件,因为那些条件不会执行。 如果说只想用绝对最小HTML代码量替换装饰器脚部: Content2.html <p layout:decorate="~{Layout}" layout:fragment="custom-footer"> This is some footer text from content page 2. </p> 这就是全部所需的东西!<p>标签同时用作根元素与片段定义,生成一个像这样的页面: <!DOCTYPE html> <html> <head> <title>Layout page</title> <script src="common-script.js"></script> </head> <body> <header> <h1>My website</h1> </header> <section> <p>Page content goes here</p> </section> <footer> <p>My footer</p> <p> This is some footer text from content page 2. </p> </footer> </body> </html> 可以把布局看作母版,会得以填充或者被内容(子模板)覆盖,仅当内容会填充/覆盖父类。以这种方式,布局充当某种’默认’,内容充当这种默认之上的实现。 给布局传送数据 子模板向上给母版布局传送数据,在涉及到布局/装饰过程的任意元素上使用th:with/ data-th-with属性处理器,可以在任何地方layout:decorate/ data-layout-decorate 或者可以发现 layout:fragment/data-layout-fragment, 例如: 孩子/内容模板: <html layout:decorate="your-layout.html" th:with="greeting='Hello!'"> 1 父类/布局模板: <html> ... <p th:text="${greeting}"></p> <!-- You'll end up with "Hello!" in here --> 将来,或许会增加支持使用分片局部变量,很像Thymeleaf用于创建片段签名。 配置标题 鉴于布局方言自动用内容模板中所发现的重载布局<title>,可能会发现自己重复布局中发现的标题部分,尤其是想要创建面包屑或者在页面标题中保留页面名称。layout:title-pattern处理器可以免除重复布局标题的问题,通过使用一些特殊标记以想要标题如何出现的模式。 这是一个例子: Layout.html <!DOCTYPE html> <html xmlns:layout="http://www.ultraq.net.nz/thymeleaf/layout"> <head> <title layout:title-pattern="$LAYOUT_TITLE - $CONTENT_TITLE">My website</title> </head> ... </html> layout:title-pattern处理器采取简单字符串,识别两种特殊标记:$LAYOUT_TITLE与$CONTENT_TITLE。每种标记在结果页中会被各自相应的标题替换。所以,如果有下面的内容模板: Content.html <!DOCTYPE html> <html xmlns:layout="http://www.ultraq.net.nz/thymeleaf/layout" layout:decorator="Layout"> <head> <title>My blog</title> </head> ... </html> 结果页会是这样: <!DOCTYPE html> <html> <head> <title>My website - My blog</title> </head> ... </html> 这对<title>元素内的静态/内联文本或者<title>元素上发现使用th:text的动态文本均有效。 上述例子中的模式在布局中指定,所以对所有使用布局的内容模板均适用。如果在内容模板中指定另一种标题模式,那么会覆盖布局中发现的那个,允许细粒度的控制标题的展现形式。 可重用模板 假如发现有一些HTML或者结构经常性地重复,想要做成自己的模板从不同地方插入以便减少代码重复。(模块化Thymeleaf?)这个的例子可能会是一个模态面板,由几个HTML元素与CSS类构成,在网页应用中产生一个新窗口的效果: Modal.html <!DOCTYPE html> <html> <body> <div id="modal-container" class="modal-container" style="display:none;"> <section id="modal" class="modal"> <header> <h1>My Modal</h1> <div id="close-modal" class="modal-close"> <a href="#close">Close</a> </div> </header> <div id="modal-content" class="modal-content"> <p>My modal content</p> </div> </section> </div> </body> </html> 会发现可以将一些东西转换成像头部、ID的变量,以便包含Modal.html的页面可以设定它们自己的名称/ID。继续尽可能泛型化编写模态代码,然而会遇到填充自己的模态框内容的问题,那是开始接触一些限制的地方。 一些页面使用单一消息的模态框,其他想要使用模态框容纳一些更复杂的东西比如接受用户输入的表单。模态框可能性变得无休无止,但是未支持想象,发现自己得不得将这段模态框代码拷贝到每一个模板中,每一次使用场合变化相应内容,重复同样的HTML代码维持同样的外观感受,打破了过程中的DRY原则。 主要妨碍适当重用的事情是无法将HTML元素传递至插入模板中。这正是layout:insert有用的地方。它运作起来完全像th:insert,但是通过指定与实现片段很像内容/布局实例,可以创建一个公共的结构,对插入它的模板使用场合作出响应。 这是一个更新的模态框模板,使用Thymeleaf与layout:fragment属性定义一个可替换的模态框内容部分以变得更加泛型化: Modal2.html Modal2.html <!DOCTYPE html> <html xmlns:th="http://www.thymeleaf.org" xmlns:layout="http://www.ultraq.net.nz/thymeleaf/layout"> <body layout:fragment="modal(modalId, modalHeader)"> <div th:id="${modalId} + '-container'" class="modal-container" style="display:none;"> <section th:id="${modalId}" class="modal"> <header> <h1 th:text="${modalHeader}">My Modal</h1> <div th:id="'close-' + ${modalId}" class="modal-close"> <a href="#close">Close</a> </div> </header> <div th:id="${modalId} + '-content'" class="modal-content"> <div layout:fragment="modal-content"> <p>My modal content</p> </div> </div> </section> </div> </body> </html> 现在可以插入这个模板,使用layout:insert处理器与无论怎样需要实现modal-content片段,通过在调用模板插入元素内创建同样名称的片段: Content.html <!DOCTYPE html> <html xmlns:th="http://www.thymeleaf.org" xmlns:layout="http://www.ultraq.net.nz/thymeleaf/layout"> ... <div layout:insert="Modal2 :: modal(modalId='message', modalHeader='Message')" th:remove="tag"> <p layout:fragment="modal-content">Message goes here!</p> </div> ... </html> 就像内容/布局实例,插入模板layout:fragment会被匹配片段名称的元素替换掉。在这种场合下,Modal2.html的整个modal-content部分会被上述自定义段落替换掉。这是结果: <!DOCTYPE html> <html> ... <div id="message-container" class="modal-container" style="display:none;"> <section id="message" class="modal"> <header> <h1>Message</h1> <div id="close-message" class="modal-close"> <a href="#close">Close</a> </div> </header> <div id="message-content" class="modal-content"> <p>Message goes here!</p> </div> </section> </div> ... </html> 定义在模板内包含Modal2.html的自定义消息作为模态框内容的一部分。在插入模板上下文环境中的片段与用于内容/布局过程中的片段一样工作:如果片段未在模板中定义,那么它不会覆盖插入模板中的内容,使得在可重用版本中创建默认。
景凌凯 2020-04-29 21:11:25 0 浏览量 回答数 0

问题

网站优化之提升访问速度的影响因素

       众所周知,网站速度对于SEO和用户体验来说至关重要。更快的网站访问速度能获得更高的搜索引擎排名,这就意味着更多的用户点击访问,也就代表了更高的用户转化率。简而言之,对于S...
chenchuan 2019-12-01 21:01:05 7177 浏览量 回答数 0

问题

模板,从服务端到客户端

  英文原文 : Client-Side Templating   在浏览器中使用模板是一个日渐热门的趋势。将服务端的逻辑应用到客户端上,还有越来越多的类MVC模式(模型-视图-控制器:...
go696 2019-12-01 21:32:31 3535 浏览量 回答数 0

问题

网站优化之提升访问速度的影响因素

   众所周知, 网站 速度对于SEO和用户体验来说至关重要。更快的网站访问速度能获得更高的搜索引擎排名,这就意味着更多的用户点击访问,也就代表了更高的用户转化率。简而言之,对于SEO...
chenchuan 2019-12-01 21:37:28 3707 浏览量 回答数 0

问题

【CSS学习全家桶】416道CSS热门问题,阿里百位技术专家答疑解惑

阿里极客公益活动:或许你挑灯夜战只为一道难题或许你百思不解只求一个答案或许你绞尽脑汁只因一种未知那么他们来了,阿里系技术专家来云栖问答为你解答技术难题了他们用户自己手中的技术来帮助用户成长本次活动特邀百位阿里技术专家对CSS常见问题进行了集...
管理贝贝 2019-12-01 20:07:24 8458 浏览量 回答数 1

问题

【javascript学习全家桶】934道javascript热门问题,阿里百位技术专家答疑解惑

阿里极客公益活动:或许你挑灯夜战只为一道难题或许你百思不解只求一个答案或许你绞尽脑汁只因一种未知那么他们来了,阿里系技术专家来云栖问答为你解答技术难题了他们用户自己手中的技术来帮助用户成长本次活动特邀百位阿里技术专家对javascript常...
管理贝贝 2019-12-01 20:07:22 6202 浏览量 回答数 1

云产品推荐

上海奇点人才服务相关的云产品 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 阿里云AIoT 阿里云科技驱动中小企业数字化