Update web-platform-tests to revision 58eb04cecbbec2e18531ab440225e38944a9c444

This commit is contained in:
Josh Matthews 2017-04-17 12:06:02 +10:00 committed by Anthony Ramine
parent 25e8bf69e6
commit 665817d2a6
35333 changed files with 1818077 additions and 16036 deletions

View file

@ -0,0 +1,4 @@
<?xml version="1.0" standalone="yes"?>
<svg version="1.1" viewBox="0.0 0.0 400.0 240.0" fill="none" stroke="none" stroke-linecap="square" stroke-miterlimit="10" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><clipPath id="p.0"><path d="m0 0l400.0 0l0 240.0l-400.0 0l0 -240.0z" clip-rule="nonzero"></path></clipPath><g clip-path="url(#p.0)"><path fill="#000000" fill-opacity="0.0" d="m0 0l400.0 0l0 240.0l-400.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m24.0 200.0l192.0 0l0 16.0l-192.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m24.0 24.0l192.0 0l0 16.0l-192.0 0z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m216.0 63.244095l102.39371 0l0 113.51181l-102.39371 0z" fill-rule="nonzero"></path><path fill="#000000" d="m262.19684 107.549995q10.0 7.8125 17.1875 16.5625l-6.5625 6.8749924q-7.8125 -9.687492 -16.874985 -18.124992l6.2499847 -5.3125z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m107.43044 63.244095l102.3937 0l0 113.51181l-102.3937 0z" fill-rule="nonzero"></path><path fill="#000000" d="m153.62729 107.549995q10.0 7.8125 17.1875 16.5625l-6.5625 6.8749924q-7.8125 -9.687492 -16.875 -18.124992l6.25 -5.3125z" fill-rule="nonzero"></path></g></svg>

After

Width:  |  Height:  |  Size: 1.2 KiB

View file

@ -0,0 +1,4 @@
<?xml version="1.0" standalone="yes"?>
<svg version="1.1" viewBox="0.0 0.0 400.0 240.0" fill="none" stroke="none" stroke-linecap="square" stroke-miterlimit="10" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><clipPath id="p.0"><path d="m0 0l400.0 0l0 240.0l-400.0 0l0 -240.0z" clip-rule="nonzero"></path></clipPath><g clip-path="url(#p.0)"><path fill="#000000" fill-opacity="0.0" d="m0 0l400.0 0l0 240.0l-400.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m24.0 200.0l192.0 0l0 16.0l-192.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m24.0 24.0l192.0 0l0 16.0l-192.0 0z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m216.0 63.244095l102.39371 0l0 113.51181l-102.39371 0z" fill-rule="nonzero"></path><path fill="#000000" d="m262.19684 107.549995q10.0 7.8125 17.1875 16.5625l-6.5625 6.8749924q-7.8125 -9.687492 -16.874985 -18.124992l6.2499847 -5.3125z" fill-rule="nonzero"></path></g></svg>

After

Width:  |  Height:  |  Size: 968 B

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 26 KiB

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 16 KiB

View file

@ -0,0 +1,4 @@
<?xml version="1.0" standalone="yes"?>
<svg version="1.1" viewBox="0.0 0.0 1152.0 1152.0" fill="none" stroke="none" stroke-linecap="square" stroke-miterlimit="10" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><clipPath id="p.0"><path d="m0 0l1152.0 0l0 1152.0l-1152.0 0l0 -1152.0z" clip-rule="nonzero"></path></clipPath><g clip-path="url(#p.0)"><path fill="#000000" fill-opacity="0.0" d="m0 0l1152.0 0l0 1152.0l-1152.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m418.51968 418.51968l314.9606 0l0 314.9606l-314.9606 0z" fill-rule="nonzero"></path><path stroke="#09f" stroke-width="24.0" stroke-linejoin="round" stroke-linecap="butt" stroke-dasharray="40.0,30.0" d="m418.51968 418.51968l314.9606 0l0 314.9606l-314.9606 0z" fill-rule="nonzero"></path><path fill="#000000" d="m103.55905 103.55905l314.96063 0l0 944.88184l-314.96063 0z" fill-rule="nonzero"></path><path fill="#000000" d="m733.4803 103.55905l314.96063 0l0 944.88184l-314.96063 0z" fill-rule="nonzero"></path></g></svg>

After

Width:  |  Height:  |  Size: 1 KiB

View file

@ -0,0 +1,4 @@
<?xml version="1.0" standalone="yes"?>
<svg version="1.1" viewBox="0.0 0.0 1152.0 1152.0" fill="none" stroke="none" stroke-linecap="square" stroke-miterlimit="10" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><clipPath id="p.0"><path d="m0 0l1152.0 0l0 1152.0l-1152.0 0l0 -1152.0z" clip-rule="nonzero"></path></clipPath><g clip-path="url(#p.0)"><path fill="#000000" fill-opacity="0.0" d="m0 0l1152.0 0l0 1152.0l-1152.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m733.4803 418.51968l0 314.9606l-314.9606 0l0 -314.9606z" fill-rule="nonzero"></path><path stroke="#09f" stroke-width="24.0" stroke-linejoin="round" stroke-linecap="butt" stroke-dasharray="40.0,30.0" d="m733.4803 418.51968l0 314.9606l-314.9606 0l0 -314.9606z" fill-rule="nonzero"></path><path fill="#000000" d="m1048.4409 103.55905l0 314.96063l-944.88184 0l0 -314.96063z" fill-rule="nonzero"></path><path fill="#000000" d="m1048.4409 733.4803l0 314.96063l-944.88184 0l0 -314.96063z" fill-rule="nonzero"></path></g></svg>

After

Width:  |  Height:  |  Size: 1 KiB

View file

@ -0,0 +1,4 @@
<?xml version="1.0" standalone="yes"?>
<svg version="1.1" viewBox="0.0 0.0 400.0 240.0" fill="none" stroke="none" stroke-linecap="square" stroke-miterlimit="10" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><clipPath id="p.0"><path d="m0 0l400.0 0l0 240.0l-400.0 0l0 -240.0z" clip-rule="nonzero"></path></clipPath><g clip-path="url(#p.0)"><path fill="#000000" fill-opacity="0.0" d="m0 0l400.0 0l0 240.0l-400.0 0z" fill-rule="nonzero"></path><path fill="#ffffff" d="m104.0 24.0l192.0 0l0 192.0l-192.0 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="2.0" stroke-linejoin="round" stroke-linecap="butt" stroke-dasharray="8.0,6.0" d="m104.0 24.0l192.0 0l0 192.0l-192.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m104.0 200.0l192.0 0l0 16.0l-192.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m104.0 24.0l192.0 0l0 16.0l-192.0 0z" fill-rule="nonzero"></path></g></svg>

