w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
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.
19 answers have been received.
Jump to results for question:
- Group
- Sample(s)
- Specification Processor(s)
- Group style sheet(s)
- Like
- Dislike
- Complex style
- Table style
- CSS WG Style
- Anything else?
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)
Paste in URLs to a representative sample (1-3 links) of your specs. If styling differs substantially between /TR and your editor's drafts, please link to both versions.
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/> <view-source:http://w3c.github.io/webcomponents/spec/shadow/> 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/ http://w3c.github.io/preload/ |
| Gregg Kellogg | 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/ |
| 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 http://www.w3.org/TR/dpub-metadata/ |
| 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 |
| Joshue O'Connor | 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 |
| 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
What do you like about your current styles?
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). Support readability by increasing spacing in certain situations, particularly padding. 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) 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...) ]] |
| Deborah Dahl | They're simple and readable. |
| Ilya Grigorik | Overall happy: reasonably readable on all screen sizes, good highlighting, classes for notes & errors. |
| Gregg Kellogg | Easily readable. |
| 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
What do you dislike about your current styles?
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. http://www.w3.org/TR/wai-aria-1.1/#alert tables have both row and column headers that are meaningful. |
| 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 hyperlinked RelaxNG grammars eg 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. http://www.w3.org/TR/wai-aria-1.1/#alert tables have both row and column headers that are meaningful. 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/tabular-data-model/#using-a-metadata-file 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. |
| Chris Lilley | paragraph permalink symbol per-section test suite summary shorter measure and slightly looser line height for increased readability (both blocked by previous webmaster) |
| Nigel Megitt | Likes: * cleaner * links on sections * 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. 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. |
| 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. |
| Deborah Dahl | no comments |
| 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)
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project