molly.com
Friday 16 March 2007
What Content Would You Generate?
Quite a number of comments from yesterday’s baseline CSS question brought up support for the :before and :after pseudo elements and generated content in browsers, particularly IE, which has no generated content support at all.
Interestingly, most current browers have generated content support, but there are some specific implementation oddities that I’ll be talking more about in my “Building Better Browsers” session at An Event Apart Boston in a couple of weeks. One of the major oddities is in Firefox.
Keeping our fantasy hats on (because it’s oh so much fun!), if IE.next actually supported generated content, how would you use it? Also, if you’re using it now, how are you doing so and managing degradation?
Filed under: WaSP, browsers, ie7, microsoft, software, standards, w3c, web design and development
Posted by: Molly | 11:17 | Comments (45)
The main benefit for me would be that my MySpace profile ( http://myspace.com/rickcurran ) would accurately proclaim “Rick has 65 Gazillion friends” to those using IE!!!
I can’t think of anything more useful right now, Friday night and it’s time to go home!
Seriously the only useful application I have seen so far is the easy clearing method. There is nothing :before and :after gives me that I cannot do with the DOM and I can test in JS if something is supported whereas in CSS I have to guess if it does.
It _could_ provide hooks for rounded corners and things like that, but it’ll make more sense to support the multiple background images instead. To me before and after are a dangerous step towards mixing structure and presentation. In most cases these days we only need to generate content to work around lacking CSS support and offer more hooks to apply styling to (niftycorners…). Adding these with CSS would be as much a hack as we do it now.
It is tough enough to trace back where some content comes from nowadays (with DOM enhanced content), CSS also creating content would make it even harder. The other question is if assistive technology would support it or – even better – reliably *not* support it.
Well, personally I’m not very font of generating content with CSS. It’s not what it was meant to do and there are easier ways to generate content.
That said, I only use :after in cases where the content generated should only be visible when CSS is on. For example, adding a ‘:’ after a heading which is floated and there’s text next to it. Without CSS the text would be underneath so no need for semicolon
In general tho, it seems to me that :before and :after are screaming for abuse. We’ll see.
One useful application of generated content is for providing link information in printed documents.
e.g.
@media print {
a[href^=http]::after {
content: " (link: " attr(href) ") ";
}
}
Print-medium link URLs, as I wrote in ‘Going to Print‘. Occasional diagnostic styles, like
*[class]:before {content: attr(class)}. Possibly the easy-clearing trick. That’s mostly it for basic generated content.Counters, though… those I’d have fun with. Like numbering paragraphs and hiding the numbers, then showing them with arbitrary-element hovering:
p:after {content: counter(para); visibility: hidden;}
p:hover:after {visibility: visible;}
Fun!
(Hope the markup makes it through unmolested…)
Titles for semantically-marked up menus:
Item 1
Item 2
UL.menu::before {
content: attr(title);
// … and some styling
}
This works in Firefox and Opera; Safari seems to have problems finding the right attribute (which may be my fault; I haven’t investigated in detail); IE just ignores it as expected.
The alternative is to add a further (for vague semantic goodness) ahead of the , which is just ugly. I haven’t actually tested this with assistive technologies yet (bad me), but I’m guessing (hoping?) that the mode which accesses lists will do the right thing with the title attribute, in a way that isn’t so possible with a related but not semantically-linked presentational title.
(1) Clearing method
(2) link enhancement [ back/forward images with paging links, [see chunkysoup.net], external icon, etc]
(3) real counters
(4) prefixes for different content block types [WARNING, NOTE, etc.]
(5) presentation of highlights on required elements or other callouts.
(6) graphical rules and dividers before or after an element without abusing background images & margins
(7) the above mentioned print style sheet showing link URLs
(8) usage hints [like echoing access key] or other cases along the lines of pulling out
(9) html and markup tutorials driven by echoing the “tag” around its content [see some toolbars or bookmarklets]
(10) I really don’t know because I haven’t felt compelled to use them where I needed to rely on them, but can see things like CSS tooltips [echo title in a highly stylized maner], help functions or echoing information in sidebar [abs. positioning the generated content on hover]
Most of the time the places I’d use it would be situations where iconography or similar touts would be more design/site version/appearance related then content related. Cases like enhancing a next page link with text >>> in one version of the site I could easily change to a graphical arrow in the next version simply though CSS. Some of the cases [like * before a required field] may be borderline content vs. presentation cases [e.g. do I still want to convey that info in a document sans-css] but bottom line is that in most cases those things feel to me like they’re of the current presentation or site design.
Email addresses! Last I checked, this was still unspammable:
.author:after {
content: “me\40myaddress.com”;
}
Surely a “warning” should not be dependent on CSS but be real HTML content! As for the “unspammable email”, all I need to do is scrape your site and dependencies and filter for \40, so if there were a massive support for this, rest assured spammers will find it.
I do like the print CSS bit, but also found that in reality really usable print versions go far beyond what you can do in CSS.
Lots to think about here. Surprised no one (Eric?) has mentioned the use of :before and :after in paged media for screen, such as S5 or OperaShow. It could be useful there too, I think???
For definition list decoration, to make them look more like unordered lists:
.omake dt:before {
content:counter(bullet, disc);
}
or, in IE 6, using Dean Edwards’ IE7 scripts
.omake dt:before {
content:”\2022 “;
}
Chris H: As I said, some cases aren’t clearly the domain of css. some of that is because the ‘content’ should be in the HTML document, and some of that is because we, as authors, are worried about cues missing in non-css supported presentations. But in the case of a WARNING or a NOTE I was thinking that these would be additional queues to ones already in content perhaps additional iconography or other item that would currently be relegated to, perhaps, a no-repeating background image combined with the proper margins. But lets take a more stylistic case and consider wanting to stylize a blockquote with graphical (”) characters before and after the text to get you back in my frame of mind with that suggestion of mine above.
Extra ‘fluff’ you know.
But it does leave the question of enhancing more important stuff [see my separate suggestion about required fields]. What about enhancing aural style sheets with generated content? perhaps the visual queues on a long form that may typically be an asterisk and some color changes could benefit from a rule like label.required:after { content:” required”; }. It would be the flip side to the current habit in some cases of hiding accessibility ‘hints’ via screen style sheets. Now I haven’t thought this through necessarily, so I won’t spend much time defending these specific cases, just exploring ideas.
I find a lot of things useful to generate… one thing I *really* love to do is generate the symbol for a monitary unit, according to what language a table cell is or use a class to determine it (since in some cases, one language can cross different monitary units… $, euros, and pounds).
I’ve seen people do all kinds of useful things with generated content, and it’s a shame it can’t be used to enhance pages in IE.
Rounded corners!!
Here’s a neat trick:
Output a H1 with a title attribute equal to the enclosed text. Then generate a “drop shadow” with something like this:
h1:before {
content: attr(title);
width: 1px;
…
}
IE users will then just have to live without drop shadows.
Or what about this:
input[type=submit] {
background : url(button-open-ended.img);
}
input[type=submit]:after {
content : url(button-right-end.img);
}
Gives us styled form buttons that handle variable text lengths. No extra markup.
Common use of generators will undoubtedly lead to more tricks being invented. And less redundant markup generated.
As for IE not having generators. The trick is “list-item”. See my entry on styling HR’s.
I don’t agree with some of the suggested uses of :before and :after for the single fact that they entangle the different layers of separation. :before and :after should really only be used for content that’s specific to the presentational layer and wouldn’t make sense if it appeared in either of the other two layers (i.e. just like a close button text appearing in HTML when it relies on JavaScript to make any sense in the first place).
Examples for :before and :after use include:
1) Insertion of delimiter characters next to list items that are displayed inline (or floated) (i.e. commas or pipes)
2) Superfluous characters used for graphic design effects (stuff like ~.::Ara::.~ when the real text is simply Ara)
3) Notes for CSS specific functionality (e.g. in the case of a CSS show/hide effect would say, “hover over here to display content” next to it) (though I question if this sort of effect shouldn’t be handled in the behavioural layer in the first place)
Again, I can’t stress enough how bad it would be to generate content that’s necessary in the structural layer (should CSS support be missing) and would end up restricted to the presentational due to :before and :after misuse (like, sorry Devon, the generation of the monetary unit).
I have to be honest. CSS generated content makes me a bit nervous. Generally, anything I consider content should be in the markup. The only time I see a viable use for CSS generated content is for items that are for design only.
If we start using CSS to generate content, we’re going to run into the same accessibility and cross device issues we have with most AJAX heavy sites.
That being said, there are some great design tricks that you could do with it. Clearing, bullets, and eliminating elements like the hr and br are all good uses.
The before and after pseudo elements, in cases, offer distinct benefits for improving accessibility. Using them, when ASP.NET menu control adapters are used, to insert printable characters, e.g. vertical bar, between links or using them to identify external web site links are primary uses. Have never been interested in using any CSS style properties, or script for that matter, to create circus acts.
For me it’d have to be Rounded Corners too.
It seems that in my work, every client and their dog wants rounded corners on their website and it sucks that to create flexible rounded corners (liquid layout! any width!) I have to resort to using extra markup. A sprinkle of generated content can take care of this…
div::before {
display: block;
background: url(/images/top_right.png) no-repeat 100% 0;
content: url(/images/top_left.png);
}
div::after {
display: block;
background: url(/images_bottom_right.png) no-repeat 100% 100%;
content: url(/images/bottom_left.png);
}
The counter stuff Eric mentions sounds technically cool, but really, how often will you require the number of a paragraph to be displayed when you hover over it?
In russian typography unordered lists using em-dashes instead bullits before it:
— List item one
— List item two
So content property helps me to insert them without any graphic.
There are countless uses and at the moment, nobody implements them since IE (unfortunately the browser with the highest number of users) doesn’t implement :before and after.
For example adding a “:” after a heading which has text right next to it, better styling of definition lists or ordered lists, better styling of hover links, adding rounded corners… These are just a few cases where :before and :after are useful.
While any content should stay in the markup, these examples show that *some* content is also important for purely presentational value.
I agree with what people said about using generated content for things like colons and dashes between items – for example, between DT/DD pairs where the items are floated. They aid visual comprehension, but are semantically meaningless.
Also useful for typographical symbols like bullets and arrows next to links.
Basically, wherever the text is presentation and not content. But definitely not where the text is content – the email address example is just a whole world of wrong.
(maybe not meaningless, but superfluous
)
I tend to Unordered lists for things such as “tags for this post: tag1, tag2, tag3″ it would be great to use :after to generate the commas. The comma itself is NOT part of the tag and therefore should not be part of the LI element, but you can NOT sneak that comma between LI elements? it is purely presentational and therefore the :after could be used.
A situation where the :before could be used is in XHTML 1.1 (maybe 2 as well?) where the count attribute has been depreicated from the Ordered List element. Now you can NOT start an ordered list at some thing like “10″ for “search reults page 2, 10-20″. With the :before you could change that value to anything you nedded.
Quotation marks that vary according to the language of content (needs :lang too). Href links when a document is printed rather than displayed on screen. Rounded corners, etc.
Fully stylable separators. It’s already mentioned, however, my approach is different. The hr-element is just a line that’s stylable with color, but :before and :after could generate stars or something that fits the overall style of a design.
I use the :after to generate an icon of a file type which is linked, eg a pdf icon if the file download is a pdf, to give a clue what the file is that people are downloading. Or a jump icon if its a link that takes you to another site.
Related to DanielS’s comment, I usually use generated content to publish separators for breadcrumbs, like this:
#breadcrumbs li:before { content: “0bb “; }
#breadcrumbs li:first-child { padding-left: 0; }
#breadcrumbs li:first-child:before { content: “”; }
The problem, of course, is IE. For IE, I usually append an image of the separator as a background image of the list item. I class the first list item and remove the background image and any padding from that item.
[...] Algunos de los que contestamos apostamos por la implementación de los pseudo elementos :content y :after y a partir de ahí Molly vuelve a pedir nuestra opinión ¿Qué contenido generarías [con esos pseudo-elementos]?. [...]
Others have mentioned already quotation marks, clearing content :before, particular list bullets, and printable links. A similar approach can be taken for printable acronyms and abbreviations.
But think about links: you could display an icon for internal, external or visited links :before them, automatically. Or display the :lang or [hreflang] :after them. That would be a real benefit for users.
Oh, and I remember a method for clearing floats with code insertion :after the float.
I would do:
img::after { content: ""; }and then style that span to overlay the image, and either apply transparency or clip to taste.
It’s a lot nicer than inserting the spans into the markup server-side.
There’s nothing here that couldn’t be built into other parts of CSS, for example the use of dashes as bullets (which I have actually done this way, comfortable that only 20% of the population will see them). And, of course, I use the :after clearing method in standards browsers – but again there could be a better mechanism added to CSS to tell a block element to enclose its floats. Generally, content belongs in the HTML layer.
I agree with Nicolas: once generated content finds its way into IE, it’s only a matter of time before SEO, marketing and other spammers find out about it and devise evil uses beyond the imagination of our standardista brains. Maybe it should be killed off now, before the population starts crying out for a “Generated Content Blocker”?
Accessibility:
a[href^="https"] {
background-color: yellow;
}
a[href^="https"] span::after {
position: absolute;
margin-left: -999px;
content: “(secure connection)”;
}
I can’t think how to get rid of the extra span right now, anyone have any ideas?
Accessibility? Drrr… not put into the DOM tree. Better meant for DOM scripting.
thank you molly
thanks for
good site
good blogger
very nice
thanks