- From: Thierry MICHEL <tmichel@w3.org>
- Date: Mon, 17 Aug 2015 18:16:17 +0200
- 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
http://www.w3.org/2015/08/17-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
17 Aug 2015
[2]Agenda
[2] http://www.w3.org/mid/55CD1C5A.6030302@gmail.com
Attendees
Present
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.
Regrets
Alan Stearns, Ben De Meester, Ayla Stein, Paul
Belfanti, Luc Audrain.
Chair
Markus Gylling
Scribe
Tzviya Siegman, Nick Ruffilo
Contents
* [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
that."
<clapierre1> +1
+1
<HeatherF> +1
Markus: "OK - ARIA Described-at meeting recap."
Deborah: "It was fine - it could have gone much...
differently..."
<tzviya> current requirements for extended descriptions:
[9]http://www.w3.org/dpub/IG/wiki/Publisher_requirements_for_ex
tended_descriptions
[9]
http://www.w3.org/dpub/IG/wiki/Publisher_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
reasonable."
...: "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
browser"
<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
'objection'."
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?"
<dauwhe>
[10]https://html.spec.whatwg.org/multipage/forms.html#the-detai
ls-element
[10]
https://html.spec.whatwg.org/multipage/forms.html#the-details-element
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. "
<mgylling>
[11]http://w3c.github.io/dpub-pagination/priorities.html
...: "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
content?"
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"
+1
<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."
<tzviya>
[12]http://www.w3.org/TR/css-cascade-3/#cascading-origins
[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
themselves..."
...: "We need a new mechanism for advanced customization of
styles."
<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
implementation."
<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
[13]http://www.w3.org/TR/2012/WD-css3-conditional-20120911/#at-
document and
[14]https://developer.mozilla.org/en-US/docs/Web/CSS/@document
[13]
http://www.w3.org/TR/2012/WD-css3-conditional-20120911/#at-document
[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
functionality."
<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
mis-feature."
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
contribute
<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/
scribe/
[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