Re: w3c html dom versioning oddities

Jake,



Jacob Kjome wrote:
>
> Hi Arno,
>
> So that's why setDefaultSelected() didn't work.  I actually tried that
> but, like you, found it to behave oddly.  Yes definitely post the
> patch.  Actually, the best thing to do would be to post it to Apache's
> Bugzilla under a new bug entry so it doesn't get lost in the shuffle.
> http://issues.apache.org/bugzilla/index.html
>
> Then just post the link to the bug entry here for our reference.
>

here is the bug-report
http://issues.apache.org/bugzilla/show_bug.cgi?id=20097

And this is the patch
http://issues.apache.org/bugzilla/showattachment.cgi?attach_id=6437
What it does is just have setDefaultSelected behave the same as setSelected, because in a 
server DOM, there are the same.

> One thing about setDefaultSelected().  Doesn't it assume that only one 
> item in the list is selected?  I haven't read the spec about this or 
> anything, but it just seems to imply that.  What if it is a multiply 
> selected list?  Does setDefaultSelected() really work for that case?  Or 
> does default not just imply one, but one or more defaults.  Probably the 
> latter, I guess.

setDefaultSelected-method is called on an HTMLOptionElement, multiple option in a 
selectelement can have that attribute set to true. So I don't see a problem, it is analog 
to setSelected...

> While you are at it, can you add a patch in the javadoc for the 
> setAttribute() method?  It is decieving.  Here is what I mentioned about 
> it previously...

ok, bug report + patch:
http://issues.apache.org/bugzilla/show_bug.cgi?id=20131

> "BTW, the javadoc for that seems to be incorrect.  It claims "If the 
> value is true, the attribute is set to an empty string".  That is, 
> obviously, not the case.  If the value is true, the attribute value is 
> set to the value of the "name" parameter, which is the same as the 
> attribute name.  So, instead of <option selected ...>, as the javadoc 
> seems to claim, it would be <option selected="selected" ...>.  I'm 
> actually not complaining about the behavior (I don't want that to 
> change), I'm just saying that javadoc should be corrected to state what 
> actually  happens."

Note, It will never be serialized as 'selected="selected"', since the serializer knows 
that the 'selected'-attribute is boolean and therefore, if the attribute exists, it will 
only print the name of the attribute, in this case: 'selected'.

The relevant code snippet from org.apache.xml.serialize.HTMLSerializer is:

                        } else if ( HTMLdtd.isBoolean( rawName, name ) )
                            _printer.printText( name );
                        else {
                            _printer.printText( name );
                            _printer.printText( "=\"" );
                            printEscaped( value );
                            _printer.printText( '"' );
                        }

The above patch just corrects the javadoc in regards of the internal representation of 
boolean attributes.

-Arno