Repository navigation
Is reference to xpointer shorthand for fragment identifiers too restrictive? #1586
Description
The media overlay attributes that expect a fragment identifier say they require: "a fragment identifier that references the specific element as per the [XPTRSH]".
Is the reference to xpointer shorthand necessary here? If we were to actually follow XPTRSH we'd invalidate many potential ID references into HTML documents as HTML IDs no longer have to be NCName values.
Doesn't referencing XPTRSH also negate being able to use EPUBCFI?
Activity
[-]Is reference to xptrsh too restrictive?[/-][+]Is reference to xpointer shorthand for fragment identifiers too restrictive?[/+]wareid commentedon Apr 23, 2021
@marisademeglio @danielweck do you have any background on this?
iherman commentedon Apr 23, 2021
The issue was discussed in a meeting on 2021-04-23
View the transcript
2. xpointer shorthand for fragment identifiers too restrictive?
See github issue #1586.
Dave Cramer: does anybody know why we referenced xpointer in the first place?
Matt Garrish: maybe they were trying to make sure it was a CFI?
… but we've since thought about allowing CFIs
Brady Duga: does XHTML still require NCNames?
Matt Garrish: no
… can follow up with Marisa and Daniel?
… to clarify intent here
Dave Cramer: agree
Ivan Herman: I propose we table the container constrained scripts to next time
marisademeglio commentedon Apr 23, 2021
cc @murata2makoto @danielweck -- you guys may remember this too:
In an early draft, Media Overlays 3.0 said:
But then this feedback was received regarding further defining fragment identifiers:
So we changed it to its current wording.
I believe CFI was purposely excluded, as there were no use cases to justify the complexity it would add to a media overlays implementation.
mattgarrish commentedon Apr 24, 2021
But wouldn't wording like the following achieve the same end without calling on xpointer shorthand: "including a fragment identifier that references the
idattribute of the specific element." ?(HTML doesn't use
namefor anchors anymore and SVG doesn't have the attribute.)XPointer shorthand made sense prior to HTML loosening its id requirements, but as it is we'd be requiring authors to follow the old naming convention in order to use media overlays. We could do that, of course, but it's not terribly apparent that you'd have to do this or why. (And who knows what happens if we begin to enforce this in epubcheck now.)
That's fine. I thought people were using it, or maybe I'm just thinking of people asking for it to be officially allowed.
In any case, if the only reason for citing xptrsh was to disallow other schemes, there must be other ways we can phrase this.
marisademeglio commentedon Apr 24, 2021
It sounds good to me. I was answering the question about what's the background for our use of xpointer shorthand. And, on that note, I found the conversation thread
I don't see anything wrong with including CFI and or any new locator mechanism(s) that might come along. My opinion is that it makes sense for MO to incorporate whatever's in use in the rest of the EPUB spec. Whether that sort of change would be welcome or not, I can't say.
mattgarrish commentedon Apr 24, 2021
The question on the call yesterday was whether there was a specific technical need for xpointer shorthand. If it's just to limit the schemes, as you've noted in the discussions, it seems more problematic than it's worth.
Right, and I don't believe we currently limit fragment identifier schemes anywhere else. I wouldn't restrict authors but only look at whether we should require reading system support for specific cases.
iherman commentedon Apr 30, 2021
The issue was discussed in a meeting on 2021-04-29
View the transcript
2. xpointer shorthand
See github issue #1586.
Dave Cramer: this was about using xpointer shorthand as identifiers in MO spec
… xpointer defines all sorts of different fragment identifier schemes
… do any implementations of MO use anything other than HTML
#id?Marisa DeMeglio: not that I know
Dave Cramer: yes, that matches my experience too
Marisa DeMeglio: the intention in MO was to say "refer to fragment identifier"
… what happened was that that idea got formalized into xpointer shorthand
… it was a suggestion from JP reviewers of epub 3
… but intention was not changed
Dave Cramer: so we were trying to find a stable spec reference to reflect that concept
Marisa DeMeglio: yes
Dave Cramer: and these were also more XML centric times
… i think its worth exploring a simply way of expressing this without misleading authors that they can use anything in xpointer
Marisa DeMeglio: yes. I think encouraging ease of use will increase adoption
Dave Cramer: when Microsoft was trying to implement epub in Edge, they had questions about this use of xpointer too
Wendy Reid: was there a MO test in the old epubtest?
Marisa DeMeglio: yes, it was massive and hard to pass test
… but that old site isn't really up to date
Dave Cramer: but i think there are quite a few implementations of MO
… but this is enough info to move forward on the issue
… I'll assign myself to find a better spec reference for what we are trying to say about fragment identifiers
mattgarrish commentedon May 5, 2021
I've been tinkering with this for a couple of weeks, but not sure if I've found great wording yet as there doesn't seem to be a specific scheme definition for referencing html elements by simple string fragids. I've been wondering if we can tie this into the html target element definition, though.
So, in the authoring spec we'd generalize the requirement to:
And then in the reading system specification we'd only need to adjust the paragraph about scrolling the referenced element into view. I think this can be done with a statement like this:
This would potentially allow other schemes like cfi while not changing that we only support basic element id references.
What still bothers me is the playback class dependence on elements. What happens if a cfi references a text run instead of an element?
Sooo.... maybe we should keep things more as they are and simply match the authoring spec that the fragment identifier reference a target element. If we need cfis, we should probably look at all that entails separately.
iherman commentedon May 5, 2021
(I am late to the party...)
We do say that RS MAY support other schemes; maybe there should be some sort of hand waving that requires RS-s to document how they would handle such schemes if those schemes are more complex (eg, allow for text runs).
Another question on your proposal: I presume the proposal is to remove all references to xpointer, right? It is also mentioned for the
seqandbodyelements.The other (editorial) issue is the usual problem of SVG content documents: your proposal refers to the HTML spec for target elements; if SVG is applicable in those contexts (and I do not see why not) then the reference to the SVG element should also be included...
iherman commentedon May 5, 2021
Just to muddy the waters in case SVG is also relevant for Media Overlays: SVG allows for more complex references, see the SVG Fragment identifiers. We should be careful to allow those... But if we specifically link to the HTML and the SVG linking then we are covered I guess.
mattgarrish commentedon May 5, 2021
Only in the modification I've proposed above. I've added that as the xpointer shorthand requirement currently negates any other schemes. We don't have to be more liberal.
Ya, it's always a bit clunky to leave features unspecified, but in this case I guess there's no better option. The specification has a very element-heavy tone to it.
It is, but there's already some hand waving that we don't deal with them specifically:
That's why I'm wondering if we can get away with just referring to the target element definition in html. SVG has target elements, too.
iherman commentedon May 5, 2021
... and I was agreeing with your proposal! I was just saying that what you proposed covers things...
Why this note? What makes interoperability through SVG worse than with XHTML? I am not sure if I understand this.
SVG has more than that, and it would/should fit in our model. The reference above includes, for example:
to display a specific area of the SVG content. Are we saying that we do not allow this?
I believe that we should allow those targets that are defined in the HTML and SVG specifications, and nothing else (normatively). Maybe we can define a 'content target' (or whatever) as a term we use, pointing at the relevant part of the HTML and SVG specs, respectively, and use that term wherever we refer to xpointer at this moment.
add change log entries for #1586