- From: Mark Birbeck <mark.birbeck@webbackplane.com>
- Date: Wed, 25 Jun 2008 16:30:33 +0100
- To: "Luca Passani" <passani@eunet.no>
- Cc: "Tina Holmboe" <tina@greytower.net>, "Shane McCarron" <shane@aptest.com>, "Michael(tm) Smith" <mike@w3.org>, www-html@w3.org
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? >>>> >>>> >>>> >>> >>> >> >> >> >> > > -- Mark Birbeck, webBackplane mark.birbeck@webBackplane.com http://webBackplane.com/mark-birbeck webBackplane is a trading name of Backplane Ltd. (company number 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street, London, EC2A 4RR)
Received on Wednesday, 25 June 2008 15:31:10 UTC