- From: Thierry MICHEL <tmichel@w3.org>
- Date: Mon, 15 Jun 2015 21:31:39 +0200
- To: Julie Morris <julie@bisg.org>
- CC: W3C Digital Publishing IG <public-digipub-ig@w3.org>
Julie, With Webex it is now quite difficult to track who is present. Therefore, each participant should type present+ <name> in the irc channel immediately upon joining the call Please refer to - my earlier email and put in IRC present+ Julie Morris when joining. https://lists.w3.org/Archives/Public/public-digipub-ig/2015Jun/0018.html - the WebEx instructions in the wiki: http://www.w3.org/dpub/IG/wiki/WebEx - See also Web Ex Best Practices Wiki page https://www.w3.org/2006/tools/wiki/WebExBestPractices Therfore, please type in IRC "present+ Julie Morris" when joining the call. If you can't connect simultaniouslly to IRC, just ask the scribe or the chair to add your name upon joining the call. Meanwhile, I have added your name to today's minutes. Best, Thierry On 15/06/2015 20:32, Julie Morris wrote: > I was present- please add me to the attendees list. > > Thanks, > Julie > > On Mon, Jun 15, 2015 at 1:00 PM, Thierry MICHEL <tmichel@w3.org > <mailto:tmichel@w3.org>> wrote: > > Hi all, > > The minutes of the Digital Publishing Interest Group Teleconference > dated 2015-06-15 are now available at > > http://www.w3.org/2015/06/15-dpub-minutes.html > > These public minutes are also linked from the dpub wiki > http://www.w3.org/dpub/IG/wiki/Meetings > > Also find these minutes in a text version following, for your > convenience. > > Best, > > Thierry Michel > > ------------------------------------------ > > > > [1]W3C > > [1] http://www.w3.org/ > > Digital Publishing Interest Group Teleconference > > 15 Jun 2015 > > [2]Agenda > > [2] http://www.w3.org/mid/557B46E6.6060506@gmail.com > > See also: [3]IRC log > > [3] http://www.w3.org/2015/06/15-dpub-irc > > Attendees > > Present > Tzviya Siegman (tzviya), Ralph Swick (ralph), Ivan > Herman (ivan), Alan Stearns (astearns), Thierry Michel > (tmichel), Laura Fowler (lfowler), Dave Cramer (dauwhe), > Ben De Meester (bjdmeest), Markus Gylling (mgylling), > Brady Duga (duga), Toru Kawakubo (kwkbtr). > > Regrets > Luc Audrain, Phil Madans, Bill Kasdorf, Ayla Stein, > Heather Flanagan > > Chair > Markus > > Scribe > dauwhe, NickRuffilo > > Contents > > * [4]Topics > 1. [5]Charter renewal update > 2. [6]TPAC > 3. [7]Summear break > 4. [8]CSS needs > * [9]Summary of Action Items > __________________________________________________________ > > <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> [10]Unofficail announcement > > [10] > https://lists.w3.org/Archives/Member/w3c-ac-members/2015AprJun/0044.html > > [furious typing] > > scribe: not yet a formal vote; hoping for replies and comments > > <ivan> [11]http://w3c.github.io/dpub-charter/index.html > > [11] 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 > > <NickRuffilo> scribenick: NickRuffilo > > "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?" > > Summear 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: > [12]https://www.w3.org/dpub/IG/wiki/CSS_Priorities_for_the_Digi > tal_Publishing_Community > > [12] > 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." > > <astearns> sorry - can't seem to get it to work > > 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 repurcussions. 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 accessability 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 evalution 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 > > <scribe> 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 familys have 160 different fonts to the family. > CSS is not up to that challenge." > ... "8 or nine wieghts, 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 we have atenna 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 Latin > REQ. 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." > > Summary of Action Items > > [End of minutes] > __________________________________________________________ > > > Minutes formatted by David Booth's [13]scribe.perl version > 1.140 ([14]CVS log) > $Date: 2015/06/15 16:13:47 $ > __________________________________________________________ > > [13] > http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm > [14] 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 [15]http://dev.w3.org/cvsweb/~checkout~/2002/ > scribe/ > > [15] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/ > > Guessing input format: RRSAgent_Text_Format (score 1.00) > > Succeeded: s/???/Thierry/ > Succeeded: s/Ivan/Markus/ > Succeeded: s/WPIC/WCAG/ > Succeeded: s/Prints/Prince/ > Succeeded: s/HSBA/HSLA/ > Succeeded: s/@@/Brady/ > Succeeded: s/alot/a lot/ > Found ScribeNick: dauwhe > Found ScribeNick: NickRuffilo > Inferring Scribes: dauwhe, NickRuffilo > Scribes: dauwhe, NickRuffilo > ScribeNicks: dauwhe, NickRuffilo > Default Present: lfowler > Present: lfowler Dave_Cramer mgylling Ivan_Herman astearns RalphSwick To > ru_Kawakubo duga Thierry Michel Tzviya_Siegman Ben_De_Meester > > WARNING: Replacing previous Regrets list. (Old list: Luc_Audrain, Phil_M > adans) > Use 'Regrets+ ... ' if you meant to add people without replacing the lis > t, > such as: <dbooth> Regrets+ Bill_Kasdorf > > Regrets: Luc_Audrain Phil_Madans Bill_Kasdorf Ayla_Stein Heather > Agenda: [16]http://www.w3.org/mid/557B46E6.6060506@gmail.com > Found Date: 15 Jun 2015 > Guessing minutes URL: [17]http://www.w3.org/2015/06/15-dpub-minutes.html > People with action items: > > [16] http://www.w3.org/mid/557B46E6.6060506@gmail.com > [17] http://www.w3.org/2015/06/15-dpub-minutes.html > > > [End of [18]scribe.perl diagnostic output] > > [18] > http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm > > > > > [1]W3C > > [1] http://www.w3.org/ > > Digital Publishing Interest Group Teleconference > > 15 Jun 2015 > > [2]Agenda > > [2] http://www.w3.org/mid/557B46E6.6060506@gmail.com > > See also: [3]IRC log > > [3] http://www.w3.org/2015/06/15-dpub-irc > > Attendees > > Present > Tzviya Siegman (tzviya), Ralph Swick (ralph), Ivan > Herman (ivan), Alan Stearns (astearns), Thierry Michel > (tmichel), Laura Fowler (lfowler), Dave Cramer (dauwhe), > Ben De Meester (bjdmeest), Markus Gylling (mgylling), > Brady Duga (duga), Toru Kawakubo (kwkbtr). > > Regrets > Luc Audrain, Phil Madans, Bill Kasdorf, Ayla Stein, > Heather Flanagan > > Chair > Markus > > Scribe > dauwhe, NickRuffilo > > Contents > > * [4]Topics > 1. [5]Charter renewal update > 2. [6]TPAC > 3. [7]Summear break > 4. [8]CSS needs > * [9]Summary of Action Items > __________________________________________________________ > > <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> [10]Unofficail announcement > > [10] > https://lists.w3.org/Archives/Member/w3c-ac-members/2015AprJun/0044.html > > [furious typing] > > scribe: not yet a formal vote; hoping for replies and comments > > <ivan> [11]http://w3c.github.io/dpub-charter/index.html > > [11] 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 > > <NickRuffilo> scribenick: NickRuffilo > > "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?" > > Summear 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: > [12]https://www.w3.org/dpub/IG/wiki/CSS_Priorities_for_the_Digi > tal_Publishing_Community > > [12] > 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." > > <astearns> sorry - can't seem to get it to work > > 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 repurcussions. 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 accessability 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 evalution 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 > > <scribe> 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 familys have 160 different fonts to the family. > CSS is not up to that challenge." > ... "8 or nine wieghts, 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 we have atenna 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 Latin > REQ. 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." > > Summary of Action Items > > [End of minutes] > __________________________________________________________ > > > Minutes formatted by David Booth's [13]scribe.perl version > 1.140 ([14]CVS log) > $Date: 2015/06/15 16:13:47 $ > __________________________________________________________ > > [13] > http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm > [14] 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 [15]http://dev.w3.org/cvsweb/~checkout~/2002/ > scribe/ > > [15] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/ > > Guessing input format: RRSAgent_Text_Format (score 1.00) > > Succeeded: s/???/Thierry/ > Succeeded: s/Ivan/Markus/ > Succeeded: s/WPIC/WCAG/ > Succeeded: s/Prints/Prince/ > Succeeded: s/HSBA/HSLA/ > Succeeded: s/@@/Brady/ > Succeeded: s/alot/a lot/ > Found ScribeNick: dauwhe > Found ScribeNick: NickRuffilo > Inferring Scribes: dauwhe, NickRuffilo > Scribes: dauwhe, NickRuffilo > ScribeNicks: dauwhe, NickRuffilo > Default Present: lfowler > Present: lfowler Dave_Cramer mgylling Ivan_Herman astearns RalphSwick To > ru_Kawakubo duga Thierry Michel Tzviya_Siegman Ben_De_Meester > > WARNING: Replacing previous Regrets list. (Old list: Luc_Audrain, Phil_M > adans) > Use 'Regrets+ ... ' if you meant to add people without replacing the lis > t, > such as: <dbooth> Regrets+ Bill_Kasdorf > > Regrets: Luc_Audrain Phil_Madans Bill_Kasdorf Ayla_Stein Heather > Agenda: [16]http://www.w3.org/mid/557B46E6.6060506@gmail.com > Found Date: 15 Jun 2015 > Guessing minutes URL: [17]http://www.w3.org/2015/06/15-dpub-minutes.html > People with action items: > > [16] http://www.w3.org/mid/557B46E6.6060506@gmail.com > [17] http://www.w3.org/2015/06/15-dpub-minutes.html > > > [End of [18]scribe.perl diagnostic output] > > [18] > http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm > > > > > > > > -- > > *Julie Morris____* > > Project Manager: Standards & Best Practices____ > > Book Industry Study Group | BISG.org <http://www.bisg.org/>____ > > Tel: 646-336-7141 Ext 14 <tel:646-336-7141%20Ext%2014>____ > > Email: julie@bisg.org <mailto:julie@bisg.org> >
Received on Monday, 15 June 2015 19:31:51 UTC