See also: IRC log
trackbot, start telecon
<trackbot> Meeting: Digital Publishing Interest Group Teleconference
<trackbot> Date: 27 July 2015
<pkra> +present Peter Krautzberger
scribenick mgylling
<scribe> scribenick: mgylling
<tzviya> http://www.w3.org/2015/07/13-dpub-minutes.html
tzviya: any comments?
… minutes approved
<tzviya> https://docs.google.com/document/d/1ShvCn3roYENFMAqYhFL169nTeov1f-1OL6rsJa6nDZk/edit
tzviya: just a draft in google docs for now, I’ll walk through where we are
… we’ve talked about it being an abstraction, at least in the online mode. In the online mode, scripting and service workers can handle lots of this stuff
… I’ve divided the document into online and offline state, the only thing unique to offline is portability
tzviya: it becomes unclear in my mind if this is part of packaging requirements, or if its requirements on the content, e.g. navigation
BillK: small comment, strikes me that as we struggle with the global unique identifier, most sectors of publishing industry is struggling with work identifier, it strikes me that from a functional pov, maybe package identifiers are what we need
tzviya: right, I dont think its this group’s task to solve work identifiers
charles: we may have certain pieces optional when going to the offline state, e.g. video may or may not be included
Tim: I basically agree with the value and importance of the package identifier, but we also need to keep in mind that items within a package may have preexisting identifiers
… e.g. DOIs on articles within the package
BillK: thats exactly what I meant, the components are gonna have all kinds of identifiers, thats fine, what we are after is the package itself
tzviya: one section in the doc says package within a package, we should add a note there about retaining identifiers
<tzviya> markus: Should be make a clearer distinction between offline and portable?
<pkra> transferable
<tzviya> ...offline may use service workers to create a temporary cache
<tzviya> ...portable is completely network-free
<tzviya> tzviya: can't the portable document come from the online version?
<tzviya> markus: yes, but let's clarify what this document is describing
<pkra> raising hand wildly...
pkra: main difference in the discussion just now seems to be the transferability, being able to take whats in the browser and run with it
… just a rough idea, somewhat unfortunate discussion on mailing list that I cause by pointing to save as PDF in iOS 9, this is the same use case
BillK: key concepts that I would associated with the packaged state are persistence and independence of any particular browser or browser cache
<pkra> +1
<pkra> :(
<pkra> O:-)
<pkra> typo.
tzviya: I think we all agree, should clarify terminology in the document
pkra: the work has been progressing nicely, we have been processing the comments by hand, 3/4 done
<pkra> https://docs.google.com/spreadsheets/d/10Uvg0ile7qiygyDBocnN882cMmIub5wR200fFIoMFUs/edit?usp=sharing
… that will be an important part of the note we are creating
… the spreadsheet gives an idea of the slicing and dicing that we can do
… get a more detailed look and dive into the data a bit more
… we welcome feedback
TimCole: one thing thats interesting about the survey was how many people wear multiple hats, when you slice the data by subject domain you get many apparent responses
… the slices are now anonymized… will soon have a graphical update with bar charts
… a lot of concern with the issues we expected
pkra: a couple of questions where the data essentially shows that we didnt get the point across in the question
… when people talk browser implementations when we asked about standards, things like that
pkra: the basic interest on my end developed when MathJAX had a call with AT vendors, somebody noted that the math role doesnt serve any purpose at the moment, I looked into more detail
<pkra> http://w3c.github.io/aria/practices/aria-practices.html#math
… this is the one from the current workning draft, both of them are very empty when it comes to the math role itself, the main use case is on the math element where it is implicit so its meaningless
… the problem is that the actual standard that we have, MathML, exists but isnt widely implemented, really sketchy browser support
… the only two implementations is entirely volunteer driven
… native support isnt something that seems to be happening, that makes the need for ARIA really necessary
… there is no polyfill in the modern sense for MathML
… since there really aren’t any advanced layout polyfills out there
… what we do have instead is “converters” such as MathJAX
… in that situation, ARIA roles would fit very well, you should be able to use e.g. SVG and expose the underlying structure
… so thats basically the problem and I am interested in solving it, limited interest in Math WG
markus: are you envisioning an entire vocabulary of math terms?
pkra: that might be one of the answers, but I don’t know
… right now a good solution could be to dump mathml source into an aria-mathml element
… chromevox just exposes the underlying MathML
… having a vocab might be the right thing
tzviya: I did mention to PF, Janina had hoped to join
pkra: if you wanted to do a polyfill in the modern sense, you could use web components + shadow dom, but you couldnt do this without client-side javascript
<astearns> I believe another problem is that web components still won't have enough glyph layout capabilities to do better than SVG
Bill_Kasdorf: I am struggling with the issue, a sense of proportion, what are you targeting here, at one end of the spectrum, the close to meaningless math role, and on the other side, all terms from MathML
… how could this be done in a sufficiently useful way without duplicating MathML?
pkra: if we were to duplicate
MathML, we could generate HTML that looks like MathML and could
behave to AT as MathML
... the motivation is that we can’t use MathML because browser
wont render it, we need a way to put MathML out there
… a static realization of Math in HTML or SVG
… on role value for each MathML element would be total overkill obviously… trying to find what the sweet spot would be
<tzviya> https://www.w3.org/2002/09/wbs/1/tr-design-survey-2015/
tzviya: we can look at latinReq to see what our current styles look like
… no we can’t!
<tzviya> http://www.w3.org/TR/dpub-metadata/
… thats what our current styles look like, the survey asks what we like about current styles
<tzviya> https://drafts.csswg.org/css-text-3/
<Bert> (Funny, the maximum line length is exactly what I dislike. :-) It requires me to make a user style sheet if I want to see more text at the same time.)
clapierre: noticed there’s the section 4.1.1 where they have these different colored blocks, for me is hard to see, issue with contrast
<pkra> that's custom to that doc though?
<astearns> max width is the main thing I do like. I don't want to have to change my browser width to be able to read with proper line lengths :)
<clapierre> both
pkra: looks like its not part of the styling package, but document-specific
<clapierre> good :)
<tzviya> https://lists.w3.org/Archives/Member/w3c-ac-members/2015JulSep/0021.html
tzviya: we encourate everybody to
vote, we need 20 votes to be renewed, please ask your AC rep,
vote ends August 20
... so far we have seen only three votes
<pbelfanti> you will have my vote
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/approvied/approved/ Succeeded: s/dodnt/didnt/ Succeeded: s/verybody/everybody/ Found ScribeNick: mgylling Inferring Scribes: mgylling Present: clapierre Tzviya_Siegman Deborah_Kaplan astearns Bill_Kasdorf Peter Krautzberger Markus Gylling Tim_Cole Julie_Morris Regrets: Ivan Thierry Chris Brady Dave Laura Nick Luc Phil Michael Vladimir Zheng Agenda: https://lists.w3.org/Archives/Public/public-digipub-ig/2015Jul/0064.html Found Date: 27 Jul 2015 Guessing minutes URL: http://www.w3.org/2015/07/27-dpub-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]