After

Width:  |  Height:  |  Size: 939 B

View file

@ -0,0 +1,4 @@
<?xml version="1.0" standalone="yes"?>
<svg version="1.1" viewBox="0.0 0.0 400.0 240.0" fill="none" stroke="none" stroke-linecap="square" stroke-miterlimit="10" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><clipPath id="p.0"><path d="m0 0l400.0 0l0 240.0l-400.0 0l0 -240.0z" clip-rule="nonzero"></path></clipPath><g clip-path="url(#p.0)"><path fill="#000000" fill-opacity="0.0" d="m0 0l400.0 0l0 240.0l-400.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m104.0 24.0l192.0 0l0 192.0l-192.0 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="2.0" stroke-linejoin="round" stroke-linecap="butt" stroke-dasharray="8.0,6.0" d="m104.0 24.0l192.0 0l0 192.0l-192.0 0z" fill-rule="nonzero"></path><path fill="#ffffff" d="m153.37007 66.07874l93.25986 53.921257l-93.25986 53.921265z" fill-rule="nonzero"></path></g></svg>

After

Width:  |  Height:  |  Size: 872 B

View file

@ -0,0 +1,4 @@
<?xml version="1.0" standalone="yes"?>
<svg version="1.1" viewBox="0.0 0.0 400.0 240.0" fill="none" stroke="none" stroke-linecap="square" stroke-miterlimit="10" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><clipPath id="p.0"><path d="m0 0l400.0 0l0 240.0l-400.0 0l0 -240.0z" clip-rule="nonzero"></path></clipPath><g clip-path="url(#p.0)"><path fill="#000000" fill-opacity="0.0" d="m0 0l400.0 0l0 240.0l-400.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m104.0 24.0l192.0 0l0 192.0l-192.0 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="2.0" stroke-linejoin="round" stroke-linecap="butt" stroke-dasharray="8.0,6.0" d="m104.0 24.0l192.0 0l0 192.0l-192.0 0z" fill-rule="nonzero"></path><path fill="#ffffff" d="m146.07874 166.62993l53.921265 -93.25985l53.921265 93.25985z" fill-rule="nonzero"></path></g></svg>

After

Width:  |  Height:  |  Size: 873 B

View file

@ -0,0 +1,4 @@
<?xml version="1.0" standalone="yes"?>
<svg version="1.1" viewBox="0.0 0.0 400.0 240.0" fill="none" stroke="none" stroke-linecap="square" stroke-miterlimit="10" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><clipPath id="p.0"><path d="m0 0l400.0 0l0 240.0l-400.0 0l0 -240.0z" clip-rule="nonzero"></path></clipPath><g clip-path="url(#p.0)"><path fill="#000000" fill-opacity="0.0" d="m0 0l400.0 0l0 240.0l-400.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m104.0 24.0l192.0 0l0 192.0l-192.0 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="2.0" stroke-linejoin="round" stroke-linecap="butt" stroke-dasharray="8.0,6.0" d="m104.0 24.0l192.0 0l0 192.0l-192.0 0z" fill-rule="nonzero"></path></g></svg>

After

Width:  |  Height:  |  Size: 760 B

View file

@ -0,0 +1,4 @@
<?xml version="1.0" standalone="yes"?>
<svg version="1.1" viewBox="0.0 0.0 400.0 240.0" fill="none" stroke="none" stroke-linecap="square" stroke-miterlimit="10" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><clipPath id="p.0"><path d="m0 0l400.0 0l0 240.0l-400.0 0l0 -240.0z" clip-rule="nonzero"></path></clipPath><g clip-path="url(#p.0)"><path fill="#000000" fill-opacity="0.0" d="m0 0l400.0 0l0 240.0l-400.0 0z" fill-rule="nonzero"></path><path fill="#ffffff" d="m104.0 24.0l192.0 0l0 192.0l-192.0 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="2.0" stroke-linejoin="round" stroke-linecap="butt" stroke-dasharray="8.0,6.0" d="m104.0 24.0l192.0 0l0 192.0l-192.0 0z" fill-rule="nonzero"></path></g></svg>

After

Width:  |  Height:  |  Size: 760 B

View file

@ -0,0 +1,4 @@
<?xml version="1.0" standalone="yes"?>
<svg version="1.1" viewBox="0.0 0.0 400.0 240.0" fill="none" stroke="none" stroke-linecap="square" stroke-miterlimit="10" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><clipPath id="p.0"><path d="m0 0l400.0 0l0 240.0l-400.0 0l0 -240.0z" clip-rule="nonzero"></path></clipPath><g clip-path="url(#p.0)"><path fill="#000000" fill-opacity="0.0" d="m0 0l400.0 0l0 240.0l-400.0 0z" fill-rule="nonzero"></path><path fill="#ffffff" d="m44.0 24.0l192.0 0l0 192.0l-192.0 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="2.0" stroke-linejoin="round" stroke-linecap="butt" stroke-dasharray="8.0,6.0" d="m44.0 24.0l192.0 0l0 192.0l-192.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m44.0 200.0l192.0 0l0 16.0l-192.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m44.0 168.0l192.0 0l0 16.0l-192.0 0z" fill-rule="nonzero"></path><path fill="#ffffff" d="m260.0 24.0l96.0 0l0 192.0l-96.0 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="2.0" stroke-linejoin="round" stroke-linecap="butt" stroke-dasharray="8.0,6.0" d="m260.0 24.0l96.0 0l0 192.0l-96.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m260.0 200.0l96.0 0l0 16.0l-96.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m260.0 168.0l96.0 0l0 16.0l-96.0 0z" fill-rule="nonzero"></path></g></svg>

After

Width:  |  Height:  |  Size: 1.3 KiB

View file

@ -0,0 +1,4 @@
<?xml version="1.0" standalone="yes"?>
<svg version="1.1" viewBox="0.0 0.0 400.0 240.0" fill="none" stroke="none" stroke-linecap="square" stroke-miterlimit="10" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><clipPath id="p.0"><path d="m0 0l400.0 0l0 240.0l-400.0 0l0 -240.0z" clip-rule="nonzero"></path></clipPath><g clip-path="url(#p.0)"><path fill="#000000" fill-opacity="0.0" d="m0 0l400.0 0l0 240.0l-400.0 0z" fill-rule="nonzero"></path><path fill="#ffffff" d="m68.0 24.0l192.0 0l0 192.0l-192.0 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="2.0" stroke-linejoin="round" stroke-linecap="butt" stroke-dasharray="8.0,6.0" d="m68.0 24.0l192.0 0l0 192.0l-192.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m68.0 200.0l192.0 0l0 16.0l-192.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m68.0 168.0l192.0 0l0 16.0l-192.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m68.0 136.0l192.0 0l0 16.0l-192.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m68.0 104.0l192.0 0l0 16.0l-192.0 0z" fill-rule="nonzero"></path><path fill="#ffffff" d="m284.0 24.0l48.0 0l0 192.0l-48.0 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="2.0" stroke-linejoin="round" stroke-linecap="butt" stroke-dasharray="8.0,6.0" d="m284.0 24.0l48.0 0l0 192.0l-48.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m284.0 200.0l48.0 0l0 16.0l-48.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m284.0 168.0l48.0 0l0 16.0l-48.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m284.0 136.0l48.0 0l0 16.0l-48.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m284.0 104.0l48.0 0l0 16.0l-48.0 0z" fill-rule="nonzero"></path></g></svg>

