<dauwhe> we need a scribe

<wendyreid> scribenick: wendyreid

dauwhe: Let's get started, I want to remind everyone about EPUBCheck fundraising
... order your tshirt today! and were designed by Iris
... tshirts aren't enough, so ask your companies to send money
... especially Amazon
... any new members?
... let's move on to EPUB 3.2 Github issues, there are a few issues that are priorities for EPUBCheck
... I'm going to change the agenda to address these issues

<dauwhe> https://github.com/w3c/publ-epub-revision/issues/1237#issuecomment-472822055

dauwhe: #1237 fallback requirements for the picture element
... Romain did some more research on how imgs are taken out of the picture element so believes we should look at this again
... does anyone have any thoughts
... The suggestion was to change the rules so that if an img is not the child it can use a source fallback, or sourceset set to a foreign type

mattg: I was talking about this with Romain this morning because of the processing model
... It's not always going to be the case that src is in the list of available srcs
... If any of the srcset elements set a width, what is in the src action will not be seen
... I don't know how to disagree with what he has proposed, if we want to ensure a fallback, we need to consider changing the wording the in spec

Makoto: Does his proposal intend to include both?

mattg: I don't know if manifest fallbacks should be injected in the HTML, but considering it exists, and it's the defined fallback method for img elements, we are taking advantage of that

Makoto: is it possible to mandate the usage of core media types?

mattg: I don't know if that would fly, it would mean people would be unable to use a foreign resource
... I would be happy if we could get rid of the epub defined fallbacks

Makoto: We might want to throw away the fallback

dauwhe: It does seem to be a worthy longer term goal

Makoto: Yes, but then what is the point of complicating the fallback mechanisms

<garth> /rakuten.zoom.us/j/324554862” on the invite… is there a normal dial-in?//rakuten.zoom.us/j/324554862” on the invite… is there a normal dial-in?

dauwhe: The other question, is what Romain described ???

mattg: Once Romain makes the change it is possible

dauwhe: If we can make EPUBCheck aligned with what is possible, and people aren't using non-core media types anyway, it keeps us covered
... we still make sure we get to a core media type, the spec is weirder, we go home
... Do we have general agreement to adopt Romain's wording?

<mattg> +1

<tzviya> +1

<dauwhe> +1

+1

<Naomi> +1

<gpellegrino> +1

<scribe> scribenick: Naomi

<dauwhe> https://github.com/w3c/publ-epub-revision/issues/1241

dauwhe: larger question of where epub:type is appropriate

Matt: heart of the definition of semantic inflection
... doesn't make a lot of sense that it's left open
... could have purpose in metadata
... if it's going to cause problems and invalidate content then I'll cave

tzviya: agrees with matt, even if it won't cause problems in the real world its bad practice

Naomi: been putting things on the body (epub:types and roles) and it's now causing errors

Matt: it's the roles on the body that aren't allowed

tzviya: was concerned about this

Avneesh: concerned about the backwards compat issues
... add normative text to discourage this in the future

<Avneesh> correction: ad non-normative text to discourage

mattg: not even sure if we can note in the spec, epubcheck was just very lax and have upgraded the schema

<Avneesh> EPUBCheck RC is out. Please report as much issues as you can.

<Avneesh> It will be out soon, sorry not out at this point.

Naomi: depreciated epubtypes are causing errors

<tzviya> log your epubcheck issues at https://github.com/w3c/epubcheck/issues

mattg: been waiting for someone to bring this up, we should probably make this an info statement

<tzviya> +1 to usage messages

<mateus> +1

dauwhe: that would convey our intent

+1 to usage message

<mattg> +1

<dauwhe> +1

<duga> +1

<wendyreid> +1

dauwhe: do we have consensus? ...silence

DId we end up anywhere with the issue we were supposed to be talking about?

<Avneesh> It is already in to do list of Ace

scribe: Do we need to file an ACE issue?
... question is how to handle epub:type in <head> and decedents

tzviya: should leave as-is to avoid breaking backlist

dauwhe: add a note that if you leave it in <head> a polite Canadian will come to your door and disagree
... leave role alone, it's not ours to mess with
... got to a better place there

<dauwhe> https://github.com/w3c/publ-epub-revision/issues/1070

