# Results of Questionnaire TR Design Survey

The results of this questionnaire are available to anybody. In addition, answers are sent to the following email address: www-archive@w3.org

This questionnaire was open from 2015-05-21 to 2015-09-01.

### 1. Group

On behalf of which W3C Working Group are you answering this survey?

#### Details

Responder Group
Jim Melton XML Query Working Group
Chris Lilley WebFonts
Nigel Megitt Timed Text Working Group
Michael Cooper Protocols and Formats
Joshue O Connor WCAG
Frederick Hirsch Web Annotation WG, http://www.w3.org/annotation/
Doug Schepers Pointer Events WG
Arthur Barstow Web Applications
Deborah Dahl Multimodal Interaction
Ilya Grigorik Webperf
Gregg Kellogg CSV on the Web Working Group
Paul Grosso XML Core WG
Ted Guild Automotive
Norman Walsh XML Processing Model
David Carlisle Math WG
Michael Kay XSL WG. We also work closely with XQuery WG, so these answers supplement those from Jim Melton. (In some cases I think I have interpreted the questions differently.)
Dave Cramer Digital Publishing Interest Group
Nick Doty Tracking Protection Working Group
François Daoust Second Screen Working Group

### 2. Sample(s)

#### Details

Responder Sample(s)
Jim Melton https://www.w3.org/TR/xquery-31/
https://www.w3.org/TR/xpath-functions-31/
Chris Lilley http://www.w3.org/TR/WOFF20ER/ (TR, vanilla W3C style)
http://www.w3.org/TR/WOFF2/ (TR, vanilla) and http://dev.w3.org/webfonts/WOFF2/spec/ (ED, slightly different styling)
Nigel Megitt WebVTT:

Editor draft:
http://dev.w3.org/html5/webvtt/

FPWD:
http://www.w3.org/TR/webvtt1/

IMSC:

http://www.w3.org/TR/ttml-imsc1/

(styling the same on ED and /TR)

TTML:

http://www.w3.org/TR/ttml1/

(styling the same on ED and /TR)
Michael Cooper http://www.w3.org/TR/core-aam-1.1/ particularly mapping tables, in two incarnations flipped by script
http://www.w3.org/TR/wai-aria-1.1/
Joshue O Connor http://www.w3.org/TR/WCAG20/
http://www.w3.org/TR/WCAG20-TECHS/G143.html
http://www.w3.org/TR/WCAG20-TECHS/failures.html#F1

Frederick Hirsch Web Annotation Data Model http://www.w3.org/TR/2014/WD-annotation-model-20141211/ (FPWD)

RangeFinder API http://w3c.github.io/web-annotation/api/rangefinder/ (Editors Draft)

Web Annotation Protocol http://w3c.github.io/web-annotation/protocol/wd/ ( Editors Draft )
Doug Schepers http://www.w3.org/TR/2015/REC-pointerevents-20150224/
Arthur Barstow Links to all of WebApps' EDs are included in <https://www.w3.org/2008/webapps/wiki/PubStatus>.

Most EDs use ReSpec but a few EDs do have their own style such as:

Service Workers:
<http://slightlyoff.github.io/ServiceWorker/spec/service_worker/>

Web Components specs:
<http://w3c.github.io/webcomponents/spec/custom/>

The APIs that were originally part of HTML5, f.ex.:
<https://w3c.github.io/websockets/>
<https://w3c.github.io/webstorage/>

FIleAPI:
<https://w3c.github.io/FileAPI/>

WebIDL:
<http://heycam.github.io/webidl/>

