This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 197144 - Namespeces filtering issue in xhtml
Summary: Namespeces filtering issue in xhtml
Status: RESOLVED WONTFIX
Alias: None
Product: web
Classification: Unclassified
Component: HTML Editor (show other bugs)
Version: -S1S-
Hardware: PC Mac OS X
: P3 normal (vote)
Assignee: Marek Fukala
URL:
Keywords: REGRESSION
Depends on:
Blocks:
 
Reported: 2011-03-28 08:59 UTC by Marek Fukala
Modified: 2011-11-03 10:43 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Testcase (2.83 KB, text/html)
2011-03-28 19:50 UTC, bht
Details
Testcase 2 (673 bytes, text/html)
2011-08-16 03:44 UTC, bht
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marek Fukala 2011-03-28 08:59:50 UTC
Extracted from the original issue 194939:

I don't know whether this name space filtering is the final solution. Not name
spaced content enclosed by name space filtered tags is hidden, which means in
case of the testcase, the content within the <head> section is missing,
therefore causing warnings and the lack of proper validation.

I don't know how NB6.9 does it, but I could imagine that name spaced tags are
kept in a separate space so that they don't interfere with others but still are
validated for nesting, closing etc..
Comment 1 Marek Fukala 2011-03-28 09:10:18 UTC
This is possibly doable, but in my opinion once such foreign content is present it usually means that the foreign content defines a logic interpreted by a framework or in general by a code preprocessor which somehow builds the resulting html page for the browser. As such the code cannot be validated since it doesn't represent a valid html source in the design time.
Comment 2 bht 2011-03-28 19:48:43 UTC
May be we don't need validation of the foreign tags - we may just need to check that the foreign tags are closed properly.

However, the content enclosed by the foreign tags - this content is not foreign - should be validated as if the foreign tags did not exist, instead of ignoring it.

In the attached testcase, the title tag is ignored which results in a warning.

NetBeans 6.9 does all this really well.
Comment 3 bht 2011-03-28 19:50:57 UTC
Created attachment 107349 [details]
Testcase
Comment 4 Marek Fukala 2011-03-28 21:02:56 UTC
(In reply to comment #2)
> May be we don't need validation of the foreign tags - we may just need to check
> that the foreign tags are closed properly.
That's true. I didn't realize you are complaining about validation of the foreign content.

> 
> However, the content enclosed by the foreign tags - this content is not foreign
> - should be validated as if the foreign tags did not exist, instead of ignoring
> it.
No, such trees are usually invalid from the html point of view. I think my previous comment explained it sufficiently.

> 
> In the attached testcase, the title tag is ignored which results in a warning.
> 
> NetBeans 6.9 does all this really well.
Comment 5 bht 2011-03-28 23:01:51 UTC
Would it be possible to pinpoint the root cause of this problem?

Wicket is a modern top-of-the-line framework that has the cleanest markup that I can think of, and Wicket makes claims in that direction. If it wasn't using the best possible approach to markup then this would have been challenged long ago - and fixed.

So in order to avoid errors, it uses namespaces for a handful of wicket tags wrapping HTML markup that it must generate. I am not a HTML expert, but could it be true that the parser included in NB6.9 is namespace-aware and the one in NB7.0 is not?

Would it make sense that you file an issue against the new parser, or to use additional features of it?
Comment 6 bht 2011-08-16 03:44:42 UTC
Created attachment 109997 [details]
Testcase 2

Testcase 2 shows a HTML error hidden by filtering
Comment 7 Marek Fukala 2011-11-03 09:19:36 UTC
Please read my comment #1 *... ss such the code cannot be validated since
it doesn't represent a valid html source in the design time.*.

I'm not saying it must always be true, but I'm almost sure many others will complain if I do such validation and mark false errors.

Maybe some explicit wicket support could handle this.
Comment 8 bht 2011-11-03 10:21:57 UTC
I am requesting that the title gets changed back to its previous value "Namespaces filtering problem"

Namespace support worked fine with NetBeans 6.9 - HTML errors were flagged between name-spaced tags. Since 7.0 such erors are hidden due to "name-space filtering" which appears to be a workaround.

This is not really Wicket specific, because wicket is not the only namespace in xhtml documents. Using namespaces is the best practice to code custom tags while keeping XHTML clean and valid, and this should not break the editor.

It is not true that many others would complain about a fix of this bug because there are no "false errors" in this context as in comment #7. May be the issue of this bug is being misunderstood. How can anyone complain about something that gets fixed?
Comment 9 Marek Fukala 2011-11-03 10:43:52 UTC
(In reply to comment #8)
> I am requesting that the title gets changed back to its previous value
> "Namespaces filtering problem"
> 
> Namespace support worked fine with NetBeans 6.9 - HTML errors were flagged
> between name-spaced tags. Since 7.0 such erors are hidden due to "name-space
> filtering" which appears to be a workaround.
There was no real html code validation in 6.9. The only thing which was checked was whether a tag is properly matched. This should always be true in xhtml files since so from this point I understand your point about "hiding" the content of the namespaced tag from the validator.

In 7.0 the html validation service was added. It does far deeper validation of the code. The point I'm still trying to explain to you is that in that case your framework may generate parts of the document so just "collecting" the html (non-namespaced) content and letting it validate wouldn't work. The "hiding" is not a workaround, it is a must.

> 
> This is not really Wicket specific, because wicket is not the only namespace in
> xhtml documents. Using namespaces is the best practice to code custom tags
> while keeping XHTML clean and valid, and this should not break the editor.
> 
> It is not true that many others would complain about a fix of this bug because
> there are no "false errors" in this context as in comment #7. May be the issue
> of this bug is being misunderstood. How can anyone complain about something
> that gets fixed?