- <STYLE TYPE="text/css">
.foo { color: white; background: red; }
bar { color: white; background: green; }
</STYLE>
- 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 -
What a surprise, of course it does. Sigh.
No doubt this would confuse most validators too.
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.
Doesn't work with opera either. Incidentially, opera looks like shit under linux.
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.
AFAIK, defining a STYLE tag like this within <HEAD/> is valid. I've never come across an instance of a STYLE tag within <BODY/>.
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 style...like so:
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".
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?
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
...AFAIK, "D" (div), "S" (span) and "C" (class) wouldn't conflicts with existing stuff.
IIRC, the only single-letter tags are "A" (anchor), "B" (bold), "I" (italics) and "U" (underline).
<P>
Don't trust your memory. :)
</P>
Yep; you're right. Thx for not being an asshole about it! :)
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.)
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.
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.
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...
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.
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.
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.
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?
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.
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.
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.
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.
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.
Totally off topic. But with all the complaints you've had about X11 in the past, maybe it would be good to join http://xwin.org/index.php 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.