W3C home > Mailing lists > Public > public-html@w3.org > March 2015

Re: DPUB module comments

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Tue, 31 Mar 2015 10:49:26 -0500
To: Matt Garrish <matt.garrish@bell.net>, public-dpub-aria@w3.org
Cc: "Michael Cooper" <cooper@w3.org>, "James Craig" <jcraig@apple.com>, Matthew King <mattking@us.ibm.com>, mgylling@idpf.org, "HTMLWG WG" <public-html@w3.org>, "W3C WAI Protocols & Formats" <public-pfwg@w3.org>, tsiegman@wiley.com
Message-ID: <OFB0D49D4C.A0FF8E0E-ON86257E19.005687B9-86257E19.0056EC41@us.ibm.com>

Folks,

I was wondering why I was not seeing comments. There is a public-dpub-aria
list where comments should go. The task force did not send out for comments
to the HTML working group.

Please send comments there.

It was resolved at the face to face meeting that we would not have
hyphenated pseudo namespace roles for DPUB as there would be tremendous
pushback by the publishing industry. This was conveyed to us by members of
the dpub interest group.

That said, the dpub-aria task force has been avoiding the use of hyphens
should we require them in the future. James's point is well taken.

Rich


Rich Schwerdtfeger



From:	Matt Garrish <matt.garrish@bell.net>
To:	"James Craig" <jcraig@apple.com>
Cc:	Matthew King/Fishkill/IBM@IBMUS, "Michael Cooper"
            <cooper@w3.org>, <mgylling@idpf.org>, "HTMLWG WG"
            <public-html@w3.org>, "W3C WAI Protocols & Formats"
            <public-pfwg@w3.org>, <tsiegman@wiley.com>
Date:	03/17/2015 08:38 AM
Subject:	Re: DPUB module comments



> Might DPUB define this as an id?
> <nav id="landmarks">

It'll be hit and miss whether an approach like that could work. Maybe for
the landmarks since in EPUB it's a component of the navigation document,
but
there aren't that many niche cases.

What I find problematic is that pinning semantics to IDs ultimately
intrudes
into the authoring sphere, and tries to layer meaning where it wasn't
intended. Did the author want to identify a structure, or did they just
happen to use an ID that matches a specification requirement they may not
have been aware of? That's why we have the epub:type attribute.

Publishers are typically also using their own identification systems for
content (think CMS and content aggregation), so pushing simple ID naming
conventions is going to prove problematic, as it forces the content
creators
to fall back on the kinds of models (epub:type) that we're trying to move
away from.

And it will lead to conflicts. A work as a whole might have a table of
contents, but then every section within it might also have a table of
contents at the start. Now you're forced to break your content up into
separate documents to avoid naming conflicts, even if it's not what you
want.

But to try and make a long story shorter, it was discussed and agreed at
the
last call that the name "landmarks" is problematic, so the ball is back in
Markus, Tzviya and my court to fix that role. At the very least, that name
won't be in the final vocabulary list. And hopefully we'll have a
definition
that doesn't sound so much like a generic nav.

Matt




graycol.gif
(image/gif attachment: graycol.gif)

Received on Tuesday, 31 March 2015 15:49:59 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:46:12 UTC