- 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