W3C home > Mailing lists > Public > public-digipub-ig@w3.org > August 2015

RE: aria-describedat - Elsevier

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Mon, 24 Aug 2015 16:43:50 -0500
To: Paul Topping <pault@dessci.com>
Cc: "White, Jason J" <jjwhite@ets.org>, "DPUB mailing list (public-digipub-ig@w3.org)" <public-digipub-ig@w3.org>, PF <public-pfwg@w3.org>, "Gies, Edward M. (ELS-DAY)" <Ted.Gies@elsevier.com>, "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com>
Message-ID: <OFE1CFADC8.E63348FE-ON86257EAB.0076FA24-86257EAB.00775F28@us.ibm.com>
That makes total sense.

I think tying visualization of the details/summary view based on media
queries exposed through CSS in the browser should do it. Exposure of the
possible additional information could be done using style sheets as well.
JavaScript is out of the picture. I would like to do all this without a
plugin but potentially the reading system could be modified to trigger the
media query on platform that don't have a system property for that setting.
e.g. exposelongdescriptions or exposeextendedcontent.


Rich Schwerdtfeger

From:	Paul Topping <pault@dessci.com>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS, "Siegman, Tzviya -
            Hoboken" <tsiegman@wiley.com>
Cc:	"White, Jason J" <jjwhite@ets.org>, "DPUB mailing list
            (public-digipub-ig@w3.org)" <public-digipub-ig@w3.org>, PF
            <public-pfwg@w3.org>, "Gies, Edward M. (ELS-DAY)"
Date:	08/24/2015 04:07 PM
Subject:	RE: aria-describedat - Elsevier

[Although I am not really part of this thread and may have gotten things
wrong, I will offer this for what it’s worth.]

There is a big difference in using JavaScript in reading system
implementations and requiring a reading system accept arbitrary JavaScript
in the documents it processes. Since reading systems are overwhelmingly
based on HTML engines, using JavaScript in their implementation is routine.
It would impossible to implement one without it. On the other hand,
JavaScript in the document is a big problem from many perspectives. It is a
potential security hole since a malicious document could attempt to get the
reading system to run its malicious code. It is also difficult for the
reading system to ensure that the document’s JavaScript code does
reasonable things, even when nothing malicious is intended.

Paul Topping

Design Science, Inc.
"How Science Communicates"
Makers of MathType, MathFlow, MathPlayer, Equation Editor

From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: Monday, August 24, 2015 1:53 PM
To: Siegman, Tzviya - Hoboken <tsiegman@wiley.com>
Cc: White, Jason J <jjwhite@ets.org>; DPUB mailing list
(public-digipub-ig@w3.org) <public-digipub-ig@w3.org>; PF
<public-pfwg@w3.org>; Gies, Edward M. (ELS-DAY) <Ted.Gies@elsevier.com>
Subject: RE: aria-describedat - Elsevier

Use CSS driven styling from media queries. I guess I am not yet seeing the
need for javascript here.

WRT aria-describedat, how were you expecting to render the alternative
content without javascript for all users? Browsers, will not render it
automatically. Were you going to modify the e-readers to render "more
information" type renderings with the epub readers?


Rich Schwerdtfeger

Inactive hide details for "Siegman, Tzviya - Hoboken" ---08/19/2015
08:31:32 AM---I've added the DPUB IG to this discussion so "Siegman, Tzviya
- Hoboken" ---08/19/2015 08:31:32 AM---I've added the DPUB IG to this
discussion so the group can chime in. In last week's meeting we discu

From: "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com>
To: "White, Jason J" <jjwhite@ets.org>, Richard
Cc: "Gies, Edward M. (ELS-DAY)" <Ted.Gies@elsevier.com>, PF <
public-pfwg@w3.org>, "DPUB mailing list (public-digipub-ig@w3.org)" <
Date: 08/19/2015 08:31 AM
Subject: RE: aria-describedat - Elsevier

I've added the DPUB IG to this discussion so the group can chime in.

In last week's meeting we discussed a strong preference for avoiding
reliance on scripting. This is because many reading systems will not accept
files that contain scripts. See point 8 in requirements document [1].


Tzviya Siegman
Digital Book Standards & Capabilities Lead

-----Original Message-----
From: White, Jason J [mailto:jjwhite@ets.org]
Sent: Wednesday, August 19, 2015 9:20 AM
To: Richard Schwerdtfeger
Cc: Gies, Edward M. (ELS-DAY); PF
Subject: Re: aria-describedat - Elsevier

> On Aug 18, 2015, at 17:37, Richard Schwerdtfeger <schwer@us.ibm.com>
>  we have talked about using CSS media quiries to hide the content
> unless the user turns on a feature in the host OS platform that would
> trigger a media query attribute which would turn on the visibility of
> the details element in the book.

I would strongly support further development of the media query proposal,
which would continue the good work accomplished by the IndieUI working
group in this area.

The capability hinted at in section 10.1 of the Media Queries Level 4
editors’ draft, if specified and implemented, would enable organizations
such as the DAISY Consortium or the IMS Global Learning Consortium to
design more elaborate media features than those which might be provided for
in a W3C specification.

See “Scripted custom media queries”:

and note discussion of tis topic earlier in the year by the IndieUI working

In the EPUB context, a reading system implemented as a Web application
could define custom media features in JavaScript according to conventions
developed for example by one of the organizations noted above. These
features could then be used in media queries within book content to select
from among the available alternatives to an image, table or other
construct. The user interface for specifying the user’s needs could be
provided by the reading system or externally.

This is entirely compatible with the existence of system or user
agent-level preferences reflected in media features; the idea is that
custom media queries would enable more elaborate user needs/preferences to
be defined and used in specific contexts.


This e-mail and any files transmitted with it may contain privileged or
confidential information. It is solely for use by the individual for whom
it is intended, even if addressed incorrectly. If you received this e-mail
in error, please notify the sender; do not disclose, copy, distribute, or
take any action in reliance on the contents of this information; and delete
it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.


(image/gif attachment: graycol.gif)

Received on Monday, 24 August 2015 21:44:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:08 UTC