TYPO3 Core

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?

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).

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.

css-styled content also has to be modified to use these anchors

1. 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

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

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

ok, so it should be <a name="c{field:uid}" id="c{field:uid}"></a><a name="{field:uid}" id="{field:uid}"></a> |

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.

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

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.

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

yes, let's drop support for netscape 4!

merged to CVS.