After

Width:  |  Height:  |  Size: 1.7 KiB

View file

@ -0,0 +1,4 @@
<?xml version="1.0" standalone="yes"?>
<svg version="1.1" viewBox="0.0 0.0 400.0 240.0" fill="none" stroke="none" stroke-linecap="square" stroke-miterlimit="10" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><clipPath id="p.0"><path d="m0 0l400.0 0l0 240.0l-400.0 0l0 -240.0z" clip-rule="nonzero"></path></clipPath><g clip-path="url(#p.0)"><path fill="#000000" fill-opacity="0.0" d="m0 0l400.0 0l0 240.0l-400.0 0z" fill-rule="nonzero"></path><path fill="#ffffff" d="m60.0036 24.0l192.0 0l0 192.0l-192.0 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="2.0" stroke-linejoin="round" stroke-linecap="butt" stroke-dasharray="8.0,6.0" d="m60.0036 24.0l192.0 0l0 192.0l-192.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m60.0036 200.0l192.0 0l0 16.0l-192.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m60.0036 168.0l192.0 0l0 16.0l-192.0 0z" fill-rule="nonzero"></path><path fill="#000000" d="m60.0036 136.0l192.0 0l0 16.0l-192.0 0z" fill-rule="nonzero"></path><path fill="#ffffff" d="m276.0028 24.0l63.99359 0l0 192.0l-63.99359 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="2.0" stroke-linejoin="round" stroke-linecap="butt" stroke-dasharray="8.0,6.0" d="m276.0028 24.0l63.99359 0l0 192.0l-63.99359 0z" fill-rule="nonzero"></path><path fill="#000000" d="m276.0028 200.0l63.99359 0l0 16.0l-63.99359 0z" fill-rule="nonzero"></path><path fill="#000000" d="m276.0028 168.0l63.99359 0l0 16.0l-63.99359 0z" fill-rule="nonzero"></path><path fill="#000000" d="m276.0028 136.0l63.99359 0l0 16.0l-63.99359 0z" fill-rule="nonzero"></path></g></svg>

After

Width:  |  Height:  |  Size: 1.6 KiB

View file

