Meeting minutes
PR Cleanup
<Wendy Reid> w3c/
w3c/epub-specs#2527
Matt Garrish: Changes back where a11y 1.1 from 1.0 would be compatible. 1.0 required an accessibilitySummary but 1.1 it is only a SHOULD not a MUST. technically not backward compatible but we need to do an errata to make that change.
… PR must close since its on 3.3 and must be revised to 3.4
… could be a 1.2 or a 1.1.1. stuck in the holding pattern until we can make the IDPF change.
… it says its backward compatible but it clearly isn't. Could got to ISO but that only changes part of the issue.
Shinya Takami: two years have passed since it is raised. I think we can close this we should think with 3.4 how to handle it.
Ivan Herman: not sure how the old IDPF docs can be changed? Matt maybe we can send a request to vivia? until now we were discussing general things but if send a specific request we can take it from there.
Matt Garrish: we are only changing the errata document so its a small change.
Matt Garrish: I agree a small change. I will send him directly an update errata and cc Ivan and Ralph
Avneesh Singh: Ralph said we are the owners but we don't know how to update it.
… this was submitted as a document to the W3C member submission. we should also consider ISO and that may not be straight fwd. they may be following the ISO 1.0.
Matt Garrish: This came from if we issue a new ISO version that is not compatible that is where this came from.
Matt Garrish: I thought we just need to change the errata and will be a very small change.
Avneesh Singh: we are loosening the restriction from a MUST to a SHOULD for the inclusion of the accessiblitySummary metadata.
Susan Neuhaus: Are we only doing this to support folks using the old version?
Matt Garrish: these standards also exist in these other standards it makes it compatible with an errata so it is backward compatible.
Avneesh Singh: We had in the Publishing Steering Committee, we are the owners but don't know the passwords tochange it.
w3c/epub-specs#2706
Matt Garrish: this is a massive headache. we had to add a version identifier to create the history for epub 3.3 / 3.2 would rather use a date range of closed issues, instead of tagging everything. this is a lot of busy work behind the scenes.
<Susan Neuhaus> +1
Ivan Herman: not in opposition, the final recommendation we refer to github as a changelog and we may get angry remarks from folks if github goes away for some reason.
Matt Garrish: we won't get the changelog. this is for non-substantive changes.
Ivan Herman: Ok, merge the damn thing :)!!!
w3c/epub-specs#2707
Wendy Reid: make the editor happier, always a good thing!
Matt Garrish: this is last modified data, we held off on changing. it has specific formatting, and we added how it had to be in UTC, formatting etc. just turning this into a note, it will be in UTC time but this is already in the formatting of the string. it doesn't change anything it gets rid of 2 MUST which isn't needed since its already in the string format.
Wendy Reid: OK we will merge it.
w3c/epub-specs#2708
Wendy Reid: clarification of styling documents.
Matt Garrish: has a Reading System requirement but cleaning it up but we had some authoring recommendation but didn't notice that the the Reading System in spine requirements. When you are using it in the spine its up to the author to style it. when a RS shows the TOC in their own UI they need to hide the line numbers.
… we never did put that as a requirement in the RS's when using the nav documents to ignore that part of styling.
… this is just reshuffling of the requirements documents.
Susan Neuhaus: both to the author and the RS that this is list style none, outside the spine they require that they need to supress the style. it wasn't stated clearly, when authoring in the nav and put it in the <spine> then you as a content document author must suppress the numbering style.
Ivan Herman: I have updated test suite to handle 3.4
… more important, testing period was long an tedious, this should be a lot better since we have backward compatible. When we add any normative change to document that will stay around we create the test right away. we don't want to wait to add all the tests at the end.
… makes everyones life easier.
Matt Garrish: similar with EPUBCheck
Ivan Herman: Merge it!
<Romain Deltour> +1 to what Matt just said :)
Wendy Reid: in reading it I am curious about <nav.xhtml> some creators will use that to include page list and landmarks.
Matt Garrish: ignored in both cases, or ignore <nav elements?
… for in spine reading systems should ignore it, could be hiding branches within it. RS should ignore it just use it.
w3c/epub-specs#2709
Matt Garrish: start to supporting HTML. Adds media type starts to configure the content document to identify it with a Note, define epub-type to use it in the HTML representation. There is a defintion and NOTE to under discussion potentially *At Risk* to get on everyone's radar.
Brady Duga: 1. this will be fun for testing, this will take a lot of tests, not sure yet how. could be 100s of tests then to delete them at the end if we pull it.
Ivan Herman: this is an exception to create tests first. since we are requiring feedback from the larger community. just put a toe in not a complete dive.
… merge as soon as we are happy and see if we can put it in EPUBCheck and see what publishers will do, as long as we can rollback at the present. we could add a couple tests turning some into html from XHTML.
Brady Duga: I do think we should have a hand full of tests for RS to tests.
Gregorio Pellegrino: clarification: all HTML is all in addition to XHTML. not removing XHTML.
Wendy Reid: we would be allowing EPUB creators to choose XHTML or HTML.
Brady Duga: important to answer it will impact what this PR look likes. we can have 2 types of content documents (HTML & XHTML) maybe replace xhtml with html and allow for the serialization of HTML in XML, but maybe this is not the case but where do we land with this PR.
<Susan Neuhaus> +1
Ivan Herman: we have a very strong requirement of backward compatibility so my view is HTML is alongside XHTML.
… is it ok to mix the two inside the same publication or restrict it to one for a publication.
… this is what the document does but leave it to Matt.
Matt Garrish: I was trying to achieve to start to align us with HTML and there is an different syntax for each. requirements are the same a lot of duplicates. we have a lot of notes/specs so we want to try to minimize the change.
… do we wont to get into defining XHTML or HTML documents or could have an XHTML nav doc since its better supported for example. I would let folks figure it out on their own. I would be surprised if they switch syntaxs.
Brady Duga: I agree mixed is fine, so lets not try to restrict it. XHTML is not really a thing we reference a spec that says it is not really a thing. we are saying you can use any HTML its up to you to use HTML, we require support for the XML serialization but we are fully backward compatible.
<Romain Deltour> +1
Matt Garrish: I agree we have HTML content and don't use say XHTML. I don't think we want two termsmoving forward.
Wendy Reid: Sounds like this is a cleaner approach, but will need some explanation to our community if we remove XHTML and replace it with HTML but its just the XML serialization. Change in terminology.
Hadrien Gardeur: when we reference a media type when declare resources where they will be treated differently.
Ivan Herman: current draft maintains both so that's fine. define epub-type not epub:type similar to aria-*
… when we merge this we should have a discussion on outreach on this right away. Could lead to misunderstandings. Blog Mailing List announcements etc.
Brady Duga: if we dont' decide not use HTML in the content we could remove the term XHTML everywhere.
Ivan Herman: I think its a good idea.
Susan Neuhaus: as a book publisher I am not sure, I could get myself into trouble.
Brady Duga: xhtml is not a term that is used anymore in the HTML specs. we could get rid of the term xhtml but xhtml doesn't define it. we require XHTML everywhere but just the term XHTML doesn't exist.
Romain Deltour: split the PR one side implements what Brady suggests, and the other PR for extends the spec to use the HTML syntax.
George Kerscher: tools I use when I switch between the two with the validation. that will be an important distinction.
<Susan Neuhaus> +1
George Kerscher: not just EPUBCheck but all the other tools out there.
Brady Duga: I agree it is a concern. Maybe that is a good idea. Not sure if we should remove the XHTML term in our spec, not sure that could lead to real confusion. Might be the right thing to do, may need more time or coffee :)
DaleR: sounds like 2 audiences, authors how do I create a product that will be rendered and doesn't produce errors, the the authors of the creators of the reading systems.
Matt Garrish: sitting on the fence getting rid of X. safer if we have both syntax's if the spec just says HTML but the content still requires XHTML. just could be confusing until we really do support both.
Ivan Herman: there are different audiences. change in the reading system, is easier since only RS developers.
Matt Garrish: except the RS does refer to the authoring document so they need to be in sync.
Wendy Reid: help to see what if we remove the X to see what it looks like. I have an EPUB that uses HTML content documents. and see what breaks.
Matt Garrish: what is there now is easy to back out.
… we won't get any feedback until we merge this in our draft.
Shinya Takami: I agree we should merge this then we can wide review. This will become a possiblity once its merged.
Susan Neuhaus: is this a Task Force to explore this? test document failures??
Ivan Herman: I don't think a TF is needed we have been discussing this for 2 1/2 years or more. its time to merge and get wide review / discussions.
… if there is an acceptance, then we can restructure the document in the long term is a good thing to do. use epub-type instead of epub:type but lets see.