While most things are easily extendable in older browsers, CSS seems to be tricky. Every markup language that is new on the web and wants to be a success needs to work in Internet Explorer. For XForms there have been several implementations, both client and server side and the most are trying to make XForms work in Internet Explorer. Several are relying on javascript for the implementation and are thus using text/html for their extension to work.
This is a similar approach as the Internet Explorer implementation of Web Forms 2 will get (some has been implemented) and works quite well. However, while XForms was supposed to become the semantic counter solution to HTML forms, the need for making it work in Internet Explorer made many people using tables again for laying out the forms. “Why,” you ask. Well, Internet Explorer doesn’t support the CSS table module of CSS2.1. Neither does Mozilla for forms; simply because no interaction between forms and CSS has been described.
In XForms, a very basic form control looks like:
<xforms:input><xforms:label>Name</xforms:label></xforms:input>
What you really want to do, when you have a sequence of such xforms:input elements (xforms is bound to http://www.w3.org/2002/xforms) is to format them as you would do with a table. Something like:
@namespace xforms url(http://www.w3.org/2002/xforms);
xforms|input{display:table-row}
xforms|label{display:table-cell}
xforms|label::value{display:table-cell}
Now that last rule is not really necessary as — according to the CSS table rendering model — display:table-cell should be implied for that box thanks to its parent having display:table-row, but it’s written down here for completeness. (You might want to apply a border around the input field, for example; in that case you need that particular selector.)
(Technically, when you leave that last rule out an anonymous box is created between the anonymous XForms input field and its parent element, the XForms input element. Practically I think there is not much difference and when browsers support this they will create such an anonymous box anyway.)
Now there is not a single browser out there which supports that. Of course, you can work around it using float:left and display:block but when examples get more complex you are left behind. It’s nice that markup languages evolve and bring more abstraction and semantic solutions for day to day problems, but when CSS doesn’t evolve along — both in terms of specifications and implementations — semantic abuse will be there. Nothing we can do about it.
(Really, JavaScript and Javascript are outdated. Let’s lowercase it, just like internet.)
yeah, uppercase is outdated. it's only typographic, it conveys no important semantic information. and what information there is should be encoded with markup, not with a messy encoding mechanism that is only applicable to a subset of unicode, and that differs from language to language.
there are a few problems with css for extending it without changing the layout engine:
(Really, JavaScript and Javascript are outdated. Let’s lowercase it, just like internet.)
No! Just as you wouldn't call PHP php
, CSS css
and Ruby ruby
, you shouldn't call JavaScript javascript
(P.S. Is the use of <q> correct in the above paragraph? Oh well, never mind this)
Mark, while your point stands true for Ruby (or Python, or Java, or Perl) it doesn't for PHP or CSS, since none of them are names and both are acronyms (PHP being a recursive one), just like HTML or XML
(bah, can't even use <acronym>)
No, you can’t; yay for XHTML2 which removes this dubious element. And it is Extensible Markup Language; not eXtensible Markup Language.
I may be strange, but I always considered that the uppercase letters were the one appearing in the acronym when explaining/clarifying said acronym. Wrong or not, I'll still use an uppercase X as long as XML is XML, and I'll use an uppercase E when XML will be renamed EML.
(this post was commited without any anger or hate, and I apoligize if anyone finds my tone harsh, stupid or offensive)
FYI: JavaScript is the brand name of Netscape's Javascript, whereas the latter is the generic name of the language, and thus includes JScript, which of course, is the brand name of M$'s implementation of JS.
Is it then “nasa” instead of “NASA”, “esa” instead of “ESA”, “eu” instead of “EU”, “usa” instead of “USA”? Is it “anne van kesteren” instead of “Anne van Kesteren” and “the netherlands” instead of “The Netherlands”?
And with regards to “JavaScript”: Should “ECMAScript” become “ecmascript”?
I do not like switching to all lowercase letters for certain terms like “Internet”, “Web”, etc. – but of course I am German and capital letters are therefore natural to me, you know :-)
It was just about javascript. Although I guess it applies to ecmascript as well. Preferably I’d just point to a IRI and be done with it.
JavaScript is the brand name of Netscape's Javascript, whereas the latter is the generic name of the language
That's totally (and horribly) wrong! JavaScript is the scripting language invented by Netscape. There is no "generic name" for this language. But a common core language specification was standardized and known as ECMAScript.
P.S. Case sensitivity, IMO, is very important. Probably because my first programming language is C++. There is no valid reason to use the lowercased name, except in MIME type, i.e. text/javascript or application/x-javascript.
An initial comment: Please don't talk about CSS 2.1 as a though it is a specification that should be supported. It isn't; CSS 2.1 is a candidate recommendation. Nobody should count on CSS 2.1 yet.
Personally, I like to set acronyms in small capitals, which is a rather common practice in traditional type setting. For example; I mark up the word ECMAScript
as <abbr>ecma</abbr>Script, which works great with the following style rule I often apply: abbr { font-variant: small-caps }. Well, perhaps not actually great as small caps are not rendered very well on screen (yet) … then again, what typographic aspect is? (Sometimes bolding, and adding letter spacing does some good, but it can also cause more pain.)
Back to your original point: in the example you provide, is the problem not in the way browser vendors do or do not impliment css, rather than in css itself? Sure these things are underspecified up to level 2.1, but are we (www-style subscribers, and then some) not all breaking our heads over fixing this in level 3? Or is your point that css3 is taking to long reaching Recommendation
status?
Concerning Masklinn’s point: The W3C used to refer to xhtml as eXtensible HyperText Markup Language
itself (albeit not in every case), but they seem to have abandoned that. It’s true that capitals are often/traditionally used as a visual indicator to match the letters of an acronym (or other type of abbreviations — think of initials of given names) with the words they relate to, but one shouldn’t get dogmatic about it. (Even moreso now that we’re discussing whether said acronym perhaps shouldn’t be set in all-caps
at all.)
P.S. The thing is called JavaScript.
☺
An initial comment: Please don't talk about CSS 2.1 as a though it is a specification that should be supported. It isn't; CSS 2.1 is a candidate recommendation. Nobody should count on CSS 2.1 yet.
This is plain and simply wrong, the current stage of CSS2.1 means that it's ready to be implemented and waiting for implementations, it'll stay a CR until there are at least two interoperable implementations for every feature
.
CSS 2.1 are no less implementable than CSS1 themselves, their status only means that the W3C needs for it to switch to full recommandation have not been met yet, these needs being:
- There must be at least two interoperable implementations for every feature. For the purposes of this criterion, we define the following terms:
- feature
- A section or subsection of the specification.
- interoperable
- passing the respective test cases in the test suite, or, if the implementation is not a web browser, equivalent tests. Every relevant test in the test suite should have an equivalent test created if such a UA is to be used to claim interoperability. In addition if such a UA is to be used to claim interoperability, then there must one or more additional UAs which can also pass those equivalent tests in the same way for the purpose of interoperability. The equivalent tests must be made publicly available for the purposes of peer review.
- implementation
- a user agent which:
- implements the feature.
- is available (i.e. publicly downloadable or available through some other public point of sale mechanism). This is the "show me" requirement.
- is shipping (i.e. development, private or unofficial versions are insufficient).
- is not experimental (i.e. is intended for a wide audience and could be used on a daily basis).
- A minimum of six months of the CR period must have elapsed. This is to ensure that enough time is given for any remaining major errors to be caught.
- The CR period will be extended if implementations are slow to appear.
- Features that were not in CSS1 will be dropped (thus reducing the list of "all" features mentioned above) if two or more interoperable implementations of those features are not found by the end of the CR period.
- Features will also be dropped if sufficient and adequate tests (by judgment of the working group) have not been produced for those features by the end of the CR period.
CSS 2.1 are ready to be implemented (unless bugs or implementation issues arise, such as the ones that led to CSS 2.1 from CSS 2.0) and should be implemented by User Agents, there is currently no reason to hold back.
Masklinn, thanks for the insight. I was talking the POV of a web developer rather than a browser developer. I also think Anne was taking the POV of web developers by complaining that Mozilla and MSIE don't support the CSS 2.1 table module yet. From this perspective, you can't expect them to support anything until after the CR phase because of the sentence:
Features that were not in CSS1 will be dropped (thus reducing the list of "all" features mentioned above) if two or more interoperable implementations of those features are not found by the end of the CR period.
This means that the spec is not stable; features may be dropped if nobody ends up supporting them. In fact the spec hasn't been shown to be implementable at all in practice: CR reports are just best guesses by the W3C. It is unreasonable to expect browsers to support CSS 2.1 for at least six months past the start of the CR phase (my guess: longer since CSS is complex). CR phase is the when specifications undergo "beta testing." They should not be relied upon until after they become a Recommendation!
So I don't think the situation is as black and white as you proclaim.
about lowercase javascript... javascript *urls* should have the (pseudo-)protocol scheme name in lowercase.
Although schemes are case-insensitive, the canonical form is lowercase and documents that specify schemes must do so with lowercase letters.
- p
Jimmy, one of the people writing CSS2.1 recently expressed that CSS2.1 is CSS2 and that therefore CSS2 is obsoleted by whatever state CSS2.1 may be in. That it is inside another document doesn’t matter. CSS2.1 is in fact the most accurate document to date, it even is more advanced than many CSS3 specifications. Much more thought and feedback went into CSS2.1 (which is CSS2). That is the reason I’m referring to that specification and not some old one that got left behind.
Anne, I read that piece a while ago, and I understand why people should advocate CSS 2.1 support in browsers. The authors may be proud of revision 1 and feel that it is more well thought out than the original, but they haven't proven it works yet.
It is like using a trunk build of Firefox close to a branch; sure it may have less bugs, but it is still untested. For web developers CSS 2.1 isn't stable yet (granted it seems to be a high quality than the previous revision, but that is hardly canon yet). Note the statement:
The only changes that will be made to the CSS2.1 spec are changes in response to implementors finding errors in the specification, such as contradictory requirements or ambiguities.
This is like saying, the only changes that will be made to the program's design are errors found while writing the unit tests. Whenever I write a specification, I write a simple implementation to see how things interact. This is the reason that the W3C no longer pumps out spec after spec without waiting for implementors to catch up (that leads to ugly inconsistancies... cough RDF/XML... cough W3C Schema... cough xml:base...).
Among that, CSS2.1 also more accurately represents what Internet Explorer has implemented. Really, every web developer who thinks they have found some bug in a browser is mostly looking at something of the ‘original’ CSS2 that has been revised.