Meeting minutes
PR Cleanup
<wendyreid> w3c/
w3c/epub-specs#2527
mgarrish: 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.
shiestyle: 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: 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.
mgarrish: we are only changing the errata document so its a small change.
mgarrish: I agree a small change. I will send him directly an update errata and cc Ivan and Ralph
AvneeshSingh: 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.
mgarrish: This came from if we issue a new ISO version that is not compatible that is where this came from.
mgarrish: I thought we just need to change the errata and will be a very small change.
AvneeshSingh: we are loosening the restriction from a MUST to a SHOULD for the inclusion of the accessiblitySummary metadata.
SueNeu: Are we only doing this to support folks using the old version?
mgarrish: these standards also exist in these other standards it makes it compatible with an errata so it is backward compatible.
AvneeshSingh: We had in the Publishing Steering Committee, we are the owners but don't know the passwords tochange it.
w3c/epub-specs#2706
mgarrish: 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.
<SueNeu> +1
ivan: 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.
mgarrish: we won't get the changelog. this is for non-substantive changes.
ivan: Ok, merge the damn thing :)!!!
w3c/epub-specs#2707
wendyreid: make the editor happier, always a good thing!
mgarrish: 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.
wendyreid: OK we will merge it.
w3c/epub-specs#2708
wendyreid: clarification of styling documents.
mgarrish: 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.
SueNeu: 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: 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.
mgarrish: similar with EPUBCheck
ivan: Merge it!
<rdeltour> +1 to what Matt just said :)
wendyreid: in reading it I am curious about <nav.xhtml> some creators will use that to include page list and landmarks.
mgarrish: 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
mgarrish: 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.
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: 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.
duga: I do think we should have a hand full of tests for RS to tests.
gpellegrino: clarification: all HTML is all in addition to XHTML. not removing XHTML.
wendyreid: we would be allowing EPUB creators to choose XHTML or HTML.
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.
<SueNeu> +1
ivan: 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.
mgarrish: 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.
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.
<rdeltour> +1
mgarrish: I agree we have HTML content and don't use say XHTML. I don't think we want two termsmoving forward.
wendyreid: 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: when we reference a media type when declare resources where they will be treated differently.
ivan: 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.
duga: if we dont' decide not use HTML in the content we could remove the term XHTML everywhere.
ivan: I think its a good idea.
SueNeu: as a book publisher I am not sure, I could get myself into trouble.
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.
rdeltour: split the PR one side implements what Brady suggests, and the other PR for extends the spec to use the HTML syntax.
George: tools I use when I switch between the two with the validation. that will be an important distinction.
<SueNeu> +1
George: not just EPUBCheck but all the other tools out there.
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.
mgarrish: 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: there are different audiences. change in the reading system, is easier since only RS developers.
mgarrish: except the RS does refer to the authoring document so they need to be in sync.
wendyreid: 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.
mgarrish: what is there now is easy to back out.
… we won't get any feedback until we merge this in our draft.
shiestyle: I agree we should merge this then we can wide review. This will become a possiblity once its merged.
SueNeu: is this a Task Force to explore this? test document failures??
ivan: 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.