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 20:53:36 +0200
Message-ID: <48629430.2070306@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


 > I happen to agree with you.

Cool!  So, how do we undeprecate @style?

Luca


Mark Birbeck wrote:
> Hi Luca,
>
>   
>>> 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.
>>     
>
> I hadn't heard any, up to this email...but anyway, let's drop the
> 'meta debate' and just have the debate. :)
>
>
>   
>> 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.
>>     
>
> Just because something is not possible in certain circumstances,
> doesn't mean you can't call it a 'best practice'.
>
> And I should clarify that deprecating only means that it gets moved
> into a 'deprecated' module, which is still available to language
> designers who want to create a language with @style in. The point of
> moving it to a deprecated module is simply to say that it's not best
> practice.
>
> But anyway, I happen to agree with you. I just felt that putting some
> bullet points down that people could engage with was more productive
> than ranting about who the authentic developers are. :)
>
> The reason I agree with you is that the languages we design need to
> support people through a wide range of scenarios, from beginners to
> advanced users, from server-generated mark-up to hand-coded pages, to
> full sites, to blog entries.
>
> And as you rightly say, we can't always know these in advance.
>
> But that does not mean that we don't advise people that there are
> better ways to do things, when there quite obviously are. At the same
> time, we do need to remember that when someone is first learning,
> being able to get a div to go red is actually quite exciting!
>
> Whether that's best done with the deprecation module I'll leave for
> another post. I simply wanted to say that I think there is a place for
> @style, even if it's not central.
>
> Regards,
>
> Mark
>
>   
>> 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 18:54:32 GMT

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