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...
BackgroundProposalExamplesAccessibilityInternationalizationAlternativesCompatibility and FallbackComparison 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: