Jump to content

Should one have to fully comply with W3C validator?


man5

Recommended Posts

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 3 weeks later...

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.

Link to comment
Share on other sites

This thread is more than a year old. Are you sure you have something important to add to it?

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.