https://www.w3.org/2002/09/wbs/1/tr-design-survey-2015/results

=====XML Query Working Group =====
Processors:
  none
Style sheets:
  none
Sample specs:
  https://www.w3.org/TR/xquery-31/
  https://www.w3.org/TR/xpath-functions-31/
Current style likes:
  Familiarity
Current style dislikes:
  Not anything, really.
CSSWG style opinions:
  No opinion one way or the other.
Other comments:
  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. 

=====WebFonts =====
Processors:
  none
Style sheets:
  http://dev.w3.org/webfonts/WOFF2/spec/conform.css
Sample specs:
  http://www.w3.org/TR/WOFF20ER/ (TR, vanilla W3C style)
  http://www.w3.org/TR/WOFF2/ (TR, vanilla)
  http://dev.w3.org/webfonts/WOFF2/spec/ (ED, slightly different styling)
Current style likes:
  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
Current style dislikes:
  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.
CSSWG style opinions:
  paragraph permalink symbol
  per-section test suite summary
  shorter measure and slightly looser line height for increased readability
  (both blocked by previous webmaster)
Other comments:
  not really
=====Timed Text Working Group =====
Processors:
  ReSpec, XMLSpec
Style sheets:
  ReSpec +
  https://dvcs.w3.org/hg/ttml/file/tip/ttml1/spec/xmlspec-ttml1.xsl
Sample specs:
  http://dev.w3.org/html5/webvtt/ (ED)
  http://www.w3.org/TR/webvtt1/ (FPWD)
  http://www.w3.org/TR/ttml-imsc1/
  http://www.w3.org/TR/ttml1/
Current style likes:
  * IDL styles
  * example styles
  * todo section handling
  * table handling
  * bug registration box at top right
Current style dislikes:
  That we had to make changes to ReSpec template.
CSSWG style opinions:
  Likes:
  * cleaner
  * links on sections
  * example styling
  * syntax highlighting
  * test marker box
  
  Dislike:
  * the test markers sit in the document a little randomly
Other comments:
  N/A

=====Protocols and Formats =====
Processors:
  ReSpec
Style sheets:
  ReSpec +
  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
Sample specs:
  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/
Current style likes:
  * Support readability by making inline elements with special meaning more
    visually distinct (e.g., role, state, and property references).
  * Support readability by increasing spacing in certain situations,
    particularly padding.
  * Calling out important features like notes and editorial notes
    (two distinct concepts btw).
Current style dislikes:
  Difficult to tell heading level from style.
CSSWG style opinions:
  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.

  Permalinks to the left of the heading are distracting. They should be to the
  right of the heading, after the heading itself in the reading order.

  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.
Other comments:
  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).

=====WCAG =====
Processors:
  custom extension to XMLSpec
Style sheets:
  http://www.w3.org/TR/UNDERSTANDING-WCAG20/additional.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/additional.css
  http://www.w3.org/TR/WCAG20-TECHS/diffs.css
  http://www.w3.org/TR/WCAG20-TECHS/slicenav.css
Sample specs:
  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
Current style likes:
  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'.
Current style dislikes:
  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.

CSSWG style opinions:
  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 "colour contrast test of the CSS3 spec"
  http://www.d.umn.edu/~lcarlson/wcagwg/tests/css3_spec_color.html
Other comments:
  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.

=====Web Annotation WG =====
Processors:
  ReSpec
Style sheets:
  ReSpec
Sample specs:
  http://www.w3.org/TR/2014/WD-annotation-model-20141211/ (FPWD)
  http://w3c.github.io/web-annotation/api/rangefinder/ (ED)
  http://w3c.github.io/web-annotation/protocol/wd/ (ED)
Current style likes:
  Familiarity
Current style dislikes:
  not sure
CSSWG style opinions:
  not sure
Other comments:
  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

=====Pointer Events WG =====
Processors:
  ReSpec
Style sheets:
  ReSpec
Sample specs:
  http://www.w3.org/TR/2015/REC-pointerevents-20150224/
Current style likes:
  [nothing mentioned]
Current style dislikes:
  We have a mild preference for shorter line widths, for ease of readability.
CSSWG style opinions:
  [nothing mentioned]
Other comments:
  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

=====Web Applications =====
Processors:
  ReSpec
  custom XML for WebIDL
Style sheets:
  ReSpec +
  https://w3c.github.io/FileAPI/FileAPI.css
  http://heycam.github.io/webidl/WebIDL.css
  https://github.com/w3c/webcomponents/tree/gh-pages/assets/styles
  https://raw.githubusercontent.com/w3c/IndexedDB/gh-pages/index.html
  http://slightlyoff.github.io/ServiceWorker/spec/assets/scripts/capture.js
Sample specs:
  See https://www.w3.org/2008/webapps/wiki/PubStatus
  * http://slightlyoff.github.io/ServiceWorker/spec/service_worker/
  * http://w3c.github.io/webcomponents/spec/custom/
    view-source:http://w3c.github.io/webcomponents/spec/shadow/
  * https://w3c.github.io/websockets/
    https://w3c.github.io/webstorage/
  * https://w3c.github.io/FileAPI/
  * http://heycam.github.io/webidl/
