Separate handling XML attributes and style values separately about svgweb HOT 15 CLOSED

r174 incorporates this improvement to the trunk. Improves the code that handles
getting and setting attributes, and simplifies style parsing. getAttribute() is 
used
in rendering code instead of styles. Styles are now parsed upon being set 
instead of
upon rendering. This merges r117, 118, r128, r129 and portions of r148 and r155,
from James experimental branch. 
Issue 14 was also resolved by r174.

Unfortunately the native support in Firefox and Safari keep attributes and 
style=""
values separate. The SVG spec itself doesn't have enough detail around correct
behavior, but Firefox and Safari are identical in this respect. Reopening bug 
with
two goals:

* Restore separate attribute and style="" handling
* Get photos.svg to work with separated handling (Rick said that photos.svg was
failing before this -- perhaps it's related to something else).

I'm making these changes on my branch so far (branches/brad-merge-to-trunk). 
Here's
an overview of the architecture I am going to take.

I am adding two new methods, setStyle() and getStyle(). There is now still
getAttribute() and setAttribute(), but those only get and set the XML 
attributes and
do not affect the CSS style="" string. There will also be a new getStyleOrAttr()
method that can be used to get a final value ready for displaying, such as
getStyleOrAttr('fill')

BTW, I should mention that I am keeping the nice 'inherit' code, which will 
look up
the style tree through ancestors for inherited styles if they are not present 
on the
node that getStyle() is called on.

r348 on branches/brad-merge-to-trunk implements this change. Commit message 
with details:

"attributes and styles are now tracked separately again to match what
Firefox and Safari does; new getStyle() and setStyle() methods are now there,
and getAttribute and setAttribute only return XML attributes now rather than
including CSS ones like in the past. We suport inherited styles in getStyle().
New method getStyleOrAttr() should be called when you want to get some value
that could be set either in XML or style='' string in order to build up
something to display. Note that getAttribute, getStyle, and getStyleOrAttr now
return null instead of an empty string when a prop name is not present. Tested
on my own files but I have not tested this on Rick's demo.html files yet."

I'm not able yet to test photos.svg; I will isolate what the issue is there 
later as
I get closer to supporting rendering that file on my branch.

Note: there are a number of issues with my change. I'm tracking down the bugs 
now and
will have another SVN checkin that should fix some new regressions from this 
change.

r354 contains more fixes for this bug. However, I believe there might still be 
some
regressions from this refactoring so I wouldn't apply it to trunk yet.

More fixes in r357.

More fixes in r358 around correctly applying opacity to images, which I 
regressed
with my earlier changes for this bug.

r361 fixes a regression I introduced around gradients. Fixed now.

r362 fixes regression in filters caused by this refactoring.

r363 needed as well.

Gradients fixed in r364. This should be the last set of fixes necessary. 
Keeping open
though until I can test photos.svg.

I implemented this a long time ago. Also, since I brought trunk back in a few 
days
which has these together I had to re-seperate them once again.