This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27326 - Supporting text/plain fragment identifiers
Summary: Supporting text/plain fragment identifiers
Status: RESOLVED DUPLICATE of bug 22562
Alias: None
Product: TextTracks CG
Classification: Unclassified
Component: WebVTT (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: Web Media Text Tracks CG
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-14 17:33 UTC by Erik Wilde
Modified: 2014-11-15 09:56 UTC (History)
3 users (show)

See Also:


Attachments

Description Erik Wilde 2014-11-14 17:33:45 UTC
What about supporting text/plain fragment identifiers? Then WebVTT users could point into a WebVTT document and say "there's a typo on line 42":

http://tools.ietf.org/html/rfc5147
Comment 1 Philip J├Ągenstedt 2014-11-14 23:30:47 UTC
Are there mainstream editors/browsers/something that will generate such a URL from the cursor position? If not, it seems like far less work to say "there's a typo itendifier" than generating a URL, especially since the receiver would also need software that understands the scheme, or be able to read it manually.
Comment 2 Silvia Pfeiffer 2014-11-15 03:54:11 UTC
The fragment identifier scheme would need to be defined for text/vtt specifically. Positions, characters and lines aren't so relevant to VTT. Since VTT has a structure, having references to cues via their identifiers and to time ranges (i.e. subsets of cues) makes a lot more sense. Something more in line with media fragment identifiers: http://www.w3.org/TR/media-frags/ .

As for use cases: there's also a discussion in https://www.w3.org/Bugs/Public/show_bug.cgi?id=22562 - I think we should take it back there.

*** This bug has been marked as a duplicate of bug 22562 ***
Comment 3 Erik Wilde 2014-11-15 09:56:42 UTC
good point about VTT being structured and thus using that structure making more sense than just using text/plain fragment semantics. thanks for taking the time to respond to this!