Current style likes:
  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)
  specs styles floating about.
  
  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...)
  ]]
Current style dislikes:
  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?
  ]]
CSSWG style opinions:
  No comment.
Other comments:
  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>.
=====Multimodal Interaction =====
Processors:
  none
Style sheets:
  none
Sample specs:
  http://www.w3.org/TR/emma/
  http://www.w3.org/TR/mmi-mc-discovery/
Current style likes:
  They're simple and readable.
Current style dislikes:
  A lot of manual work

CSSWG style opinions:
  No comments.

Other comments:

=====Webperf =====
Processors:
  ReSpec
Style sheets:
  ReSpec
Sample specs:
  http://w3c.github.io/performance-timeline/
  http://w3c.github.io/preload/
Current style likes:
  Overall happy: reasonably readable on all screen sizes, good highlighting,
  classes for notes & errors.
Current style dislikes:
  Nothing in particular

CSSWG style opinions:
  Looks great.. and looks like a very small delta from what we use today.

Other comments:

=====CSV on the Web Working Group =====
Processors:
  ReSpec
Style sheets:
  ReSpec +
  Inlined styling for ol.algorithm
Sample specs:
  http://www.w3.org/TR/tabular-data-model/ http://w3c.github.io/csvw/syntax/
  http://www.w3.org/TR/tabular-metadata/ http://w3c.github.io/csvw/metadata/
  http://www.w3.org/TR/csv2json/ http://w3c.github.io/csvw/csv2json/
Current style likes:
  Easily readable.
Current style dislikes:
  No good support for algorithmic steps. externalDFNs aren't styled to make
  them easier to see.
CSSWG style opinions:
  For my part, I think they look good.

Other comments:

=====XML Core WG =====
Processors:
  XMLSpec
Style sheets:
  Inlined styling for example code blocks.
Sample specs:
  http://www.w3.org/TR/2015/CR-xinclude-11-20150630/
  http://www.w3.org/TR/2008/REC-xml-20081126/
Current style likes:
  They work just fine, and have for years. 
Current style dislikes:
  Nothing.
CSSWG style opinions:
  No comment.

Other comments:
  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.

=====Automotive =====
Processors:
  ReSpec
Style sheets:
  none
Sample specs:
  http://www.w3.org/TR/vehicle-information-api/
  http://www.w3.org/TR/vehicle-data/
Current style likes:
  [nothing mentioned]
Current style dislikes:
  [nothing mentioned]
CSSWG style opinions:
  [nothing mentioned]

Other comments:
  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. 

=====XML Processing Model =====
Processors:
  XSLT over DocBook
Style sheets:
  http://www.w3.org/TR/xproc20/xproc.css
Sample specs:
  http://www.w3.org/TR/xproc-v2-req/
  http://www.w3.org/TR/xproc20/
  http://www.w3.org/TR/xproc20-steps/
Current style likes:
  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.
Current style dislikes:
  [nothing mentioned]
CSSWG style opinions:
  They look fine to me. Consistency FTW.

Other comments:

=====Math WG  =====
Processors:
  customized XMLSpec
Style sheets:
  Inlined styling for 
    * chapter TOCs and navigation
    * example code blocks
    * invalid example code blocks
    * attribute definition tables
    * element definition tables
Sample specs:
  http://www.w3.org/TR/MathML3/ (TR)
  http://www.w3.org/Math/draft-spec/mathml.html (ED)
  * 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.
  http://www.w3.org/TR/xml-entity-names/ (TR)
  http://www.w3.org/2003/entities/2007doc/ (ED)
Current style likes:
  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. 
Current style dislikes:
  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.
CSSWG style opinions:
  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...

Other comments:
  Math rendering... 

=====XSL WG =====
Processors:
  customized XMLSpec
Style sheets:
  
Sample specs:
  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

Current style notes:
  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.
Current style likes:
  They're not perfect but they work.
Current style dislikes:
  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.
CSSWG style opinions:
  Looks nice, but of course one can't tell how it work for a different spec without trying it.
Other comments:
  Not that comes to mind...

=====Digital Publishing Interest Group =====
Processors:
  Bikeshed, ReSpec
Style sheets:
  none
Sample specs:
  http://w3c.github.io/dpub-pagination/priorities.html
  http://w3c.github.io/dpub-pagination/index.html
  http://w3c.github.io/aria/aria/dpub.html
  http://www.w3.org/TR/dpub-metadata/
Current style likes:
  I like how issues and notes work. Propdef tables and the associated DLs look great.
Current style dislikes:
  I've found I generally need to write additional styles to handle tables
  other than things like propdef tables.
CSSWG style opinions:
  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 :)
Other comments:
  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. 

=====Tracking Protection Working Group =====
Processors:
  ReSpec
