I wrote this

The tests aren't flawed. They just ask for specific tasks to be done, and people often do not do those tasks accordingly, such as above. The task did not ask anywhere for the script tags to be placed in the head section lol.

They actually are flawed in that objectives require a specific way that may not completely be standards. They don't take into account variable ways of achieving something in many cases. Such as in this case, it should work despite that he has script tags in the head. Anything that doesn't take into account the different standards-compliant possibilities, is fundamentally flawed.

I don't think you quite understand how difficult it is to account for every single possible scenario that might pop up as an answer. This isn't for production code at all, and what they're asking you to do is standards compliant. If you fail to do something simple, it is on you, not the system.

Never said anything about accounting for every possible scenario. Such as in some of the PHP classes,

<?php echo "something"; ?>

is fundamentally the same as

<?= "something"; ?>

however in some of the tests the latter would fail despite producing the exact same output.

Now for this case, which states to put script tags in the body -- the only part of the markup that should be checked in the test is what's inside the body tags. If there is the presence of the script tags, it should pass, granted the syntax of it is valid, it should pass despite of what is elsewhere on the page.

You must have wrote some HTML elements there in your "is fundamentally the same as", but they aren't showing up because unless they're encapsulated in a 3 backtick code block, you must use entities for the < and > (which are & lt; and & gt; respectively, push the & and the lt; or gt; together); otherwise, your elements won't show up at all, which is what happened here.

What I'm saying is that there is no reason to put anything else on these challenge pages except for what the tasks ask you to put on there. None whatsoever. Why people continue to do so confounds me to be honest.

I fixed my last comment, but I agree there's no need -- but it happens often enough that certain precautions should be fixed. And in the case of my last comment, shows that it's fundamentally flawed as the would-be failing test is standards compliant as is the passing answer. It should account for both in that respect.

While <?= and <?php echo might be fundamentally the same, one is not a best practice when it comes to writing PHP: the first method. Short tags have to be enabled by the server (pre-PHP 5.4), and if you move your code over to a server where they aren't enabled, you are going to be looking at a debugging nightmare, because your code isn't going to work which will leave you scratching your head as to why it isn't working. As of PHP 5.4+, short tags are enabled by default, but then again, you never know what version of PHP the server you migrate to is going to be using.

Before the misinformation train goes too far out of the station, there are a bunch of things you need to understand about PHP short tags.

The primary issue with PHP's short tags is that PHP managed to choose a tag (<?) that was used by another syntax, XML.

With the option enabled, you weren't able to raw output the xml declaration without getting syntax errors:

<?xml version="1.0" encoding="UTF-8" ?>

This is a big issue when you consider how common XML parsing and management is.

What about <?=?

Although <? causes conflicts with xml, <?= does not. Unfortunately, the options to toggle it on and off were tied to short_open_tag, which meant that to get the benefit of the short echo tag (<?=), you had to deal with the issues of the short open tag (<?). The issues associated with the short open tag were much greater than the benefits from the short echo tag, so you'll find a million and a half recommendations to turn short_open_tag off, which you should.

With PHP 5.4, however the short echo tag has been re-enabled separate from the short_open_tag option. I see this as a direct endorsement of the convenience of it, as there's nothing fundamentally wrong with it in and of itself.

The problem is that you can't guarantee that you'll have it if you're trying to write code that could work in a wider range of PHP versions.

So, if you have 5.4+, the shorthand is the preferred method for an inline echo by the community.

First of all nice, copy and paste action with that comment above. I saw that exact answer in StackExchange: http://programmers.stackexchange.com/questions/151661/is-it-bad-practice-to-use-tag-in-php

You are the one with the misinformation, sir. From PHP.net's site:

"PHP also allows for short open tag <? (which is discouraged since it is only available if enabled using the short_open_tag php.ini configuration file directive, or if PHP was configured with the --enable-short-tags option)."

on this article: http://php.net/manual/en/language.basic-syntax.phptags.php.

Also, it is said that in PHP 6 short tags will be deprecated, although I've been unable to find confirmation of this from php.net.

Yes it was a copy and paste, and for good reason.

Here's the thing, short tags yes -- those are essentially gone. Go ahead and turn your short tags off, i guarantee that the short echo still works.

Hence this line, on the very PHP manual page you linked:

5.4.0 The tag <?= is always available regardless of the short_open_tag ini setting.

But I guess you're right, and the last 18 years of writing PHP have been a waste for me...

If the creators of PHP tell me that I really shouldn't use something in their own language, I think I would go with what they say, unless I was delusional lol.

That line right there, that's on the manual should be proof enough.

Also: There will be no PHP 6. They promised it years ago, it never came. They've decided to skip version 6 as there was already so much hype about it, but the next version will be very different than the proposed version 6 so they've gone ahead and jumped straight to 7.

https://wiki.php.net/rfc/php6

Well, then, we both learned something new because PHP 6 wasn't a proposed version; it was its own version that was almost completely different from the PHP version at that time. It says that PHP 6 already existed, which I didn't think would happen with a version control system since we're currently on some 5.x versions. Their code must have been so botched in version 6 that they had to take a step back into the old code lol.

And just in case you need more information on the short echo tag: http://marc.info/?t=123964298400001&r=1&w=2 http://svn.php.net/viewvc?view=revision&revision=311260

Also take note in that I say proposed version, in that many of us developers were looking forward to some of the core features of 6. What ultimately botched 6 was the unicode support they were trying to implement, and just couldn't get correct.

The end result was that each feature slated for PHP 6 was back-ported into the 5.x branch, which is why we saw such a jump in awesome useful features for PHP 5.3.

http://php.net/manual/en/doc.changelog.php

scroll down ( or ctrl + f ) 5.3.0 and notice all the changes.