Deborah Dahl EMMA http://www.w3.org/TR/emma/
Discovery http://www.w3.org/TR/mmi-mc-discovery/
Ilya Grigorik http://w3c.github.io/performance-timeline/
Gregg Kellogg http://www.w3.org/TR/tabular-data-model/ http://w3c.github.io/csvw/syntax/
http://www.w3.org/TR/csv2json/ http://w3c.github.io/csvw/csv2json/
Paul Grosso http://www.w3.org/TR/2015/CR-xinclude-11-20150630/
http://www.w3.org/TR/2008/REC-xml-20081126/
Ted Guild http://www.w3.org/TR/vehicle-information-api/
http://www.w3.org/TR/vehicle-data/
Norman Walsh http://www.w3.org/TR/xproc-v2-req/
http://www.w3.org/TR/xproc20/
http://www.w3.org/TR/xproc20-steps/
David Carlisle
**MathML3
TR
http://www.w3.org/TR/MathML3/

Editors draft
http://www.w3.org/Math/draft-spec/mathml.html

Note MathML3 is published in several forms (html4, pdf, html5/mathml etc) the editors draft version has several style changes that have been requested by readers since the TR publication, most notably a maximum
width of the text body and permalinks on all section headings which appear on mouseover currently.

** XML entities
TR
http://www.w3.org/TR/xml-entity-names/

Editors draft
http://www.w3.org/2003/entities/2007doc/

Michael Kay https://www.w3.org/XML/Group/qtspecs/specifications/xslt-30/html/Overview.html
https://www.w3.org/XML/Group/qtspecs/specifications/xslt-30/html/Overview-diff.html
Dave Cramer http://w3c.github.io/dpub-pagination/priorities.html
http://w3c.github.io/dpub-pagination/index.html
http://w3c.github.io/aria/aria/dpub.html
Nick Doty http://www.w3.org/TR/tracking-dnt/
http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html
François Daoust http://w3c.github.io/presentation-api/

### 3. Specification Processor(s)

What spec pre-processor(s) does your WG use?

#### Details

Responder Specification Processor(s)
Jim Melton If I understand your question correctly, the only pre-processor we use is tidy.
Chris Lilley none
Nigel Megitt ReSpec
XMLSpec
Michael Cooper Respec
Joshue O Connor A custom XML format and set of XSLTs. These extend XML Spec. (Thanks to Michael C for clarification).
Frederick Hirsch ReSpec
Doug Schepers ReSpec
Arthur Barstow Mostly ReSpec.

Anolis was used at one time but I think it is not used any more.

WebIDL uses XML as the source code.
Deborah Dahl None
Ilya Grigorik respec
Gregg Kellogg ReSpec
Paul Grosso Not sure what this means. We create specs in XML using the XMLspec DTD and XSLT stylesheets and automatically generate the HTML (and diffs). We make both the XML and HTML available when we publish. See https://www.w3.org/XML/Group/Core#useful-info
Ted Guild Respec
Norman Walsh I'm not sure I understand the question. We mostly produce HTML from DocBook with a bit of customization in both the markup and the transforms.
David Carlisle XSLT using a modified version of xmlspec sources. (The Math WG has been using a forked version of xmlspec since before XSLT 1 was a recommendation.)
Michael Kay The source text is maintained in XML, based on a customized version of xmlspec. There is a complex pipeline (in Ant) to generate the final HTML for publication.
Dave Cramer Both bikeshed and respec
Nick Doty ReSpec
François Daoust ReSpec

### 4. Group style sheet(s)

Paste in URLs to any WG-specific style sheets you use.

#### Details

