Digital Publishing Interest Group Teleconference

<trackbot> Date: 15 June 2015

<dauwhe> scribenick: dauwhe

mgylling: approval of last week's minutes
... any comments or objections?
... minutes approved.
... some administrivia:
... update on status of charter renewal

Charter renewal update

ivan: ten days ago, the charter has been announced unofficially

<ivan> Unofficial announcement

[furious typing]

scribe: not yet a formal vote; hoping for replies and comments

<ivan> http://w3c.github.io/dpub-charter/index.html

scribe: we have one comment so far, from clapierre
... we like that comment
... Last Friday, I began to contact people in browser community
... to get comments from that corner, no results yet.
... important for all of us in member companies to give comments
... tell us where we're wrong, if things should be different
... and positive comments are good, too
... I don't know when we go for formal AC vote
... we should probably wait for some comments
... Does Ralph have anything to add?

Ralph: Nope.

mgylling: is the absence of comments a problem?

ivan: at this stage, no
... when we get to the formal vote
... then we need 5% of the membership, which is 19 members, need to approve
... if we don't get the five percent, then we have unpleasant discussions with management

mgylling: for those of us who are not AC reps, we have been given work: nudge our AC rep into making comments on the draft
... what really matters is being able to rally votes when it counts.

ivan: mid-July, probably

Ralph: that could be realistic

mgylling: the time of year when people are hardest to rally

ivan: we could have a longer voting period

Thierry: we need comments now; so we can change things
... in later stages, we don't want to change

mgylling: moving on

TPAC

mgylling: time to register for TPAC
... registering early makes w3c staff happy
... we do yet know how many IG members will be there

<clapierre> 99%

<brady_duga> +1

brady_duga: I'm coming, but only for this meeting
... if it's not going to happen I'd need to know

ivan: anyone who's sure now should register

mgylling: anyone sure they won't be going

tzviya: we did do a survey before we filled out room request
... lots of people said they were coming

ivan: we should set up the F2F wiki page now

mgylling: who sets up the wiki?

ivan: any of us

mgylling: any questions or remarks about tpac?

<tmichel> I will set the wiki registration page for DPUB

mgylling: "One thing we forgot to put on is a summer Hiatus or Summer Break. We did this last summer - not meeting in July. The question we have is whether we would want to do the same thing this year?"

Summer break

nick: "I'll be poking people to get articles to create a backlog"

Dave: "Lets just cancel individual meeting if we get enough regrets? It seems like we have important things - charter, epub web, etc"

<Karen_> +1 keep going and cancel ad hoc

Tzviya: "I think we should keep it going. Unless we get regrets."

"NO SUMMER BREAK FOR YOU!" :)

Markus: "For next week, we'd like to get going again on topics that have been discussed on the list requiring publication identification. The problem of resource collection on the web. It's Bill K's topic, but he's not here. We'll go into it more next week and try to get more continuity. Let's define what is actually needed to establish basic identities and unpackaged identities. "

ACTUAL Ivan: "We've had all sorts of discussions via email, which is a good starting point."

CSS needs

Markus: "on to today's main topic: There is a misconception floating around. Ivan, can you repeat?"

<dauwhe> Here's the start of a list: https://www.w3.org/dpub/IG/wiki/CSS_Priorities_for_the_Digital_Publishing_Community

Ivan: "The observation goes that somehow there were people with the impression that there are no open issues for CSS features needed by this community. To be self-critical, we have not publishes very often any documents on this. That is why we thought to have this topic - to have a better view of what else, beyond pagination, are the things that CSS should provide, but does not. We all know Pagination is a major issue, but what else is there?"

Dave: "I would mention that I only started the WIKI page this morning, and I included pagination, even though it didn't seem necessary. I tried to categorize things logically. Foundations, typography,..."
... "I'm not quite sure how we'd want to discuss this: One sad observation is that many of the things mentioned here have been in CSS drafts (and some were removed - due to at risk from no implementations)"

Ivan: "Looking at the list - there is a reference here on GRID. The way I understand it is that there are loads of modules in CSS3. I don't see from this list a kind of categorization - something saying 'this is what we need, but it's not a standard' or 'it's not what we need and here's where' or 'this is almost what we need but here's what's different'. In terms of functionality as well as evolution in the working group life. "

Dave: "Agreed. There are some things that the spec is nice, but it hasn't been implemented. Some things that aren't fully there yet, some things that haven't been spec'd at all..."

Ivan: "For each bullet item we need to add the grid of where things are."

Markus: "Your typography section sits well with me because it describes things from a publisher's perspective which is very important. When you say in pagination 'GCPM' what does that mean? Everything in GCPM? If we could have the first column similar to what you have in typography, that would be a great short-description of what a publisher might need."

Dave: "GCPM handles cross-reference, but it hasn't been implemented by the browser."

Tzviya: "It's great that certain things exists in the spec, but if it hasn't been implemented, then it's important to elevate it to Houdini or something else to ensure that it is handled."

Markus: "As a side-note, we need to keep in mind the potential accessibility repercussions. There is a potential accessibility hazard there. I believe that WCAG 2 says that we shouldn't be using this for things beyond decoration."

