- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Mon, 30 Aug 2010 23:10:20 +0000
- To: Håkon Wium Lie <howcome@opera.com>, Doug Schepers <schepers@w3.org>
- CC: "www-style@w3.org" <www-style@w3.org>, "www-svg@w3.org" <www-svg@w3.org>
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On > Behalf Of Håkon Wium Lie > I think this is the right approach. The feature is, as you say, little > used and only provides convenience -- not necessity. I don't know why > e-notation was allowed in numeric values on SVG attributes in the > first place, but it seems better to deprecate them there than to > mandate e-notation across the board. Harmonization one way or the other is the right approach as long as the rationale is sound. > Introducing e-notation in CSS would have a considerable cost. We would > need to change the CSS core grammar, which is -- sort of -- our > constitution. Constitutions can be changed, but only for truly > important things, when there is long-standing consensus. Dramatic analogies can only get you so far. Constitutions are also old, calcified documents overseen by small groups of - mostly - old men appointed for life; they are often behind reality, incomplete, limited and get changed extremely slowly at great cost when the gaps are unsustainable. While some people might find this description to be a disturbingly accurate reflection of the CSSWG and the pace of its work, I would not consider it to be a desirable goal nor, if I thought it were true, would I consider it a feature :) > The convenience that e-notation provides to some counts on the plus side, > but on the minus side we find incompatibility with existing browsers > and reduction of human readability. No incompatibility occurs until the feature is used which, as explained, involves new features like transforms which are already not supported in all browsers. Thus, in practice, the real incompatibility will lie elsewhere. I don't buy the human readability argument. This notation is extremely common in the scripting and programming languages in common use by web authors. There is no reason to suppose it is any more or less readable in CSS than it is in Javascript, Python or Perl. This has always been an important > design principle in CSS: > > CSS is a simple style language which is human readable and writable. > > http://www.w3.org/TR/CSS2/intro.html#design-principles The Python, Perl and Javascript programmers I know are all human. Python programmers who don't know Perl are perfectly capable of identifying number literals in Perl programs and vice-versa. > Further, the design principle states: > > The CSS properties are kept independent of each other to the largest > extent possible and there is generally only one way to achieve a > certain effect. > > Introducing e-notation is against this principle, as it offers no new > functionality, only a different syntax for achieving the same thing. This is a red herring. This is not a property addition but a new literal notation. You might as well argue that since inches and centimeters can be used to represent the same lengths we should keep only one. What do centimeters offer that cannot be expressed in inches, or millimeters or picas? As it happens CSS also supports mm, pt, pc and the px as 1/96". Supporting two ways to represent floating point numbers is no different. > > > You call it an artifact. I call it a ubiquitous, living notation > > > embraced by all the programming languages people are using today. > > You're right, it's common in programming languages. But CSS was > explicitly designed to *not* be a programming language. The last words > in the CSS1 Recommendations are: > > We do not expect CSS to evolve into a programming language > > http://www.w3.org/TR/REC-CSS1-961217 This is a very specious argument. Adding the e notation does not turn CSS into a programming language anymore than removing it from Python would make the latter declarative. The spec does *not* say: "We do not expect CSS to *look* like a programming language", Håkon. If that was true then surely declaration blocks should not use {} as delimiters as these look very familiar to even C programmers. Never mind the functional notation, semi-colon delimiters, quoted string values, comma-separated enumerations etc. > > The main competitor to CSS in the early days was DSSSL, which *was* a > programming language. I believe that one reason for the success of CSS > is its lack of features from programming languages: Same implicit claim that adding support for a widespread literal number syntax creates programming capabilities that are conveniently left entirely unexplained. Could you elaborate on the programming I can do using this notation ? Since IE has supported it for more than a decade, isn't it curious it has not been exploited for programming purposes yet ? If you want to make this argument, I strongly suggest you focus your attention on calc(). That is the proper place for your anti-programming crusade. On this specific issue, it sounds rather preposterous. And I will note that it would in fact be very easy to argue than the syntax of CSS is easy to learn *because* it looks familiar and conventional to even the occasional programmer. > > Compared to DSSSL-Lite, CSS was easier to support since it wasn't > Turing-complete and didn't require a transformation step. So, in a > way, it was the simplicity -- the lack of features -- that won people > over. > > http://friendlybit.com/css/interview-why-did-css-succeed/ > > Other features from programming languages can also be said to be > ubiquitous, e.g. regular expressions. In 1998 there was a big debate > about introducing regular expressions in CSS selectors. The debate is > worth recounting, both for its entertainment value and for its > arguments. Some key messages: > > http://lists.w3.org/Archives/Public/www-style/1998Mar/0048.html > http://lists.w3.org/Archives/Public/www-style/1998Mar/0032.html > http://lists.w3.org/Archives/Public/www-style/1998Mar/0051.html > I fail to see the relevance or soundness of this argument. The implicit claim here seems to be that 'regex is a feature in some programming languages, regex did not make it into CSS therefore anything that looks like a programming language feature will not be supported in CSS'. This is not just absurdly simplistic and circular, calc() proves it's already wrong in practice. I am in support of the feature. I do not think it is critical; it's a convenience. But claims of its 'great cost' seem hugely exaggerated and superficial.
Received on Monday, 30 August 2010 23:11:15 UTC