Responder Group style sheet(s)
Jim Melton http://www.w3.org/StyleSheets/TR/W3C-WD.css
http://www.w3.org/StyleSheets/TR/W3C-CR.css
http://www.w3.org/StyleSheets/TR/W3C-PR.css
http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css
Chris Lilley http://dev.w3.org/webfonts/WOFF2/spec/conform.css
Nigel Megitt See https://github.com/w3c/webvtt/blob/master/webvtt.html
and http://www.w3.org/TR/ttml1/ <style> element, generated from https://dvcs.w3.org/hg/ttml/file/tip/ttml1/spec/xmlspec-ttml1.xsl
Michael Cooper https://raw.githubusercontent.com/w3c/aria/master/common/css/common.css
https://raw.githubusercontent.com/w3c/aria/master/common/css/mapping-tables.css
https://raw.githubusercontent.com/w3c/aria/master/core-aam/css/core-aam.css
https://raw.githubusercontent.com/w3c/aria/master/html-aam/css/html-aam.css
https://raw.githubusercontent.com/w3c/aria/master/practices/css/aria-apg.css
http://www.w3.org/TR/UNDERSTANDING-WCAG20/diffs.css
http://www.w3.org/TR/UNDERSTANDING-WCAG20/slicenav.css
http://www.w3.org/TR/UNDERSTANDING-WCAG20/print.css
http://www.w3.org/TR/WCAG20-TECHS/diffs.css
http://www.w3.org/TR/WCAG20-TECHS/slicenav.css
Frederick Hirsch
Doug Schepers
Arthur Barstow Some of the spec-specific stylesheets:
https://w3c.github.io/FileAPI/FileAPI.css
http://heycam.github.io/webidl/WebIDL.css

WebComponents has several: <https://github.com/w3c/webcomponents/tree/gh-pages/assets/styles>

Some specs include stylesheets directly in the source, f.ex:
https://raw.githubusercontent.com/w3c/IndexedDB/gh-pages/index.html

Some specs use JS:
https://github.com/slightlyoff/ServiceWorker/blob/master/spec/service_worker/index.html
Deborah Dahl None
Ilya Grigorik none
Gregg Kellogg Stylesheets are inlined in documents.
Paul Grosso See the previous answer for the XSLT used by the published XML. The (auto-generated) published HTML uses the standard W3C ones, e.g., http://www.w3.org/StyleSheets/TR/W3C-CR.css with perhaps a few overriding CSS styles.
Ted Guild NA
Norman Walsh http://www.w3.org/TR/xproc20/xproc.css
David Carlisle The generated HTML just uses standard rec track css stylesheets augmented by inline style block in the document head.
Michael Kay I guess you mean CSS here? The two HTML specs cited above include some local CSS style declarations modifying/supplementing the standard W3C CSS stylesheets. These have been used for many years and some of them may no longer be relevant. One change I recall was to use "softer" background colours for "diff" markup (new and changed text) as the original colours were found to be very harsh. I think we also made some changes to hyperlink rendition: the spec is very densely hyperlinked and to keep the text readable we needed the hyperlinks to be less intrusive. We also introduced a superscript notation for cross-spec hyperlinks within the family of specification.
Dave Cramer We don't have a IG-specific stylesheet; we sometimes add custom CSS to individual documents
Nick Doty We don't currently use WG-specific stylesheets.
François Daoust None, a few inline styles copied from HTML5 specs and that's about it.

### 5. Like

#### Details

Responder Like
Jim Melton They are conformant with PubRules, and our user community is experienced with and comfortable with them.
Chris Lilley For ED, we use generated content so that each testable assertion has a very visible flag to say whether it applies to User Agents, Authoring Tools, or File Format. We also have :target styling so that linking to a testable assertion hilights the exact text of the assertion, rather than just scrolling the viewport. An example
http://dev.w3.org/webfonts/WOFF2/spec/#conform-mustNotDuplicateTables
Nigel Megitt * IDL styles
* example styles
* todo section handling
* table handling
* bug registration box at top right
Michael Cooper Support readability by making inline elements with special meaning more visually distinct (e.g., role, state, and property references).

Calling out important features like notes and editorial notes (two distinct concepts btw).
Joshue O Connor We surveyed the group, and there wasn't a lot of positive commentary about the current style at all. One comment was 'Text is fairly readable and the overall structure is ok'.
Frederick Hirsch familiar
Doug Schepers
Arthur Barstow Here is what Joshua Bell, Editor of Indexed Database said about the changes he uses:

