More MO tests #117

marisademeglio · 2022-02-09T23:23:29Z

Three tests for this subsection: https://w3c.github.io/epub-specs/epub33/rs/#sec-rsconf-rendering-audio

Three clip times tests

Fix css reference error

iherman · 2022-02-10T15:56:20Z

@marisademeglio I pre-empt @dlazin's reactions: you should restructure the file organization of the tests internally, following the templates... (the content should be in an OPS directory...)

mattgarrish · 2022-02-10T16:26:46Z

the content should be in an OPS directory

Why are you using OPS, out of curiosity? That's the name of the EPUB 2 structure spec.

iherman · 2022-02-10T16:34:41Z

the content should be in an OPS directory

Why are you using OPS, out of curiosity? That's the name of the EPUB 2 structure spec.

I do not remember... but all our tests use the same structure, which is helpful.

Cc @dlazin

mattgarrish · 2022-02-10T16:38:46Z

but all our tests use the same structure, which is helpful.

Sure, but that's why you'll find /EPUB directories used in all the post EPUB 2 stuff we did in IDPF. You used to also find a lot of /OEBPS directories, too, which came from the even older Open EBook Publication Structure spec name.

It's kind of weird to use EPUB 2 terminology with EPUB 3.

marisademeglio · 2022-02-10T17:29:34Z

I have used "EPUB" because I like it better :) I didn't know about the requirement to use "OPS". Do you want me to change it?

iherman · 2022-02-10T17:43:59Z

I have used "EPUB" because I like it better :) I didn't know about the requirement to use "OPS". Do you want me to change it?

I let @dlazin a.k.a. the boss decide it, but I think it would be better.

dlazin · 2022-02-10T22:45:34Z

the content should be in an OPS directory

Why are you using OPS, out of curiosity? That's the name of the EPUB 2 structure spec.

I do not remember... but all our tests use the same structure, which is helpful.

Cc @dlazin

This came from the templates that Dave created; I just cleaned them up for consistency, and wasn't aware that OPS was an EPUB 2 convention; I thought the name was arbitrary and OPS was one of the common choices. (InDesign produces an OEBPS folder, as I'm sure you know.)

We can change it, but I would like to be consistent at any point in time, because that way you can more easily tell what the intentional choices in a given test are relative to the default non-choices. So for now, indeed, please do OPS and otherwise match the template in https://github.com/w3c/epub-tests/tree/main/tests/xx-epub-template, and we can rename all tests to EPUB in a separate PR if you think it's worth doing.

dlazin · 2022-02-10T23:15:31Z

Folder naming aside, Ivan and Marisa mentioned in today's testing call that they both wrote the same test. I have reviewed #118 and am working on #116 right now; does this still conflict? If so, please fix before I review; otherwise let me know and I will try to review tomorrow! Thanks and sorry for the collision.

iherman · 2022-02-11T07:56:13Z

Looking at the tests, it looks like one of the tests in the PR (mol-rendering-audio) overlaps with three tests in #116. The difference is their granularity: the test in this PR takes the whole section (i.e., the three MUST statements) in one test, whereas the ones of #116 treat them separately, i.e., a separate test for each of them. Personally, I would favour a smaller granularity; wdyt, @marisademeglio?

The other test is in navigation that do not overlap with neither #116 nor #118 in my view.

marisademeglio · 2022-02-11T18:13:21Z

Looking at the tests, it looks like one of the tests in the PR (mol-rendering-audio) overlaps with three tests in #116. The difference is their granularity: the test in this PR takes the whole section (i.e., the three MUST statements) in one test, whereas the ones of #116 treat them separately, i.e., a separate test for each of them. Personally, I would favour a smaller granularity; wdyt, @marisademeglio?

I could argue it either way; I was following the example of the tests in the previous MO section (timing and sync), which combine several MUSTs into a single test. The test in "rendering audio" can be for the concept of "media clipping", which is what this PR does; or the tests can be for each permutation of media clipping, as in #116.

mattgarrish · 2022-02-11T19:36:38Z

I thought the name was arbitrary and OPS was one of the common choices.

