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

[Minutes] 2015-08-17 Digital Publishing Interest Group Teleconference

From: Thierry MICHEL <tmichel@w3.org>
Date: Mon, 17 Aug 2015 18:16:17 +0200
Message-ID: <55D208D1.9070003@w3.org>
To: "public-digipub-ig@w3.org >> W3C Digital Publishing IG" <public-digipub-ig@w3.org>
Hi all,

The minutes of the Digital Publishing Interest Group Teleconference 
dated 2015-08-17 are now available at


These public minutes are also linked from the dpub wiki

Also find these minutes in a text version following, for your convenience.


Thierry Michel



       [1] http://www.w3.org/

             Digital Publishing Interest Group Teleconference

17 Aug 2015


       [2] http://www.w3.org/mid/55CD1C5A.6030302@gmail.com


           Markus Gylling, Tzviya Siegman, Dave Cramer, Brady
           Duga,  Ivan Herman , Deborah Kaplan, Heather Flanagan,
           Peter Krautzberger, Thierry Michel, Ayla Stein, Bill
           Kasdorf, Charles La Pierre, Paul Belfanti, Nick Ruffilo,
           Chris Liley, paul, Julie Morris, Leonard Rosenthol,
           Karen Myers, Jeff Xu, Vladimir Levantovsky.

           Alan Stearns, Ben De Meester, Ayla Stein, Paul
           Belfanti, Luc Audrain.

           Markus Gylling

           Tzviya Siegman, Nick Ruffilo


      * [3]Topics
          1. [4]Last week's minutes
          2. [5]CSS publishing
          3. [6]User style sheet, personalization
      * [7]Summary of Action Items

    <ivan> trackbot, start telcon

    <trackbot> Date: 17 August 2015

    <NickRuffilo> scribenick: Tzviya_Siegman

    <NickRuffilo> JKJK

    <NickRuffilo> scribenick: NickRuffilo

    <HeatherF> The host can mute, but then the muted person cannot
    unmute themselves.

    <mgylling> [8]http://www.w3.org/2015/08/10-dpub-minutes.html

       [8] http://www.w3.org/2015/08/10-dpub-minutes.html