[[
<https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0787.html>

* Impose a maximum body width and center to improve readability on wide
windows +
* Increase body line spacing to ~1.45 to improve readability of dense text +
* Size of inline <code> text should match body text size +
* Reduce vertical space taken up by note/Issue blocks +
* Size of block code samples should be at least slightly closer to body size
* Introduce standard "switch" <dl> style

These were (of course!) inspired by some of the newer, more readable (IMHO)

The items marked with + above seem to already be addressed Fantasai's
http://dev.w3.org/csswg/css-text-3/ (i.e. I'm borrowing from the right
people...)

]]

Deborah Dahl They're simple and readable.
Ilya Grigorik Overall happy: reasonably readable on all screen sizes, good highlighting, classes for notes & errors.
Paul Grosso They work just fine, and have for years.
Ted Guild
Norman Walsh As long as the appearance is clear and consistent, I don't feel strongly about the specifics. Our WG-specific style is mostly about displaying function and step markup.
David Carlisle Suitable for document production pipeline from multiple sources, including rendering mathematical examples from tex fragments in the source, generating tables of data extracted from Unicode UCD files etc.

Presentation in multiple formats but notably with MathML and optional
mathjax rendering, tables of contents at different levels for main document and chapters. permalinks and constrained page width in editors draft.
Michael Kay They're not perfect but they work.
Dave Cramer I like how issues and notes work. Propdef tables and the associated DLs look great.
Nick Doty * clean display consistent with other specifications
* clear boxes for different class names/categories: issues, notes, examples
François Daoust The overall simplicity

### 6. Dislike

#### Details

Responder Dislike
Jim Melton Not anything, really.
Chris Lilley We delete them and make them an alternate style for the /TR pulications, so the spec isn't plastered with coloured stickers by default. However, browser support for alternate stylesheets blows.
Nigel Megitt That we had to make changes to ReSpec template.
Michael Cooper Difficult to tell heading level from style.
Joshue O Connor Mostly dull - lack of colour and élan. The current use of typography does not really enhance the reading experience or help the user better digest the sea of content that is WCAG.

Better use of colour to indicate code/examples/etc combined with better attention to kerning/leading and the overall typographic tone may help make reading our stuff more pleasant.

Also a general like of 'style' in our style - was mentioned.
Frederick Hirsch not sure
Doug Schepers We have a mild preference for shorter line widths, for ease of readability.
Arthur Barstow Here is what Joshua Bell, Editor of Indexed Database said:

[[
<https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0787.html>

Other notes:

* Current IDL blocks are pretty garish; I think they could use a little
*less* syntax highlighting.
* In dense algorithmic steps, the underlines on linked terms become fairly
cluttered since nearly every word is a reference. I suppose the
alternatives are color (?), style (italics is used for variables), or
weight (used for definitions). Ideas?
]]
Deborah Dahl A lot of manual work
Ilya Grigorik Nothing in particular.
Gregg Kellogg No good support for algorithmic steps. externalDFNs aren't styled to make them easier to see.
Paul Grosso Nothing.
Ted Guild
Norman Walsh
David Carlisle Tables of contents are internally a mess, should be redone as nested lists not paragraphs with forced space. (Present form was a compromise to work in IE5/Netscape 4....)

I (David C) dislike the unconstrained width of the page in the TR styles.
Michael Kay The sans-serif font is sometimes a problem, e.g. lack of distinction between upper-case I and lower-case ell. One can certainly envisage improvements, e.g. "hover" actions to show the definition of a defined term.
Dave Cramer I've found I generally need to write additional styles to handle tables other than things like propdev tables.
Nick Doty * a lot of boilerplate and space at the top before the contents of the document that readers need to see
* (previously) hard to help casual readers skip over different sections (like options, non-normative text, issue boxes, etc.)
François Daoust - Lack of clean separation between sections
- On narrow screens, examples and interfaces styles overflow their container. Not sure there is much that can be done there since these rows do not wrap
- On narrow screens, the left banner takes a lot of space on the left. This is particularly annoying when reading a spec on a mobile in portrait mode.
- In data tables, headers/borders are too strong/thick for our usage (mapping between event handlers and event handler event type)
- Extensive use of terms and references creates lots of underlines in some sections, particularly in algorithms.
- ReSpec includes a mechanism to display the list of terms defined in the spec in a pop-up window. Could a similar mechanism be useful in the /TR spec?
- Could there be a way to improve the layout of the terminology section that references terms defined in other specs so that it feels more "human friendly"?
- Algorithms are tough to read although that's arguably not a problem with styles.
- Probably more platform-specific, but the result looks weird on Internet Explorer for Mobile: text either appears as tiny (regular prose, examples) or normal (ToC, algorithms, notes). Viewport directive?