Sure, you can call the folder whatever you want, or not even bother with one. But for a formal test suite, it's a weird association with an acronym of the past. We're not testing OPS or OEBPS structure. That's why we opted to use "EPUB" as the name for all things 3.0+ -- to break the cycle of revision-based acronyms. It's why the specs are all "EPUB XYZ" now, too, as it didn't help to have a format called EPUB defined by standards with acronyms like OPS and OPF.

I can fix this for you if you want, though, since I'm the one complaining (in a separate PR, of course).

dlazin · 2022-02-11T19:38:24Z

I can fix this for you if you want, though, since I'm the one complaining (in a separate PR, of course).

Sure, that would be very welcome! I would happily accept a separate PR that renames all OPS folders to EPUB.

iherman · 2022-02-12T05:53:08Z

I can fix this for you if you want, though, since I'm the one complaining (in a separate PR, of course).

Sure, that would be very welcome! I would happily accept a separate PR that renames all OPS folders to EPUB.

I think that is really the issue: I am afraid this boat has sailed. There are about 100 tests in the repo; we should come up with a script that makes the folder name change in all folders; modify the necessary files within the folders; and re-generate the epub files. Doable of course, but I am not sure it is worth at this point...

iherman · 2022-02-12T05:55:09Z

I could argue it either way; I was following the example of the tests in the previous MO section (timing and sync), which combine several MUSTs into a single test. The test in "rendering audio" can be for the concept of "media clipping", which is what this PR does; or the tests can be for each permutation of media clipping, as in #116.

True enough.

My pragmatic point is that having more tests does not harm; I would just take all of these. I hate throwing out things that we already have. @dlazin ?

iherman · 2022-02-12T06:01:07Z

I can fix this for you if you want, though, since I'm the one complaining (in a separate PR, of course).

Sure, that would be very welcome! I would happily accept a separate PR that renames all OPS folders to EPUB.

I think that is really the issue: I am afraid this boat has sailed. There are about 100 tests in the repo; we should come up with a script that makes the folder name change in all folders; modify the necessary files within the folders; and re-generate the epub files. Doable of course, but I am not sure it is worth at this point...

Oops, I just see that @mattgarrish has done this in #119!

I guess this means I would have to change things manually in #116 and #118

mattgarrish · 2022-02-12T13:14:30Z

I guess this means I would have to change things manually in #116 and #118

I'd say it's up to you. Feel free to integrate them as-is and I can do a merge from master and fix in the branch I created.

iherman · 2022-02-14T11:43:57Z

True enough.

My pragmatic point is that having more tests does not harm; I would just take all of these. I hate throwing out things that we already have. @dlazin ?

Thinking about this further... I convinced myself that @marisademeglio is right :-)

I will then remove two tests from #116: namely mol-audio_no_clipbegin and mol-audio_no_clipend. I will, however, repurpose mol-audio_exceeding_clipend because it has shown a possible RS bug already: I will turn into mol-timing-synchronization_multiple_audio, reusing the fact that it has a SMIL file that refers, sequentially, to two audio files; this is perfectly valid and should be invisible to the reader.

@dlazin your turn in reviewing this PR...

iherman

epubcheck (the version for EPUB 3.3) reports errors on both files:

8:59 tests> epubcheck5 mol-navigation.epub 
Validating using EPUB version 3.3 rules.
ERROR(MED_014): mol-navigation.epub/EPUB/mo/ch1.smil(2,43): A non-empty fragment identifier is required.
ERROR(MED_014): mol-navigation.epub/EPUB/mo/ch2.smil(2,37): A non-empty fragment identifier is required.
ERROR(RSC-007): mol-navigation.epub/EPUB/mo/ch1.smil(2,43): Referenced resource "EPUB/xhtml/ch1.xhtml" could not be found in the EPUB.

Check finished with errors
Messages: 0 fatals / 3 errors / 0 warnings / 0 infos

EPUBCheck completed

and

9:07 tests> epubcheck5 mol-navigation.epub     
Validating using EPUB version 3.3 rules.
ERROR(MED_014): mol-navigation.epub/EPUB/mo/ch1.smil(2,37): A non-empty fragment identifier is required.
ERROR(MED_014): mol-navigation.epub/EPUB/mo/ch2.smil(2,37): A non-empty fragment identifier is required.