Last week's minutes

    Markus: "Any objections to approving?"

    Masses: Silence

    Markus: "While in admin mode - in order to show up in the
    attendee list, you have to do "present+ in IRC""

    <ayla_stein> * present+ ayla_stein

    Markus: "We wanted to make sure Deborah is around for the ARIA
    description for described-at. So we're going to start with

    <clapierre1> +1


    <HeatherF> +1

    Markus: "OK - ARIA Described-at meeting recap."

    Deborah: "It was fine - it could have gone much...

    <tzviya> current requirements for extended descriptions:


    Deborah: "Instead of going to the group saying "we need it" we
    re-wrote the list of requirements that publishing needed. We
    don't care what makes us do these things, but we need a
    consistent way to do this without polyfills. There were lots of
    people and publishers in the meeting - even though they ended
    up not speaking up..."
    ...: "There was some tech conversation but in the end what I
    think happened that what we were asking for was not some
    specific implementation, or something with legacy issues - that
    we had suggestions but did not have strong feelings on how the
    functionality should be implemented. They brought up valid
    questions about making things easy to implement while not
    making it present for those that

    don't want it. We did convince them that what we wanted was
    ...: "Tzviya and others are polishing up the wording and
    requirements. The one thing that came out of this meeting is
    that we agreed it was too complicated to talk about backwards
    compatibility. For any number of reasons, that publishing
    requires older technology - so worrying about backwards
    compatibility was one of the things dragging us down - if you
    have newer tech, then you will be able

    to have access to this feature - but probably not in older
    browsers. Unfortunately IE is now being considered an older

    <ChrisL> edge is the new IE and is installed by default in
    Windows 10 which is a free upgrade
    ...: "We decided to push forward."

    Tzviya: "Thank you to all who stayed for the full time - it was
    long but worth it. Also, even if you were in the meeting and
    didn't say anything. I know our friends from ARIA and PF were
    appreciative. it meant alot that people showed up."

    Ivan: "Let's add one point that Markus did HEROIC scribing
    during that meeting."

    <ChrisL> "Mobile Safari is the new IE6"

    Ivan: "I wanted to check if my impressions were right if this
    was an apple VS anybody else - was this correct? The other
    thing is that it seems that the solution is the details element
    - in which case then Apple will reject..."
    ... "I had a slightly disagreeable feeling that the reaction of
    apple is that 'this is already implemented, so we won't make
    any change." Maybe I misunderstood..."

    Chris: "The old IE vs Edge is a temporary phenomenon - Windows
    10 replaced IE with Edge - so you get rid of it..."

    Deborah: "As far as Ivan's perspective - (I want to thank
    everyone for showing up - as well as Markus for scribing!) It
    does seem true that the needs of the meeting were being driven
    by the goals of one manufacturer. Someone said: 'This seems
    like what long-desc is, and all it needs is more info' and the
    manufacturer said: 'we will not do it.' While it may be strange
    and frustrating that the

    goals of ARIA/HTML are being so influenced by one browser, at
    the same time, it looks like we WILL achieve most of our
    requirements. Details isn't perfect, and it won't work
    out-of-the-box (not sure everyone is willing to make those
    changes) but it's closer than we have ever gotten in the past."

    Tzviya: "I'm not entirely sure that Details is what we will
    arrive that. It seemed that way in the meeting, but we still
    need to make a grid of requirements and options and see what we
    arrive at. We set forth requirements - if details is the
    solution, then we'll go with it. There was silence when
    long-desc was brought up and didn't end until the browser said

    Ivan: "yes, we do need to make the grid. One of the good things
    of last week - through Deborah's list - was a new fresh view
    from a different domain. It was an eye opener for an old debate
    that was going on for a decade. That wiki and Deborah's
    requirements are wonderful."

    Brady: "Quick Q about details: it seems like in the one demo
    I've seen of it, it was used to show the camera settings a
    picture was used. is there a way to show 'this is the
    accessability text'. So can you have multiple notes?"



    Deborah: "It's work that needs to be done. Details is not
    connected to a thing - so you'd need to connect it to an ARIA
    thing. it's not designed to be hidden... The semantic meaning
    that publishing would need - to say 'this is a role that always
    means this is a description, so that all readers can deal with
    it the same way - that is what isn't there. It isn't perfect,
    but it's also not part

    of the spec yet, so there is room to improve it."

    Brady: "Although it's implemented, and exists, it doesn't do
    what we want it to do.' is what I hear from publishers.."

    Peter: "I wanted to 2nd brady from math's perspective - even
    for accessibility - you may want to embed several different
    formats, a typical usage is that you might have speech text,
    some you want a LaTex, so you may want to have multiple
    descriptions for multiple views. MathML has a framework for
    this purpose, which I don't think is highly useful because of
    the state of support for MathML. I

    think the details sounds like a more realistic path."

    Ivan: "To answer one of the specific questions, the 'details'
    element is a general block element. has only 2 special elements
    - the first required child element is a 'summary' and the 2nd
    is the user-agent default is 'display:none;' That's all it is,
    so if you take a FIGURE element, is that you can put as many
    detail child elements. Apart from the summary, you can put into
    the details element

    whatever you want. It is generic - so it's both good and bad,
    because it's difficult to know what a specific detail element
    is made for."

    markus: It does not allow the re-use of details or information,
    which is one requirement. "

    ...: "Unless there are final comments, lets move on. Publishing
    the CSS Requirements doc:"

      [11] http://w3c.github.io/dpub-pagination/priorities.html

CSS publishing

    ...: "We're not very far off from publishing this?"

    <ChrisL> oh, I was supposed to look at one of those sections.
    sorry, was travelling. agree that publish early and often is
    good so +1 to publish

    Dave: "I subscribe to publish-early publish-often, so lets get
    it out with more eyeballs and community feedback. Only half
    tongue-in-cheek. Since we've started on this document, there
    have been progress on the 2 highest priority items. Apple and
    Google have been working on things (hyphens bug for example)"

    Markus: "Is the target a note?"

    Dave: "A working Draft..."

    Ivan: "This is what we did with LatinReq as well. We mimic the
    req track, so we publish notes..."

    dave: "Working draft is an accurate description. Note implies a
    degree of finality."

    Markus: "Should we ask the W3C staff to get things going?"

    Dave: "Are there more comments before we push it through?"

    +1 push

    Chris: "I haven't had a chance to get my edits in, but I can
    get them in next round..."

    <mgylling> +1 push

    Tzivya: "There is a little section called 'accessibility'. I
    know ARIA is planing on getting very involved with CSS. We want
    to note the generated content issue, but we will at least wnat
    to note what may or may not be our problem."

    dave: "If you have things you want to add, please do..."

    <ChrisL> Generated content is an issue for many reasons (like
    selectability and searchability) as well ass accessibility

    Tzviya: "The fact that generated content creates an issue says
    alot, but if you'd like me to write a paragraph or so, getting
    it out before the next face-to-face is important..."

    Ivan: "Practicalities, the 2 possible dates, this coming
    thursday or 2 weeks from tuesday. It's up to you Dave. If you
    want to have the publication request should go out tomorrow to
    the webmaster... This is not RESPEC, it's the CSS workflow..."

    <ChrisL> Oh good, Bikeshed

    Ivan: "You will have to produce the final version so that I can
    push it up..."

    Chris: "i'm also here the rest of this week - ivan if you have
    any questions"

    <tmichel> I am here this week also.

    Dave: "I think I can just change the status to working draft
    and it'll be OK."

    Ivan: "No figures - just text? One HTML file?"

    DavE: "Yes"

    <ChrisL> shortname approval

    Ivan: "Wait, one minor thing we have to settle today. This is a
    new document. I will have to contact Ralph to get authorization
    for the dpub-pagination as a short name"

    Chris: "Yes."

    Ivan: "Ok, I will send a request after this call."

    Dave: "Short name is an interesting question. in the spec the
    URL is mainly because we're hosting it in the same GITHUB as
    latin-req. I call it DPUB-CSS-Priorities"

    Ivan: "I don't care, just tell me what it is."

    Dave: " I'll send you the file and info"

    Markus: "Tzviya - you wanted to add a paragraph for generated

    Tzviya: "I think it's OK to go ahead without it..."

    Dave: "I'll send it tomorrow morning US time... "

    Ivan: "That's afternoon my time."

    Dave: "Ok, so by EOD my time"

    <ChrisL> yes, needs a recorded decision

    Ivan: "For short-name we need official concensus"

    <dauwhe> dpub-css-priorities is shortname proposal

    <ChrisL> yes, needs a recorded decision for shortname and
    another to actually publish

    Markus: "dpub-css-priorities"


    <tzviya> +1

    <clapierre1> +1

    <pkra> +1

    <ivan> +1

    <ChrisL> +1

    <Bill_Kasdorf> +1

    <mgylling> +1

    <Vlad> +1

    <Jeff_Xu> +1

    <tmichel> thierry +1

    <lrosenth> +12

    <lrosenth> +1

    <brady_duga> +1

    <ayla_stein> +1

    <pbelfanti> +1

    <ivan> RESOLUTION: ask for the dpub-css-priorities short name
    and FPWD publication

    Ivan: "^^"

