Feature Proposal: HTML attributes should use single quotes

Motivation

If you use a macro or a piece of template code and use that string inside another macro, chances are you'll encouter quote hell.

Quote hell is when double quotes break macro parameter strings, like INCLUDE params, which are defined inside double quotes. It is not always possible to $percnt escape those strings. So someone has used a double string in the piece of html you are adding and your app breaks. You are borked.

One of the troublemakers is ICON. But there are more. And now you can use TMPL:P inside topics, you will get borked for sure, someday.

Description and Documentation

Make a promise to only use single quotes for html attributes. So: <a href='#'>.

Change the places where you see them.

Document this.

And if something breaks in the future, it is because someone else didn't read TFR.

Implementation

-- Contributors: ArthurClemens - 20 Dec 2011

Discussion

We've been through the %ICON{..}% quote discussion before. The solution was to use $percntICON{...}$percnt. But in this case you are talking about where we haven't got control of escaping/delaying.

-- PaulHarvey - 21 Dec 2011

Constraining the quote that is used just raises the game to another level of hell. Let's get back to the root of the problem. It's the evaluation order - left-right-inside-out - which requires macro parameters to be fully expanded before the calling macro is itself expanded.

Unless someone can think of a way to do it, there is no way for the macro parser to automatically treat macro parameters specially. The reason is the way TML works. For example, a valid way to "parameterise a parameter" is to write: %EATME{"%DRINKME%"}%. If the parse could somehow "know" that DRINKME was part of a macro parameter, it could shield the quotes. However TML also allows: %EATME{%DRINKME%}% which would leave the parser not knowing how to handle the expansion of quotes in DRINKME. Worse is %%EATME%{}% where the outer macro isn't seen until the inner macro is fully expanded. So, no way to automatically handle quotes in the parser. We have to rely on user hints instead.

One way of hinting is to use single quotes in HTML, as Arthur describes, but it isn't an ideal solution, as users' expectation is that double quotes are also usable in HTML - and you still have the problem of inserting a double quote in HTML parameters.

Another possible solution would be to escape the parameters using another macro in some way. For example, %EATME{"%ENCODE{type="quotes" "%DRINKME%"}%"}% but that still leaves you with the problem that the expansion of DRINKME can ruin the ENCODE.

My conclusion is that we need some new syntax (sorry) that can be used to fully escape quotes within a span. For example,

%EATME{"<tmlq>%DRINKME%</tmlq">"}%"}%

which would be processed in the macro parser and would cause anything within <tmlq></tmlq> to have quotes escaped.

Though it has to be said I have a really bad cold, and this might just be the fevered outpourings of a deranged mind

-- CrawfordCurrie - 21 Dec 2011

Hey! Is that the same cold I've got? I'm actually using my currently fevered mind to have another go at a doomed-DOM-Foswiki::Render-replacement. But don't hold your breath

-- PaulHarvey - 21 Dec 2011

I fully agree with the general intend expressed in Arthur's original proposal: enforce a best practice to use single quotes on all html attributes. Alas, there might be code breaking when ICON now changes to that style, similarly all color prefs and the like. But maybe that's not as sever as it turns out for legacy wiki apps. The related pattern needs to be documented with hints for the user how to find and clean that up in old pages, maybe.

With regards to the outbreak of yet another parser rant above: I can't see how this is related to what Arthur proposed other than getting double quotes out of the way in tml parsing. Once they are single quotes they don't play a role anymore in tml parsing. That's the whole point of this proposal....

-- MichaelDaum - 21 Dec 2011

Getting quotes out of the way is exactly the point. Currently there is no way to safely embed quotes. A classic example of the bugs this causes is when user data (such as search results) contains both single and double quotes. You can't do anything with it, and no amount of "best practice" is going to help.

-- CrawfordCurrie - 21 Dec 2011

A slight problem that I encountered: using CGI to create html elements will always create double quoted attributes. I haven't found a way to let it generated single quotes.

-- ArthurClemens - 26 Feb 2012

If possible we should avoid using CGI. That's not possible in some places in foswiki, i.e. when populating forms with values. However, a lot of other code uses CGI to produce html markup where you'd be able to craft it otherwise easily, using single quotes.

-- MichaelDaum - 26 Feb 2012

yes, we should replace CGI for html generation and replace it with some kind of semantic templating. well, ok, so I can wish.

Paul's pluggable F::Render feature will help us experiment though

-- SvenDowideit - 09 Mar 2012

What have you got against CGI, apart from the double quotes?

• CGI looks after HTML encoding for you
• CGI looks after quotes (so long as you use it consistently)
• CGI is maintained by another project, so we don't have to bother.

-- CrawfordCurrie - 09 Mar 2012

Putting it the other way around: what is the benefit of using CGI for rendering HMTL snippets? When do I have to use it?

-- MichaelDaum - 09 Mar 2012

You never have to use it (sometimes you can't use it, because of the param rewriting). But:

• CGI looks after HTML encoding for you
• CGI looks after quotes (so long as you use it consistently)
• CGI is maintained by another project, so we don't have to bother.

So I use it whenever I can, so I don't have to worry about these things.

-- CrawfordCurrie - 09 Mar 2012

Well, umpf, if that's it ...

-- MichaelDaum - 10 Mar 2012

so basically, Crawford is saying that CGI is the least useful tool for the task at hand, and that we should indeed look at better ones.

Once the PSGI work is done, replacing it with a more modern html templating system becomes a no-brainer.

-- SvenDowideit - 10 Mar 2012

CGI is a shit. I have absolutely no problem with replacing it with something better. What I have a problem with is being asked to "...produce html markup where you'd be able to craft it otherwise easily, using single quotes", which is shittier.

-- CrawfordCurrie - 11 Mar 2012

What else is required to call this a done job? I don't see us rip out CPAN:CGI anytime soon. Can we shift this work to Foswiki-2.0?

-- MichaelDaum - 24 Apr 2013

This is what's caused the mess with the WikiGroups topic due to %ICON quotes changes. So this either needs to be reverted, or we need to fix up everywhere %ICON is used in the topics & templates, or enhance ICON to permit choice of single or double quote in rendering.

-- GeorgeClark - 24 Apr 2013

I suspect that this is about as complete as it can be while we continue to use CGI to generate HTML. I don't know whether to mark this merged, or defer it to 2.0? Anyone?

-- GeorgeClark - 03 Apr 2014

No, this proposal isn't quite finished. Nor do I know we really can without removing CGI from HTML rendering. Points listed by Crawford are all lapsed by now as CGI is being deprecated in perl land. To really finish this it actually needs a new proposal and a new committed developer. Therefore I'd suggest we mark this merged-to-core and close this one.

-- MichaelDaum - 03 Apr 2014

Done: Item11411 is now waiting for release.

-- GeorgeClark - 04 Jun 2014

Commenting is disabled while not logged in