On Mon, 17 Feb 2014 20:58:58 -0500, Jon Reece <jon.re...@gmail.com> wrote:
>I'm probably misunderstanding the question, but based on your pseudo-code >you could accomplish this with CSS 2.1 using display: inline: > >Example: http://codepen.io/jreece/pen/yznEw Actually, you _were_ misunderstanding the question as written - but your codepen code was actually a nearly-ideal answer to the meta-question. The question as written was predicated on the usual stand that "if {feature} isn't supported, degrade gracefully". Thus, rendering 1 - the run-in model - should only have been achieved if display: run-in was actually supported by the user-agent, and rendering 2 otherwise. With support for display: run-in, the CSS for case 1 would have been dt { display: run-in; font-weight: bold; } dt:after { content: ":"; margin-right: 0.33em; } dd { margin-left: 0; } and what I was really asking about was simply the CSS for the DD, as I had somehow gotten the impression that "margin-left: 0" would not have changed the indent. For Case 2 (display: run-in NOT supported), I was assuming that I'd have to revert to a standard DL, with only the bolding of the DTs. The issue for that case was simply "How do I detect whether 'display: run-in' is supported. You, however, went beyond the posed question to the "meta-question", which was, in effect, "I WANT DISPLAY: RUN-IN TO WORK, DAMMIT!", and provided a solution for _that_. I will point out that if you search the list archives for questions posed by me, you'll see that this isn't the first time I've gone after that 'holy grail', but it's the first time I've gotten a response that hasn't tried to discourage me from attempting the indicated presentation. Additionally, your solution provides an excellent model for those occasions where it is NOT a DL that needs to be managed in this way - even ordinary topic headings at comparatively low levels (e.g., H4 through H6) can be run-in to their following paragraphs using this technique plus the adjacency selector. I appreciate your help, more than I can express, and I applaud your willingness - even if inadvertent - to think outside the box and beyond the prima-facie question. Thank you. What follows is a rant; there is no need to read further for discussion of CSS code or techniques, though there may be a couple of nuggets of relevant philosopy buried therein. I grant that one should not - cannot - expect on-line publication to exactly match print publication. Some things that make print publications easier to read will make on-line publications *harder* to read - serpentine (newspaper-style) columns, for example - on-line, you'd read down one column, scrolling the page as you go, then have to jump back up to the top to continue reading. Bad. The only time that serpentine columns should be used on the web is when you can guarantee that the entire content of the page will fit on the user-agent's rendering surface without scrolling. Run-in headers are not such a feature. Where they work in print publication - and they are common there - they will work equally well in on-line publication, and for exactly the same reasons (excluding the reason "I use less paper with run-ins, which reduces the cost of the publication".) The lack of support has been, essentially, due to developers saying "It's too hard to code properly, the spec is unclear, and nobody is using it" - except that nobody was using it because they were told that it isn't supported (principally by gecko), and few web developers were adamant enough about wanting it to go ahead and find a solution such as yours, so that one would see the technique (of run-in headers) used, even without direct support for it. Nor are user-agent-specific solutions (e.g., IE conditionals) considered acceptable, except occasionally in the extreme case of IE6. A vicious cycle, that fed right into lazy developers. Yes, the spec is unclear; Philippe's link to codereview.chromium.org contains a link to css-tricks.com that discusses that issue, though I think it may be less unclear than suggested. I certainly don't think that it's unclear enough that _reasonable_ interpretations couldn't have been arrived at - and both IE and (Presto-based) Opera agreed, as did older Webkit (recent Webkit has removed support). Then, you either let the "marketplace" fight it out for the "correct" interpretation, or you appeal to the Working Group and say "The Specification is unclear in this way; here are alternative reasonable interpretations; which is correct?" and get a 'ruling' on intent. -- Jeff Zeitlin, Editor Freelance Traveller The Electronic Fan-Supported Traveller® Fanzine and Resource edi...@freelancetraveller.com http://www.freelancetraveller.com http://come.to/freelancetraveller http://freelancetraveller.downport.com/ ®Traveller is a registered trademark of Far Future Enterprises, 1977-2009. Use of the trademark in this notice and in the referenced materials is not intended to infringe or devalue the trademark. Freelance Traveller extends its thanks to the following enterprises for hosting services: CyberNET Web Hosting (http://www.cyberwebhosting.net) The Traveller Downport (http://www.downport.com) ______________________________________________________________________ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