dauwhe: what is our reference to web IDL going to be
... do we use a "stable" reference or an accurate reference?

mattg: always erred on the side of recommendations. It is a huge concern to leave it as-is? has it significantly changed

dauwhe: steady stream of commits, hard to tell since it's more of a living standard
... doesn't bring me any closer to a decision. appears web IDL 2 won't ever exist

tzviya: can ask ivan what the w3c should do, "evergreen" standard is coming in the future

dauwhe: web publications refers to both
... do we have ISO issues because of this?
... doesn't affect anything, should we just point at the rec and not worry about it?

<dauwhe> +1

mattg: sounds good to me

+1

<dauwhe> https://github.com/w3c/publ-epub-revision/issues/1212

dauwhe: MathML descriptions
... spec has MathML restrictions, some of which seem a little more draconian than necessary

mattg: we were trying to come up with a limited MathML set to get support built
... not sure it's relevant anymore

dauwhe: drop the restrictions, shouldn't restrict things we are borrowing from other specs

mattg: yes that makes things easier

dauwhe: allowing more means it's backwards compatible

<dauwhe> +1

<mattg> +1

<tzviya> +1

dauwhe: objections?...silence

+1

<mateus> +1

<dauwhe> https://github.com/w3c/publ-epub-revision/issues/1236

dauwhe: every issue is worse than the one before
... SVG and expressing the initial containing block

mattg made an edit to the spec. Does this address the issue?

mattg: we reverted to 3.0.1, romain doesn't like that we use viewport, thinks we should leave it to SVG rendering

duga: might need a term that is not "initial containing block"
... look at aspect ratio, then make object as big as you can make it. SVG can't determine that itself. This is spine level SVG so can't get page area from HTML.

garth: If we don't stay the course, things are going to break in RS
... 3.0.1 is good enough. ICB isn't a great term but we don't have a better one

dauwhe: making up words is bad

<garth> +1

<dauwhe> +1

<mattg> +1

<duga> +1

dauwhe: close this issue and never speak of this again?

+1

<wendyreid> +1

<dauwhe> https://github.com/w3c/publ-epub-revision/issues/1238

dauwhe: talked about this in epubcheck terms
... current loopholes allow HTML in iframes
... should the spec match what we decided for epubcheck

garth: not a lot of religion on this one, don't change the spec to fix the bug, but leave the bug.

mattg: Are we allowing all foreign resources or just this one?

dauwhe: sneaking this one in the back door since it's not aparently breaking anything

duga: don't ask, don't tell :p

mattg: in favor of HTML, it doesn't mean that all vendors are going to accept it. It might get rejected by retailers anyway

dauwhe: could have HTML as a fallback in the current system

Garth: all agreeing to be bad kids

<dauwhe> +1

<garth> +1

dauwhe: any objections?

<duga> +1

<mattg> +1

<mateus> no objections; +1 on no change

<tzviya> +1

<dauwhe> https://github.com/w3c/publ-epub-revision/issues/1195

dauwhe: digital signatures exists but are currently ignored
... add a note that including this feature doesn't guarantee it will be affected

<mateus> +1

garth: some proposed text...agrees with dauwhes comment

<garth> +1

dauwhe: any other comments?

<dauwhe> +1

<mattg> +1

+1

<duga> +1

<gpellegrino> +1

<wendyreid> +1

<dauwhe> RRSAgent: draft minutes

<dauwhe> RRSAgent: make logs public

<dauwhe> RRSAgent: make logs public

<dauwhe> RRSAgent: make logs public

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/I see “https://rakuten.zoom.us/j/324554862” on the invite… is there a normal dial-in?/
Succeeded: s/wed/web/
Succeeded: s/???/ivan/
Succeeded: s/???/Garth/
Present: tzviya gpellegrino mateus toshiakikoike wendyreid dauwhe mattg Avneesh dkaplan3 Naomi Danielle Makoto duga Garth
Found ScribeNick: wendyreid
Found ScribeNick: Naomi
Inferring Scribes: wendyreid, Naomi
Scribes: wendyreid, Naomi
ScribeNicks: wendyreid, Naomi

WARNING: No "Topic:" lines found.

Found Date: 14 Mar 2019
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


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.)