14:04:27 <RRSAgent> RRSAgent has joined #dpub
14:04:27 <RRSAgent> logging to http://www.w3.org/2015/09/21-dpub-irc
14:04:29 <trackbot> RRSAgent, make logs public
14:04:31 <trackbot> Zakim, this will be dpub
14:04:31 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
14:04:32 <trackbot> Meeting: Digital Publishing Interest Group Teleconference
14:04:32 <trackbot> Date: 21 September 2015
14:04:41 <ivan> zakim, code?
14:04:41 <Zakim> I have been told this is WebEx https://mit.webex.com/mit/j.php?MTID=m09c698f2da7d2f28d301b85cf2d76b08 with password dpub, dial in 644 278 410
14:11:26 <ivan> Regrets: Julie, Mike_Miller
14:11:44 <ivan> Agenda: http://www.w3.org/mid/60044b021c654e5f98268070bc5c796a@CAR-WNMBP-006.wiley.com
14:12:04 <ivan> Chair: Tzviya
14:14:53 <glazou> glazou has joined #dpub
14:19:17 <ivan> Regrets+ Nick
14:36:01 <tzviya> tzviya has joined #dpub
14:36:19 <glazou> Present+ glazou
14:36:31 <glazou> salut ivan
14:42:56 <ivan> bonjour,
14:43:03 <ivan> je suis a un call...
14:43:12 <glazou> np
14:52:10 <pkra> pkra has joined #dpub
14:52:41 <mgylling> mgylling has joined #dpub
14:55:34 <brady_duga> brady_duga has joined #dpub
14:56:04 <Ayla_Stein> Ayla_Stein has joined #dpub
14:56:55 <Ralph> Ralph has joined #dpub
14:57:00 <Ralph> present+ RalphSwick
14:57:23 <tzviya> present+ TzviyaSiegman
14:57:26 <dauwhe> present+ dauwhe
14:57:32 <glazou> hi dauwhe :-)
14:57:54 <dauwhe> Bon soir, Daniel!
14:58:57 <dkaplan3> dkaplan3 has joined #dpub
14:59:03 <tzviya> agenda: https://lists.w3.org/Archives/Public/public-digipub-ig/2015Sep/0138.html
14:59:11 <tzviya> chair: tzviya
14:59:20 <tzviya> scribenick: dauwhe
14:59:21 <brady_duga> present+ duga
14:59:28 <dkaplan3> present+ Deborah Kaplan
14:59:32 <dkaplan3> present+ Deborah_Kaplan
14:59:43 <mgylling> present+ Markus_Gylling
14:59:53 <lrosenth> lrosenth has joined #dpub
15:00:18 <clapierre> clapierre has joined #DPUB
15:00:25 <John_Pedersen> John_Pedersen has joined #dpub
15:00:28 <bjdmeest> bjdmeest has joined #dpub
15:00:33 <ivan> Present: Ivan
15:00:39 <clapierre> present: Charles
15:00:47 <bjdmeest> Present+ Ben_De_Meester
15:00:52 <ivan> Present+ Ivan
15:00:59 <ivan> Present+ Charles
15:01:08 <Karen__> Present+ Karen
15:01:13 <ivan> Present+ Ben
15:01:17 <Ralph> present+ glazou, RalphSwick, TzviyaSiegman, dauwhe
15:01:24 <glazou> Present+ glazou
15:01:36 <lrosenth> present+ Leonard
15:01:38 <Ralph> present+ Deborah_Kaplan, Markus_Gylling
15:01:39 <pkra> Present +Peter Krautzberger
15:01:41 <ivan> Present+ Ayla,
15:01:52 <Vlad> Vlad has joined #dpub
15:01:54 <astearns> present+ Alan Stearns
15:01:54 <ivan> Present Leonard
15:02:22 <ivan> Present+ John_Pedersen
15:02:29 <ivan> Present+ Vlad
15:02:33 <Vlad> present+
15:02:46 <brady_duga> present+ duga
15:03:06 <dauwhe> scribenick: dauwhe
15:03:09 <tzviya> http://www.w3.org/2015/09/14-dpub-minutes.html
15:03:16 <dauwhe> tzviya: first item: approving minutes
15:03:22 <Ralph> agenda: https://lists.w3.org/Archives/Public/public-digipub-ig/2015Sep/0138.html
15:03:28 <dauwhe> ... any comments on minutes?
15:03:36 <dauwhe> ... minutes approved
15:03:53 <dauwhe> ... we've invited Daniel Glazman to talk about...
15:04:20 <dauwhe> glazou: I am the implentor of a wysiwig editor
15:04:28 <dauwhe> ... only native epub2/3 editor
15:04:36 <dauwhe> ... which led me to discover some complications in spec
15:04:46 <dauwhe> ... the very low-level code you have to write to access the package
15:04:48 <pkra> I keep dropping off :(
15:04:53 <astearns> http://bluegriffon.org/
15:05:07 <dauwhe> ... if you want to add metadata, for example
15:05:17 <dauwhe> ... you have to follow a chain of IDs and IDREFs
15:05:26 <dauwhe> ... so I want to hide that complexity behind some APIs
15:05:28 <tzviya> http://www.bluegriffon-epubedition.com/
15:05:34 <dauwhe> ... to open, validate, add files to package
15:05:45 <dauwhe> ... delete files, change metadata
15:05:56 <dauwhe> ... the code you have to write now to do this is huge
15:06:05 <pbelfanti> pbelfanti has joined #dpub
15:06:05 <dauwhe> ... and I think this has hindered the adoption of EPUB3
15:06:17 <pbelfanti> present+ paul belfanti
15:06:20 <dauwhe> ... if we had an EPUB object model with an open-source object model
15:06:29 <dauwhe> ... and a polyfill
15:06:44 <dauwhe> ... right now everyone has to implement everything from scratch
15:06:59 <tzviya> q+
15:06:59 <dauwhe> ... so an object model for epub, or more generally electronic books
15:07:02 <dauwhe> ... would be a good thing
15:07:10 <clapierre> q+
15:07:11 <dauwhe> ... I can elaborate, but this is the summary
15:07:15 <lrosenth> qq+
15:07:15 <tzviya> ack tzv
15:07:16 <dauwhe> tzviya: I have a question
15:07:18 <lrosenth> q+
15:07:38 <Bill_Kasdorf> Bill_Kasdorf has joined #dpub
15:07:41 <dauwhe> ... this group has been talking about shifting the digital publication model towards models available on the open web
15:07:54 <dauwhe> ... are you thinking about EPUB package?
15:08:07 <Bill_Kasdorf> present+ Bill_Kasdorf
15:08:09 <dauwhe> glazou: I want something more general
15:08:26 <dauwhe> ... that would work for HTML in ZIP, for example
15:08:37 <dauwhe> ... I want to hide the complexity of the package, of epub
15:08:49 <dauwhe> ... hide the complexity of *whatever* is implemented
15:08:55 <tzviya> q?
15:09:04 <dauwhe> ... the object model could be mapped to whatever the implementation is
15:09:08 <tzviya> ack cla
15:09:11 <dauwhe> tzviya: I like that idea
15:09:15 <Bill_Kasdorf> +1
15:09:25 <dauwhe> clapierre: I was wondering about a11y features of bluegriffon
15:09:29 <rego> rego has joined #dpub
15:09:39 <dauwhe> ... can you add aria-roles and accessibility features
15:09:45 <dauwhe> glazou: yes I can
15:09:48 <tzviya> ack lr
15:09:59 <dauwhe> lrosenth: I think the idea is very good
15:10:10 <dauwhe> ... especially if it's not package-format-specific
15:10:16 <dauwhe> ... the question is where's the boundary?
15:10:26 <dauwhe> ... is this an API or an object model for any type of publication?
15:10:31 <dauwhe> ... or just OWP publications?
15:10:38 <dauwhe> ... I'm trying to understand the boundaries
15:10:47 <dauwhe> glazou: think of that object model in two layes
15:10:53 <dauwhe> ... the first level is the visible API layer
15:11:07 <dauwhe> ... the second layer underneath is sthe system layer where you call the guts of the package
15:11:13 <dauwhe> ... my primary goal now is EPUB3
15:11:18 <ivan> q+
15:11:19 <Bill_Kasdorf> +1 to the two layered strategy
15:11:30 <dauwhe> ... but that second layer could be different for different implemenations epub2, mobi, whatever
15:11:34 <dauwhe> ... it's doable
15:12:01 <dauwhe> lrosenth: all the examples you gave are variants of the same thing, for example PDF
15:12:22 <dauwhe> ... do you envision that same object model could apply to something completely different
15:12:36 <dauwhe> ... or does it only apply to OWP resources bundled togehter
15:12:49 <dauwhe> glazou: I think it could be open to absolutely everything
15:13:09 <dauwhe> ... it's just a question of writing a layer that's between the PDF and the API
15:13:26 <mgylling> q+
15:13:30 <dauwhe> ... in theory, yes.
15:13:42 <lrosenth> q+
15:13:47 <dauwhe> ... the lower level would have to be rewritten for every format you want to reach
15:13:55 <tzviya> ack iv
15:13:59 <dauwhe> ... think of it as a "publication object model"
15:14:04 <dauwhe> ivan: coming back to epub
15:14:15 <clapierre> clapierre has left #dpub
15:14:31 <dauwhe> ... how does this API deal with other object models, like HTML
15:14:37 <dauwhe> ... how are these combined?
15:14:43 <dauwhe> glazou: I don't understand the Q
15:15:02 <dauwhe> ivan: I understand that from your API I reach a specific resource in the package, for exmaple HTML5
15:15:13 <dauwhe> ... do you try to parse the HTML with your stuff?
15:15:21 <dauwhe> glazou: I've not completely written this
15:15:32 <dauwhe> ... imagine you open a package and get list of resources and fetch one
15:15:42 <dauwhe> ... if it's HTML, what you retrieve is the HTML DOM
15:15:54 <dauwhe> ... if you want reach it as a file, you just need another set of API
15:16:12 <dauwhe> ... it's not really a file system
15:16:22 <clapierre> clapierre has joined #DPUB
15:16:31 <dauwhe> ... the idea is to as soon as you can fall back to existing DOM APIs you do so
15:16:31 <tzviya> ack mg
15:16:42 <dauwhe> mgylling: just to be clear
15:16:52 <dauwhe> ... I thought I heard you say an API for reading and writing
15:17:09 <dauwhe> ... this is for reading systems as well as authoring tools?
15:17:13 <dauwhe> glazou: absolutely
15:17:21 <dauwhe> ... add stuff, delete stuff, change stuff...
15:17:32 <dauwhe> ... thing of all the things you do to a DOM tree
15:17:45 <dauwhe> ... you should be able to do all those things to a publication package
15:17:58 <Bill_Kasdorf> Also +1 to always referring to what we are talking about as "a publication package."
15:18:00 <dauwhe> mgylling: one issue on the reading side is the Readium foundation
15:18:05 <dauwhe> ... they have a read-only API
15:18:18 <tzviya> ack lr
15:18:20 <dauwhe> ... would be interesting to compare your proposal to what Readium has
15:18:31 <rego> rego has joined #dpub
15:18:34 <dauwhe> lrosenth: focused on a JS-based API model
15:18:46 <dauwhe> ... do you think this could extend to a REST model or other languages
15:19:01 <dauwhe> glazou: I mentioned JS because this is obvious and immediate usage
15:19:08 <dauwhe> ... clearly JS is not my sole focus
15:19:15 <dauwhe> ... should be buildable in C++
15:19:30 <dauwhe> ... a REST API should be possible in an ideal world
15:19:41 <dauwhe> lrosenth: are you designing it around JS or a generic object model?
15:19:56 <dauwhe> glazou: the latter. I'm writing web IDLs, not JS
15:20:33 <dauwhe> ... it's a lot of work but wanted to talk to people before investing lots of time
15:20:49 <dauwhe> tzviya: this is very much in line with what we've been working on lately
15:21:00 <dauwhe> ... like our requirements for packaging web apps
15:21:07 <dauwhe> ... the concepts work very well together
15:21:14 <dauwhe> ... what the next step is is a good question
15:21:20 <lrosenth> q+
15:21:22 <dauwhe> glazou: I started writing web IDLs
15:21:28 <dauwhe> ... it's a lot of effort
15:21:38 <dauwhe> ... having a place to discuss this with people would be good
15:21:44 <ivan> q+
15:21:49 <dauwhe> ... I'm a newcomer to world of dpub
15:21:56 <dauwhe> ... I could miss things, make bad design choice
15:22:02 <dauwhe> ... having discussion would be good
15:22:10 <dauwhe> tzviya: are you on EPUB31 ML?
15:22:12 <dauwhe> glazou: I am
15:22:18 <Ralph> [I wonder to what extent Markus and other EPUB architects have been thinking of an object model in the background]
15:22:20 <dauwhe> tzviya: we're having this kind of discussion there, too
15:22:34 <dauwhe> glazou: my problem is that we should go quite fast
15:22:45 <dauwhe> ... an OM to be designed should take 18 months max
15:22:51 <dauwhe> ... it will pass quite quickly
15:22:56 <Bill_Kasdorf> Fast is good for this, because it's foundational for other specs and implementations
15:23:10 <dauwhe> ... the more I look at the market the more we're limited by the lack of such a framework on a stable OM
15:23:15 <dauwhe> ... I think it's a market enabler
15:23:18 <tzviya> ack lr
15:23:27 <dauwhe> lrosenth: I think it's a good idea
15:23:46 <dauwhe> ... my biggest comment would be that this object model needs to align with work on identification
15:24:06 <dauwhe> ... whatever work we do in this area is done by same group or in close collaboration
15:24:23 <dauwhe> glazou: my only goal is to make that happen and I'll work with anyone, W3C, IDPF, wherever
15:24:25 <tzviya> ack iv
15:24:31 <dauwhe> ivan: putting on w3c hat
15:24:36 <dauwhe> ... what's next step?
15:24:50 <dauwhe> ... having discussion based on more specific document would be great
15:24:57 <dauwhe> ... I think this group is the right forum
15:25:07 <dauwhe> ... don't want to argue whether it's here or IDPF
15:25:11 <dauwhe> glazou: I have a question
15:25:19 <dauwhe> ... this group is not tailored to published specs
15:25:30 <dauwhe> ivan: initial discussion stays informal
15:25:40 <dauwhe> ... with new charter we can do proof-of-concept spec
15:25:44 <dauwhe> ... but won't be REC
15:25:56 <dauwhe> ... if it should be REC then we must go down WG route
15:26:08 <dauwhe> ivan: my suggestion would be to write a note publiched by DPUB
15:26:15 <dauwhe> ... explaining why an OM would be good
15:26:21 <dauwhe> ... and suggesting ways to reach a REC
15:26:33 <dauwhe> ... I think it's a joint effort between IPDF and W3C
15:26:42 <dauwhe> ... higher-level objects are IDPF
15:26:43 <tzviya> s/IPDF/IDPF
15:26:51 <dauwhe> ... but objects to be retrieved are DOM nodes
15:27:04 <dauwhe> ivan: let's not get into "cuisine" of where/how it gets done
15:27:20 <dauwhe> ... tzviya and mgylling are the chairs, they can decide if this is the place to publish a note
15:27:34 <dauwhe> ... I'd go further, and publish a skeleton of the interface
15:27:46 <mgylling> q+
15:27:52 <dauwhe> ... whatever it is, we'll have to convince people to devote time and energy to a WG
15:27:55 <dauwhe> glazou: I can start that
15:28:21 <lrosenth> POM works for me...
15:28:22 <dauwhe> ... I can start that document, but what would be the title? Publications Object Model?
15:28:35 <dauwhe> ivan: we've had a hundred-email discussion on terminology
15:28:37 <Ralph> "curated document object model" - cdom ;)
15:28:41 <mgylling> q-
15:29:02 <dauwhe> tzviya: we haven't talked about portable object model :)
15:29:09 <dauwhe> mgylling: it's apple not potato
15:29:13 <glazou> ;-)
15:29:24 <dauwhe> ... I almost forgot
15:29:30 <dauwhe> ... Ivan covered it
15:30:05 <dauwhe> ... we need to get IPDF implementors a way to be involved
15:30:10 <dauwhe> ... maybe it's a CG
15:30:19 <dauwhe> glazou: I have no religion about that
15:30:22 <dauwhe> ... whatever works
15:30:25 <dauwhe> ivan: let's not worry
15:30:35 <dauwhe> ... let's get a document and then see where it goes
15:30:36 <dauwhe> tzviya: OK
15:30:41 <dauwhe> ... we are at the half-hour
15:30:49 <dauwhe> ... we'll try to get something started
15:31:01 <dauwhe> ... we can tie in some loose ends... packaging, glossary, etc
15:31:11 <dauwhe> ivan: each word is a hundred emails ;)
15:31:38 <dauwhe> tzviya: as soon as glazou said publication object model it sounded good
15:31:44 <lrosenth> +1 on POM
15:31:53 <pbelfanti> +1 on POM
15:32:00 <Bill_Kasdorf> +1 but I prefer "Publication" to "Publishing"
15:32:09 <pbelfanti> As long as we don't get sued by Apple
15:32:39 <Bill_Kasdorf> It is also promoted as a healthy thing a la "POM Wonderful"
15:33:03 <dauwhe> tzviya: any more comments?
15:33:09 <dauwhe> everyone: silence
15:33:15 <dauwhe> tzviya: thanks glazou!
15:33:19 <Bill_Kasdorf> Seriously I like the pomegranate metaphor because it
15:33:32 <Bill_Kasdorf> 'because it's a package with lots of little things in it
15:33:32 <dauwhe> tzviya: I forgot to introduce my colleage John Peterson
15:33:45 <dauwhe> John_Pedersen: I've been involved in developing our schemas in Wiley
15:33:47 <tzviya> s/Peterson/Pedersen
15:33:53 <dauwhe> ... we're getting involved in all things digital
15:33:55 <dauwhe> tzviya: OK
15:34:06 <dauwhe> ... John is particularly interested in Math
15:34:19 <dauwhe> John_Pedersen: it is my background, I was a math professor
15:34:28 <dauwhe> tzviya: Peter, we'll turn it over to you
15:34:35 <dauwhe> pkra: I hope I figured them out :)
15:34:42 <dauwhe> ... where should we start?
15:34:46 <dauwhe> ... should I recap?
15:34:48 <ivan> topic: MathML discussions II
15:34:48 <dauwhe> mgylling: yes please
15:35:02 <dauwhe> pkra: the most obv. Q is where is this coming from
15:35:20 <dauwhe> ... most critical one is that browser dev for MathML support has stalled in the past year
15:35:33 <dauwhe> ... has never been driven by browser vendors but by unpaid volunteers
15:35:38 <dauwhe> ... this is the base problem
15:35:44 <dauwhe> ... we have MathML but not implemention
15:35:53 <dauwhe> ... 2nd problem is MathML is in maintenance mode
15:35:59 <dauwhe> ... Math WG is up for rechartering
15:36:07 <dauwhe> ... maintenance mode would have some consequesnce
15:36:18 <dauwhe> ... the 3rd issue is new tools for Math on web
15:36:25 <dauwhe> ... new features in MathJAX
15:36:42 <dauwhe> ... ability to convert MathML into something that looks good
15:36:44 <Ralph> -> http://www.w3.org/2015/09/14-dpub-minutes.html#item01 14-Sep MathML discussion (part 1)
15:36:50 <dauwhe> ... pre-render into HTML or SVG
15:37:02 <dauwhe> ... so you have good rendering but not actual MathML in the page
15:37:23 <dauwhe> ... other tools like ??? that don't even use MathML and go to LaTex days
15:37:35 <tzviya> s/???/KaTeX
15:37:36 <dauwhe> ... or tools like PDF.js that just convert something into HTML
15:37:45 <dauwhe> ... my personal perspective:
15:37:58 <dauwhe> ... browser development is not working out
15:38:03 <dauwhe> ... we see no interest
15:38:16 <dauwhe> ... this is a huge issue
15:38:28 <dauwhe> ... 2nd assumption is how mathml should be realized in browsers
15:38:33 <dauwhe> ... for me that means HTML+CSS
15:38:48 <dauwhe> ... in the aughts it was a black box for rendering
15:38:57 <dauwhe> ... some people think it should be in a separate renderer
15:39:17 <dauwhe> ... at end of call last week, Ivan asked what I would do iif I coudl do anything
15:39:30 <dauwhe> ... the key problem is that browser vendors don't care
15:39:30 <rego> rego has joined #dpub
15:39:37 <dauwhe> ... which has tech and personal connotation
15:39:44 <dauwhe> ... they're not involved in Math WG
15:39:51 <dauwhe> ... haven't given input to spec
15:40:02 <dauwhe> ... fundamentally there's no interest
15:40:10 <dauwhe> ... so we have to make them interested
15:40:19 <dauwhe> ... there are areas that we can make them interested
15:40:28 <dauwhe> ... typographic detail and reliability
15:40:55 <dauwhe> ... if math layout was implemented you'd get better typography
15:41:02 <dauwhe> ... odd way to get there
15:41:07 <dauwhe> ... large areas are shared
15:41:20 <dauwhe> ... multiscript, sub/superscript and pre/post
15:41:27 <dauwhe> ... fancy borders
15:41:35 <dauwhe> ... lots of math is just fancy borders
15:41:43 <dauwhe> ... there's layout and semantics
15:42:01 <dauwhe> ... on layout end, there's interest from Houdini that we might pursue
15:42:16 <dauwhe> ... on the semantic side, there's the big glaring hole of the ARIA spec
15:42:22 <dauwhe> ... which has just one "Math" role
15:42:32 <dauwhe> ... and there seems to be some interest from ARIA
15:42:34 <Bert> Present+ Bert
15:42:42 <dauwhe> ... since renderers can't rely on MathML
15:42:59 <dauwhe> ... you want to expose underlying semantics
15:43:06 <tzviya> q?
15:43:09 <dauwhe> ... one more thing
15:43:17 <dauwhe> ... ivan asked why browsers don't care
15:43:25 <dauwhe> ... mathml is a top-down solution
15:43:53 <lrosenth> q+
15:43:55 <dauwhe> ... it assumes you want to solve fundamental problems before you want to help your layout along
15:43:57 <tzviya> ack lr
15:44:17 <dauwhe> lrosenth: are you suggesting that ARIA would be the direction to apply semantics to math rather than many other directions?
15:44:20 <dauwhe> ... why ARIA?
15:44:34 <dauwhe> pkra: I'm not sure if ARIA is the right direction
15:44:43 <dauwhe> ... with the tools I use for math on the web
15:45:30 <dauwhe> ... you can't use the endroot element and use clever CSS, you must use dom injection to build layout around it
15:45:59 <dauwhe> ... feels similar where you want to build button but you can't use button element, but must use ARIA role="button"
15:46:09 <dauwhe> ... I"m not talking about detailed semantics
15:46:20 <dauwhe> ... but I think there's low-hanging fruit to help a11y
15:46:25 <ivan> q+
15:46:29 <lrosenth> q+
15:46:29 <dauwhe> ... like presentation MathML-level semantics
15:46:30 <tzviya> ack iv
15:46:42 <dauwhe> ivan: I'd come back to presentation side
15:46:51 <dauwhe> ... I'm not really clear on the direction you want to propose
15:47:07 <dauwhe> ... current approach is that I put in my HTML5 some MathML markup
15:47:20 <dauwhe> ... the script just catch this stuff then does complex JS rendering
15:47:24 <dauwhe> ... is that correct
15:47:27 <dauwhe> pkra: yes
15:47:42 <dauwhe> ... I see a strong move towards doing the JS on the server rather than the client
15:47:53 <dauwhe> ivan: there's a move to do all that on the server
15:48:07 <dauwhe> ... take that element and turn it into clever html and CSS, and that's all my client sees
15:48:13 <dauwhe> ... is that what you're proposing?
15:48:18 <dauwhe> pkra: it's what we're facing
15:48:30 <rego> rego has joined #dpub
15:48:45 <dauwhe> ... developers are eager to not do MathML rendering on client
15:49:17 <dauwhe> ivan: that means if I am a random user who writes HTML with math then I have to run it through a special server
15:49:25 <tzviya> q?
15:49:27 <dauwhe> pkra: it's not like the client side is going away but you can do both
15:49:36 <dauwhe> ... professionals can use the complex solution
15:49:58 <dauwhe> ... there are people that throw markdown on their web page and have JS convert it on the fly
15:50:09 <dauwhe> ... but we'll see more and more poeple doing it on server
15:50:17 <dauwhe> ... but then you disconnect the MathML from the output
15:50:24 <dauwhe> ivan: that's where ARIA would come in
15:50:27 <dauwhe> pkra: yes
15:50:45 <dauwhe> ... right now you could just put MathML beside rendering and hide it
15:50:52 <dauwhe> ... you want to expose MathML to AT
15:51:00 <tzviya> q?
15:51:07 <dauwhe> ... now you have AT content not connected to visual
15:51:16 <dauwhe> ivan: still concerned about client side
15:51:30 <dauwhe> ... they use the term "polyfill" as the tool that solves every misery of the world
15:51:56 <dauwhe> ... last time you remarked that MathJax? is not good at polyfilling
15:52:13 <dauwhe> pkra: MathJax is not a pollyfill in the modern sense
15:52:39 <dauwhe> ... a polyfill should be as similar to a native implementaiton as possible
15:52:48 <dauwhe> ... and lay the basis for the native implementation
15:52:53 <dauwhe> ... for example, picturefill
15:53:04 <dauwhe> ... you develop spec alongside polyfill
15:53:12 <dauwhe> ... with MathML you could imagine this
15:53:25 <dauwhe> ... you could write a polyfill that creates custom elements etc
15:53:52 <dauwhe> ... make complicated custom element structure
15:53:55 <dauwhe> ... we don't work that way
15:54:06 <dauwhe> ... it seems like a difficult process for performance
15:54:22 <dauwhe> ... you don't want to expose any APIs but the DOM
15:54:42 <dauwhe> ... you would expect dev to manipulate DOM as if it was a normal MathML implemenation
15:54:45 <tzviya> q?
15:54:46 <dauwhe> ... but no one is doing that
15:55:01 <dauwhe> ivan: You don't think there would be interest?
15:55:10 <dauwhe> pkra: I don't think it will solve the core problems
15:55:16 <lrosenth> waiting for Ivan to finish up on the client discussion…
15:55:21 <dauwhe> ... it wouldn't solve layout, just shove it into shadow DOM
15:55:30 <dauwhe> ... it wouldn't show us a way towards native
15:55:37 <dauwhe> ... make it easier for browsers to ignore
15:55:48 <dauwhe> ... third, it doesn't solve any of the non-JS problems
15:55:54 <dauwhe> ... since web components require JS
15:55:59 <dauwhe> tzviya: is there a solution?
15:56:11 <Ayla_Stein> need to run to a meeting, thanks!
15:56:16 <dauwhe> ... it sounds like we're saying there are a lot of different bad solutions
15:56:29 <dauwhe> pkra: we're not a polyfill because web components aren't yet availabe
15:56:37 <dauwhe> ... we've decided to ignore this
15:56:48 <dauwhe> ... because the real problem is to render in HTML and CSS
15:57:09 <dauwhe> ... let's bridge the gap and get the rendering to be easier
15:57:16 <dauwhe> ... have more of it done by native
15:57:21 <dauwhe> ... make this usable to AT
15:57:29 <dauwhe> ... have a way of exposing semantics
15:57:51 <dauwhe> ... it's like grid before grid layout, or flex before flexbox
15:57:59 <dauwhe> ... we need new stuff to make this possible
15:58:11 <tzviya> ack lr
15:58:15 <dauwhe> ... just a personal opinion
15:58:24 <dauwhe> lrosenth: that makes perfect sense
15:58:38 <dauwhe> ... my concern is that I don't want us to lose the semantics
15:58:47 <dauwhe> ... or redo the syntax for different people
15:58:55 <dauwhe> ... AT knows how to deal with MathML
15:59:04 <dauwhe> ... but layout doesn't know how to deal with MathML
15:59:19 <dauwhe> ... so let's not throw away the existing work in order to make browser vendors happy
15:59:23 <dauwhe> tzviya: to flip that
15:59:29 <dauwhe> ...it's used on back end now
15:59:36 <dauwhe> ... it's used in processing
15:59:46 <dauwhe> ... how a11y is it in real world?
15:59:59 <dauwhe> ... if the browsers aren't using it, how used is it, really?
16:00:22 <dauwhe> ... maybe not scrapping mathml but building on it
16:00:32 <Bill_Kasdorf> the company I work for creates thousands of MathML expressions daily. It is used a LOT, just not in browsers.
16:00:40 <dauwhe> lrosenth: you need all groups in the room--AT, renderers, semantics
16:00:49 <dauwhe> ivan: this has been tried and failed for the last twenty years
16:01:02 <pkra> I could go on ...
16:01:04 <dauwhe> tzviya: at least ARIA has browsers and AT vendors in the same room
16:01:12 <tzviya> q?
16:01:30 <dauwhe> tzviya: we're not talking about scrapping MathML
16:01:31 <rego> rego has joined #dpub
16:01:38 <dauwhe> ivan: the question for me
16:01:54 <dauwhe> ... do we have to modify mathml to make this server-side processing more streamlined?
16:02:09 <pkra> +1 to dauwhe
16:02:13 <dauwhe> tzviya: we're over time here
16:02:20 <dauwhe> ... we'll talk to y'all next week
16:02:25 <clapierre> clapierre has left #dpub
16:02:27 <dauwhe> all: beep beep beep
16:03:15 <ivan> rrsagent, draft minutes
16:03:15 <RRSAgent> I have made the request to generate http://www.w3.org/2015/09/21-dpub-minutes.html ivan
16:03:47 <ivan> trackbot, end telcon
16:03:47 <trackbot> Zakim, list attendees
16:03:47 <Zakim> As of this point the attendees have been resets, the, list, Ben, glazou, RalphSwick, TzviyaSiegman, dauwhe, Leonard, Deborah_Kaplan, Markus_Gylling, Ayla, Alan, Stearns,
16:03:50 <Zakim> ... John_Pedersen, Vlad, duga, paul, belfanti, Bill_Kasdorf, Bert
16:03:55 <trackbot> RRSAgent, please draft minutes
16:03:55 <RRSAgent> I have made the request to generate http://www.w3.org/2015/09/21-dpub-minutes.html trackbot
16:03:56 <trackbot> RRSAgent, bye
16:03:56 <RRSAgent> I see no action items