Should one have to fully comply with W3C validator?

[man5]

Is w3c a truce source to follow for any errors found on a website?

 

For eg. I have my links setup like this.  < a href="record.php?id=4&user=smith"></a> 

 

W3C is tell me to not use "&" symbol and that instead escape it as &

So what do I just replace & with & in all my links?

[requinix]

Is w3c a truce source to follow for any errors found on a website?

Yes.

 

So what do I just replace & with & in all my links?

Yes. That particular problem rarely ever causes any issues so focus on other problems first.

[man5]

Yes.

 

Yes. That particular problem rarely ever causes any issues so focus on other problems first.

 

 

I find adding & looks ugly in the links. If it doesn't cause any issues, perhaps I can just stick with &?  Every other error has been fixed for W3C, except for this.

[Jacques1]

Personally, I prefer a simple rule (all literal ampersands must be encoded) over the highly complex ruleset for ambiguous ampersands which differs across HTML versions (and possibly browsers) and was revised several times.

 

Hard-coded URLs aren't a particularly good idea, anyway. How do you do URL-encoding? By hand? How do you reference files in higher directories? By travelling all the way up from the current file? If you just have a bunch of small PHP scripts, this may be good enough. But for anything more complex, I'd think about a proper URL function.

[man5]

Great. I will look into doing more proper url-encoding. 

 

Thanks.

[CroNiX]

it's pretty easy

http://php.net/manual/en/function.urlencode.php

[Jacques1]

Only to clarify: The ampersand problem cannot be solved with URL-encoding. If you encode the ampersand, then it loses its functionality.

 

What I meant is that you might want to replace the hard-coded URLs with an intelligent mechanism which takes care of all the low-level details: HTML-escaping of the entire URL (to prevent syntax issues like the ambiguous ampersand), URL-encoding of individual parameters, maybe custom resolution of relative URLs.

 

A simple URL function could look something like this:

function app_url($base_url, $parameters = null)
{
    $url = $base_url;
    if ($parameters)
    {
        $url .= '?' . http_build_query($parameters);
    }

    return $url;
}

The http_build_query() function automatically URL-encodes the parameters, so you don't have to do that by hand.

 

Then you simply HTML-escape the whole URL. If you use a template engine like Twig rather than plain PHP, you can leave that job to the engine. For example, your HTML snippet above would look like this:

<a href="{{ app_url('record.php', {'id': 4, 'user': 'smith'}) }}"></a>

This gives me a correctly encoded, correctly escaped URL, and I don't have to worry about any syntax problems.

 

Of course the benefit is less obvious with simple static URLs that don't have any special characters. Those might as well be prepared by hand. But as your application becomes more complex, it's a good idea to actually solve the problem once and for all.

[man5]

Only to clarify: The ampersand problem cannot be solved with URL-encoding. If you encode the ampersand, then it loses its functionality.

 

What I meant is that you might want to replace the hard-coded URLs with an intelligent mechanism which takes care of all the low-level details: HTML-escaping of the entire URL (to prevent syntax issues like the ambiguous ampersand), URL-encoding of individual parameters, maybe custom resolution of relative URLs.

 

A simple URL function could look something like this:

function app_url($base_url, $parameters = null)
{
    $url = $base_url;
    if ($parameters)
    {
        $url .= '?' . http_build_query($parameters);
    }

    return $url;
}

The http_build_query() function automatically URL-encodes the parameters, so you don't have to do that by hand.

 

Then you simply HTML-escape the whole URL. If you use a template engine like Twig rather than plain PHP, you can leave that job to the engine. For example, your HTML snippet above would look like this:

<a href="{{ app_url('record.php', {'id': 4, 'user': 'smith'}) }}"></a>

This gives me a correctly encoded, correctly escaped URL, and I don't have to worry about any syntax problems.

 

Of course the benefit is less obvious with simple static URLs that don't have any special characters. Those might as well be prepared by hand. But as your application becomes more complex, it's a good idea to actually solve the problem once and for all.

 

 

I know I am late on the reply but WOW! That looks a lot better than plain url.  I am learning shopify liquid and the above looks similar.  I will definitly check out Twig as I think I am going to enjoy the template language as I do with Liquid.  I like the setup and orgnization.