Hi, all,
Caveat, I am only a participant in the W3C group being discussed and
am not its spokesman. So please take what I say with a grain of salt.
@ Sherwood Botsford: "The only way I've been able to figure out how to
work with this would
be as follows:
"Every MD implementation would have to have two behaviours, set either
by a command line flag, a configuration file, or a preference if used
with a GUI. One behaviour would be the individual behavior so that
the followers of that implementation wouldn't be left in the lurch.
One would be the standard behavior."
I think the behavioral switch could be handled automatically if the
standardized version has its its own doctype declaration and profile
header. If the doc has the doctype declaration, then process the doc
as the standardized version of markdown; if not, then apply the
implementation's unique default processing.
@ Fletcher T. Penney: Although the working group is very new, there
seems to be some preliminary consensus (of varying degrees) emerging
on some issues, but it all needs input from implementers:
1. Outreach to implementers for participation.
2. Aiming for a core profile of markdown that is near universal along
with a corresponding schema.
3. Inventorying MD extensions used in the most popular MD
implementations and exploring what might be done to define one or more
profiles that superset the core profile. Related, see the table of
implementations under construction at
<http://www.w3.org/community/markdown/wiki/MarkdownImplementations>.
4. Target XHTML 1.1 plus a sprinkling of W3C Aria accessibility
attributes as the output format for transformations. See this thread
for more detail.
<http://lists.w3.org/Archives/Public/public-markdown/2012Nov/0094.html>.
(I've suggested "Accessible Markdown" as the name for the project
and
its deliverables. Bridging the A11Y gap is in my view a major
incentive for MD implementers to participate in the working group and
to implement its deliverables. This is a legal requirement for web
sites at least in the U.S. and E.U. Although enforcement has been lax
so far, there is no guarantee that enforcement won't be ramped up
later.)
No feedback yet, but I've suggested borrowing heavily from the W3C
Compound Document by Reference
Framework conformance requirements for layered profiles.
<http://www.w3.org/TR/2007/CR-CDR-20070718/#conformance>. E.g. "A
conformant user agent of a superset profile specification must process
subset profile content as if it were the superset profile content."
@ Aristotle Pagaltzis: "Keep it conservative: stick to existing
implicit consensus, concentrate on working out the edge cases and
formalising. That is what will provide value. Anyone who is after new
features can implement them independently and if a feature works out
it will then be heard of anyway. "
This is exactly where we seem to be aiming except for the
accessibility attributes in the output format.
> The exception to that is support for the one feature that is likely to be
added which has no
> direct support in HTML, precisely because of that lack of direct
expressibility in HTML,
> namely footnotes. (Or has HTML 5 provided a solution here (and one that
isn?t still
> evolving)?) "
Kinda'/Sorta'. HTML 5 has the "aside" element that was
originally
stuck in with footnotes in mind.
<http://dev.w3.org/html5/spec/single-page.html#the-aside-element>. But
it's really just a container that can be positioned on the page with
CSS. No footnote/endnote-specific markup. (I'll omit my long rant
about browser developers and their mindset when it comes to HTML spec
footnote proposals. Let it suffice to observe that repurposing of
content never enters their minds when the topic of footnotes comes
up.)
I'll pass along your suggestion regarding a test suite.
Best regards,
Paul E. "Marbux" Merrell, J.D.