Check finished with errors
Messages: 0 fatals / 2 errors / 1 warning / 0 infos

EPUBCheck completed

The missing file reference is easy (and I submitted an editorial change); for the others the issue is that the reference in the smil file's <body> element should refer to a fragment in the target xhtml file: ie, and id value should be given to, e.g., the <body> element of the relevant xhtml file and referred to from the smil file. (I did those changes on my local machine and epubcheck was happy).

iherman · 2022-02-15T08:04:40Z

tests/mol-navigation/EPUB/mo/ch1.smil

@@ -0,0 +1,20 @@
+<smil xmlns:epub="http://www.idpf.org/2007/ops" xmlns="http://www.w3.org/ns/SMIL" version="3.0">
+  <body epub:textref="../xhtml/ch1.xhtml">


Suggested change

<body epub:textref="../xhtml/ch1.xhtml">

<body epub:textref="../ch1.xhtml">

iherman · 2022-02-15T08:34:38Z

FWIW, the navigation test runs on the web version of Colibrio as well as on Thorium on the Mac. The rendering audio one runs on Colibrio but the third 'subtest' (clipEnd exceeding) does not work on Thorium (the other two sub-tests do work).

The exceeding clipEnd stuff seems to be the tricky one... interestingly, this tests use the same trick that I tried, namely using several audio files, and that is where Thorium failed on the earlier tests as well. On the other hand, Thorium actually is o.k. with a 'regular' change of one media file to the other (the separate test I added works well).

marisademeglio · 2022-02-15T23:01:32Z

Thanks for the file reference fix :)

I was not getting EPUBCheck errors with version 4.2.4 but I've now upgraded to v5 and I see what you see.

However, the error about there being no fragment identifier in the URL, e.g. <body epub:textref="file.xhtml"> rather than "file.xhtml#ident", does not match what the spec says for body

"
The value MUST be a path-relative-scheme-less-URL string, optionally followed by U+0023 (#) and a URL-fragment string.
"

It does not affect this test but does it seem wrong to you too? I can open an issue over in the appropriate repo.

Anyway, I am pushing a fix to make EPUBCheck happier, since it doesn't really matter for our purposes here if it's flagging an error when there is none.

dlazin · 2022-02-21T16:26:11Z

True enough.
My pragmatic point is that having more tests does not harm; I would just take all of these. I hate throwing out things that we already have. @dlazin ?

Thinking about this further... I convinced myself that @marisademeglio is right :-)

I will then remove two tests from #116: namely mol-audio_no_clipbegin and mol-audio_no_clipend. I will, however, repurpose mol-audio_exceeding_clipend because it has shown a possible RS bug already: I will turn into mol-timing-synchronization_multiple_audio, reusing the fact that it has a SMIL file that refers, sequentially, to two audio files; this is perfectly valid and should be invisible to the reader.

@dlazin your turn in reviewing this PR...

Reviewing now. Just to confirm, we've decided that all the tests in this PR will survive, because Ivan removed some from #116, right? Cool.

dlazin

Thank you so much for the tests! Sorry for the delay and all the comments; most of these are just first-time "here is how we do things" changes, not substantive; next time should be much cleaner.

dlazin · 2022-02-21T16:35:02Z

tests/mol-navigation/EPUB/css/base.css

