W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2005

Re: [dom3core] getAttribute

From: Ray Whitmer <ray@personallegal.net>
Date: Thu, 1 Dec 2005 10:23:09 -0700
Message-Id: <BE556744-5A77-4631-9F06-0CE2721D71F8@personallegal.net>
Cc: DOM mailing list <www-dom@w3.org>
To: Curt Arnold <carnold@houston.rr.com>

On Dec 1, 2005, at 9:07 AM, Curt Arnold wrote:

> There is a legitimate end-user benefit for non-dominant browsers to  
> conform the de-facto behavior when it deviates from the spec.

It would be far more compelling and legitimate, in this case, for the  
dominant browser vendors to fix their browsers in upcoming releases,  
compelling page authors to confront the issue and solve it in their  
code in one of the easily-available techniques that would work on all  
browser versions: "We made a mistake, here is the work-around".

I would think they could have some sort of check box for maintaining  
non-compliant behavior, making it quite clear to web authors that  
they should fix their pages to be standard-compliant, if they have  
not, so web authors are given a clue that the behavior is not  
compliant but allowed to continue.

I would even not complain much if such a checkbox were checked by  
default as long as it says "web authors should uncheck this box". The  
web browser should be a tool for promoting good behavior, not broken  
behavior, because ultimately it is not an end-user benefit to  
encourage broken html, etc. This is no harder to deal with than  
similar compatibility solutions in the past.

> However, HTML browsers are only one class of apps that implement  
> the DOM spec.  If an errata was issued that made null a valid  
> return value for getAttribute, Java code that depended on the  
> behavior in the recommendation could break with a new comformant  
> Java implementation that decided to return null instead of empty.
>
> There may be some benefit from documenting where HTML+Javascript  
> implementations are known to deviate from the recommendation for  
> compatibility.  However, if something is done, it should be done in  
> a way that XHTML+Javascript or SVG+Javascript browsers are required  
> to follow the recommendation since there isn't a significant body  
> of existing script.

I would have no problem with the note saying that browser vendors  
have famously misimplemented the standard so web authors should avoid  
the call and get the functionality in another way.

It could be said the dominant browser implementors (especially those  
who participated in the process) have some obligation to do something  
more.  Promoting nonstandard content is not in the user's interest.

I think it might be possible, if done cleverly, to lead the way,  
while passing the tests and keeping the spirit of the standards.  If  
a special mode rejected broken HTML, etc. so much the better for web  
masters. If the mode were good enough, it could be more compelling  
still for web authors to use that browser as the exclusive test,  
besides IE -- start a real standards compliance competition and make  
it easier to distinguish between browser bugs and non-compliant content.

Perhaps the checkbox is not the best, but there should be some  
reasonable way to proceed if enough thought is given.

Ray Whitmer
Received on Thursday, 1 December 2005 17:23:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:58 GMT