Reassigning, please evaluate. Thanks.

I have downloaded wordpress 3.6 and opened in the NetBeans 7.4. In project navigator there is one file with red exclamation mark icon (wp-include/js/thickbox.css).

Please try with the latest build and let me know. You can download the latest NB 7.4 build here: http://bits.netbeans.org/download/trunk/nightly/latest/ . Thanks.

Thanks for your feedback,
I just tried with the latest build. Effectively, a red exclamation mark icon appears on wp-include/js/thickbox.css. In my opinion, it shouldn't appears as an error cause "expression" is a function in CSS. It allows managing some cases on IE (mostly the version 6), that's why some jquery plugins uses it.
Another point, it seems you didn't test the latest Prestashop CMS version. Many errors appears with this CMS (mostly javascript errors in tpl file).

Thanks to take this comment in account. Have a good day.

Marku, could you please look at the css part? I have seen that you solved recently similar issue. Thanks

The wordpress problem is desrcibed in the issue 230042, unfortunately not yet fixed. Passing back to Petr.

I have opened Prestashop CMS, there are some problem in css files again. Mareku, could you look at this as well?

But regarding the tpl files, there are some tpl files that have extension .php, which is wrong IMHO. These files are treated as php and not tpl files. If you want to threat them as tpl files you have to set up in Tools->Options->Miscellaneous->Files tab TPL mimetype for all php files. Then php files will be also tpl files, which is basically wrong, because the php files shouldn't have tpl syntax inside. 

I have notice one more issue in tpl: issue #235733

I wen't trough all files that are marked with red icon in Prestashop CMS. The red marked files are html, css, php files that contains Smarty and tpl files that suffer with issue #235733 or there is issue in css, where is used Smarty. So from javascript point of view it's clean. 

So if you want to fix issue #235733, please increase the priority to P2. 

Marku the metioned problem in tpl file with css is this one:

<table
  {if $table_id} id={$table_id}{/if}
				class="table {if $table_dnd}tableDnD{/if} {$list_id}"
				cellpadding="0" cellspacing="0"
				style="width: 100%; margin-bottom:10px;">

It looks like the line with id cause the problem. Reassigning back to css.

> So if you want to fix issue #235733, please increase the priority to P2. 
No, it is P3 on purpose.

> 
> Marku the metioned problem in tpl file with css is this one:
> 
> <table
>   {if $table_id} id={$table_id}{/if}
=> marfous

