W3C home > Mailing lists > Public > public-html@w3.org > May 2009

Re: Design Principles

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 25 May 2009 07:15:44 -0700
Cc: Anne van Kesteren <annevk@opera.com>, Larry Masinter <masinter@adobe.com>, Charles McCathieNevile <chaals@opera.com>, Sam Ruby <rubys@intertwingly.net>, HTML WG <public-html@w3.org>
Message-id: <D5F0843D-70B7-462B-B2FE-0B3F98D92E40@apple.com>
To: Leif Halvard Silli <lhs@malform.no>

On May 25, 2009, at 6:15 AM, Leif Halvard Silli wrote:

> Maciej Stachowiak On 09-05-25 14.41:
>>
>> On May 25, 2009, at 5:29 AM, Leif Halvard Silli wrote:
>>
>>> No one will subscribe to reasonable principles if, in reality,  
>>> they are (honestly, of course)  interpreted to legitimize things  
>>> that one are opposed to, disagree with and, in fact, not found in  
>>> the principles. I think Larry (and Dan also, if I understood the  
>>> IRC log of the telcon correctly) has pointed to a problem with  
>>> the /interpretation/ of the principles. "Pave the cow paths" has  
>>> been interpreted to say "do not pave anything that perhaps isn't a  
>>> cow path".
>>
>> Can you cite an example of anyone making that kind of argument and  
>> citing the "Pave the Cowpaths" principle? The text says: "When a  
>> practice is already widespread among authors, consider adopting it  
>> rather than forbidding it or inventing something new."
>
> @profile is widespread amongst authors to the extent that Dublin  
> Core is widespread.
>
> It is a specified MUST for for anyone using Dublin Core to use  
> @profile [1]. Interpreting the DC properties as DC properties is not  
> licensed without it [2]. It is not this working group's task to to  
> "inform" the Dublin Core Metadata Initiative that they don't need  
> it. In fact DC has two meta data profiles and @profile is needed to  
> tell which one to use. So, as far as I am concerned, this principle  
> has so far not had any effect on @profile, even though it should  
> apply.

If that's true, then probably the most applicable principle would be  
"Support Existing Content."  But I don't think we have evidence from  
the above that profile is in fact used a lot. Sounds like it could be,  
depending on how much Dublin Core is used and whether authors using DC  
follow the profile requirement.

>
> It is not fair only time the design principles are applied is when  
> someone is /citing/ them. This WG has many times been presented with  
> statistics that lists how many times something is used. Where do we  
> see in the principles that this is the right thing to do? When  
> something has been found/claimed to not be much (correctly) used,  
> then it has been used as a argument for "removing" (putting it in  
> quotes to satisfy Anne) the attribute. I see this as an example of  
> what you ask.

I would say that, first off, if people are doing such things without  
citing the principle, then removing or changing the principle will not  
affect their behavior. But if they do cite it, it can be pointed out  
that they are applying it wrong.

My own impression is that quantitative studies are used to answer  
questions like these:

- Would removing support for a particular tag or attribute  
significantly hurt compatibility with existing Web content? (Support  
Existing Content)
- Would altering the parsing or interpretation of a certain tag or  
attribute significantly hurt compatibility with existing Web content?  
(Support Existing Content)
- What values of freeform semantic attributes may be de-facto  
standards? (Pave the Cowpaths)
- Are certain attributes or elements used wrong more often than they  
are used right? (not clear if this relates directly to a stated design  
principle)

The answers to these kinds of questions cannot by themselves lead to a  
conclusion that some markup feature should be left out. But they can  
help inform the decision.

I hope this clarifies the "Pave the Cowpaths" principle and how it  
relates to quantitative studies of Web content.

Regards,
Maciej
Received on Monday, 25 May 2009 14:16:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:03 UTC