最稳妥方式是用+写静态推荐信卡片,语义清晰、兼容性强;需配alt具体描述、署名、role/aria-labelledby增强可访问性;邮件中须用表格布局降级,动态加载需设fallback。

HTML 本身不生成推荐信内容,只负责结构化展示已有评价;直接写死 + 最稳妥,动态加载需额外处理跨域和 fallback。
用 + 写静态推荐信卡片
这是最可控、兼容性最好的方式,所有主流浏览器和邮件客户端(如 Outlook)都能正确解析。关键不是“多炫”,而是语义清晰、可访问性强。
-
包裹整张卡片, 专用于引述内容,别用 替代——屏幕阅读器会据此识别为引用而非普通段落
- 每张卡片的
![]()
必须带 alt,且内容要具体,比如 alt="本·哈德利,AI饮食服务用户,2025年注册",不是 alt="头像"
-
或独立 放署名,别塞进 里——语义错乱会导致 SEO 和语音朗读出问题
- 如果推荐信来自不同客户,建议加
data-customer-id="ben-hadley" 这类属性,方便后续 JS 筛选或 A/B 测试分组
用 CSS Grid/Flex 布局控制卡片排列,但别在邮件里用
网页中推荐用 display: grid 或 display: flex 控制列数和间距,但在 HTML 邮件或老版本 Outlook 中会完全失效,必须降级为表格布局。
HTML Text Extract
从HTML页面(URL、文件或标准输入)中提取主体内容文本,去除导航、页脚、广告和模板文本。可直接传递给readability_check或其他文本工具。
下载
- 网页端可用
grid-template-columns: repeat(auto-fit, minmax(300px, 1fr)) 实现响应式等宽卡片,小屏自动堆叠
- 邮件中必须改用嵌套
:外层 width="600",每张卡片占一个 ,并设 valign="top" 防止高度不一致导致错位
- 避免依赖
gap —— Outlook 不支持,改用 padding 或固定高度 隔开卡片
- 所有字体大小用
px 或 em,别用 vmin —— 邮件客户端不解析视口单位
动态加载推荐信时,fetch 失败必须有降级方案
前端从 API 拉取推荐信看似灵活,但网络波动、CORS、后端宕机都会导致空白卡片。不能让用户看到“加载中…”卡住几秒再失败。
- 先在 HTML 中硬编码 3–4 条高置信度推荐信(比如最早/评分最高/带图的),作为 fallback
- JS 里用
fetch(...).catch(() => {}) 捕获错误,不抛异常,也不清空已有 DOM
- 别在
DOMContentLoaded 后立刻 fetch —— 可能抢在 DOM 渲染前执行,导致插入位置错乱;改用 setTimeout(() => fetch(), 100) 微调时机
- 如果推荐信含用户头像,API 返回的图片 URL 必须是 HTTPS 绝对路径,否则在微信内嵌浏览器或某些企业防火墙下会被拦截
容易被忽略的可访问性细节
很多团队花时间做动效和排版,却漏掉让残障用户真正“读到”推荐信的关键点。
- 每张卡片外层加
role="region" aria-labelledby="testimonial-label-1",对应内部 客户戴夫的反馈,否则屏幕阅读器无法定位上下文
-
要加 cite 属性,比如 cite="https://example.com/testimonials/dave",指向原始评价页,增强可信度
- 别用颜色单独表达信息,比如“绿色文字 = 好评”——色弱用户无法分辨,得搭配图标或文字标签(如 ✅ + “强烈推荐”)
- 移动端点击区域至少 44×44px,
包围整个卡片时,确保 padding 足够,否则手指点不准
真正难的不是把四条评价排成三列,而是让每条评价在无 JS、无 CSS、无图片、甚至只有语音输出时,依然能被准确理解并信任。结构先行,样式后置,容错兜底——这三点卡住了绝大多数翻车现场。
|
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!