+@charset "utf-8";
+
+/*for the active text element*/
+.-epub-media-overlay-active {


Nit: so that our tests have consistent setup, can this be .active-item like in https://github.com/w3c/epub-tests/blob/main/tests/mol-css/EPUB/package.opf?

(Consistency is important so that, when analyzing, we don't have to puzzle out whether something is intentionally different or just arbitrarily so. IMO only things under test should vary from one test to another — hence the EPUB vs OPS debate too.)

Ok we can make it match across all the tests but I don't like the classnames in the test you linked to. Let's copy the spec example. We have found that if we put out documentation with a classname that sounds too nerdy or "official", implementers treat them like magic strings and start supporting those exact classnames. So using my-active-item helps to not reinforce this.

Sure, sounds good.

FYI, I changed this for the second test in #148 (but see below — maybe we are deleting that test?).

tests/mol-navigation/EPUB/package.opf

tests/mol-navigation/EPUB/nav.xhtml

tests/mol-navigation/EPUB/package.opf

dlazin · 2022-02-21T16:50:46Z

tests/mol-rendering-audio/EPUB/package.opf

+    <link rel="dcterms:rights" href="https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document"/>
+    <link rel="dcterms:rightsHolder" href="https://www.w3.org"/>
+    <meta property="belongs-to-collection">should</meta>
+    <meta property="dcterms:isReferencedBy">https://w3c.github.io/epub-specs/epub33/rs/#sec-rsconf-rendering-audio</meta>


Suggested change

<meta property="dcterms:isReferencedBy">https://w3c.github.io/epub-specs/epub33/rs/#sec-rsconf-rendering-audio</meta>

<meta property="dcterms:isReferencedBy">https://www.w3.org/TR/epub-rs-33/#sec-rsconf-rendering-audio</meta>

...but there are five separate normative statements in this section, and I think (?) this test only tests the four MUSTs (which is by itself fine). Each normative statement should have its own anchor, so please add more anchors in the spec, then include I guess four isReferencedBy elements here.

This is kinda documented at step 12 of https://w3c.github.io/epub-tests/contributing#step-by-step, although we should be more explicit that every normative statement needs a separate anchor (otherwise we can't tell what's tested and what isn't).

Yes I was just focusing on the MUSTs because I thought that was what we needed to tackle first. I can write test for that last SHOULD (will prob be a separate EPUB since that test does not have anything in common with the others).

And when I add the test references to the normative statement, as per step 12, I use the test IDs, but where should these be defined for this situation of having multiple tests in one EPUB?

In that situation, you would have a single epub but multiple data-tests attributes pointing to the same test, like so:

First normative statement.

Second normative statement.

Third normative statement.

And then mol-rendering-audio.epub would have three dcterms:isReferencedBy:
https://www.w3.org/TR/epub-rs-33/#first-anchor
https://www.w3.org/TR/epub-rs-33/#second-anchor
https://www.w3.org/TR/epub-rs-33/#third-anchor

Make sense?

And you can't refer to a test below the package level of the test EPUB. Is that right?

It doesn't matter at this point for me but conceptually I am curious.

Sorry, missed this. Yes, that's correct.

dlazin · 2022-02-21T16:54:10Z

tests/mol-rendering-audio/EPUB/package.opf

+    <meta property="dcterms:isReferencedBy">https://w3c.github.io/epub-specs/epub33/rs/#sec-rsconf-rendering-audio</meta>
+    <meta property="dcterms:modified">2022-02-10T00:00:00Z</meta>
+    <meta property="media:duration" refines="#smil-1">00:00:18.479</meta>
+      <meta property="media:duration">00:00:18.479</meta>


Inconsistent indentation again.

Fixed in #148.

dlazin · 2022-02-21T16:57:40Z

tests/mol-rendering-audio/EPUB/clip_times_tests.xhtml

+    </head>
+    <body id="body">
+        <h1>EPUB Media Overlays Tests: Rendering Audio</h1>
+        <p>Each sentence below should play in full when this page is played.</p>


This should explicitly list the criteria for the test passing; pass/fail shouldn't require interpretation on the part of the tester (who will hopefully be a RS person not familiar with individual tests).

Put another way, you have this from the perspective of the document (X is not specified, so its value is assumed to be Y) rather than the behavior (X is not specified, so its value is assumed to be Y, and thus Z must occur).

See examples from Ivan's reverted tests in b3ae281.

Fixed in #148.

dlazin · 2022-02-21T16:59:18Z

tests/mol-rendering-audio/EPUB/package.opf

+    <dc:coverage>Media Overlays</dc:coverage>
+    <dc:creator>Marisa DeMeglio</dc:creator>
+    <dc:date>2022-02-10</dc:date>
+    <dc:description>Tests whether the Reading System implements Media Overlays' RS Spec "Rendering Audio" section.</dc:description>


As with the other package description, please describe the behavior under test rather than just the section of the spec.

Fixed in #148.

dlazin · 2022-02-21T17:00:33Z

tests/mol-navigation/EPUB/ch2.xhtml

+    </head>
+    <body id="body">
+        <h1 id="mo-1">Chapter 2</h1>
+        <p id="mo-2">This page should play when "Chapter 2" is selected from the table of contents.</p>


For clarity, I'd recommend something explicit like "Test passes if the media overlay audio on this page plays when..." (and does the reader need to enable MO on the first page before doing that? If so, please say so.)

The instructions start on chapter 1, please see that page first and then let me know if it still doesn't make sense.

I will update the wording to say "The test passes if..."

Yes, I had seen that. The issue is that the chapter 1 and chapter 2 text focus on telling you what to do, not what the pass/fail criteria are. Explicit "test passes if" would help, but for example Ivan's tests say that the RS needs to prompt you to start the MO playing; my belief is it shouldn't be automatic, but I think you can read chapter 1+2 here as the whole thing should be automatic. Since the tester won't have just read the relevant sections of the spec and won't have context, they could misinterpret the criteria; this should be clear to someone who has no context. (I'd copy language from Ivan's tests. We don't want the testers to wonder why one test has different instructions — do those genuinely indicate something different, or just that two different people wrote the tests? Our authorship shouldn't matter.)

(Marisa did this.)

marisademeglio · 2022-02-21T19:13:14Z

I think that having multiple tests in a single EPUB, as in mol-rendering-audio does not work with the test system that has been set up here. The easiest solution is to remove mol-rendering-audio and replace with the tests that Ivan had written which test the same things.

iherman · 2022-02-22T05:54:47Z

I think that having multiple tests in a single EPUB, as in mol-rendering-audio does not work with the test system that has been set up here. The easiest solution is to remove mol-rendering-audio and replace with the tests that Ivan had written which test the same things.

Well... I have already removed those tests from the respective PR and merge that one. I guess we could find those somewhere in github's memory... (or my mac backups)

@marisademeglio what do you prefer the next action would/should be?

marisademeglio · 2022-02-22T06:03:20Z

I would do whatever is faster :) This week I don't have much time to spend on this, unfortunately.

iherman · 2022-02-22T12:30:47Z

I would do whatever is faster :) This week I don't have much time to spend on this, unfortunately.

