W3C home > Mailing lists > Public > www-html@w3.org > June 2008

Re: XHTML Basic 1.1 and setting input field to numeric mode

From: Luca Passani <passani@eunet.no>
Date: Wed, 25 Jun 2008 15:19:44 +0200
Message-ID: <486245F0.3080801@eunet.no>
To: Mark Birbeck <mark.birbeck@webbackplane.com>
CC: Tina Holmboe <tina@greytower.net>, Shane McCarron <shane@aptest.com>, "Michael(tm) Smith" <mike@w3.org>, www-html@w3.org


 > so if you have some strong arguments, let's hear them.

of course I have strong arguments, and they have already emerged in the 
thread. In fact, Shane mentioned some of them first.

Deprecating the style attributed makes a few assumptions that are not 
always true:

- authors/developers have control over the whole page they are generating
- authors/developers do not need to generate CSS properties dynamically 
just like any other bit of markup
- authors/developers can always use an existing style sheet 
class/property for their needs
- authors/developers do not need to test/prototype/experiment with  the 
look and feel of a page

There are plently of real-life cases in which these assumptions are 
simply wrong. What you call "best practices", really aren't.

Luca

Mark Birbeck wrote:
> Luca,
>
> How is it a shotgun?
>
> If very time a standard was updated, it was deemed the result of some
> evil power imposing its will, then nothing would ever change!
>
> So if you have disagreements, voice them. If you don't say *why* you
> think @style is useful (other than 'I've got a job to do'...which is
> just daft...we all have that), then all you are really saying is that
> 'anyone who disagrees with me is some kind of dictator'.
>
> How can anyone know where to stand on this, if you haven't said what
> they should agree with?
>
> Just for reference, I have no view on this one way or the other, so if
> you have some strong arguments, let's hear them. Deprecation is a
> reasonable compromise because it allows language designers to use a
> feature if they want (they can include the deprecated module in their
> language), but draws to their attention that the feature they are
> using is not regarded as 'best practice'.
>
> Regards,
>
> Mark
>
> On Tue, Jun 24, 2008 at 4:30 PM, Luca Passani <passani@eunet.no> wrote:
>   
>>> The consensus today
>>>       
>> Consensus of who? I for one disagree. And so do a load of other developers
>> out there, I am sure.
>>
>> One thing is to advise developers to separate content and presentation.
>> Quite another is to use a shotgun to enforce it.
>>
>> Luca
>>
>> Tina Holmboe wrote:
>>     
>>> On Tue, Jun 24, 2008 at 05:05:55PM +0200, Luca Passani wrote:
>>>
>>>
>>>       
>>>>> We /are/ developers
>>>>>
>>>>>           
>>>> sure. You are. I am not denying you are developers. But are you
>>>>  developers who understand other developers and, above all, the variation
>>>>  in background, preparation, actual needs that characterize developers'
>>>>  lives and work?
>>>>
>>>>         
>>>  Yes. But more to the point we are developers who understand, and work
>>>  with, the needs of browser developers, content developers, AND end
>>>  users.
>>>
>>>  That's a standards process in a nutshell.
>>>
>>>
>>>
>>>
>>>
>>>       
>>>> are you building standards that will help people do their jobs, dirty
>>>>  jobs, underpaid jobs, way-too-little-time-to-do-properly-jobs,
>>>>  need-to-interface-to-a-legacy system-jobs,
>>>>  need-to-deal-with-crazy-requirements jobs?
>>>>
>>>>         
>>>  We are building standards - with caveats for the fact that we are,
>>>  alas, only human - to help users access content, to help developers
>>>  create good, high quality content, and to aid other developers in
>>>  creating applications that can do both.
>>>
>>>  Are we creating standards that will, basically, contain everything
>>>  one, or the other, developer want? Not necessarily, no. Some things
>>>  will be added, and some removed, that have been shown to be functional
>>>  or non-functional.
>>>  I'm afraid it won't necessarily include features added because there
>>>  is no proper quality process or project manager on a certain job
>>>  out there.
>>>
>>>  Your requirement for STYLE is one, out of many, requirements that we
>>>  need to balance.
>>>
>>>
>>>
>>>
>>>       
>>>> utopian view of what the world should be. Well, wake up. People need
>>>>  tools to do well in their job, not tools that try to force them to buy
>>>>  someone else's view of what their tools should be.
>>>>
>>>>         
>>>  I'm sorry you feel this way. We are trying to provide the best tools
>>>  for the job, and the STYLE attribute isn't among them. The consensus
>>>  today is that it mixes presentation in with the code, and it makes
>>>  for code which is awfully hard to maintain.
>>>
>>>  And for a developer, hard-to-maintain is anathema. Surely even in your
>>>  field of work you'd like to be able to go back and update code without
>>>  finding yourself having to hunt one elusive little STYLE somewhere in
>>>  one out of a number of templates which muck up the new layout?
>>>
>>>
>>>       
>>
>>     
>
>
>
>   
Received on Wednesday, 25 June 2008 13:20:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:16:14 GMT