User style sheet, personalization

    Markus: "User style sheets and personalization. it's being
    discussed in epub web whitepaper. For many of us it's a big
    unknown and it's an oft-requested feature to taylor
    presentations dynamically. This sessions is primarily about
    what is going on and what we can do to improve this situation."
    ...: "Chris will give us an intro and brief on what is going on
    with this and how the lay of the land works."


      [12] http://www.w3.org/TR/css-cascade-3/#cascading-origins

    Chris: "There are 3 sources. User-agent, which it applies to
    all content. It was a polite fiction, but it actually works.
    Then there are the document stylesheets, then lastly with the
    highest priority are the stylesheets provided by the user. Been
    in since CSS1, and lets a user change font-size, etc. There are
    some problems. Firstly, it's not consistently implemented.
    Chrome may have

    removed it... More importantly, users do not know they can do
    this - similar to alternate stylesheets."
    ...: "For example, you could have a reading stylesheet, a
    highlight stylesheet, etc. Users want to see content on the
    page that says 'pick bigger font' not go through hoops to load
    a CSS. On a low-level, it is implemented, but on a high-level,
    it is unused (it is not made easy)"
    ... "There are other problems beyond the UI. Modern web content
    is heavily tweaked - so it's easily broken. Lots of current
    web-design makes it so that changing styles could easily break
    things - so it is not the right place to do restyling. Another
    solution is browser preferences. This has the advantages that
    it isn't in the cascade - but overrides things. No one says you
    need to use the

    same CSS overrides on every page. Even attaching a custom CSS
    to a bookmark. There are no mechanisms for users to share
    stylesheets. I'm starting to think this is a nice little
    feature that it is puny for the job we want to do - and they
    don't have the facility to construct these things
    ...: "We need a new mechanism for advanced customization of

    <ChrisL> yes, I thought the normal browser is what we were
    talking about here

    Leonard: "Obviously you're talking in respect to the browser as
    the user agent. In the context of publications - while we may
    use a browser engine, we're creating a custom application
    around it (or some wrapper) so from a technical perspective,
    many of the things should be pushed into the engine..."
    ... "So there is no technical limitation - it comes down to UI

    <ChrisL> I forgot to mention the lack of support for @document
    rules which would help

    Markus: "The styling in the document is so complex, that it
    still needs to be addressed."

    Nick: "UI solution to complexity is to be able to customize CSS
    for specific "div" or "sections"

    <ChrisL> more on @document
    document and

      [14] https://developer.mozilla.org/en-US/docs/Web/CSS/@document

    Tzivya: "add an additional layer for user-specific-stylesheets.
    Reading systems are relying on browser or user-agent
    functionality. We don't want reading systems to roll their own

    <HeatherF> I need to drop of for another call. Good call today!

    Leonard: "UI should be the reading system - functionality
    should be the browser"

    Brady: "We do have some simple UI - for instance books - it's
    lots of text with a bunch of paragraphs. Just making the font
    bigger is hard to do - making text 120% bigger is a complex
    thing to do in CSS. Often requires going through CSS styles,
    adjusting font properties... And then it gets crazier... We
    still have failures in certain peices of content - even when
    you have full control of CSS
    . This doesn't even get into when you want to change only some
    of the font-families. When you have a custom font, you amy not
    want to replace certain pieces."

    Brady: "User-style-sheets are interesting idea, but they don't
    require the power needed, and they are too complicated."

    Dave: "Just to illustrate some of the problems we have in the
    ebook world today - around this idea - amazon for example says
    that we cannot apply 'text-align' property to items in body
    text. They claim they cannot build a reading system if you have
    something that may over-ride. We do have headaches because of
    this. I'd also like to point out - are existing mechanisms in
    CSS enough... We need

    something beyond what the cascade does... There are some
    houdini ideas around custom parsing of CSS. How do we expose
    our requirements to that effort?"

    Leonard: "I know many people focus on book publishing - but i
    would like to point out that the issues and concerns extend way
    beyond books - and we need to keep in mind magazines, manga,
    etc. Is this a solution we'd like to solve with existing
    technology or do we need something new. How much backwards
    compatibility is needed? Something like we did with CSS
    prioritization may be needed."

    Markus: "Requirements again would probably be one things that
    could help."

    Ivan: "Do browser manufactures care in the first place? Are
    they trying to solve this? Or is this a problem that the
    browser manufacturers recognize that it should be solved - but
    it has never been a priority?"

    Chris: "Not sure they don't want to do it or oppose it, but
    they do not seem motivated to implement it."
    ... "Haven't heard that it should be removed or that it's a

    Ivan: "Charles, then next steps.."

    Charles: "Quick point on Nick's comment on limiting regions to
    be modified. I have a slight issue in regards to disabilities.
    If you cannot change the color, and you're color-blind, you may
    not be able to read it."

    <lrosenth> +100 to Charles - accessibility needs to overrideā€¦(I
    like the dyslexic font example, but colour is good too)

    Markus: "How do you think the DPUB interest group can best help
    you think about this issue."

    Chris: "It would be good to have examples of the types of
    customization that would be required. Shoudl we beef them up?
    Should we invent a new mechanism? These are all primarily
    use-case driven."

    Markus: "That's what I hoped you would answer."
    ...: "We'll be producing another document - with example and
    publishing domain. Not exclusively trade books, but all types
    of customization and personalization. Things that are either
    being done with lots of fiddling, or things that we want to do
    today but cannot. That's one new work item..."

    Leonard: "I'll happy to help"

    <tzviya> I will write some use cases, and ARIA WG Is interested
    in observing/contributing to some extent

    Thanks dave!

    Markus: "Nick is the owner of this document."

    <ayla_stein> ha!

    <ChrisL> I'm happy to review, but don't have use cases to

    <clapierre1> also happy to review

    Markus: "As tzviya reminded us - ARIA working group is also
    heading into this area

    Thanks to all for being here!

    <pkra> bye.

