defining new tags with CSS?

I just noticed that this works, but I've never seen anyone actually do this before, so I'm wondering whether it's legal, or just accidentally allowed by Mozilla? It seems that instead of using <SPAN STYLE=...>, which is a lot of typing (adding at least 11 characters to each tag), it's actually possible to define new tag names, in addition to changing the semantics of existing ones:

    <STYLE TYPE="text/css">
      .foo { color: white; background: red; }
      bar  { color: white; background: green; }

    - plain
    - <SPAN CLASS="foo">foo</SPAN>
    - <BAR>bar</BAR>

I wonder if LJ is going to strip out the embedded <STYLE> tag and make all the following text show up the same:

    - plain - foo - bar

What a surprise, of course it does. Sigh.

No doubt this would confuse most validators too.

Tags: , ,

25 Responses:

  1. fo0bar says:

    Works with mozilla/phoenix, not with IE (curiosity outweighed needing to go 3 feet from my linux laptop to a windows workstation at work). If I actually give a fuck, I may download opera later and test.

  2. fo0bar says:

    Doesn't work with opera either. Incidentially, opera looks like shit under linux.

  3. omnifarious says:

    I believe this is allowed as a consequence of Mozilla supporting XML stylesheets. CSS is supposed to be a valid way to set up styles for XML, in which case, you should be able to specify the styles for random tags like you just did. It may be that IE supports this only for XML documents or something.

  4. jace says:

    AFAIK, defining a STYLE tag like this within <HEAD/> is valid. I've never come across an instance of a STYLE tag within <BODY/>.

  5. teleject says:

    I believe creating your own tags and styling them anyway you want is great thing(tm) and, I believe, should be totally valid. In order for it to be legal, you probably will need to include those tags in your own DOCTYPE and link to it at the top of the document. Then try to go validate it. I tried this exact thing a year or so ago and it didn't really work. However, browsers have come a long way since then--so it might work.

    Of course, if you want to you can use STYLE as an attribute into any HTML element. But then that's hardcoding the design information at the element level--which isn't such a good idea. Might as well go back to using FONT tags then.

    I wonder, though, if you can make up an element (<foo>)and then apply so:

    This might be red.

    Hmmm...I tested this on my desktop. It works in Mozilla just fine, but in MacIE just default black test. As my technical editor would say, this just proves that "MacIE is pants".

  6. Why (besides laziness) wouldn't you just use <span class="bar">? Same effect, and works cross-browser. I don't get what the advantage is, re: making your own tags?

    • dygel says:

      Yeah, I mean, saving thirteen keystrokes doesn't really seem to a major leap forward in efficency.

      What I think would be neat would be "short names" for the words 'span' and 'style' for the furiously fast HTML author. Something like ... wouldn't be too hard to interptet. (Hell, we use "a" for "anchor.") A short name for 'class' might also be neat, but "cla" doesn't quite cut it...

    • jwz says:

      It just seems to me that document-specific / domain-specific semantic markup looks cleaner if you're doing something like:

        <DJ> DJ Fuckface </DJ>
        <AFFILIATIONS> (Playing Other People's Music) </AFFILIATIONS>

      instead of:

        <SPAN CLASS=DJ> DJ Fuckface </SPAN>
        <SPAN CLASS=AFFILIATIONS> (Playing Other People's Music) </SPAN>

      Why should the DJ and AFFILIATIONS tags be second-class citizens, expressed as attributes of SPAN instead of as "real" tags?

      See, XML is really just Lisp s-expressions with open-paren and close-paren spelled out with way too many <, >, and / characters, and part of the Lisp Nature is on-the-fly domain-specific syntax. Defining new tags just seems the obvious analog to DEFMACRO. (Though, yeah, I'm conflating code and data, but that is also the Lisp Nature.)

      • dygel says:

        Well, they're second class citizens because that's part of the virtue of having a standardized DOCTYPE - you don't want to be using things that are going to lie outside of that standard.

        • jwz says:

          But I've already "defined" those new tags in the <STYLE>. I think it's lame that I'm expected to define new tags in a DTD or something, when there's this obvious CSS-oid syntax that should work just fine (and apparently does work, but only in some implementations.)

          What, having two orthogonal languages with totally unrelated syntax (HTML and CSS) isn't enough, we should go for three by throwing DTD into the mix? Gag me. That way lies Perl and it's billion different sub-syntaxes all over again.

          • rockuloid says:

            The thing is, if you tell me you're serving HTML, I might want to
            display it in a different way than you expect, whereas if you tell
            me it's JWZML in advance, then I'll follow your rules, or learn your
            structure and apply my own set of new rules, or ignore your stuff,
            or whatever. That DTD has it's own obscure syntax is nasty, sure,
            but whatchagonna do?

            On the other hand, I think people have been saying things
            like I just said for a long while, and those people keep getting
            in a lot of trouble with reality. Still, a man can dream...

          • tritone says:

            If you're a RE41 XM1 GEE]<, you create a DTD or schema, store all your data as pure XML, and then write XSL/T transformations to convert the XML to HTML + CSS, or PostScript, or Logo programs, or whatever presentation method you like. Of course, if you enjoy doing that sort of thing, you're probably the kind of person who likes pounding metal spikes through his testicles. You also probably don't get out much.

          • zonereyrie says:

            What you're doing is perfectly valid if you're using XML+CSS - but not HTML+CSS. There is *no* requirement to create a DTD and/or a schema when working with XML. It might be a good idea, but all XML requires is following the spec and being well formed.

            You might try what you're doing with an XML document served as text/xml in different browsers. If they really support XML and CSS, it *should* work.

            Though I think IE might only support XSL when used with XML.

      • jfedor says:

        Well, some people think that The Right Thing To Do(tm) is to keep your documents in XML (with custom tags) and convert them to HTML (with SPANs and DIVs and whatever else) using XSLT. I think some of the browsers can even do the translation client-side, but I didn't check.

        • volkris says:

          Mozilla can and I believe IE can a little.

          I did a project about half a year ago when I was doing these very things.

      • Hmm ... but isn't that an important part of HTML -- that it's composed of a finite set of previously-agreed-upon tags?

      • montoya says:

        That's perfectly legit XML, and if you just wanted to serve CSS-styled XML, you could do so easily enough (by just setting the MIME type on a well-formed XML document to text/xml and associating a stylesheet with it using the xml-stylesheet processing instruction). You don't want to do that, though, for the very sensible reasons that: 1) HTML-only browsers would be totally broken, and 2) you'd have to define CSS rules for each and every HTML element you used in your document, since pure XML gets nothing for free from the browser.

        On the other hand, you can't just do what you're doing, either -- you're trying to embed random XML in the middle of an HTML document, and that's not legit. HTML isn't arbitrarily extensible, and HTML clients can do whatever they want with tags they don't recognize.

        XHTML, though, is arbitrarily extensible, and you can extend it pretty easily. Declare your own namespace in the root element (in addition to the XHTML namespace); put whatever tags you want into the document, using that namespace, then use the proposed CSS3 namespace selectors to define how you want the tags styled. This is what you really want to do, and if you use real XHTML (that is, served with a MIME type like application/xhtml+xml rather than text/html), this is perfectly legit and will work in standards-compliant browsers.

        Okay, on second thought, it's only quasi-legit. The page you'd turn out doing it that way is well-formed XML, but it's not really valid XHTML. Fortunately, the only browser that can actually handle this (Mozilla) doesn't use a validating XML parser, so it works. Technically, if you want it to be really valid, you need to write your own DTD in conformance with the "Modularization of XHTML" spec, I think; I'm not completely certain about that, though.

      • kfringe says:

        Dear god! You expect something to behave sensibly just because Lisp has behaved sensibly in that regard for decades? Jamie, your dosage is off. I don't know if you're taking too many or too few drugs, but there's something wrong here.

  7. naturalborn says:

    It's astoundingly hard to filter out all possible pieces of script from HTML unless you're doing it by specific inclusion rather than exclusion. Defining new tags, especially given the complexity of XML is something I wouldn't even bother trying to filter properly.

    There was a problem recently on advogato in which someone put a script in their username which caused the same script to be put in the username of anyone who looked at it. Very clever, potentially much more damaging than it was, and very hard to stop given HTML's total lack of security model.

  8. nachtfalke says:

    There was something along these lines on alistapart using XML namespaces to define new tags.
    And, as usual, the article ends with "Unfortunately, styling these elements doesn't work in even some very recent browsers such as Opera 6/Win"
    But at least your documents will be full of chocolaty semantic goodness.

  9. volkris says:

    The guys above seem to disagree with this a bit, but I've seen this done before as an aside of a tutorial on CSS positioning. I'm pretty sure the author said it was valid.

    But that's a pretty sure along with the asumption that the auhor knew for sure.

    It was a good reference to CSS positioning, though, for what that's worth.

  10. adameros says:

    Totally off topic. But with all the complaints you've had about X11 in the past, maybe it would be good to join early on as the strive to make a competitor. Get in there and make sure they don't make the same sorts of mistakes they made with X11.