Ok, I have re-instated the three tests for clipend and clipbegin, see #125.

@marisademeglio you can then remove the corresponding test from this PR.

dlazin

Hi! Very sorry for the slow reviews here — can you summarize the current state of this PR for me? Is it waiting on my re-review, or do you have changes you need to make first?

(I could probably figure this out myself by careful reading, but I have other PRs to catch up on too.)

Also, attached is a second comment that apparently I wrote weeks ago and neglected to post. I hope it's still relevant!

dlazin · 2022-02-22T14:42:34Z

tests/mol-navigation/EPUB/ch2.xhtml

+    </head>
+    <body id="body">
+        <h1 id="mo-1">Chapter 2</h1>
+        <p id="mo-2">This page should play when "Chapter 2" is selected from the table of contents.</p>


Yes, I had seen that. The issue is that the chapter 1 and chapter 2 text focus on telling you what to do, not what the pass/fail criteria are. Explicit "test passes if" would help, but for example Ivan's tests say that the RS needs to prompt you to start the MO playing; my belief is it shouldn't be automatic, but I think you can read chapter 1+2 here as the whole thing should be automatic. Since the tester won't have just read the relevant sections of the spec and won't have context, they could misinterpret the criteria; this should be clear to someone who has no context. (I'd copy language from Ivan's tests. We don't want the testers to wonder why one test has different instructions — do those genuinely indicate something different, or just that two different people wrote the tests? Our authorship shouldn't matter.)

iherman · 2022-04-01T14:52:03Z

@marisademeglio I wonder where we are with these tests... It would be good to close all outstanding issues and tests before going to CR (which does not mean that we would not need new tests, of course)

marisademeglio · 2022-04-01T17:09:13Z

@marisademeglio I wonder where we are with these tests... It would be good to close all outstanding issues and tests before going to CR (which does not mean that we would not need new tests, of course)

Of the 4 tests in this PR, we are not using the 3 media clipping tests, so that just leaves mol-navigation. I am looking at a comment from @dlazin and I gather that 2 things are being requested:

change to "test passes if..." language: this has already been done.
for example Ivan's tests say that the RS needs to prompt you to start the MO playing; my belief is it shouldn't be automatic, but I think you can read chapter 1+2 here as the whole thing should be automatic.

The test currently says "While Chapter 1 is playing...", which does not make any assumptions on how playback is initiated or if it's manual or automatic (all this is therefore implementation-dependent - nowhere in the spec(s) do we say how an RS should initiate MO playback though it is generally a "play" button and whether "prompt you to start the MO playing" is the absolute best language to refer to a play button, is a rabbithole I am not going down :) Anyway my opinion is that it's fine as-is.

iherman · 2022-05-23T04:46:28Z

@marisademeglio any reason why this PR should not be merged?

marisademeglio · 2022-05-23T15:21:20Z

@marisademeglio any reason why this PR should not be merged?

No objection from me, I don't have any plans to make more changes.

dlazin · 2022-05-23T15:29:10Z

@marisademeglio any reason why this PR should not be merged?

Sorry, this is on me. I've repeatedly intended to re-review but kept not doing so. Lemme go get another coffee and then I shall! I'll commit once I'm happy. (And if I still want some changes, I'll just commit and send a followup PR, because I've kept Marisa waiting waaaaay too long on this one — sorry again!)

dlazin · 2022-05-24T17:56:28Z

@marisademeglio any reason why this PR should not be merged?

Sorry, this is on me. I've repeatedly intended to re-review but kept not doing so. Lemme go get another coffee and then I shall! I'll commit once I'm happy. (And if I still want some changes, I'll just commit and send a followup PR, because I've kept Marisa waiting waaaaay too long on this one — sorry again!)

Ah, a bunch of the comments I left in the last review in February have not been addressed, but I will commit this PR anyway and then send a followup PR to make those changes.

marisademeglio · 2022-05-24T18:23:56Z

@marisademeglio any reason why this PR should not be merged?

Sorry, this is on me. I've repeatedly intended to re-review but kept not doing so. Lemme go get another coffee and then I shall! I'll commit once I'm happy. (And if I still want some changes, I'll just commit and send a followup PR, because I've kept Marisa waiting waaaaay too long on this one — sorry again!)

Ah, a bunch of the comments I left in the last review in February have not been addressed, but I will commit this PR anyway and then send a followup PR to make those changes.

The decision as I understood it was to not use these rendering-audio tests and use Ivan's instead, so I didn't bother to address what you brought up related to rendering-audio.

As for your comment about the navigation test, I did reply already.

I think then the only thing to do is remove the rendering-audio tests from this PR? Looking back, I see Ivan mentioned that, and I ran out of time to take care of it.

dlazin · 2022-05-24T22:49:05Z

@marisademeglio any reason why this PR should not be merged?

Sorry, this is on me. I've repeatedly intended to re-review but kept not doing so. Lemme go get another coffee and then I shall! I'll commit once I'm happy. (And if I still want some changes, I'll just commit and send a followup PR, because I've kept Marisa waiting waaaaay too long on this one — sorry again!)

Ah, a bunch of the comments I left in the last review in February have not been addressed, but I will commit this PR anyway and then send a followup PR to make those changes.

The decision as I understood it was to not use these rendering-audio tests and use Ivan's instead, so I didn't bother to address what you brought up related to rendering-audio.

As for your comment about the navigation test, I did reply already.

I think then the only thing to do is remove the rendering-audio tests from this PR? Looking back, I see Ivan mentioned that, and I ran out of time to take care of it.

A-ha! I finally understand. Sorry, I hadn't read the comment threads carefully enough. I thought that your mol-rendering-audio was staying and Ivan's was already gone. Now I see it's the converse. I just cleaned up that test in #148, but I will now send another commit to remove it.

