KEMBAR78
Made the epub:type restrictions explicit and adapted the RS by iherman · Pull Request #2380 · w3c/epub-specs · GitHub
Skip to content

Conversation

iherman
Copy link
Member

@iherman iherman commented Jul 28, 2022

Went roughly along the line of #2377 (comment).

In the §10 of the RS I was tempted to turn the two MUST-s into SHOULD-s; ignoring those terms is untestable in my view. But I did not do it for now

Fix: #2377


Preview | Diff

@iherman iherman requested review from dauwhe and mattgarrish July 28, 2022 15:19
@mattgarrish
Copy link
Member

mattgarrish commented Jul 28, 2022

I was tempted to turn the two MUST-s into SHOULD-s; ignoring those terms is untestable in my view

I don't understand the point of this one, to be honest:

MUST ignore terms that it does not recognize.

This looks like a relic of when we thought epub:type might influence assistive technologies. What is it going to do with terms it doesn't recognize and why do we care?

I'd just erase it.

@mattgarrish
Copy link
Member

It should be possible to write a test for the "must" you're adding in this PR, though. Since we know pop-up footnotes are implemented on at least a couple of RSes, make a test document that tries to make a meta tag a footnote and see if it works.

It's not a perfect example of the requirement's restriction, but we only have to prove it can be done, right?

@iherman
Copy link
Member Author

iherman commented Jul 29, 2022

It should be possible to write a test for the "must" you're adding in this PR, though. Since we know pop-up footnotes are implemented on at least a couple of RSes, make a test document that tries to make a meta tag a footnote and see if it works.

It's not a perfect example of the requirement's restriction, but we only have to prove it can be done, right?

Actually, I did not know about the footnotes being implemented...

Let us see if this sketch for a test would work, containing two content files, p1 and p2

  • On p1 have a proper footnote and see if the system implements it in the first place
  • On p2, have a footnote term added to, say, the <title> element and show that that footnote is ignored

Is this what you mean? Which RS does implement a footnote with epub:type, b.t.w.? I mean, how would I test to see if the test itself is o.k.?

@iherman
Copy link
Member Author

iherman commented Jul 29, 2022

I was tempted to turn the two MUST-s into SHOULD-s; ignoring those terms is untestable in my view

I don't understand the point of this one, to be honest:

MUST ignore terms that it does not recognize.

This looks like a relic of when we thought epub:type might influence assistive technologies. What is it going to do with terms it doesn't recognize and why do we care?

I'd just erase it.

Happy to do it :-)

@mattgarrish
Copy link
Member

mattgarrish commented Jul 29, 2022

Which RS does implement a footnote with epub:type, b.t.w.?

iBooks was the first to implement them. You can read how to define them here: https://help.apple.com/itc/booksassetguide/en.lproj/itccf8ecf5c8.html

Thorium also has the same.

And just on a quick search there are some others like Calibre, Moon+, and even Kindle. I expect there are more, too.

@iherman
Copy link
Member Author

iherman commented Jul 29, 2022

Which RS does implement a footnote with epub:type, b.t.w.?

iBooks was the first to implement them. You can read how to define them here: https://help.apple.com/itc/booksassetguide/en.lproj/itccf8ecf5c8.html

Thorium also has the same.

And just on a quick search there are some others like Calibre, Moon+, and even Kindle. I expect there are more, too.

Brilliant! I have created two tests:

  1. Essentially implementing what is in that apple note with an aside element
  2. The same but the epub:type="footnote" id="the_note" is put on the title element.

According to our spec, but also according to its earlier incarnations, the title element text should not appear in a footnote popup. Guess what? It does in both Thorium and Apple Books...

Is it o.k. to merge this PR? I will add the anchor to these two tests, too, it will save another PR.

@iherman iherman added the Testing Issues about testing label Jul 29, 2022
@mattgarrish
Copy link
Member

It does in both Thorium and Apple Books...

At least it's testable. I thought for sure they'd both ignore such a case, but I guess they aren't paying attention to where the semantic is set.

Is it o.k. to merge this PR?

Looks fine to me now.

@iherman iherman merged commit 35ba699 into main Jul 29, 2022
@mattgarrish mattgarrish deleted the issue-2377-head-element-semantics branch August 2, 2022 14:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Testing Issues about testing

Projects

None yet

Development

Successfully merging this pull request may close these issues.

"head" elements semantics?

2 participants