### 7. Complex style

Paste in URLs to any parts of your spec that are stylistically complex or tricky, and we should therefore be careful not to screw up.

#### Details

Responder Complex style
Jim Melton https://www.w3.org/XML/Group/qtspecs/specifications/xquery-31/html/xquery-31-diff.html

Diff markup using our styles can be tricky (especially when we have marked up diffs within diffs, such as a change to an inserted section or a deletion of part of a changed section). We think we've tamed the diff markup, but every now and again we discover some edge case that doesn't work quite right.

https://www.w3.org/XML/Group/qtspecs/specifications/xquery-31/html/xquery-31-diff.html#id-sequencetype-syntax

Our language grammar is defined using a very specific and customized XML vocabulary and generating HTML that displays the grammar (extended BNF) is very tricky, especially when generating multiple HTML documents from single sources.
Chris Lilley Nothing especially complex
Nigel Megitt We can probably adjust to changes.
Michael Cooper http://www.w3.org/TR/core-aam-1.1/#h-mapping_role_table has a table that can be presented in two ways, both of which we want to preserve.
Joshue O Connor http://www.w3.org/TR/WCAG20-TECHS/ARIA1.html
http://www.w3.org/TR/WCAG20-TECHS/Overview.html#contents

Frederick Hirsch views switching - toggle between tabs; Ability to have tabbed views for different representations (e.g. turtle, JSON-LD etc in Data Model, see end of http://www.w3.org/TR/2014/WD-annotation-model-20141211/#annotation )
Doug Schepers
Arthur Barstow The only feedback was from Joshua.
Deborah Dahl We don't really have anything like that.
Ilya Grigorik
Gregg Kellogg http://w3c.github.io/csvw/csv2json/#minimal-mode
http://www.w3.org/TR/csv2json/#example-tree-ops-ext (Show detailed table annotations button)
Paul Grosso Our specs rarely have particularly tricky parts.
Ted Guild
Norman Walsh Step summaries:

http://www.w3.org/TR/xproc20-steps/#c.http-request

and function declarations

http://www.w3.org/TR/xproc20/#f.step-available

are probably about as complex as we get.
David Carlisle
Any math examples eg

http://www.w3.org/Math/draft-spec/mathml.html#chapter3_id.3.2.5.8.1

any attribute table eg

http://www.w3.org/Math/draft-spec/mathml.html#chapter3_id.3.3.2.2

http://www.w3.org/Math/draft-spec/mathml.html#appendixa_parsing.rnc.strict
Michael Kay
At one point the XSLT spec had some pretty complex SVG diagrams, e.g. here
http://www.w3.org/TR/2010/WD-xslt-21-20100511/#streamability-choice-and-repetition
but there is only one remaining (and very simple) SVG diagram in the current spec.

Note the use of function signatures: https://www.w3.org/XML/Group/qtspecs/specifications/xslt-30/html/Overview-diff.html#func-json-to-xml

Examples:
https://www.w3.org/XML/Group/qtspecs/specifications/xslt-30/html/Overview-diff.html#json-to-xml-mapping

Syntax templates for elements:
https://www.w3.org/XML/Group/qtspecs/specifications/xslt-30/html/Overview-diff.html#xsl-for-each-group

Of course, all of these could be improved.
Dave Cramer We do tend to use lots of levels of heads (at least down to h5) and at least with Bikeshed we don't get a visual distinction between TOC entries for h4 and h5. See TOC at http://w3c.github.io/dpub-pagination/priorities.html
Nick Doty
François Daoust Nothing too complex or specific to this spec. Example of procedure:
http://w3c.github.io/presentation-api/#starting-a-presentation-session

### 8. Table style

The new styles will include rules for rendering data tables. These will be opt-in by class name, and rely heavily on good markup (use of THEAD, TBODY, COLGROUP, scope attributes, etc.). See Simple Example, Less Simple Example, and Extra-Complex Example. Paste in URLs to a sampling of any data tables you are using so that we can try to accommodate those in the styling, if practical.

#### Details

Responder Table style
Jim Melton https://www.w3.org/XML/Group/qtspecs/specifications/xquery-31/html/xquery-31-diff.html#id-sequencetype-syntax

Our documents display our language grammar using HTML tables, which leads to some interesting styling requirements.

https://www.w3.org/XML/Group/qtspecs/specifications/xquery-31/html/xquery-31-diff.html#id-sequencetype-subtype

This section of one of our documents contains a fairly simple table, but it is more complex than most of the tables we use.
Chris Lilley our tables are basic, but some are *huge*. We do :hover row hilighting to aid readability.
http://www.w3.org/TR/WOFF20ER/#appendixB

If the new style had column sorting or table collapsing we would certainly use that
Nigel Megitt https://github.com/w3c/webvtt/blob/master/webvtt.html#L3578
http://www.w3.org/TR/ttml-imsc1/#common-features
http://www.w3.org/TR/ttml1/#vocabulary-namespaces
Michael Cooper Same as above:

http://www.w3.org/TR/core-aam-1.1/#h-mapping_role_table has a table that can be presented in two ways, both of which we want to preserve.

The styles suggested look ok but the above specs probably wouldn't be able to opt into them for the most part. As long as they're opt-in that's ok.
Joshue O Connor http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-audio-desc-only.html
http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-text-presentation.html
http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-text-images.html
Frederick Hirsch not sure
Doug Schepers
Arthur Barstow I am not aware of any especially complex tables but some specs have a relatively large number of tables such as <https://w3c.github.io/DOM-Level-3-Events-key/>.
Deborah Dahl EMMA uses a lot of tables, but they aren't particularly complicated. http://www.w3.org/TR/2009/REC-emma-20090210/#s3.2 is an example.
Ilya Grigorik None.
Gregg Kellogg http://www.w3.org/TR/tabular-data-model/#bidirectionality-in-csv-files
http://www.w3.org/TR/tabular-data-model/#simple-example
http://www.w3.org/TR/csv2json/#datatypes
http://www.w3.org/TR/csv2json/#ex-trees-annotation
Paul Grosso We don't have a lot of tricky tables.
Ted Guild
Norman Walsh I'm perfectly happy to generate any table markup you like.
David Carlisle Attribute tables as noted before

http://www.w3.org/Math/draft-spec/mathml.html#chapter3_id.3.3.2.2

The operator dictionary

http://www.w3.org/Math/draft-spec/mathml.html#appendixc_oper-dict.entries-table

is a very large table (thousand or so lines) and uses sortable columns.(Currently using http://www.kryogenix.org/code/browser/sorttable/ but if a standard solution to sortable tables was offered it would be OK to switch.)

In entities spec:

Tables of math alphabets
http://www.w3.org/TR/xml-entity-names/bold.html

Tables of unicode ranges
http://www.w3.org/2003/entities/2007doc/026.html

As all the html markup is generated, changing the html markup and/or css classes here is not a problem as we can generate whatever is required for the new style. Assuming the new style is just applied to new documents. An earlier attempt at restyling was retrospectively
applied to existing documents in TR (and broke them completely)
Michael Kay In the XSLT spec:
https://www.w3.org/XML/Group/qtspecs/specifications/xslt-30/html/Overview-diff.html#func-json-to-xml

In the functions and operators spec, note the use of colour in the table here:
https://www.w3.org/XML/Group/qtspecs/specifications/xpath-functions-31/html/Overview.html#casting-from-primitive-to-primitive
(scroll down a bit).
Dave Cramer
Nick Doty We make sparse use of tables regarding "qualifiers" to indicate certain permitted uses of data. These tables are quite simple:
http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#qualifiers
François Daoust http://w3c.github.io/presentation-api/#event-handlers

### 9. CSS WG Style

The CSSWG has made a number of minor improvements to the existing spec styles, which we might just adopt wholesale. Please comment on what you like/dislike about these styles, as demonstrated in the CSS3 Text specification.

#### Details

Responder CSS WG Style
Jim Melton No opinion one way or the other.
per-section test suite summary
shorter measure and slightly looser line height for increased readability (both blocked by previous webmaster)
Nigel Megitt Likes:
* cleaner
* example styling
* syntax highlighting
* test marker box

Dislike:
* the test markers sit in the document a little randomly
Michael Cooper Do not like the narrow centered column of text. While I appreciate that wide lines are hard to read, it's jarring to have my browser set a certain size and yet have the rendering just have a bunch of unused whitespace. I've set my browser to the width that is most useful for me and the styles should presume that.

There are various colored sections that is not apparent what the different colors mean. The styles themselves are ok but without a "key" they raise questions that interrupt reading.

Multiline figure captions that are centered are hard to read.

I did not check the WCAG luminosity contrast of all color combinations. On quick sample they look good overall, but the final proposed TR stylesheet will need a careful check on this front to be sure.
Joshue O Connor Positive feedback for this - I like the way colour is used for notes and examples etc! but there are some colour contrast issues that need to be fixed. Using a colour for text headings that is only a few shades darker than the background for example will be problematic (see the 'Example 4' colour) and "Info Needed".

EXAMPLES:
Foreground: #AB9D23 - Background: #FCF9EA

The contrast ratio is: 2.62:1

INFO NEEDED:
Foreground: #FC7236 - Background: #FEEAC1

The contrast ratio is: 2.34:1

Apart from this, the view is positive.

A working group member created <a href="http://www.d.umn.edu/~lcarlson/wcagwg/tests/css3_spec_color.html" target="_blank">colour contrast test of the CSS3 spec></a> that you may find useful.
Frederick Hirsch not sure
Doug Schepers
Arthur Barstow No comment.
Ilya Grigorik Looks great.. and looks like a very small delta from what we use today.
Gregg Kellogg For my part, I think they look good.
Paul Grosso No comment.
Ted Guild
Norman Walsh They look fine to me. Consistency FTW.
David Carlisle Generally in favour of the direction taken there as long as there is some flexibility, mathml has a lot of examples and tables for example that may necessitate a slightly wider body width, we'll see...
Michael Kay Looks nice, but of course one can't tell how it work for a different spec without trying it.
Dave Cramer The people I've talked to in DPUB are in general very happy with how the CSS specs look, and think they're much cooler than other W3C specs :)
Nick Doty It seems like there's a lot of vertical white space, especially at the top. Being able to quickly read the content of a document is important.
François Daoust - Good separation between sections
- Underlines seem to have been softened a bit, improving readability in sections that use links a lot.
- It's very good to be able to quickly navigate to the fragment corresponding to the underlying section or definition.
- Result looks good on Internet Explorer for Mobile with a couple of exceptions: numbers in the ToC and left columns in data tables are tiny for some reason (no viewport directive?)

### 10. Anything else?

Is there anything else we should consider?

#### Details

Responder Anything else?
Jim Melton The XML Query WG MAY be nearing the end of its life, which would obviate the need, and likelihood, of it learning to use new styles. In any case, whether or not the WG closes, what we have ain't broke and we see no need to "fix" it.
Chris Lilley not really
Nigel Megitt N/A
Michael Cooper Consistency with W3C recognized TR style will be important, so documents are still recognized as W3C TR documents.

Not over-developing styles, that make it harder for WGs to provide custom features when needed.

On the other hand, providing styles for common usages like notes and examples is very helpful so, lacking a reason to do otherwise, WGs can choose to use a recognized W3C-wide approach.

Documenting the available styles and / or a sample page showing them all for editors will be important. Also need to indicate which must not be overridden or ignored (e.g., heading styles), and which may be (e.g., note styles).
Joshue O Connor The new design needs to conform at WCAG Level AA.
Beyond that - we are very happy to see this work and look forward to seeing a fresh, smart style.
Frederick Hirsch ability to make specs with narrower text region, wider margins, to enhance readability or to enable annotations in the margin area

eventually to allow general application of annotations to documents
Doug Schepers We don't have any specific requirements, though if page width is narrower, it should accommodate images. In our spec, our widest image is 600px:

http://www.w3.org/TR/2015/REC-pointerevents-20150224/tiltX_600px.png
Arthur Barstow Joshua Bell is the only Editor that provided feedback and we offer it "on behalf of WebApps" <https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0787.html>.
Deborah Dahl We would like to be able to include animations.
We'd like to have a paginated version of the specs like PDF.
It would be nice for users to be able to collapse examples and informative parts of the spec.
Ilya Grigorik
Gregg Kellogg
Paul Grosso What's most important to us is to be able to continue to create our specs using the XMLspec DTD and publish both the XML and auto-generated HTML. We consider the XML the authoritative version.
Ted Guild I discussed with the other Team Contact and WG Chair and we are fine to defer to CSSWG and welcome their expertise in improving readability.
Norman Walsh
David Carlisle Math rendering...
Michael Kay Not that comes to mind...
Dave Cramer I'm not sure this is a style issue, but in general I've wondered about how to handle numbering figures, especially when they may be inside an example. Publications from this group often involve relatively complex examples with both code and sample renderings.
Nick Doty We had previously deployed CSS and JavaScript in order to collapse/hide non-normative sections and issue blocks so that casual readers could more easily see just normative sections. That code was not maintained and is no longer necessary, but that kind of functionality (different views for different users, with the ability to drill down) may be useful in a variety of contexts.
François Daoust

## More details on responses

• Jim Melton: last responded on 28, May 2015 at 00:10 (UTC)
• Chris Lilley: last responded on 4, June 2015 at 20:46 (UTC)
• Nigel Megitt: last responded on 5, June 2015 at 13:08 (UTC)
• Michael Cooper: last responded on 9, June 2015 at 20:41 (UTC)
• Joshue O Connor: last responded on 10, June 2015 at 16:56 (UTC)
• Frederick Hirsch: last responded on 10, June 2015 at 23:47 (UTC)
• Doug Schepers: last responded on 29, June 2015 at 19:01 (UTC)
• Arthur Barstow: last responded on 17, July 2015 at 22:17 (UTC)
• Deborah Dahl: last responded on 28, July 2015 at 21:36 (UTC)
• Ilya Grigorik: last responded on 28, July 2015 at 21:56 (UTC)
• Gregg Kellogg: last responded on 28, July 2015 at 23:05 (UTC)
• Paul Grosso: last responded on 29, July 2015 at 14:34 (UTC)
• Ted Guild: last responded on 29, July 2015 at 16:11 (UTC)
• Norman Walsh: last responded on 30, July 2015 at 22:19 (UTC)
• David Carlisle: last responded on 31, July 2015 at 13:00 (UTC)
• Michael Kay: last responded on 1, August 2015 at 16:04 (UTC)
• Dave Cramer: last responded on 4, August 2015 at 15:41 (UTC)
• Nick Doty: last responded on 10, August 2015 at 22:50 (UTC)
• François Daoust: last responded on 1, September 2015 at 07:37 (UTC)