From shaunm at gnome.org Fri Nov 1 18:02:33 2013 From: shaunm at gnome.org (Shaun McCance) Date: Fri, 01 Nov 2013 18:02:33 -0400 Subject: MEP template Message-ID: <1383343353.30249.0.camel@recto> Hi folks, I've attached a simple tmpl file for MEPs you can use with yelp-new. -- Shaun -------------- next part -------------- @NAME@ @EMAIL@ @YEAR@ @TITLE@ MEP-XXXX: @TITLE@ Describe the intended functionality in one sentence. MEP-XXXX @TITLE@

This page outlines...

Background
Proposal
Examples
Accessibility
Internationalization
Alternatives
Compatibility and Fallback
Comparison to Other Formats
From shaunm at gnome.org Sat Nov 2 14:18:18 2013 From: shaunm at gnome.org (Shaun McCance) Date: Sat, 02 Nov 2013 14:18:18 -0400 Subject: Conditionals 1.0 Message-ID: <1383416298.2998.10.camel@recto> Hi all, The Conditionals 1.0 spec has been in widespread use for a while, and there don't seem to be any major problems with it. I'd like to get it marked final soon. I know a number of people have more features they'd like from Conditionals. We can address those in a 1.1 after 1.0 is done. Here's what you can do: 1) Review the specification here: http://projectmallard.org/if/1.0/ Point out any problems you find. 2) Validate your pages against the Conditionals schema. By default, the Mallard schema just lets any extension stuff through without actually checking it. To actually validate your Conditionals, add this version attribute to your page elements: version="1.0 if/1.0" yelp-check recognizes the version attribute and does schema merging. yelp-check validate *.page If you want to be sure you've caught all the pages, you can try using strict validation in yelp-check, like so: yelp-check validate --strict *.page This turns off the blanket pass given to unknown extensions. However, this is likely to choke on other extensions you're using. If you're using UI expanders, you can add "ui/1.0" to the version string. For experimental or other extensions, the only way to let them through strict validation is to use the --allow feature in yelp-tools master, which unfortunately depends on an unmerged libxml2 patch. If you are seriously adventurous, here's the libxml2 patch: https://bugzilla.gnome.org/show_bug.cgi?id=710744 And here's the command I now use when validating: yelp-check validate --strict \ --allow http://www.w3.org/2005/11/its \ --allow http://www.w3.org/1999/xlink \ --allow http://projectmallard.org/experimental/ \ --allow http://projectmallard.org/experimental/ui/ \ *.page -- Shaun From shaunm at gnome.org Thu Nov 21 08:48:50 2013 From: shaunm at gnome.org (Shaun McCance) Date: Thu, 21 Nov 2013 08:48:50 -0500 Subject: MEP: The role Attribute on the links Element Message-ID: <1385041730.2998.198.camel@recto> Earlier this year, I proposed adding the role attribute to the links element to allow users to explicitly specify the link title role to use for those links: http://projectmallard.org/pipermail/mallard-list/2013-July/000167.html Attached is MEP. Here's the synopsis: Background ========== Mallard allows you to have multiple titles in an info element. These are used for different purposes, specified by the type attribute. One of those types is link titles. Link titles can also take a role attribute, which gets used in two ways: * Inline link elements can specify the title to use for link text with the role attribute on the link element. * Automatic links automatically use a role. For example, topic links will use (as a first pick) a link title with role="topic". Sometimes, however, you want to use different titles in one place where you use automatic links than in another. For example, if a topic is in two guides, and one of the guides uses thumbnails to display its topic links, that guide might want to use shorter titles than a guide that uses a standard list. Proposal ======== This page proposes allowing an optional role attribute on the links element. In Mallard 1.0, automatic links created from a links element (or implicitly) use a role by default to look up a link title for link text. For example, topic links will use link titles with the role topic by default. The general process for most types of links is: 1. Use the link title with the correct role attribute for this type of links element, if available. 2. Use the link title without a role attribute, if available. 3. Use the primary title. This page proposes keeping the default role for each links type and the general procedure above, but adding a step at the beginning, such that the procedure becomes: 1. If the links element has a role attribute, use the link title with a matching role attribute, if available. 2. Use the link title with the correct role attribute for this type of links element, if available. 3. Use the link title without a role attribute, if available. 4. Use the primary title. -------------- next part -------------- A non-text attachment was scrubbed... Name: mep-links-role.page Type: text/x-mallard-page+xml Size: 4683 bytes Desc: not available URL: