Closed Bug 184772 Opened 23 years ago Closed 15 years ago

Non-standard style="" attribute gets discarded

Categories

(Core :: DOM: CSS Object Model, defect)

Product:
Core
Component:
DOM: CSS Object Model
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: tai, Unassigned)

References

Details

User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows 98) Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 When I type in following HTML in Mozilla composer, it always trashes style="" attribute. So <a href="..." folder="..." style="behavior: url(#default#AnchorClick)">...</a> becomes <a href="..." folder="..." style="">...</a> as soon as I do a "preview" and go back to "<HTML> Source" view. This non-standard style attribute is used by Internet Explorer to make URL recognized as WebDAV resource (which will in turn invoke WebFolder client upon clicking), but due to this bug, I couldn't make a direct link to WebDAV URL. Whether style property is standard or non-standard, Mozilla Composer should be able to handle it as it is even if it does not understand the meaning or way to render it properly. Reproducible: Always Steps to Reproduce: 1. In composer "<HTML> Source" screen, type in <a href="..." style="foo: bar">...</a> 2. Switch to "Preview" screen. 3. Switch back to "<HTML> Source" screen. Actual Results: You will find non-standard style property "foo: bar" to be discarded unexpectedly. Expected Results: Should preserve any user-set property regardless of its standardness. I assume this bug is a parser bug that is linked with http://bugzilla.mozilla.org/show_bug.cgi?id=59985 So I guess current parser trashes any element that is not known to the parser?
One more note. Current workaround to this problem is to mark all link to WebDAV URL by class="" attribute, and set style behavior propery to that class. For example, <style> a.davlink { behavior: url(#default#AnchorClick); } </style> <a class="davlink" ...> Mozilla Composer does not trash above style declaration and the link does work as expected.
To composer.
Assignee: harishd → syd
Status: UNCONFIRMED → NEW
Component: Parser → Editor: Composer
Ever confirmed: true
OS: Windows 98 → All
QA Contact: moied → sujay
Hardware: PC → All
-->glazman for triage
Assignee: syd → glazman
This is not a Composer issue but a DOM Style issue since the contents of the style attribute are generated from a CSSdecl when we query it. I doubt we are going to fix this. David, Boris, opinions ?
Assignee: glazman → jst
Component: Editor: Composer → DOM Style
QA Contact: sujay → ian
I doubt that too, since the CSS parser does, should, and will drop things it does not recognize.... (unless we write a special editor mode for it).
As I have mentioned elsewhere, we should be keeping a string version of the style attribute around, and only updating it when the relevant style declaration is _changed_. So unless the style declaration gets modified, the style attribute should be exactly what was given in the markup. IMHO.
Ian, your proposed course of action is, as I've mentioned before, costly in terms of memory... It could probably be done if we introduced some overhead to nsHTMLValue by having the nsISupports point to an object that holds both the string and the style rule, then clearing the string if the style is modified and when .style is gotten checking the string and using the style rule if the string is empty.... or something along those lines. But is that really a price worth paying? If so, why? (Note that it would hardly help the composer issue, since composer does in fact change inline style rules when changes are made....)
The ideal way to not lose this information would be to do something similar to what IE does: keep a list of the unknown properties around so that they can be serialized. We could do this by having an "unknown attribute list" that is stored in the style struct. This would cost us, however--4 bytes per map. And its usefulness for dynamic Save As and View Source is dubious at best, since those features already don't serialize out the way the pages came in. Alternatively, editor could store this extra information in an external hashtable from content node to attribute list. The CSS parser would have to know that it was parsing for editor and dump unknown attributes into a per-document hashtable. The editor could then allow people to edit and delete these extra properties to their hearts' content, and serialize them when Save occurs. (Our normal serializer would work fine for this, as long as it had the same flag telling it "look for extra style information.") In the end, this is probably just an editor issue since we're trying so hard to keep bloat down in the embedding app: we don't want much overhead in layout unless we are really interested in parity with IE's DOM: .style.cssText is able to show unknown properties. The speed or memory problems associated with that might be prohibitive, but the costs can be borne in an editor, which doesn't have pageload tests to run. My two cents.
*** Bug 193685 has been marked as a duplicate of this bug. ***
jkeiser's idea wouldn't work for style attributes like: style="@foo;" ...or: style="'}{'" I don't understand why a single string per style attribute would be that costly in terms of memory.
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Assignee: general → nobody
QA Contact: ian → general
Depends on: 444379
Should be fixed by bug 582228.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.