scribe+
<dauwhe> https://w3c.github.io/epub-tests/results
dauwhe: we are getting close to the end. Idea is that we start process of moving to PR soon
... given testing is more or less finished, we have a sense of where we are lacking 2 independent implementations
... such features are under-implemented
wendyreid: the features in question are package linked record (order and priority), i18n directionality in creator field, css pub text-align last, putting images into nav
... also fixed layout orientation duplication as well, but this is more something to be flagged in epubcheck
... i don't think we will remove from spec, some have a single implementation
... esp. dir on creator field, that will probably get supported over time
mgarrish: can we get rid of the linked record stuff?
... we thought there might be json records etc. so we wanted to make rules on prioritization of metadata
... happy to say that you can put linked records in if you want, but not officially part of spec
wendyreid: we could take either approach. Either take it out, or say that we don't have evidence that this is an implemented feature
... the package linked record ones in particular have no evidence of implementation
mgarrish: some reports of failing the linked records test might actually be N/As. Not sure i've ever seen this feature implemented.
... there's a case for keeping the directionality stuff, as you said
dauwhe: did we get testing from VitalSource on linked records, etc.?
wendyreid: we did get testing from them, but they reported as N/A for both of those linked record ones
dauwhe: then my instinct is to get rid of them, the use-cases didn't pan out
wendyreid: we have a note re. prefix css properties being out of sync of their proper css equivalents, but i'm in favor of strengthening this to tell people to stop using the prefixes
duga: looking at the test reports, it looks like the MO tests still have a bunch of single implementations?
wendyreid: yes, we are hoping for Colibrio to get their tests results in. They seem to be the most accurate
dauwhe: is the problem with these tests that most RS have only supported MO for fxl?
wendyreid: yes
duga: are we hoping that the Colibrio results will provide the required implementations?
wendyreid: these tests are SHOULDs with MUSTs within. Supporting MO at all is optional
duga: so we don't think this will cause an issue?
wendyreid: no. But I'm still hoping we can get Colibrio's results
duga: it would be nice if we just re-did the tests to make them FXL, because then we'd have tons of passes
dauwhe: it seems like it might be less work to just explain this to the Director
wendyreid: for the sake of accuracy it would be nice to have more results for these MO tests
... the other one we haven't talked about yet is images in the NAV
... not sure if this is actually being done, if we can take out this feature
dauwhe: i'm thinking about the common tactic of using a tiny image if your font doesn't have a special character...
shiestyle: in JP we use gaiji (small images for representative letters) in Japan but many reading systems cannot treat images in NAV so we will not use images in NAV.
<dauwhe> ```
<dauwhe> <li>
<dauwhe> <a href="senanque.xhtml">
<dauwhe> <img src="imgs/senanque.jpg" alt="Description of the Abbey of Sénanque" title="Image of the Abbey" />
<dauwhe> </a>
<dauwhe> </li>
<dauwhe> ```
wendyreid: if you don't render the image in TOC, then you're supposed to present the alt-text
mgarrish: if you can't support the image and you don't show the alt-text it's a usability issue
wendyreid: apple books shows nothing at all, and Thorium shows the file path rather than the image or the alt-text
duga: this seems like it would be easy to implement. Could some RS just quickly add this feature?
... just check if its an image, and if so then grab alt-text and insert it
wendyreid: but how often do you even see non-text in NAV?
dauwhe: so do we have to write something into epubcheck to forbid images in NAV?
<wendyreid> https://w3c.github.io/epub-specs/epub33/rs/#confreq-nav-alt-text
wendyreid: one solution would be to replace this MUST assertion with a SHOULD. Let RS decide whether to support it
<shiestyle> +1
wendyreid: we'd have to make these changes to the spec, so that when go to PR it is clear what decision were made
... for the package linked record (order and priority) are we in agreement that we will remove because it is not used?
dauwhe: and we have evidence that this feature is not being supported, so we can now kill it
<wendyreid> Proposed: Remove the linked records order and priority requirements from the specification
<dauwhe> +1
<mgarrish> +1
<duga> +1
<wendyreid> +1
+1
<toshiakikoike> +1
<dhall> +1
<shiestyle> +1
<MasakazuKitahara> +1
RESOLUTION: Remove the linked records order and priority requirements from the specification
wendyreid: next, i18n dir attribute on package metadata (creator, title). We think this is underimplemented because we just introduced it. We want to keep it, maybe with a note explaining that we think it will be supported
dauwhe: and there are good i18n reasons for it
... the ultimately the goal is show that these features are implementable, and there is precedent for that
<wendyreid> Proposed: Keep the dir attribute requirements for the package metadata, they are important to i18n, add note explaining it is a new feature
+1
<shiestyle> +1
<wendyreid> +1
<dhall> +1
<dauwhe> +1
<toshiakikoike> +1
<duga> +1
<mgarrish> +1
<MasakazuKitahara> +1
RESOLUTION: Keep the dir attribute requirements for the package metadata, they are important to i18n, add note explaining it is a new feature
wendyreid: next, css epub text-align last. We already have a note discouraging these prefix properties
dauwhe: CSS error handling is really well defined, and we inherit a lot of that. We don't really have to do anything.
... last, processing of images in NAV document. We said we would move this from MUST to SHOULD
<wendyreid> Proposed: Lower the requirement for processing non-text elements in the nav doc from a MUST to a SHOULD
<dauwhe> +1
<shiestyle> +1
<dhall> +1
<duga> +1
<wendyreid> +1
+1
<MasakazuKitahara> +1
<toshiakikoike> +1
<mgarrish> +1
RESOLUTION: Lower the requirement for processing non-text elements in the nav doc from a MUST to a SHOULD
mgarrish: should we add any warning to the authoring document about such elements not being supported since we're dropping he requirement?
wendyreid: yeah, a note. Maybe link to the test results or something
... fxl orientation duplication test is last, but that's more a test of epubcheck
mgarrish: we're waiting on Romain to do the final release, we're pretty much good to go on that
wendyreid: we've also requested a Charter extension. If all goes well, we'll got to PR in 2 weeks (once all final edits are one). But once that's done it would be past the end of Feb, which is when our Charter ends
... we are asking for 6 mth extension, which is probably more than we need
... but we also have the question of epub3 maintenance WG. Writing the Charter for that will also take some time
... the maintenance WG is less work than this one, but the purpose is to keep track of errata, address any issues that may op-up:0020:37:00 <MattChan> dauwhe: and that won't require regular meetings or anything? Just keeping an eye on Github and addressing them there
... for the Audiobooks maintenance WG, we had maybe 3 calls in total to hash out wording and approve PRs
dauwhe: do we have to make decisions on whether epub 3.3 will be a living standard when we apply for PR?
wendyreid: i think every standard is a living standard unless you opt-out
... e.g. for audiobooks the errata we added would have involved going through the whole spec process again
... the new process organizes changes in 4 levels of severity. Errata fall within the lower two levels.
... the level 3 and 4 take you back to the CR stage and you go through the process from there
mgarrish: but for level 3 and 4, reviewers can review the whole spec, not just the things you are changing
wendyreid: one of the other reasons we extended the charter is that there is a non-zero chance we could have a formal objection logged against us, and we'd have to do deal with that as well within our current Charter
... since I've already written a maintenance WG charter for audiobooks we can re-use some of that language
<mgarrish> https://w3c.github.io/epub-specs/epub33/epub-aria-authoring/
UNKNOWN_SPEAKER: last is publication for guide for transitioning from epub:type to ARIA roles
mgarrish: this is a guide we made back in the IDPF days for teaching people how to use roles properly
... comes up every so often whether we should publish this
... we want to republish this as part of the W3C so we're not referring back to IDPF
... the information is basically the same, some minor corrections. We could then also reference this from the structural vocab
wendyreid: is this DPUB ARIA 1.1?
mgarrish: it's not specific. It talks about 1.0 but its about how to use roles in general
wendyreid: do we have to give it a short name when we say we're publishing it?
<mgarrish> epub-aria-authoring-11
<wendyreid> Proposed: Publish the EPUB ARIA Authoring Guide as a working group note, with the short name "epub-aria-authoring-11"
<shiestyle> +1
<wendyreid> +1
<dhall> +1
<dauwhe> +11
<mgarrish> +1
<toshiakikoike> +1
+1
<MasakazuKitahara> +1
RESOLUTION: Publish the EPUB ARIA Authoring Guide as a working group note, with the short name "epub-aria-authoring-11"
mgarrish: I'll tell Ivan
dauwhe: the meeting next Fri is when we would vote for PR
wendyreid: not next Fri. That one is cancelled. On the 19th we will vote for both PR and ISO
duga: is there a quorum for that meeting?
dauwhe: we will vote at the meeting, but leave email open for anyone who can't be there