- From: Robin Berjon <robin@w3.org>
- Date: Thu, 16 Jan 2014 10:41:29 +0100
- To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Henri Sivonen <hsivonen@hsivonen.fi>
- CC: Paul Libbrecht <paul@hoplahup.net>, "Michael[tm] Smith" <mike@w3.org>, www-tag <www-tag@w3.org>
On 16/01/2014 08:16 , "Martin J. Dürst" wrote: > On 2014/01/14 19:04, Henri Sivonen wrote: >> That misfeature is a reason to ban DTDs in W3C TRs--not a reason to >> keep speccing more DTDs. > > Except for the namespace part, this DTD feature is just a formalization > of default values for attributes, something that in and by itself is > very widespread. > > Are you saying that default attributes are a bad idea? Default values are a very important construct, and not one we should get rid of. But DTDs are the wrong way of handling them. To begin with, processing the external subset is optional. Defaulting should never be. If you're not getting consistent defaults, you're probably better off not getting defaults at all. Also, and this may be less clearly cut, I don't believe that it's a good idea to have the defaulting take place at the level of physical DOM constructs. For example, imagine a <rectangle> element that accepts an x attribute the the default interpretation of which is 0. In the absence of that attribute, what you'd actually want is to have: rect.getAttribute("x") === null rect.x === 0 One reason for that is proper round-tripping. Another is resilience against implementation bugs (if an implementation fails to understand a value, you don't want it to change the attribute value to zero). -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Thursday, 16 January 2014 09:41:41 UTC