Re: Doctypes and the dialects of HTML 5

I somewhat agree with Mike, and the use cases 
approach is like "if all you got is a hammer, 
everything looks like a nail".

There are areas where use cases don't cut it. We 
came to the point earlier that if we only add 
incremental improvements, it will be hard to 
introduce anything really new into HTML, whereas 
"new" here wouldn't be something completely 
different, but harmonizing a class of use cases 
into a better solution. Otherwise we end up in a 
mess - a bag of features: tag soup.

The declarative debate falls in that realm, we can 
say from looking at lots of web applications that 
a declarative expression language makes sense, but 
you only see this if you take a step back and 
analyze a wider spektrum than a single use case, 
as opposed to "look, this feature is cool, here's 
my example document with the new tag."

Having said that, use cases do make sense for e.g. 
low-hanging fruits that you can easily grasp, so I 
am not saying they don't make sense at all, just 
that they don't always make sense.

- Sebastian

Lachlan Hunt schrieb:
> 
> Mike Schinkel wrote:
>> Lachlan Hunt wrote:
>>> Without knowing and understand the problem and use cases to be 
>>> solved, a successful solution cannot be developed; and a solution 
>>> looking for a problem isn't really a solution at all.
>>
>> While your reply was actually very helpful to me, I'd like to bring up 
>> a point. The approach you describe is evidently a good and proper 
>> approach taken by very seasoned standards professionals.
>>
>> However, my understanding was that the W3C wanted to open this up to 
>> people using HTML in the real world in order to get better perspective 
>> on issues. The approach of requiring a well defined use-case prior to 
>> discussion very much discourages brainstorming.
> 
> It doesn't require the use case to be extremely well defined before 
> discussion can take place, just that the discussion begin by focussing 
> on the use cases and/or problems before people start prematurely 
> brainstorming solutions.
> 
> A good idea could start with a post as simple as "Hey, look at what 
> these sites are doing, wouldn't it be great if there were an easier 
> way?"  (Of course, a link to the actual sites and description of whey 
> they do wouldn't go astray).  That provides us with a use case and we 
> can take a look to see if there is a problem.
> 
> In many cases, it's likely to turn out that we've already developed a 
> solution for it that you may not have been aware of, but it still might 
> reveal a limitation with the solution we do have.  And even if it 
> doesn't, you (and possibly others) have learned something new and so it 
> turns out to be productive either way.
> 
>> I believe that if you attack every idea with a rigid methodology even 
>> before is can be discussed it will have a chilling  effect on 
>> discussion and it will stifle innovation.
> 
> It's not about attacking ideas or stifling innovation, it's about being 
> productive and questioning ideas to determine their worth.  There is no 
> point wasting time debating frivolous details about solutions, if 
> there's no real problem or use case to solve.
> 
>> On the other hand, if I misunderstood the intent of the W3C opening up 
>> the debate to "ordinary web developers" then forgive me for 
>> misunderstanding.
> 
> The aim is to avoid working behind closed doors and be able to get 
> contributions from a wider community.  But we should still expect 
> contributors to the mailing list to either have an understanding of the 
> process, or be willing to learn the process and accept constructive 
> criticism.
> 
> In a separate response, Mike also wrote:
>> My reply however was addressing the tone of response that informs 
>> newer people that their input is not appreciated unless it is in 
>> strict adherence.
> 
> The tone of my response wasn't meant to suggest that input from newer 
> people isn't appreciated, just that those with less experience have some 
> things to learn.
> 
>> I believe this will stifle involvement of people who can contribute
>> greatly to innovation but who probably won't continue to contribute if 
>> their receive dismissive responses in exchange for their participation.
> 
> The reality is that many ideas will get rejected for a variety of 
> reasons; some quicker than others.  In practice, this isn't a problem. 
> In fact, it's a very good thing.  Any idea that can't stand up to a 
> little bit of questioning really isn't worth spending much time on.
> 
> The ideas that tend to get dismissed quickly (even if the debate seems 
> to go on endlessly) are those that have either already been debated and 
> solved many times before, or those presenting solutions without problems.
> 
> For instance, the threads about versioning and abbr vs. acronym are 
> mostly rehashing old arguments that many of us have been through before. 
>  I guarantee that you can search the archives of www-html and the whatwg 
> list and you will find the same topics come up over and over again, with 
> essentially the same arguments each time.  (Oddly enough, the abbr vs. 
> acronym debate started up again on www-html shortly after it started 
> here, so you won't need look far)
>

Received on Monday, 26 March 2007 09:12:52 UTC