@ -0,0 +1,503 @@
<!DOCTYPE html>
<html>
<head>
<title>CSS Writing Modes testing strategy</title>
<meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
<!--
=== NOTA BENE ===
For the three scripts below, if your spec resides on dev.w3 you can check them
out in the same tree and use relative links so that they'll work offline,
-->
<script src='http://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async></script>
<script class='remove'>
var respecConfig = {
specStatus: "unofficial",
shortName: "css3-writingmodes-test-strategy",
editors: [
{
name: "Shinsuke Matsuki", mailto: "shinsuke.matsuki@access-company.com",
company: "ACCESS", companyURL: ""
},
{
name: "Masataka Yakura", mailto: "masataka.yakura@gmail.com",
company: "", companyURL: ""
},
],
testSuiteURI: "http://test.csswg.org/suites/css3-writing-modes/nightly-unstable/",
};
</script>
<style>
a.bibref,
#references dt {
text-transform: uppercase;
}
</style>
<style>
table
{
border-collapse:collapse;
}
table, td, th
{
border:1px solid black;
padding: 13px;
}
table
{
width: 100%;
}
img
{
width: 400px;
}
</style>
<style>/*****************************************************************
* ReSpec 3 CSS
* Robin Berjon - http://berjon.com/
*****************************************************************/
/* --- INLINES --- */
em.rfc2119 {
text-transform: lowercase;
font-variant: small-caps;
font-style: normal;
color: #900;
}
h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
border: none;
}
dfn {
font-weight: bold;
}
a.internalDFN {
color: inherit;
border-bottom: 1px solid #99c;
text-decoration: none;
}
a.externalDFN {
color: inherit;
border-bottom: 1px dotted #ccc;
text-decoration: none;
}
a.bibref {
text-decoration: none;
}
cite .bibref {
font-style: normal;
}
code {
color: #ff4500;
}
/* --- TOC --- */
.toc a, .tof a {
text-decoration: none;
}
a .secno, a .figno {
color: #000;
}
ul.tof, ol.tof {
list-style: none outside none;
}
.caption {
margin-top: 0.5em;
font-style: italic;
}
/* --- TABLE --- */
table.simple {
border-spacing: 0;
border-collapse: collapse;
border-bottom: 3px solid #005a9c;
}
.simple th {
background: #005a9c;
color: #fff;
padding: 3px 5px;
text-align: left;
}
.simple th[scope="row"] {
background: inherit;
color: inherit;
border-top: 1px solid #ddd;
}
.simple td {
padding: 3px 10px;
border-top: 1px solid #ddd;
}
.simple tr:nth-child(even) {
background: #f0f6ff;
}
/* --- DL --- */
.section dd > p:first-child {
margin-top: 0;
}
.section dd > p:last-child {
margin-bottom: 0;
}
.section dd {
margin-bottom: 1em;
}
.section dl.attrs dd, .section dl.eldef dd {
margin-bottom: 0;
}
</style><link rel="stylesheet" href="https://www.w3.org/StyleSheets/TR/w3c-unofficial"><!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]-->
</head>
<body>
<section id='abstract'>
<p>
This document is intended to be used as a guideline for the testing
activities related to the CSS Writing Modes spec [[!css3-writing-modes]]. Its main
goal is to provide an overview of the general testing areas, possible
caveats and testing aspects not immediately apparent from the spec.
Also, it provides a means of tracking the progress of the CSS Writing Modes
spec testing.
</p>
<p>
This document is not meant to replace the spec in determining the
normative and non-normative assertions to be tested, but rather
complement it.
</p>
</section>
<section>
<h2>Introduction</h2>
<p>
As CSS moved away from the monolithic development of CSS 2.1 to the
modular development of CSS 3, the number of proposed new features and
the complexity of the layout landscape have increased dramatically.
While this directly translates to increased flexibility and agility in
adopting and implementing new CSS features, it also increases the
complexity of testing CSS features and the need for coordinating the
testing efforts. Also, the need for testing coordination increases as
crowd-sourcing efforts like
<a href="http://testthewebforward.org/" target="_blank">Test the Web
Forward</a> present people less familiar with the processes and policies
of the W3C with the opportunity to contribute new tests.
</p>
<p>
Except when defining new behaviors or redefining old behaviors, the
implicit assumption for new CSS modules is that they play nicely with
other modules or properties defined in CSS&nbsp;2.1 [[CSS21]]. As CSS
Writing Modes is a spec that touches many aspects of layout, styling and CSSOM,
it's not unreasonable to want to test the spec against these implicit
assumptions, too.
</p>
<p>
This testing strategy document is meant to complement the CSS Writing Modes
spec and the existing test suite by providing an overview of the testing
areas (especially the less apparent ones) and tracking the progress of
the testing activities against these test areas.
</p>
</section>
<section>
<h2>Goals</h2>
<p>
To ensure a comprehensive test suite with useful, high quality tests, a
number of goals are proposed. They range from process goals (how to
conduct testing) to implementation goals (how to write good tests).
</p>
<section>
<h3>Enabling easy test contribution</h3>
<p>
An important vector in successfully testing CSS Writing Modes is to
enable easy test contributions, both from W3C partners and from
non-W3C members that wish to contribute. This is achieved by clearly
marking and explaining the areas that need testing, linked to existing
tests and general testing progress.
</p>
</section>
<section>
<h3>Providing guidance on testing</h3>
<p>
In order to increase the quality of the test contributions, this
document offers a set of guidelines for conducting testing (see
<a href="#approach" class="sectionRef"></a>) and a testing progress
tracker to increase the surface coverage of tests (see
<a href="#test-progress-tracking" class="sectionRef"></a>).
</p>
</section>
<section>
<h3>Creating automation-friendly tests</h3>
<p>
In terms of actual tests produced for the CSS Writing Modes, the main goal
is to ensure that most tests are automatable (i.e. they're either
reftests or use <code>testharness.js</code>). Even where manual tests
are absolutely necessary they should be written so that they can be
easily automated &ndash; as there are on-going efforts to make
WebDriver [[webdriver]] automated tests a first class citized in W3C
testing. This means that even if a manual test requires user
interaction, the validation or PASS/FAIL conditions should still be
clear enough as to allow automatic validation if said interaction is
later automated.
</p>
<p>
In particular need a special font in the test of CSS Writing Modes. Since these are is assumed of many tests, people who try to create the test now, check to see whether any available font.
</p>
</section>
</section>
<section>
<h2>Risks and mitigation</h2>
<p>
There are a number of risks associated with creating a high-quality
test suite for CSS Writing Modes. The most important ones are listed below.
</p>
<section>
<h3>Implicit interactions with a lot of other specs (and commonly accepted
browser behavior)</h3>
<p>
The CSS Writing Modes spec introduces a significant change in the way layout
can be done and as a consequence, many of the assumptions that hold in
the context of CSS&nbsp;2.1 must be re-validated in the context of CSS
Writing Modes. In the meanwhile, a lot of new layout modules have been
proposed, with various degrees of implementer support and maturity.
Also, non-CSS specific specs introduced concepts that affect how style
is propagated (e.g. Shadow DOM [[shadow-dom]]) or how elements are
rendered and interact with their containing documents (e.g.
<code>&lt;iframe seamless&gt;</code> in HTML 5 [[HTML5]]).
</p>
<p>
All the above factors increase the testing surface and the number of
the possible cases that might need an explicitly specified behavior in
order to ensure intuitive and predictable results as well as stable
interaction with widely used browser features (that might not be <em>yet</em>
so strictly specified).
</p>
<p>
In terms of specifying the expected behavior, the current approach is
to try and specify it for specs that are final or nearly-final and to
just make a note of the possible interactions and unspecified behaviors
in the case of specs that are still in flux. In exceptional cases, a
new spec might be created to cater for the needs of multiple specs
(e.g. the CSS Fragmentation spec [[css3-break]]).
</p>
</section>
<section>
<h3>Big number of tests required</h3>
<div class="note">
Add here the estimation of tests required produced by
<a href="https://github.com/w3c/web-platform-tests/tree/master/tools/coverage" target="_blank">W3C test coverage</a>
tool. If possible, provide a better informed guess on the number of tests.
</div>
<p>
Given the complexity of the spec, a big number of tests will need to
be created to produce a test suite that can ensure interoperability
between implementations.
</p>
<p>
In this context, the main purpose of this document is to provide
useful informations for creating and contributing tests in an effective
manner in terms of coverage and test quality.
</p>
</section>
<section>
<h3>Special fonts required</h3>
<p>
For building reftest, several special fonts are necessary.
If could not get some fonts, a test will be manual or reftest waiting fonts.
</p>
</section>
</section>
<section>
<h2>Approach</h2>
<p>
As spec testing cannot be realistically separated from testing a
particular implementation (except for the very simple cases), the
approach proposed for testing is one that tries to first cover as many
areas as possible, instead of deep diving on a certain feature or aspect
of the spec first. A side benefit of this approach is that the spec
tests can be used at any time to gauge the level of support of a certain
implementation.
</p>
<p>
Having this <em>breadth-first</em> approach in mind, tests will be
created for the testing areas listed in <a href="#testing-areas"
class="sectionRef"></a>. Testing will be done in multiple passes, each
aimed at covering more specific edge-cases.
</p>
<p>
The selection of test data, in terms of parsing, rendering, choose only one typical values from the data set on the same effect (It is a test technique known "equivalence partitioning").
</p>
</section>
<section>
<h2>Testing areas</h2>
<section>
<h3>Explicit testing areas</h3>
<p>
These are testing areas normatively defined by the spec. They cover
things explicitly or implicitly defined in the CSS Writing Modes spec.
Please note that while detailed, this list is not necessarily
exhaustive and normative behaviors may not be contained in it.
When in doubt, consult the CSS Writing Modes spec or ask a question on the
<a href="http://lists.w3.org/Archives/Public/www-style/">mailing
list</a>.
</p>
<p>
<h4>Overview</h4>
Below is the list of explicit testing areas:
<ol>
<li>
Proper parsing of the CSS properties and rules, rendering
according to the spec.
<ul>
<li><code>direction</code></li>
<li><code>unicode-bidi</code></li>
<li><code>writing-mode</code></li>
<li><code>text-orientation</code></li>
<li><code>caption-side</code></li>
<li><code>text-combine-upright</code></li>
</ul>
</li>
Test the following set of elements as a group to the 'Applies to' description.
<ul>
<li>inline element, inline block, replaced elements, block element, list-item
, table, inline-table, table-header-group, table-footer-group, table-cell, table-caption</li>
<li><code>display:none</code></li>
<li>inherit</li>
</ul>
Selected as a representative following four frequently used as 'replace element'.
<ul>
<li><code>button</code></li>
<li><code>input:text</code></li>
<li><code>select</code></li>
<li><code>text-area</code></li>
</ul>
</li>
<li>
Box related specifications that are affected as specified by <code>writing-mode</code>, <code>text-orientation</code>. The original definition about 'Box model' see [[CSS21]] for details. Calculation of the following in particular:
<ul>
<li><code>margin</code></li>
<li><code>border</code></li>
<li><code>padding</code></li>
</ul>
</li>
<li>
Compression of the glyph in horizontal-in-vertical(tate-chu-yoko) when using the text-transform [[!css3-text]] and OpenType properties.
</li>
<li>
Positioning, sizing and Auto-sizing of the box in orthogonal flows.
</li>
<li>
Text Baselines in vertical writing mode.
<ul>
<li>alphabetic</li>
<li>central</li>
</ul>
</li>
</ol>
</p>
<h3>Each Section</h3>
<ol>
<h3>Sec 2.Inline Direction and Bidirectionality</h3>
<p>
Parse, Rendering fundamental when combined the <code>direction</code> property and the <code>unicode-bidi</code> property. Applying Unicode bidirectional algorithm, behavior when the value is a newline. Placement of split inline-box. Calculation positioning of the box element.
</p>
<h3>Sec 3.Introduction to Vertical Text</h3>
<p>
Parse, Rendering fundamental for the <code>writing-mode</code> property. Character should be considered in particular the placement in vertical writing mode(Punctuation, etc. Onbiki in Japanese). Rendering for principal writing mode. Handling of child block in the case of line feed direction different from the container block. Converte value of the SVG in the writing-mode.
</p>
<h3>Sec 4.Inline-level Alignment</h3>
<p>
Consider baseline alphabetic, central in this specification. Baseline in vertical alignment for glyph, processing of dominant baseline.
<div class="note">
'dominant baseline' testing in CSS21 side?
</div>
</p>
<h3>Sec 5.Introduction to Vertical Text Layout</h3>
<p>
Parse, Rendering fundamental for the <code>text-orientation</code> property. rendering when the vertical writing mode. Rules of Appendix C.
</p>
<h3>Sec 6.Abstract Box Terminology</h3>
<p>
Processing over and under in line-relative directions. left, right adding in vertical writing mode to line-box. The processing of before, after, start, end of each block-level-element, inline-level-element in flow-relative directions.
</p>
<h3>Sec 7.Abstract Box Layout</h3>
<p>
Layout rule that refers to property in the box when in vertical writing mode and margin collapsing. Sizing, auto-sizing of the writing modes in Orthogonal Flow. Margin calculation in the case of Flow-Relative. Position calculation in the case of Line-Relative. Properties that do not affect the WritingMode. rendering and parsing of <code>caption-side</code> property.
</p>
<h3>Sec 8.Page Flow: the page progression direction</h3>
<p>
It is a page feed flow specification of UA, is beyond the scope of the current test environment.
</p>
<h3>Sec 9.Glyph Composition</h3>
<p>
Parse, Rendering fundamental for the <code>text-combine-upright</code> property. rendering when the vertical writing mode. Interrupted by a box boundary in text run-rules. Glyph of centering in 1em box. Several algorithms to compress the 1em glyph of multiple.
</p>
</ol>
</section>
<section>
<h3>Implicit testing areas</h3>
<p>
These are testing areas either normatively defined in other specs
that explicitly refer to the CSS Writing Modes spec (e.g. [[css3-text]])
or simply not explicitly defined, but implied by various aspects of
the spec (e.g. processing model, CSS 2.1 compliance, etc.).
Please note that while detailed, this list is not necessarily
exhaustive and normative behaviors may not be contained in it.
When in doubt, consult the CSS Writing Modes spec or ask a question on the
<a href="http://lists.w3.org/Archives/Public/www-style/">mailing
list</a>.
</p>
<p>
Below is the list of implicit testing areas:
<ol>
<li>
CSS Writing Modes and layout modules:
<ul>
<li><code>overflow</code></li>
<li><code>clip</code></li>
<li><code>line-height</code></li>
<li>the <code>alt</code> attribute </li>
</ul>
</li>
</ol>
</p>
</section>
</section>
<section>
<h2>People and responsibilities</h2>
<p>
Below is a list of people you should reach out to if you have any
questions related to this document or testing CSS Writing Modes in general:
<ul>
<li>fantasai &ndash; editor for CSS Writing Modes spec</li>
<li>Koji Ishii &ndash; editor for CSS Writing Modes spec</li>
<li>Rebecca Hauck &ndash; CSSWG testing owner</li>
</ul>
</p>
</section>
<section>
<h2>Test progress tracking</h2>
<p>
Currently test progress tracking is done via gitHub
<a href="https://github.com/w3c/csswg-test/issues/milestones?with_issues=yes">milestones</a>
and <a href="https://github.com/w3c/csswg-test/issues?milestone=9&state=open">issues</a>.
</p>
</section>
</body>
</html>

