Re: [Tiki-devel] Anchors are screwed up

Volker Wysk <post-hhF2Jplw28UoZk/[email protected]> Sat, 21 Jan 2023 17:46:15 +0100
Newsgroups	gmane.comp.cms.tiki.devel
Message-ID	<[email protected]>
Am Freitag, dem 20.01.2023 um 23:05 -0500 schrieb Brendan Ferguson:
> > 
> > It's also an issue for European languages other than English, which use
> > accented letters. It works, most of the time, but you have to botch
> > links
> > that use such anchors, by hand. And you get ugly URLs...
> > 
> > > Even still I do remember having some minor issues with this when
> > > working
> > > with german. In any case this issue is not a deal breaker with many
> > > installs. Old tiki’s continuing to work the same way, while new tiki’s
> > > moving forward with a universal solution would be preferable in my
> > > books.
> > 
> > > But I don’t like the idea of dual anchors. When people look at the
> > > code
> > > its not going to be obvious what is going on. If I am looking for an
> > > anchor to use, then will see two and pick one. Better to decide whats
> > > best
> > > and move forward with that.
> > 
> > You won't be looking a the HTML code, will you? It's unreadable (before
> > you
> > send it through htmltidy).
> 
> 
> I do all the time. If I want to see style something on a page, I just pull
> up the inspector butyl into my browser and zoom right into what the css-
> html looks like to write the correct css. Or likewise, if I am looking to
> link to somewhere on the page, just open open up the inspector again to
> see what there is lying around with something I am use as a anchor (like
> an anchor or a name) Or often just open the HTML to find a unique sequence
> I can search for to find the Smarty Template if I need to create custom
> smarty templates, or modify an existing one.

Okay, so for someone like you it will be non-obvious. But how many people
look in the HTML code to find something out, like the name of an anchor?
When the transition to clean anchor names in the HTML has been made, like
discussed, then the anchor name will be obvious. For explicit anchors, it
will be what has been set with the ANAME plugin. For anchors generated from
headings, the anchor name will be the heading. No looking at the HTML code
necessary and the new anchor names will be used.

> You have to remember that code sticks around for a long time sometimes.
> Its best to make things obvious about what they are doing and why they are
> there. 

I'm always in favor of good and complete documentation. (Alas the Tiki code
I've read until now was almost undocumented.)

> Leads to less errors down the line when someone modifies something and
> does not fully realize what it is doing. Although it’s not a deal breaker
> and I have been both guilty of breaking non-obvious code and also writing
> it for it only to be broken later :( Unit tests and lots of documentation!
> Ok, that was a bit of a rant.


Cheers,
Volker

> > 
> > Cheers,
> > Volker
> > 
> > > 
> > > Just my 2 cants.
> > > 
> > > > 
> > > > This way, compatibility with old Tiki pages is ensured.
> > > > 
> > > > 4. Encode the subsection part of internal Tiki links with the new
> > > > function,
> > > > when generating HTML. Old links, which have the manual underscore
> > > > replacement in it, won't get changed by the new encoding. They will
> > > > match
> > > > the old anchors (3.). New links, which don't have an encoding in the
> > > > subsection part, will match the new anchors (2.).
> > > > 
> > > > Doing it this way wouldn't require any transformation of old Tiki
> > > > pages'
> > > > source code. 
> > > > 
> > > > 
> > > > So I'm creating a wish now...
> > > > 
> > > > Cheers,
> > > > Volker
> > > > 
> > > > > > > On 15 Jan 2023, at 11:18, Volker Wysk <post-hhF2Jplw28UoZk/[email protected]>
> > > > > > > wrote:
> > > > > > 
> > > > > > Hi.
> > > > > > 
> > > > > > In wikiplugin_aname.php and wikiplugin_alink.php, there's the
> > > > > > following:
> > > > > > 
> > > > > >   // the following replace is necessary to maintain compliance
> > > > > > with
> > > > > > XHTML
> > > > > >   // 1.0 Transitional and the same behavior as tikilib.php. This
> > > > > > will 
> > > > > >   // change when the world arrives at XHTML 1.0 Strict.
> > > > > >   $aname = preg_replace('/[^a-zA-Z0-9]+/', '_', $aname);
> > > > > > 
> > > > > > This means, only latin letters and digits are allowed in anchor
> > > > > > names.
> > > > > > Everything else is replaced by an underscore when rendering the
> > > > > > HTML
> > > > > > page.
> > > > > > 
> > > > > > This (sometimes) works, as long as only the AName and ALink
> > > > > > plugins
> > > > > > are
> > > > > > used. But it doesn't, when the subsection part in an internal
> > > > > > link
> > > > > > is used -
> > > > > > ((Page|#Subsection|...)). I've tried it with
> > > > > > "((Ankertest|#Überschrift-
> > > > > > Anker))" and got a subsection part of "#%C3%9Cberschrift-Anker"
> > > > > > in
> > > > > > the
> > > > > > generated HTML.
> > > > > > 
> > > > > > The subsection part needs to undergo the same treatment as the
> > > > > > anchor name,
> > > > > > which the AName plugin does, when this is supposed to work.
> > > > > > 
> > > > > > Anchors which are generated from headings are different as well.
> > > > > > I've tried
> > > > > > it with a heading called "Überschrift dazwischen", and the
> > > > > > resulting
> > > > > > anchor
> > > > > > name in the HTML page is "berschrift_dazwischen".
> > > > > > 
> > > > > > And what about languages that don't use a latin alphabet, such
> > > > > > as
> > > > > > many Asian
> > > > > > languages? The complete anchor names will be replaced by an
> > > > > > underscore.
> > > > > > 
> > > > > > Anchor handling is really screwed up.
> > > > > > 
> > > > > > The world has "arrived at XHTML 1.0 Strict" long ago - in 2002,
> > > > > > it
> > > > > > says in
> > > > > > the https://www.w3.org/TR/xhtml1/ page. So it's time that "this
> > > > > > will
> > > > > > change".
> > > > > > 
> > > > > > Regards,
> > > > > > Volker
> > > > > > _______________________________________________
> > > > > > TikiWiki-devel mailing list
> > > > > > [email protected]
> > > > > > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
> > > > > 
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > TikiWiki-devel mailing list
> > > > > [email protected]
> > > > > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
> > > > 
> > > > _______________________________________________
> > > > TikiWiki-devel mailing list
> > > > [email protected]
> > > > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
> > > 
> > > 
> > > _______________________________________________
> > > TikiWiki-devel mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
> > 
> > _______________________________________________
> > TikiWiki-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
> 
> _______________________________________________
> TikiWiki-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

_______________________________________________
TikiWiki-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
signature.asc (application/pgp-signature, 833 B)