Summary of Action Items

    [End of minutes]

     Minutes formatted by David Booth's [15]scribe.perl version
     1.140 ([16]CVS log)
     $Date: 2015/08/17 16:12:32 $

      [15] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
      [16] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30
Check for newer version at [17]http://dev.w3.org/cvsweb/~checkout~/2002/

      [17] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/exception/objection/
Found ScribeNick: Tzviya_Siegman
WARNING: No scribe lines found matching ScribeNick pattern: <Tzviya_Sieg
man> ...
Found ScribeNick: NickRuffilo
Inferring Scribes: Tzviya_Siegman, NickRuffilo
Scribes: Tzviya_Siegman, NickRuffilo
ScribeNicks: Tzviya_Siegman, NickRuffilo
Present: Markus Tzviya_Siegman Dave_Cramer duga ivan Deborah_Kaplan Heat
her_Flanagan Peter Krautzberger Thierry Ayla Stein Bill_Kasdorf Charles
LaPierre Paul_Belfanti NickRuffilo ChrisL paul Julie_Morris Leonard Rose
nthol Karen Jeff_Xu Vlad
Regrets: Paul Luc Ben Ayla AlanS
Agenda: [18]http://www.w3.org/mid/55CD1C5A.6030302@gmail.com
Found Date: 17 Aug 2015
Guessing minutes URL: [19]http://www.w3.org/2015/08/17-DPUB-minutes.html
People with action items:

      [18] http://www.w3.org/mid/55CD1C5A.6030302@gmail.com
      [19] http://www.w3.org/2015/08/17-DPUB-minutes.html

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

WARNING: IRC log location not specified!  (You can ignore this
warning if you do not want the generated minutes to contain
a link to the original IRC log.)

    [End of [20]scribe.perl diagnostic output]

      [20] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
Received on Monday, 17 August 2015 16:16:31 UTC

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