<liam> [wcag restriction on generated content may also come from issue of fallback for when there's no CSS]

Dave: "The main accessibility issue is that there are bugs where content may not be selectable. That might be something to add to this list - is better generated content for accessibility/implementation."

Alan: "Initial intent was decoration, but it's now used for content as well, as content is used as a decoration and not actual content."
... "I agree that we need to have an evoluation of all these things. Where are they - are they usable? I am a bit too close to give things a realistic view. And there are some issues in translation - typographical features that work great for fixed layout (printing) but when we add them to the web, which is reflowable, where quite a lot more needs to be automated by the browser. So much is done by hand. There is something in the CSS-line that defines how the boxes get put into the grid - it's something publishing does by hand. While the first section of the LINEGRID module is good, the 2nd section isn't there yet."
...: "We should also be able to access alternate glyphs. I'm not sure there is a good way of doing that on the web. "

Dave: "Prince do have extensions that do that - although they may not be useful..."

Markus: "In terms of appending to this table - there are quite a few of us, that would want to add their favorite missing features into the table. I would like to announce and open period of time where we should invade Dave's work. And add anything - it's OK if it is incomplete, we can work to fill it in. We haven't talked about prioritization - but that tends to be quite messy. Let us wait until the table starts to mature then we can determine the best way."

Ivan: "I was wondering - how to start doing that - to help out dave. "

Dave: "it would help to get more things for the list. Collecting ideas is the hard part."

Ivan: "I have specific questions - what I don't see here is about control over fonts - in some sense, what alan was referring to. Are the features to control fonts and how fonts are used - are they already satisfactory for this community?
... "Maybe vlad is in position."

<astearns> need wider implementation of: font-feature-settings, subsetting, font loading events...

<liam> +1 to lack of access to actual stylistic variant fonts

Dave: "I know that I've run into CSS's classification of font properties - does not come close to covering the range of features that existing fonts have. One example is Adobe has many optical weights (captions, subheads) which CSS has no notion of that"
... "some font families have 160 different fonts to the family. CSS is not up to that challenge."
... "8 or nine weights, optical properties, so-on-and-so-forth."

Tzviya: "By linking to the existing modules that are relevant, you've pretty much covered all of our priorities?"

Dave: "yes, it needs to be done at a more gradual level."

Markus: "We should be noting atomic uses, not just high-level."

Tzviya: "Homework is to go through the modules and say: 'we need this' etc"

<Zakim> mgylling, you wanted to not forget to mention CJK

Markus: "One thing we owe it to China/Japan/Korea to do is to get something well versed in their typographical needs, to add whatever is needed there. Now that Antenna we have  house in the IG, that shouldn't be a problem, but it strikes me that what we have in the epub3 CSS profile is a number of vendor-prefix properties built on top of CSS context. All of these things are used for all epubs in those regions, and they represent items that are missing from CSS. We can go through that list and pick out features that aren't supported as of yet."

Markus: "Such as vertical centering, Who from antenna house is on the call today? "

Mike Miller: "I'll pass this information on"

Markus: "We really need a good list of features from a Japanese point of view."

Ivan: "A similar question for fonts - Are publishers happy with the control of Color? It's improved with HSL and the A parameter - which is great compared to old CSS. Maybe alan knows - is it possible to express very precise colors?"
... "If not, is it something publishers need?"

tzviya: "anyone familiar with HSLA or RGBA likes it more than CMYK

Ivan: "The question - is what is in CSS satisfactory or not?"

Tzviya: "I would need to research, but any issues ... i see where you're going... It has more to do with screens."

<Ralph> Nick: Brady

"Crappy monitors means crappy interpretation"

Nick: "Screens are limitors - CSS colors are fine."

Markus: "The group wants to contribute to the group's page. Mike is going to get Antenna house to note on the items related to Japanese. We should reach out to other locals. "
... "Tzviya, sounded like you're gearing up to add other things."

Dave: "I'm also wondering if - one possibility - is to keep the wiki page in a "listy-texty" format so that we do tables elsewhere - on Github or something. Wiki tables - especially complicated - are going to be difficult..."

Ivan: "If you put a table on the same level - it creates a table.html..."

markus: "contributors still use the wiki?"
...: "Do we just have suggestions on the wiki? Or everyone hooking up to github?"

DavE: "We'll get more input if we don't require the use of github. I offer to anyone, if you want to make changes to a github doc - contact me or Ivan."
... "use the wiki as the funnel. People who are comfortable with the github can use it."
... "CSS tends to take a lot of notice on the issues of languages, JL req, and various other scripts. In some sense, we're not the experts on those languages."

Nick: "Possibly use GoogleDocs spreadsheets for the giant table"

<astearns> is table sorting a publishing need?

<clapierre> Google Docs is good although it isn't yet 100% accessible

Ivan: "Probably, we should look at what the other groups are doing for the other languages/scripts, which have direct channels to the CSS working group. We may not want to duplicate work."
... "As for googledoc, we may not want to introduce more efforts"

Markus: "One final question - Explain to me how this work relates to latinreq. And tell me how there will not be duplication of intent and LatinREQ."

<astearns> this is input to LatinReq

Dave: "IN some cases the motivation for this effort is communication with W3C. From the email i was getting from Ivan, this is more helping W3C management with Priorities."

Markus: "Exactly. Just making sure there is no duplication."

Dave: "I like alan's comments - this could be INPUT to latinreq. Latinreq has been agnostic in how these features have been implemented. "This is how things are" and less 'CSS can do THIS but not THAT. Does latinreq goes in a direction where it calls out what is possible and suggest new CSS features? We don't go into any detail in the table either. "

Tzviya: "I wanted to add that this is the executive summary. Latinreq is intentionally detailed. 'We know it exists, but it doesn't work in the real world' so it becomes more of a call to action."

Dave: "Just don't make us implement this as annotations to latinreq"

Markus: "We're at the end. Thank you all, please help the group out in filling the WIKI page with missing CSS features. Keep in mind that we plan for next week - publication identification and resource identification on the web."