(In reply to Marek Fukala from comment #8)
> > Marku the metioned problem in tpl file with css is this one:
> > 
> > <table
> >   {if $table_id} id={$table_id}{/if}
> => marfous

Sorry for the reassignment back, but Smarty is probably not able to do here more, the generated source:
  @@@ id=@@@
	class="table @@@tableDnD@@@ @@@"
	cellpadding="0" cellspacing="0"
	style="width: 100%; margin-bottom:10px;">

Once there are completed quotes around the ID attribute, CSS doesn't complain about any issue. This looks to me that CSS is not able to handle unquoted fake value @@@. Feel free to reassign back if I'm wrong, thanks.

(In reply to Martin Fousek from comment #9)
> (In reply to Marek Fukala from comment #8)
> > > Marku the metioned problem in tpl file with css is this one:
> > > 
> > > <table
> > >   {if $table_id} id={$table_id}{/if}
> > => marfous

There's no problem with CSS, but the html lexing is incorrect for the sample code. 

The html lexer sees the input as continuous sequence of characters.  What appears in the sequence is determined (correctly) by the TPL lexer. 

The html lexer in this cases sees <table id= class="table... which means the class is considered as the value of the id attribute (correctly according to html spec). 

If there was a way how to detect the "gap" which is not visible in the html lexer input, then I could do some magic in the html lexer and lex the class as an attribute and not as the attribute value as it is now. However currently it seems to be impossible to detect that situation.

I've separated this problem in issue Bug 235794 - Incorrect html lexing of attribute if an upper level language construct present in the tag

Another css issue I found is:

div {
min-height:80px !ie;
}

is not parseable: filed as Bug 235798 - !ie hack support

Some of the parsing issue are valid code bugs like:

prestashop/admin/themes/default/css/admin.css:132:

.table{ background-color:#fff;border:1px solid #ccc;padding:0: border-radius:3px; -moz-border-radius:3px;-webkit-border-radius:3px;}

typo after padding:0 - colon instead of semicolon.

Another issue:  <div id="#id"></div> ... #id marked as erroneous - filed as Bug 235799 - <div id="#id"></div>marked as erroneous

Then finally plenty of errors in html files under prestashop/mails and modules. There are caused by presence of some {...} notation in both html and css code. For example in the prestashop/mails/en/account.html there's following code:

<td align="left">Hi <strong style="color: {color};">{firstname} {lastname}</strong>,</td>

The values delimited by the curly braces are not recognized by the html editor and hence causing issues mainly in the embedded css code.

The notation looks like smarty custom functions, and seems to be a part of some templating method. 

But I'm not sure about that, passing to Martin for further evaluation. You may refer to [1] for more information.

[1] http://doc.prestashop.com/display/PS15/English+documentation

Reporter do you know whether the {string} statements are of any specific language?

BTW, I saw something like this in its sources:
$vars = array(
'{firstname}' => $this->datas->admin_firstname,
...
'{shop_url}' => Tools::getHttpHost(true).__PS_BASE_URI__,
);
$content = str_replace(array_keys($vars), array_values($vars), $content);

Which probably means that it's custom "templating system" used by the CMS and we are not easily able to handle it. In any case Smarty values must be prefixed as a common PHP variables with the "$". Switching rest of the issue to the enhancement to HTML.

Probably there could be general HTML support to disable validations at the file or even folder, but it has to be evaluated by Marek whether there is something like that possible.

Martin,
In my opinion, {string} statements are not a specific language. In prestashop CMS, those are used to give some variables to email template for example. HTML files are just parsed and PHP replace {string} statements  by values.
So, {string} is not the smarty syntax (different of {$string}).
Let me know if you need more information.

(In reply to Zicguy from comment #16)
> Martin,
> In my opinion, {string} statements are not a specific language. In
> prestashop CMS, those are used to give some variables to email template for
> example. HTML files are just parsed and PHP replace {string} statements  by
> values.
> So, {string} is not the smarty syntax (different of {$string}).
> Let me know if you need more information.

Thanks. That's exactly what I thought/wrote. So the only way I see would be to disable validation per file/folder probably.

Closing the issue then. The individual issues were filed already.

Martin,

Maybe HTML parser can also ignore {string} statement, no?
Else, is there an actual way to disable validation per file/folder?

Thanks.

(In reply to Zicguy from comment #19)
> Maybe HTML parser can also ignore {string} statement, no?

But how would you like to generally specify something like this? ;) That's not proper way.

> Else, is there an actual way to disable validation per file/folder?

I don't think so, that should be subject of this RFE.

(In reply to Martin Fousek from comment #20)
> (In reply to Zicguy from comment #19)
> > Maybe HTML parser can also ignore {string} statement, no?
> 
> But how would you like to generally specify something like this? ;) That's
> not proper way.
> 
> > Else, is there an actual way to disable validation per file/folder?
> 
> I don't think so, that should be subject of this RFE.
There's a way how to disable html validation, which doesn't trigger any errors in this case. As for the css validation - there's a RFE for that filed: Bug 141181 - it should be possible to enable/disable CSS warnings. The issue is added to the nb8 plan.

(In reply to Martin Fousek from comment #20)

> But how would you like to generally specify something like this? ;) That's
> not proper way.

Maybe the HTML lexer can detect if there is a {string} statement and "validate it". {string} statements mostly significate the use of a template engine. So, in my opinion, HTML lexer has not to mark them as an error.

(In reply to Marek Fukala from comment #21)

> There's a way how to disable html validation, which doesn't trigger any
> errors in this case. As for the css validation - there's a RFE for that
> filed: Bug 141181 - it should be possible to enable/disable CSS warnings.
> The issue is added to the nb8 plan.

What is the "nb8 plan" and when will it be launched?

(In reply to Zicguy from comment #22)
> Maybe the HTML lexer can detect if there is a {string} statement and
> "validate it". {string} statements mostly significate the use of a template
> engine. So, in my opinion, HTML lexer has not to mark them as an error.

But sometime templates can use {string} syntax, second time %%string%% one etc. Also hard to say whether {string} couldn't be i.e. a mistake for the #{string} which is Expression Language. In any case keeping the issue on Marek. It's his component and he knows the best what to do here.

Can you tell me if corrections will be in the next release of netbeans?
Thanks.

Hello,
I just try the 7.4 RC version. It seems this version not includes corrections of this topic. Can you tell me when they will be available? maybe in the 7.4 final version? Thanks.

As you can see from the statuses of the individual bugs I've filled, not much is fixed yet, even in trunk.

I'm really sorry, but the issue was filled bit late in the development cycle to be fixed in 7.4. The issues will not be addressed sooner than in netbeans 8.0.

Thank you for your valuable feedback, it will not be lost!

I've filed Bug 236266 [CSS/HTML: add some generic support for templating] for the last problem.