Re: [dom3core] getAttribute

Hi,

On Thu, 2005-12-01 at 23:07 -0800, Maciej Stachowiak wrote:
> On Dec 1, 2005, at 2:33 AM, Kasimier Buchcik wrote:
> 
> > I understand that the DOM spec evolves over time; mostly on basis of
> > requirements of the 'real world'. But the issue we talk about is,
> > in my eyes, a simple misuse of a method. Aren't the sites you call
> > 'the real world' a broken world?
> 
> In many cases this is reasonable. For example, suppose there is a non- 
> standard method to perform a particular operation and also a  
> standards-compliant way. You can ask sites to use the standard method  
> instead of the non-standard one, or at least test for both  
> alternatives if they also wish to be compatible with legacy browsers.  
> And then browsers that wish to be both compliant and compatible can  
> implement both methods.
> 
> But in this case, there is a bit of a chicken and egg problem. Since  
> all major browsers have a behavior for a standard method that does  
> not match the spec, sites cannot change or else they will stop 

I disagree. Sites can change; and one could argue that those sites
which someone in this thread called 'important sites', are most likely
to be rewritten on a regular basis, since they have enough manpower
and monetary resources to keep their figurehead up-to-date with latest
web fashion. But they won't adjust any bit of their code, if it still
works with your browsers. They will complain for a while if something
doesn't work; and then adjust it, since they _want_ people to be
able to browse their sites.

I think if the major browser companies would talk this over _together_,
then maybe they would realize that there are options:
1) Decide what changes you want make to _all_ the browsers
2) Announce a date when those changes will occur; give the users
   enough time to migrate
3) Do the changes

Who would be the possible reactions from the user's side?
1) Those who missed to inform themself about latest browser news
2) Those who will feel punked, since they thought things don't
   change in the world and thus didn't cared about changes
3) Those who will feel irritated since they would need to adjust
   their single page home page.
4) Those who have written crappy tutorials which promoted the usage
   of bad code
5) Those who are used to accusation will accuse you anyway; but you
   have warned them and they still can inform any person which
   wants to surf their site to use an older browser
5) others?

What will most likely happen after a while?
All people will migrate to the new state of things, since they
really don't want a non-browsable site and no major browser
would support their buggy sites.

One could argue that the problem you have with sites in your
browser is based due to the lack of cooperation between
browser companies. I.e. the spec actually does not have a problem
here, but the browsers have; and since they are unwilling to
solve it properly, then transfer the problem to the spec's side.
Is this the way we want the world to be?

> working. Conversely, browsers can't change without breaking sites.  

As Curt Arnold already said: "HTML browsers are only one class of
apps that implement the DOM spec". We need to care about non-browser
code as well.

What are your priorities? Where does pragmatism reach a point
where it starts to be destructive?
IMHO DOM is there to make your life easier by giving you an API,
which, if properly implemented, will work everywhere the same.
To design such an API the DOM people have to take into accout
the various tricky differences of programming languages.
I think we should be carefull if being at the edge of breaking
such a balanced API to satisfy the incompetent site author.

> And there's no way a browser could implement both alternatives, since  
> a value must be either null or the empty string, it cannot be both.

> That's why I think this particular issue is one of very few  
> exceptions where a loosening of the spec is warranted.

Regards,

Kasimier

Received on Friday, 2 December 2005 11:14:50 UTC