Style sheets:
  Inlined styling for
    * WebIDL
Sample specs:
  http://www.w3.org/TR/tracking-dnt/
  http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html
Current style likes:
  * clean display consistent with other specifications
  * clear boxes for different class names/categories: issues, notes, examples
Current style dislikes:
  * 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.)
CSSWG style opinions:
  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.
Other comments:
  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.

=====Second Screen Working Group =====
Processors:
  ReSpec
Style sheets:
  ReSpec
Sample specs:
  http://w3c.github.io/presentation-api/
Current style likes:
  The overall simplicity
Current style dislikes:
  - 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?
CSSWG style opinions:
  - 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?)

Other comments:

===== CSS Working Group =====

Processors:
  Bikeshed
Style sheets:
  http://dev.w3.org/csswg/default.css   
Sample specs:
  http://www.w3.org/TR/css3-text/
  http://drafts.csswg.org/css-text/
Current style likes:
  [nothing mentioned]
Current style dislikes:
  Not being able to use max-width on /TR specs
CSSWG style opinions:
  We like it, duh.
Other comments:
  glazou says he has no comments, but also says he wants side-by-side ToC

===== Geolocation =====

Processors:
  ReSpec
Style sheets:
  ReSpec
Sample specs:
  http://www.w3.org/TR/css3-text/
  http://drafts.csswg.org/css-text/
Tricky sections:
  http://www.w3.org/TR/orientation-event/#deviceorientation 
  http://www.w3.org/TR/orientation-event/#worked-example
Current style likes:
  It's pretty readable and establishes a fairly clear visual hierarchy.
  Basically it's fine.
Current style dislikes:
  It often does not work well on mobile devices.
  -> position:fixed banners for e.g. "Editor's Draft" take up too much
     precious screen space, all the time
  -> Too much whitespace around the edges of the document, shortens
    visible line length
  -> Too-large indentation of lists squishes content to the right side
     of the screen
  -> The W3C logo does not look sharp on high-res screens
  -> WebIDL and code samples do not wrap smartly and cause horizontal scrolling
  -> Indentation of WebIDL blocks makes this worse, maybe it does not need
    indentation as it has other visual markers as well
  -> Longer headings tend to wrap to multiple lines
  I looked at this on a Nexus 5 with Chrome, this spec:
    http://w3c.github.io/push-api/ .
  Probably not the ideal device for looking at specs, but why make it harder
  than necessary, right?
CSSWG style opinions:
  No comments at this time
Other comments:
  Response from Michael van Ouwerkerk on public-geolocation

===== Device APIs =====

Processors:
  ReSpec
Style sheets:
  ReSpec
Sample specs:
  http://www.w3.org/TR/2015/REC-vibration-20150210/
  http://www.w3.org/TR/2014/CR-battery-status-20141209/
  http://w3c.github.io/sensors/
Tricky sections:
  WebIDL display
Current style likes:
  highlighting of notes and example blocks within spec, clear (rely on ReSpec)
  familiar with format
Current style dislikes:
  Status section could be clearer for different sections
  print version can cut off text that goes off page
CSSWG style opinions:
  not familiar with this
Other comments:
  Need to make sure styles work and are incorporated with ReSpec.
  Some old specs need to be maintained, easier to minimize changes if old
  styles are still available etc to minimize differences.
  Need way to specify 'use legacy', perhaps by year. (e.g. generate diff
  without changes due to styling...)

  Response sent by Frederick Hirsch on public-device-apis

===== XML Security WG =====

Processors:
  ReSpec (original version)
Style sheets:
  ReSpec (original version)
  http://www.w3.org/2008/xmlsec/Drafts/best-practices/practiceStyle.css
Sample specs:
  http://www.w3.org/TR/2013/REC-xmldsig-core1-20130411/
  http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/
  http://www.w3.org/TR/2013/NOTE-xmldsig-bestpractices-20130411/
  http://www.w3.org/TR/2013/NOTE-xmldsig-core2-20130411/
Tricky sections:
  We rely on ReSpec, but code sample and example displays are important,
  as well as best practices formatting.
Current style likes:
  Familiarity, ease of use via ReSpec.
  We made special effort to make best practices easy to author and display
  clearly, though combination of ReSpec additions and styling.
Current style dislikes:
  Status section could be clearer for different sections
  print version can cut off text that goes off page
CSSWG style opinions:
  not familiar with this
Other comments:
  Need to make sure  new styles work and are incorporated with ReSpec.
  Some old specs need to be maintained, easier to minimize changes if old styles are still available etc to minimize differences.
  Need way to specify 'use legacy', perhaps by year. (e.g. generate diff without changes due to styling...)
  e.g. when updating a spec that is a few years old, do not want any styles to change, so that intended changes are obvious.
  Response sent by Frederick Hirsch on public-xmlsec

===== Miscellaneous Feedback =====

Brad Hill:
  Well, to the extent that links for css, logos etc are generated they should
  be protocol-responsive, relative, or default to https to avoid mixed content
  blocking.