…dio-rendering (#148) * Standardize formatting of MOL tests and add EPUBs * Delete rendering-audio, per discussion on #117 * Update spec anchor * Restore belongs-to-collection (undecided but consistent for now)

marisademeglio added 5 commits February 9, 2022 14:54

Tests for MOL Rendering Audio

74f31ab

Three clip times tests

Update clip_times_tests.xhtml

5d5b3ff

Fix css reference error

Minor fix to rendering audio test

4ef5853

Minor wording adjustment for MO rendering audio test

ee3f252

Add test for Media Overlays RS spec "Navigation" section

9683135

marisademeglio changed the title ~~Mo tests for 'rendering audio'~~ More MO tests Feb 10, 2022

Update ch2.mp3

3031a80

iherman added a commit that referenced this pull request Feb 14, 2022

Changes per #117 (comment)

112d308

iherman requested review from iherman and dlazin February 15, 2022 08:01

iherman reviewed Feb 15, 2022

View reviewed changes

dlazin approved these changes Feb 21, 2022

View reviewed changes

marisademeglio added 5 commits February 21, 2022 09:37

Fix titles and descriptions for mol-navigation

d255d26

Fixed indentation for mol-navigation

b3f4998

Change CSS classnames

4cddb71

Fix spec reference in package document

81e5910

Change test statement wording to match "The test passes if..." format

409194f

iherman mentioned this pull request Feb 22, 2022

Re-instated the clipend and clipend tests #125

Merged

dlazin reviewed Mar 14, 2022

View reviewed changes

iherman self-requested a review April 1, 2022 14:52

iherman approved these changes Apr 1, 2022

View reviewed changes

dlazin merged commit c6342fa into w3c:main May 24, 2022

dlazin mentioned this pull request May 24, 2022

Standardize formatting of mol-navigation, add EPUB, and delete mol-audio-rendering #148

Merged

dlazin added a commit that referenced this pull request May 24, 2022

Delete rendering-audio, per discussion on #117

6dcd5f1

dlazin added a commit to w3c/epub-specs that referenced this pull request May 24, 2022

Add test references for w3c/epub-tests#117 etc

d305bca

dlazin mentioned this pull request May 24, 2022

Add more MO test references w3c/epub-specs#2311

Merged

dlazin added a commit to w3c/epub-specs that referenced this pull request May 25, 2022

Add test references for w3c/epub-tests#117 etc (#2311)

7708de2

		@@ -0,0 +1,20 @@
		<smil xmlns:epub="http://www.idpf.org/2007/ops" xmlns="http://www.w3.org/ns/SMIL" version="3.0">
		<body epub:textref="../xhtml/ch1.xhtml">

	<body epub:textref="../xhtml/ch1.xhtml">
	<body epub:textref="../ch1.xhtml">

	<meta property="dcterms:isReferencedBy">https://w3c.github.io/epub-specs/epub33/rs/#sec-rsconf-rendering-audio</meta>
	<meta property="dcterms:isReferencedBy">https://www.w3.org/TR/epub-rs-33/#sec-rsconf-rendering-audio</meta>

More MO tests #117

More MO tests #117

Conversation

marisademeglio commented Feb 9, 2022

iherman commented Feb 10, 2022

mattgarrish commented Feb 10, 2022

iherman commented Feb 10, 2022

mattgarrish commented Feb 10, 2022

marisademeglio commented Feb 10, 2022

iherman commented Feb 10, 2022

dlazin commented Feb 10, 2022

dlazin commented Feb 10, 2022

iherman commented Feb 11, 2022

marisademeglio commented Feb 11, 2022

mattgarrish commented Feb 11, 2022

dlazin commented Feb 11, 2022

iherman commented Feb 12, 2022

iherman commented Feb 12, 2022

iherman commented Feb 12, 2022

mattgarrish commented Feb 12, 2022

iherman commented Feb 14, 2022

iherman left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

iherman commented Feb 15, 2022

marisademeglio commented Feb 15, 2022

dlazin commented Feb 21, 2022

dlazin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marisademeglio commented Feb 21, 2022

iherman commented Feb 22, 2022

marisademeglio commented Feb 22, 2022

iherman commented Feb 22, 2022

dlazin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

iherman commented Apr 1, 2022

marisademeglio commented Apr 1, 2022

iherman commented May 23, 2022

marisademeglio commented May 23, 2022

dlazin commented May 23, 2022

dlazin commented May 24, 2022

marisademeglio commented May 24, 2022

dlazin commented May 24, 2022

iherman left a comment •

edited

Loading