Bugzilla – Full Text Bug Listing
| Summary: | Undefined (Custom) HTML attributes now show as warnings | ||
|---|---|---|---|
| Product: | [WebTools] WTP Source Editing | Reporter: | Cherry Development <eclipse> |
| Component: | wst.html | Assignee: | Nick Sandonato <nsand.dev> |
| Status: | RESOLVED FIXED | QA Contact: | Nitin Dahyabhai <thatnitind> |
| Severity: | normal | ||
| Priority: | P3 | CC: | for.work.things, g.georgovassilis, itewksbu |
| Version: | 1.5.3 | Keywords: | helpwanted |
| Target Milestone: | Future | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://dev.eclipse.org/newslists/news.eclipse.webtools/msg13271.html | ||
| Whiteboard: | |||
|
Description
Cherry Development
Please clarify and/or perhaps attach some samples. Not that I am doubting you, but at some point one thing that changed was now we also validate JSP fragments (better) and other have reported increases in warnings due to that fix. And, I believe, it does have a preference to disable fragment checking (hence restoring previous behavior). Let us know ... thanks. Sure thing. In 1.5.2, the following HTML fragment used to verify: <span jwcid="@Insert" value="ognl:myProperty"></span> Now it does not. Would the JSP fragments feature affect non-JSP files? I'll revert back to 1.5.3, see if turning off the fragment checking fixes it, and then report back here. Ya, so I've reverted back to 1.5.3, disabled JSP fragment checking and I am still seeing "undefined attribute name" warnings so it appears that there is some new behavior in 1.5.3 that's not directly related to the fragment checking that is causing these warnings to appear. Actually, I believe this is due to us fixing bug 159926 / bug 143209. We were incorrectly saying any attribute was allowed in html tags except for jsp tags. This bug could be used as an enhancement request for more validation preferences. You may also want to check out bug 157407 which is about the ability to add more tags (or in your case, attributes) to the html content model. That seems more ideal because then validation/content assist/anything else that uses the content model would then recognize and know how to handle your special tags/attributes. I would say till this bug or bug 157407 is fixed, your best bet is to just disable html validation via the validation preference page because you're doing something different than the html spec. Actually, there may be another option if you use xhtml vs html. For html files that using the html 4.01 spec, we are using our own internal content model. But for xhtml files, we read whatever is in the xhtml dtd (just like for any other xml file). What you could do is take the xhtml dtd and modify it/add to it to add in your special tags. Then you can add your modified xhtml dtd entry to the XML Catalog so that your special dtd is always used instead of the official one. Thanks Amy ... I should know better than rely on my memory, but glad you knew of the connection. I'm assigning to you for now, just to acknowledge the triage. I'm also marking as helpwanted, to acknowledge right at the moment we have no one or no plans to improve the preferences (correct me if I'm wrong there too :) and would seem an "isolated" bit of function someone could think about contributing. reassigning to inbox There is a preference in "Window -> Preferences -> Web -> HTML Files -> Validation -> Attributes" as to weather to validate undefined attribute names or not. This I believe is exactly what this bug was looking for. Time to close it out. The preference does exist. Marking as fixed. The preference Nick Sandonato mentions exists, but it disables validation altogether for 'unknown' attribute names. I.e. when developing with angular.js there is a completely new set of ng-* attributes. I'd like to be able to add a schema that validates those attributes for proper use. (In reply to george georgovassilis from comment #10) > The preference Nick Sandonato mentions exists, but it disables validation > altogether for 'unknown' attribute names. I.e. when developing with > angular.js there is a completely new set of ng-* attributes. I'd like to be > able to add a schema that validates those attributes for proper use. Hi George, Please see Bug 415980. Sounds pretty close to what you want, minus the schema. |