Implementation documentation in specifications

On Mon, 21 Apr 2008 16:07:24 +0200, Alan Gresley <alan@css-class.com>  
wrote:
> I'm not be judgmental of any user-agent. I talking about what's  
> happening in the the 'real' world. The large world of authors out number  
> implementers and specs writers many fold.
>
> The W3C should be open to the feedback from authors but for one author  
> (myself) speaking about many authors there is so much mis-understanding  
> of the specs (that's even if such a spec is known about). The vast  
> majority of web pages on the internet was only tested in one browser in  
> quirk mode with a lot of prosperity code. That is a reality. Some  
> authors take over these pages and attempt to code by the standards and  
> they encounter this very steep learning curve.

I've done browser QA part time for 4 year or so. I know what's out there  
:-)


>>> We are in the present now but do we have to have this not breaking  
>>> existing content haunting us for eternity. Some things must break  
>>> (past errors) to move forward. This principle doesn't just lay with  
>>> CSS or scripting (or other web languages) but in all area of life and  
>>> society.
>>>
>>> The design principles (2.1. Support Existing Content) have a past and  
>>> a present. I would rather this be more on the side of the present and  
>>> the future.
>>
>>  This seems more relevant for author tutorials than a specification. A  
>> specification defines how something should be implemented, it is not  
>> documentation on how something is implemented in various  
>> implementations.
>
> This is why I suggested it should be presented in a --'non-normative'--  
> manner. The specs are not just for implementers but for authors too. An  
> author shouldn't have to hunt this down via googling.

Even non-normative it still seems more appropriate for it to be placed  
outside the specification.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Monday, 21 April 2008 20:21:38 UTC