This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
A link element rel value is needed to support text-to-speech synthesis via Pronunciation Lexicon Specification (PLS) for customized or unexpected pronunciations. PLS 1.0 defines a way to provide pronunciations that might not already be in TTS software. While it is designed to work with XML and SSML, there seems no inherent reason why an HTML5 document can't reference a file of pronunciations. I propose section 6.12.3 add a value for the link element for the rel atribute to refer to the *.pls file. I propose the value be "pronunciation". A past practice of using abbr or acronym tags to support pronunciations caused confusions with some browsers, and should be abandoned or deprecated. I plan to add this to the RelExtensions wiki unless there's an objection. Thank you. -- Nick
Proposals should go here: http://wiki.whatwg.org/wiki/RelExtensions You'll need to write a spec first, and demonstrate that people are using the keyword.
This bug predates the HTML Working Group Decision Policy. If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.
I am drafting a spec, with a wide range of options and reliance on HTML, PLS, and other existing technologies.
Please let us know once this keyword is deployed, for reconsideration.
I've stopped developing the specification and I don't plan to implement it on any website. It's already over 177 pages long, it could take months or maybe a year (part-time) to finish it, and when I stepped away for a month or two and came back to it I had forgotten a lot of it even though I remember (X)HTML without authoring in months. Natural languages and Web features are complicated and require a spec that can handle them. It's important to support visually impaired, blind, and illiterate users and people who'd simply like the convenience of having the Web read to them when they're busy multitasking. My giving up on this means I still have no good method for supporting these users. I hope someone develops something for this functionality and I'm happy to offer my incomplete draft if that'll help them, but if another approach is better then reserving the rel value "pronunciation" as proposed in this HTML5 feature request may not be a good idea anymore. I'll leave that to someone else to ponder. So I'm closing this bug report. And I'm going to delete the corresponding entry from <http://wiki.whatwg.org/wiki/RelExtensions>. It can be restored if someone has a suitable method. Thanks.
I would like to re-open this issue, because pronunciation lexicons are very important in speech-enabled user-agents. As you know, Text to Speech (TTS) is a key enabling technology in the field of accessibility. I added a short proposal in the proposed list of "rel" extensions (named "pronunciation"): http://wiki.whatwg.org/wiki/RelExtensions Please note that the next generation of the EPUB electronic publication standard (due to be finalized in 2011) supports both (X)HTML5 and PLS, but the "link" / "rel" mechanism is not used, because EPUB applies pronunciation rules globally for the publication, not at the HTML file level (a single publication usually contains several XHTML files). http://epub-revision.googlecode.com/svn/trunk/build/spec/epub30-overview.html#sec-tts Looking forward to comments. Regards, Daniel
(In reply to comment #6) FYI, I have requested feedback on the Voice Browser and EPUB mailing-lists: http://lists.w3.org/Archives/Public/www-voice/2011JanMar/0021.html http://groups.google.com/group/epub-21-working-group/browse_thread/thread/6492e45772293ecc Regards, Daniel > I would like to re-open this issue, because pronunciation lexicons are very > important in speech-enabled user-agents. As you know, Text to Speech (TTS) is a > key enabling technology in the field of accessibility. > > I added a short proposal in the proposed list of "rel" extensions (named > "pronunciation"): > > http://wiki.whatwg.org/wiki/RelExtensions > > Please note that the next generation of the EPUB electronic publication > standard (due to be finalized in 2011) supports both (X)HTML5 and PLS, but the > "link" / "rel" mechanism is not used, because EPUB applies pronunciation rules > globally for the publication, not at the HTML file level (a single publication > usually contains several XHTML files). > > http://epub-revision.googlecode.com/svn/trunk/build/spec/epub30-overview.html#sec-tts > > Looking forward to comments. > Regards, Daniel
Comment #1: The PLS-specificness of the pronunciation file should be given by the 'type' attribute, not by the 'rel' value. The definition of the link type should thus be more generally referring to pronunciation resources. It is conceivable that another pronunciation lexicon format could be created, or a different kind of pronunciation resource could be created, in which case it should use the same link type. Comment #2: Adding the definition to the wiki doesn't fulfill the second requirement to add the link type to the HTML spec: that the link type be in wide use. Please understand that link types are an extension mechanism in HTML: a value does not need to be included in the HTML spec to be deployed. Registering it in the wiki is sufficient for use. I would recommend therefore to close this bug with no change to specification.
Just wanted to clarify that I don't think this is a bad idea: I agree 100% with what this link type is trying to accomplish. I just don't see it as having fulfilled the requirements Ian set out for acceptance of the proposal, and, given the way link type registration works, don't see the lack of inclusion in the HTML5 spec as a blocker.
(In reply to comment #9) > Just wanted to clarify that I don't think this is a bad idea: I agree 100% with > what this link type is trying to accomplish. I just don't see it as having > fulfilled the requirements Ian set out for acceptance of the proposal, and, > given the way link type registration works, don't see the lack of inclusion in > the HTML5 spec as a blocker.(In reply to comment #9) > ... given the way link type registration works, don't see the lack of inclusion in > the HTML5 spec as a blocker. I'm not sure I understand the nature of the relationship between the HTML5 specification and the "rel extensions" wiki page, but I thought that this previously-closed issue was the right place to reactivate the discussion on the "pronunciation" rel extension. On a side note, if indeed this issue doesn't actually impact the HTML5 specification itself, I suggest closing this bug using "RESOLVED INVALID" instead of the previously-used "RESOLVED WONTFIX".
(In reply to comment #8) > Comment #1: The PLS-specificness of the pronunciation file should be given by > the 'type' attribute, not by the 'rel' value. The definition of the link type > should thus be more generally referring to pronunciation resources. It is > conceivable that another pronunciation lexicon format could be created, or a > different kind of pronunciation resource could be created, in which case it > should use the same link type. Excellent point, the wiki page has been updated accordingly.
Adding the accessibility task force to the cc field of this pre-last call bug. Daniel Weck added the keyword "a11y" and "Disagree". I've also added it to the list of HTML5 Spec Bugs Awaiting "a11ytf" keyword decision, so that the a11y bug team is alerted. http://www.w3.org/WAI/PF/HTML/wiki/Bugs/Bugs_Awaiting_A11yTF_Keyword_Decision#HTML5_Spec_Bugs_Awaiting_Decision
The bug-triage sub-team thinks this should be task force priority, thus adding the a11yTF keyword. Daniel should follow-up within the next two weeks deciding if he wants to escalate this to an issue. Please add the keyword "TrackerRequest" if you'd like to escalate it.
(In reply to comment #13) > The bug-triage sub-team thinks this should be task force priority, thus adding > the a11yTF keyword. Daniel should follow-up within the next two weeks deciding > if he wants to escalate this to an issue. Please add the keyword > "TrackerRequest" if you'd like to escalate it. My understanding is that decisions pertaining to the "rel" extensions do not impact the general HTML5 working group progress. As a consequence, I do not mind this particular bug being closed as "invalid", as long as the accessibility task force (or other suitable committee) keeps track of the requirement to "reserve" the 'pronunciation' keyword, so that pronunciation lexicons referenced in HTML files can be easily discovered by speech-enabled user-agents.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: no spec change yet Rationale: Putting the link relation on the wiki page is sufficient to reserve it, but it also has to be implemented to actually be of any use in the world (and that's a prerequisite to being added to the spec, in principle). Discussion of this kind of thing is probably best done in one of the W3C lists such as public-html or the voice-related working group mailing lists.
mass-moved component to LC1