W3C WBS Home

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:

  1. Group
  2. Sample(s)
  3. Specification Processor(s)
  4. Group style sheet(s)
  5. Like
  6. Dislike
  7. Complex style
  8. Table style
  9. CSS WG Style
  10. Anything else?

1. Group

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


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.


Responder Sample(s)
Jim Melton https://www.w3.org/TR/xquery-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:




(styling the same on ED and /TR)



(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
Joshue O Connor http://www.w3.org/TR/WCAG20/

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:

Web Components specs:

The APIs that were originally part of HTML5, f.ex.:



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/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/
Ted Guild http://www.w3.org/TR/vehicle-information-api/
Norman Walsh http://www.w3.org/TR/xproc-v2-req/
David Carlisle

Editors draft

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

Editors draft

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

3. Specification Processor(s)

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


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
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.


Responder Group style sheet(s)
Jim Melton http://www.w3.org/StyleSheets/TR/W3C-WD.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
Joshue O Connor http://www.w3.org/TR/UNDERSTANDING-WCAG20/additional.css
Frederick Hirsch
Doug Schepers
Arthur Barstow Some of the spec-specific stylesheets:

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

Some specs include stylesheets directly in the source, f.ex:

Some specs use JS:
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?


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
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:


* 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


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?


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:


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.


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.


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

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:


and function declarations


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


any attribute table eg


hyperlinked RelaxNG grammars eg

Michael Kay
At one point the XSLT spec had some pretty complex SVG diagrams, e.g. here
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


Syntax templates for elements:

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:

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.


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.


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.

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
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
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
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


The operator dictionary


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

Tables of unicode ranges

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:

In the functions and operators spec, note the use of colour in the table here:
(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:
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.


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

* 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".

Foreground: #AB9D23 - Background: #FCF9EA

The contrast ratio is: 2.62:1

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?


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:

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

Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire

Maintained by Laurent Carcone, from a development by Dominique Hazaël-Massieux (dom@w3.org) on an original design by Michael Sperberg-McQueen $Id: showv.php3,v 1.135 2017/06/02 08:50:36 carcone Exp $. Please send bug reports and request for enhancements to lcarcone@w3.org with w3t-sys@w3.org copied (if your mail client supports it, send mail directly to the right persons)