View file

@ -0,0 +1,502 @@
<!DOCTYPE html>
<html>
<head>
<title>Requirements for fonts for testing text-combine-upright</title>
<meta charset='utf-8'>
<script class='remove'>
var respecConfig = {
specStatus: "unofficial",
shortName: "req-tcu-font",
editors: [ { name: "Masataka Yakura", url: "https://google.com/+MasatakaYakura" } ],
publishDate: "2015-01-28",
};
</script>
<style>
/*****************************************************************
* ReSpec 3 CSS
* Robin Berjon - http://berjon.com/
*****************************************************************/
/* --- INLINES --- */
em.rfc2119 { text-transform: lowercase; font-variant: small-caps; font-style: normal; color: #900; }
h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr { border: none; }
dfn { font-weight: bold; }
a.internalDFN { color: inherit; border-bottom: 1px solid #99c; text-decoration: none; }
a.externalDFN { color: inherit; border-bottom: 1px dotted #ccc; text-decoration: none; }
a.bibref { text-decoration: none; }
cite .bibref { font-style: normal; }
code { color: #C83500; }
/* --- TOC --- */
.toc a, .tof a { text-decoration: none; }
a .secno, a .figno { color: #000; }
ul.tof, ol.tof { list-style: none outside none; }
.caption { margin-top: 0.5em; font-style: italic; }
/* --- TABLE --- */
table.simple { border-spacing: 0; border-collapse: collapse; border-bottom: 3px solid #005a9c; }
.simple th { background: #005a9c; color: #fff; padding: 3px 5px; text-align: left; }
.simple th[scope="row"] { background: inherit; color: inherit; border-top: 1px solid #ddd; }
.simple td { padding: 3px 10px; border-top: 1px solid #ddd; }
.simple tr:nth-child(even) { background: #f0f6ff; }
/* --- DL --- */
.section dd > p:first-child { margin-top: 0; }
.section dd > p:last-child { margin-bottom: 0; }
.section dd { margin-bottom: 1em; }
.section dl.attrs dd, .section dl.eldef dd { margin-bottom: 0; }
@media print { .removeOnSave { display: none; } }
</style>
<style>/* --- ISSUES/NOTES --- */
div.issue-title, div.note-title { padding-right: 1em; min-width: 7.5em; color: #b9ab2d; }
div.issue-title { color: #e05252; }
div.note-title { color: #2b2; }
div.issue-title span, div.note-title span { text-transform: uppercase; }
div.note, div.issue { margin-top: 1em; margin-bottom: 1em; }
.note > p:first-child, .issue > p:first-child { margin-top: 0 }
.issue, .note { padding: .5em; border-left-width: .5em; border-left-style: solid; }
div.issue, div.note { padding: 1em 1.2em 0.5em; margin: 1em 0; position: relative; clear: both; }
span.note, span.issue { padding: .1em .5em .15em; }
.issue { border-color: #e05252; background: #fbe9e9; }
.note { border-color: #52e052; background: #e9fbe9; }
</style>
<style>/* HIGHLIGHTS */
code.prettyprint { color: inherit; }
/* this from google-code-prettify */
.pln{color:#000}@media screen{.str{color:#080}.kwd{color:#008}.com{color:#800}.typ{color:#606}.lit{color:#066}.pun,.opn,.clo{color:#660}.tag{color:#008}.atn{color:#606}.atv{color:#080}.dec,.var{color:#606}.fun{color:red}}@media print,projection{.str{color:#060}.kwd{color:#006;font-weight:bold}.com{color:#600;font-style:italic}.typ{color:#404;font-weight:bold}.lit{color:#044}.pun,.opn,.clo{color:#440}.tag{color:#006;font-weight:bold}.atn{color:#404}.atv{color:#060}}ol.linenums{margin-top:0;margin-bottom:0}li.L0,li.L1,li.L2,li.L3,li.L5,li.L6,li.L7,li.L8{list-style-type:none}li.L1,li.L3,li.L5,li.L7,li.L9{background:#eee}
</style>
<link rel="stylesheet" href="https://www.w3.org/StyleSheets/TR/w3c-unofficial">
</head>
<body>
<section id="abstract">
<p>The <a href="https://drafts.csswg.org/css-writing-modes/">CSS Writing Modes</a> specification defines a property <code>text-combine-upright</code> which enables a <i>tate-chu-yoko</i> (<span lang="ja">縦中横</span>) effect; applying the property to a span of text will combine the text inside it horizontally so that it looks a single character in vertical writing modes.
<p>While invesitigating the specification for developing test suite, test authors found the need for a new font specifically designed to test the property. This document gives a fairly basic guide to CSS testing and testing <code>text-combine-upright</code> specifically, and lists the requiremnts of the font needed to test the property.
</section>
<section>
<h2>CSS testing terminology</h2>
<p>Before getting into the requirements of fonts, let me explain some terms specific to CSS testing.
<section>
<h3>Reftests (reference tests)</h3>
<p>A <a href="http://testthewebforward.org/docs/reftests.html">reftest</a> are one of the testing format used in W3C and browser vendors for testing features that add visual effects to a page such as CSS and SVG. A reftest are madte of two (or more) files: a test case made using features to test, and reference file(s) made using widely-implemented-and-deployed features (e.g. CSS2). On conforming implementation the reference and the test case will visually match.
<p>For ease of testing, references often use simple geometric shapes such as <a href="http://test.csswg.org/source/css-flexbox-1/reference/flexbox-flex-wrap-nowrap-ref.htm">green square</a>.
<figure>
<iframe src="../../css-flexbox-1/reference/flexbox-flex-wrap-nowrap-ref.htm" frameborder="0" width="400" height="200"></iframe>
<figcaption>A reference of green rectangle, used for a flexbox test</figcaption>
</figure>
</section>
<section>
<h3>The Ahem font</h3>
<p>In order to test CSS features, it is required to install the <a href="http://www.w3.org/Style/CSS/Test/Fonts/Ahem/">Ahem font</a> in a testing system. The Ahem font only contains simple geometric glyphs such as a square and rectangles. With those simple glyphs it is easy to craft references and test cases. Here's a design specification of Ahem quoting from the README file:
<blockquote cite="http://www.w3.org/Style/CSS/Test/Fonts/Ahem/">
<pre>The font's em square is exactly square.
Its ascent and descent is exactly the size of the em square. This
means that the font's extent is exactly the same as its line-height,
meaning that it can be exactly aligned with padding, borders, margins,
and so forth.
The font's alphabetic baseline is 0.2em above its bottom, and 0.8em
below its top. The font has an x-height of 0.8em.
The font has four glyphs:
'X' U+0058 A square exactly 1em in height and width.
'p' U+0070 A rectangle exactly 0.2em high, 1em wide, and aligned so
that its top is flush with the baseline.
'É' U+00C9 A rectangle exactly 0.8em high, 1em wide, and aligned so
that its bottom is flush with the baseline.
' ' U+0020 A transparent space exactly 1em high and wide.
Most other US-ASCII characters in the font have the same glyph as X.</pre>
</blockquote>
</section>
</section>
<section>
<h2>Testing <code>text-combine-upright</code></h2>
<p>The <a href="https://drafts.csswg.org/css-writing-modes/#text-combine-upright"><code>text-combine-upright</code></a> property combines a short run of text horizontally in vertical writing modes. The resulting effect is called <i>tate-chu-yoko</i> (<span lang="ja">縦中横</span>, sometimes abbreviated as <abbr>TCY</abbr> in CSSWG mailing lists) and used for short digits in vertical Japanese layout.
<figure class="example">
<img src="https://drafts.csswg.org/css-writing-modes/tate-chu-yoko.png">
<figcaption>Example of tate-chu-yoko (borrowed from the Writing Modes spec). The digits "20" and "16" are aligned horizontally. Also the digit "4" is rotated upright even it looks an ASCII digit; this is because "4" is also composed thus rotated.</figcaption>
</figure>
<p>In order to make reftests, it needs a font which contains geometric glyphs designed so that horizontally-combined glyphs and the reference would look the same (e.g. a 1em &times; 1em square glyph). With such font, a test can be written as follows:
<pre class="highlight"><code>&lt;style&gt;
.test {
writing-mode: vertical-rl;
font-family: Ahem;
}
.tcy {
text-combine-upright: all;
}
&lt;/style&gt;
&lt;p&gt;Test passes if the following is identical:&lt;/p&gt;
&lt;div class="test"&gt;
&lt;p&gt;&lt;span class="tcy"&gt;123&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;x&lt;/p&gt;
&lt;/div&gt;</code></pre>
<p>In conforming user agent with the font installed on the system, the span "123" will be combined horizontally thus rendered as a single square, resulting to match the reference. In non-conforming user agents the span will neither be combined nor be compressed as a single square, it will thus not match the reference rendering.
<figure class="example">
<img src="img/figure-rendering-tcu.svg" width="480">
<figcaption>An illustration of output from ① no-tcu-support UA, ② conforming UA, ③ reference file</figcaption>
</figure>
<p>The above example uses Ahem; some tests can be written using Ahem. However, many features of <code>text-combine-upright</code> cannot be tested with only a black square glyph. Also the spec requires UAs with OpenType support to use OpenType features on rendering particular properties; to test this, the font must be an OpenType font with required fetures.
</section>
</section>
<section>
<h2>Glyphs</h2>
<p>This section describes requirements for glyphs that the font needs and gives some ideas of glyphs.
<section>
<h3>Glyphs that can be used as an alternative to Ahem glyphs</h3>
<p>In the prior section we demonstrate how we can test <code>text-combine-upright</code> using Ahem. In some cases tests can be written only using Ahem, but there are cases where we need additional glyphs.
<ul>
<li>A black square is a 1em &times; 1em square glyph; it is pretty much the same as Ahem's glyph for <code>x</code>
<li>A blank of 1em &times; 1em
</ul>
<figure>
<img src="img/square_black.svg" width="300">
<img src="img/square_blank.svg" width="300">
</figure>
<p class="note">It might be okay with just using Ahem if tests needing black square only contain codepoints in ASCII-range.
</section>
<section>
<h3>Glyphs to check whether a character is rotated or not</h3>
<p><code>text-combine-upright</code> combines a span of text horizontally and make the resulting compression rendered upright, even when the element has just one character.
<p>If the element contains two or more characters, Ahem can be used to check if user agents support composition effect. However, if it is just a single character, Ahem cannot be used since most character in Ahem is a 1em square and thus cannot figure out whether the resulting coposition is rendered upright or not.
<p>Therefore, we need two glyphs where:
<ul>
<li>their widths and heights are 1em
<li>one matches another visually when another rotated 90&deg; counterclockwise
</ul>
<figure>
<img src="img/pointing_right.svg" width="300">
<img src="img/pointing_up.svg" width="300">
<figcaption>example glyphs that satisfy the requirements above: "pointing-right" on left and "pointing-up" on right</figcaption>
</figure>
<p class="note">Yes, I stole the glyph idea from <a href="http://blogs.adobe.com/CCJKType/2013/05/css-orientation-test-opentype-fonts.html">CSS Orientation Test</a> font.
<figure>
<pre class="highlight"><code>&lt;style&gt;
body {
writing-mode: vertical-rl;
font-family: SomeFont;
}
.test {
text-combine-upright: all;
}
.reference {
text-orientaiton: upright;
}
&lt;/style&gt;
&lt;p class="test"&gt;A&lt;/p&gt;
&lt;p class="reference"&gt;B&lt;/p&gt;</code></pre>
<figcaption>Test code might look like this</figcaption>
</figure>
<p class="note">These glyphs are not directly related to TCY so perhaps it should go to CSS Orientation Test font.
</section>
<section>
<h3>Glyph to check whether the composition has no text decoration inside it</h3>
<p>In <a href="https://drafts.csswg.org/css-writing-modes/#text-combine-layout">Section 9.1.2 Layout Rules</a> it says:
<blockquote>
When combining text as for text-combine-upright: all, the glyphs of the combined text are composed horizontally (<mark>ignoring letter-spacing and any forced line breaks, but using the specified font settings</mark>), similar to the contents of an inline-box with a horizontal writing mode and a line-height of 1em.
</blockquote>
<p>Later in the section it says:
<blockquote>
For other text layout purposes, e.g. emphasis marks, text-decoration, spacing, etc. the resulting composition is treated as a single glyph representing the Object Replacement Character U+FFFC.
</blockquote>
<p>So we need to test if user agents ignore spacing, emphasis marks, decorations applied to <em>each</em> character inside the composition but rather apply those effects to the resulting composition, treating as if it were a single characeter.
<p>The test should be written to check if there is no emphasis mark or ruby character inside the composition. To make this easy to observe, we need a glyph where:
<ul>
<li>it does not overlap ruby text, emphasis mark, or any decoration
</ul>
<p>The following is an idea for such glyph: it draws overline and underline but does not do so in between them.
<figure>
<img src="img/over_and_under.svg" width="300">
</figure>
<p>With such glyph, the test would be written as:
<figure>
<pre class="highlight"><code>&lt;style&gt;
.test {
writing-mode: vertical-rl;
font-family: TCU-test;
}
.tcy {
text-combine-upright: all;
text-emphasis: sesame;
}
&lt;/style&gt;
&lt;p&gt;&lt;span class="tcy"&gt;AB&lt;/span&gt;&lt;/p&gt;</code></pre>
</figure>
<p>This will make the test reftestable.
<figure>
<img src="img/figure-over_and_under-pass.svg" width="300">
<img src="img/figure-over_and_under-fail.svg" width="300">
<figcaption>Conforming user agents apply text-emphasis as if the content inside <code>&lt;span class="tcy"&gt;</code> were a single character (left). Non-conforming user agents might apply text-emphasis to each character inside <code>&lt;span class="tcy"&gt;</code> (right)</figcaption>
</figure>
<p class="issue">This glyph cannot cover the assertion <q>the resulting composition is treated as a single glyph representing the Object Replacement Character U+FFFC</q>. Test authors are not sure if that will cause a visual effect that can be tested.
</section>
<section>
<h3>Glyphs that is larger than 1em square</h3>
<p>In <a href="https://drafts.csswg.org/css-writing-modes/#text-combine-layout">9.1.2 Layout Rules</a> the spec says:
<blockquote>
The effective size of the composition is assumed to be 1em square; anything outside the square is not measured for layout purposes.
</blockquote>
<p>Hence, we need a glyph where:
<ul>
<li>its size is greater than 1em square
</ul>
<figure>
<img src="img/heavy_h.svg" width="200">
<!-- <img src="img/heavy_h_rotated.svg" width="200"> -->
<figcaption>The "Heavy H". The dashed region in the center of the glyph indicates the 1em square and the lines besides the square has the length of 3em and the thickness of 1em.</figcaption>
</figure>
<p>By using this glyph with two square glyphs we can make a 3em square.
<figure>
<pre class="highlight"><code>&lt;style&gt;
body {
writing-mode: vertical-rl;
font-family: SomeFont;
}
.tcy {
text-combine-upright: all;
}
.reference {
font-size: 3em;
margin: 2em 0;
}
&lt;/style&gt;
&lt;div class="test"&gt;
&lt;p&gt;x&lt;span class="tcy"&gt;H&lt;/span&gt;x&lt;/p&gt;
&lt;p class="reference"&gt;x&lt;/p&gt;
&lt;/div&gt;</code></pre>
<figcaption>The test code might look like this: it assumes that a black square glyph maps to <code>x</code> and the "Heavy H" glyph maps to <code>H</code></figcaption>
</figure>
</section>
<section>
<h3>TBD</h3>
<p>In <a href="https://drafts.csswg.org/css-writing-modes/#text-combine-layout">9.1.2 Layout Rules</a> the spec says:
<blockquote>
The UA should center the glyphs horizontally and vertically within the measured 1em square.
</blockquote>
<p class="issue">work in progress. test authors are struggling with the look of shape(s) to use to create a reftest
<!--
<p>
<ul>
<li>
</ul>
<figure>
<img src="">
<figcaption></figcaption>
</figure>
<p>
-->
</section>
<section>
<h3>Glyphs to check whether <code><var>n</var>wid</code> OpenType features are used</h3>
<p>In <a href="https://drafts.csswg.org/css-writing-modes/#text-combine-compression">9.1.3 Compression Rules</a> the spec says:
<blockquote>
OpenType implementations must use width-specific variants (OpenType features hwid/twid/qwid; other glyph-width features such as fwid or pwid are not included) to compress text in cases where those variants are available for all characters in the composition.
</blockquote>
<p>In order to test this, we need glyphs for hwid, twid, and qwid; they need to be distinguishable from each other and also distinguishable from fwid/pwid glyphs. For the use in reference, we also need "extended" versions of hwid/twid/qwid glyphs; the widths of the extended version are all 1em.
</ul>
<section>
<h4>A double stripe</h4>
<p>Used for the <i>hwid</i> feature.
<figure>
<img src="img/stripe_double.svg" width="300">
<figcaption>double stripe. reference glyph on left, hwid glyph on right.</figure>
</figure>
</section>
<section>
<h4>A triple stripe</h4>
<p>Used for the <i>twid</i> feature.
<figure>
<img src="img/stripe_triple.svg" width="300">
<figcaption>triple stripe. reference glyph on left, twid glyph on right.</figure>
</figure>
</section>
<section>
<h4>A quadruple stripe</h4>
<p>Used for the <i>qwid</i> feature.
<figure>
<img src="img/stripe_quad.svg" width="300">
<figcaption>quadruple stripe. reference glyph on left, qwid glyph on right.</figure>
</figure>
</section>
<p class="note">There might be cases where a character inside TCY does not have all features, the font need to have characters that only have (or miss) hwid/twid/qwid feature. Tests need to check combination of characters with different feature sets.
<p class="issue">Since the processing details of compression rules are up to User Agents, when the resulting glyphs from composition differs from each other, the test can only be verified using negative references.
</section>
<section>
<h3>Glyphs to check the optional processing regarding U+6C34</h3>
<p>The last paragraph in <a href="https://drafts.csswg.org/css-writing-modes/#text-combine-compression">9.1.3 Compression Rules</a> says:
<blockquote>
In some fonts, the ideographic glyphs are given a compressed design such that they are 1em wide but shorter than 1em tall. To accommodate such fonts, the UA may vertically scale the the composition to match the advance height of 水 U+6C34.
</blockquote>
<p>We need two glyphs:
<ul>
<li>a glyph of horizontal rectangle (e.g. 1em &times; .8em), mapping to 0x6C34
<li>a glyph of thinner horizontal rectangle (e.g. 1em &times; .3em), mapping to a certain codepoint
</ul>
<p class="note">There is <a href="http://lists.w3.org/Archives/Public/www-style/2014Jul/0310.html">a spec issue</a>.
</section>
</section>
<section>
<h2>Glyph mappings</h2>
<p>This section describes which glyph should map to which code points.
<p class="note">This section is work-in-progress.</p>
<section>
<h3>Font A <span class="issue">TODO: Name</span></h3>
<p>Font A contains all glyphs except ones for checking <a href="#glyphs-to-check-whether-nwid-opentype-features-are-used">width-related features</a>.</p>
<p class="note">Unless otherwise specified, glyphs are mapped to both in horizontal and in vetical (using the <code>vert</code> feature) modes.</p>
<table class="simple" border>
<tr>
<th>Code Point
<th>Glyph
<th>Note
<tr>
<td>x (U+0078)
<td>Black
<td>
<tr>
<td>SPACE (U+0020)
<td>Blank
<td>
<tr>
<td>R (U+0052)
<td>Pointing Right
<td>
<tr>
<td>U (U+0055)
<td>Pointing Up
<td>
<tr>
<td>O (U+004F)
<td>Overline+Underline
<td>
<tr>
<td>h (U+0048)
<td>Heavy H
<td>
<tr>
<td>r (U+072)
<td>Pointing Right and Pointing Up
<td>
default: Pointing Right<br>
vert: Pointing Up
</table>
</section>
<section>
<h3>Fonts to test width-variant features</h3>
<p>These fonts test the <a href="#glyphs-to-check-whether-nwid-opentype-features-are-used">width-related features</a>. One font contains only <code>hwid</code> feature, and another contains all the five features (<code>hwid</code>, <code>twid</code>, <code>qwid</code>, <code>fwid</code>, and <code>pwid</code>).</p>
<p>Below is a table for the latter font; the former (only contains <code>hwid</code> feature) lacks other four features.</p>
<table class="simple" border>
<tr>
<th>Code Point
<th>Glyph
<th>Note
<tr>
<td>a (U+0078)
<td>Double Stripe<br>Triple Stripe<br>Quadruple Stripe<br>Black
<td>
hwid: Double Stripe<br>
twid: Triple Stripe<br>
qwid: Quadruple Stripe<br>
fwid: Black<br>
pwid: Black<br>
<tr>
<td>H (U+0078)
<td>Double Stripe
<td>
Used in reference
<tr>
<td>T (U+0078)
<td>Triple Stripe
<td>
Used in reference
<tr>
<td>Q (U+0078)
<td>Quadruple Stripe
<td>
Used in reference
</table>
</section>
</section>
<section>
<h2>Acknowledgements</h2>
<p>Special thnks goes to the current and former editors of the Writing Modes specification: fantasai, Koji Ishii, and Shinyu Murakami
<p>In addition to the editors, this work wouldn't have been possible without help from: Taichi Kawabata
</section>
<script src='http://www.w3.org/Tools/respec/respec-w3c-common' async class='remove'></script>