- From: Luca Passani <passani@eunet.no>
- Date: Wed, 25 Jun 2008 20:53:36 +0200
- 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 UTC