Feature #14842
closed
Request for new config option prefixLocalAnchorLinks to gain XHTML compliance
0%
Description
The definition of local anchors for content elements can be set via
tt_content.stdWrap.dataWrap
Standard output is:
<a name="{field:uid}"></a>
XHTML compliant setting would be:
tt_content.stdWrap.dataWrap = <a name="content{field:uid}" id="content{field:uid}"></a>|
We need the prefix "content" because an id has to begin with a letter and not with a number.
But now we have 2 problems:
1. the links in tt_content.menu.20.3 section indexes to local anchors will have to be prepended with content
2. the links created with the RTE linktool will also have to be prepended
While 1. can be solved easily with:
tt_content.menu.20.3.renderObj.typolink.section.wrap = content|
2. can only be fixed with a user function (thanks to Andreas Schwarzkopf for this one):
includeLibs.xhtmlanchor = fileadmin/user_typolink.inc
tt_content.text.20.parseFunc.tags.link.typolink.parameter.postUserFunc = user_xhtmlAnchor
See example function below.
This is why I`d like to ask for a new config option that prefixes links to local anchors automatically with a given string.
config.prefixLocalAnchorLinks = content
That would help to create XHTML compliant sites without having to hack user functions.
// Function posted in content rendering newsgroup by A. Schwarzkopf
function user_xhtmlAnchor($content,$conf) {
$uriparts = explode('#',$content);
if (isset($uriparts['1'])) {
$content = $uriparts['0'].'#content'.$uriparts['1'];
}
return $content;
}
?>
keyword:accessibility
(issue imported from #M1243)
Files
Updated by Sebastian Kurfuerst about 19 years ago
Is it really necessary to make this anchor configurable? Wouldn't it be enough to
prefix the anchor with "a" or some other character, but "hard-coded" to this character?
Updated by Martin Kutschker about 19 years ago
It makes little difference to me. But I think there should be a default value that is used when an XHTML doctype is in effect.
It's fine for me when this default can be overriden.
Note: Please move the functionality out of tt_content.stdWrap.dataWrap, so the dataWrap can be used for something else (on a per site basis).
Updated by Michael Stucki about 19 years ago
I see no sense in making this configurable.
Suggestion: We change the dataWrap to be prefixed with "content_" (is an underscore allowed?) and change the conflicting stuff accordingly.
I didn't check what needs to be done in the RTE but I think we just contact the authors to change this.
Updated by old_martinficzel about 19 years ago
css-styled content also has to be modified to use these anchors
- ts example
tt_content.menu.20.3.renderObj.typolink.section.field >
tt_content.menu.20.3.renderObj.typolink.section = content_{field:uid}
tt_content.menu.20.3.renderObj.typolink.section.insertData = 1
Updated by Sebastian Kurfuerst about 19 years ago
All sections are prefixed with "c" now.
The two uploaded patch parts do the following:
(1) update of the typolink function, update of CSS styled content
(2) update of static templates
This doesn't break compatibility for internal links, it only breaks compatibility if some external site links to a section on out pages. For full backwards compatibility, one would need to add:
tt_content.stdWrap.dataWrap = <a name="c{field:uid}"></a><a name="{field:uid}"></a> |
to the template. This will be written down in the changelog.
Any comments?
Greets, Sebastian
Updated by old_martinficzel about 19 years ago
why do you use the "name" attribute. as far as i know in xhtml2 this attribute is not supported. you can use the "id" attribute instead. as far as i know all browsers are supporting that to. correct me if thats wrong,
regards Martin
Updated by Ingo Renner about 19 years ago
ok, so it should be <a name="c{field:uid}" id="c{field:uid}"></a><a name="{field:uid}" id="{field:uid}"></a> |
Updated by Martin Kutschker about 19 years ago
Not really, XHTML2 has no name atribute for A elements at all.
But since XHTML2 is still in the future we can use name only or both id and name.
Updated by Sebastian Kurfuerst about 19 years ago
Hi Masi,
I think only using "id" is no problem, too. See http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1194 .
Greets, Sebastian
Updated by Ernesto Baschny about 19 years ago
As of http://www.w3.org/TR/xhtml1/#h-4.10
"Note that in XHTML 1.0, the name attribute of these elements [EB: a, applet, form, frame, iframe, img, and map] is formally deprecated, and will be removed in a subsequent version of XHTML."
So in HTML and XHTML 1.0 trans this is possible: <a name="c{field:uid}" id="c{field:uid}"></a>
But in XHTML (even 1.0 strict, and 1.1 and later), we need: <a id="c{field:uid}"></a>
As only Netscape4 seems to have a problem with anchors only with an "id", I propose we change it.
Updated by Sebastian Kurfuerst about 19 years ago
I replaced the currently available patches. only the ID is used in the new versions of the patches. I discussed this with Sacha and Ernesto, and as only Netscape 4 has a problem with the ID tag, this should be a safe change.
Greets, Sebastian
Updated by Ingo Renner about 19 years ago
yes, let's drop support for netscape 4!