Re: Are new void elements really a good idea?

On Aug 31, 2008, at 19:38, Julian Reschke wrote:

> First of all, it's not like this code needs to be maintained *once*,  
> it needs maintenance every time the set of void elements change. I  
> would call this a stupid design of the target language.

Yeah, the backwards and forwards compatibility story for void elements  
isn't great. (FWIW, the story for implied </p> isn't great, either.)

> Again, I'd argue that we should compare the cost we're causing for  
> updates with the benefit of having new void elements.

I agree.

> Keep in mind that not all developers have the freedom just to pick a  
> new off-the-shelf component, be it commercial or open source. For  
> instance, in certain companies you either stick with what the  
> shipping J2EE includes, or you need to write your own serializer  
> (speaking from experience here).

That's nuts. It would be crazy for a company that does enterprisey  
Java stuff to block application developers from using libraries from  
the Apache Software Foundation, for example. If library developers  
don't want non-JDK dependencies, that I can understand. (Of course, it  
would be silly to block application from using code from http://about.validator.nu/htmlparser/ 
, too. :-)

As matter of value judgment, I think we shouldn't try to cater for  
this case in order to make bad corporate policies easier to keep.  
However, it might still be strategically desirable to cater for this  
case in order to get deployment (although we can probably get enough  
deployment without trying to grasp at straws).

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Sunday, 31 August 2008 18:11:06 UTC