Re: [css-d] Perhaps a simple solution...
17 feb 2014 kl. 08:33 skrev MiB digital.disc...@gmail.com: You could also use microformats and make it a part of a hcard (look some text fell off there. It should be: You could also use microformats and make it a part of a hcard (look up microformats and hcard at and here too: microformats.org/wiki/hcard)”. __ 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/
Re: [css-d] Will the unsemantic HTML elements B and I be soon phased out?
feb 16 2014 23:49 Andrew Cunningham lang.supp...@gmail.com: The problem with b and i is that HTML5 gives them semantic meaning but they also have inherent styling. How is that different from any semantical element? Of I use these elements in a multilingual envirnonment, then for some languages I would need to change weight or style to normal, then use styling appropriate to the language. I’m afraid I don’t follow why is this a problem? This would be easier without using those elements in your markup? __ 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/
Re: [css-d] hiding things and bandwidth?
feb 15 2014 06:22 Chris Williams ch...@clwill.com: And how do they do that? How does the server know the user's page width? By their going to m.example.com as opposed to example.com. Or with JS… Javascript analysis of screen type will take care of a majority of users and feed the relevant data to the server-side web application. In my case I serve another style sheet. People surfing with javascript turned off are probably in the single digits for a majority of web sites and a vast majority of those on non-mobile type of devices. The default to serve to people surfing with javascript turned off has to be handled with some care per site. I have zero mobile users on all my sites surfing without javascript on mobile type devices (less than 1% on other devices with JS off). By logic then I should default to the desktop site. However, I default to the mobile site, it being my main focus. Anyway, this means my non-mobile device type users get exactly the same content on the exactly same site as mobile-type device users, only different styles. This same site thing is more important than fringe user cases IMHO. __ 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/
Re: [css-d] Will the unsemantic HTML elements B and I be soon phased out?
is span any more semantic that b, i, em, or strong ? On scanning it seems there were responses but none with respect to the spec, which is usually very helpful: span (as well as div) have literally no meaning—“[t]he span element doesn't mean anything on its own” [1], “[t]he div element has no special meaning at all” [2]. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-span-element [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#the-div-element -- Jens O. Meiert http://meiert.com/en/ __ 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/
Re: [css-d] Will the unsemantic HTML elements B and I be soon phased out?
On Feb 16, 2014, at 4:49 PM, Andrew Cunningham lang.supp...@gmail.com wrote: The problem with b and i is that HTML5 gives them semantic meaning but they also have inherent styling. Of I use these elements in a multilingual envirnonment, then for some languages I would need to change weight or style to normal, then use styling appropriate to the language. Andrew So would it be safe to say you could normalize your b and i's and then class them? b class=bold/b and i class=italic/i Then when you hit an old browser the b and i will be presentational in their originally intended way as a fall back? Bootstrap does something similar to this I believe with their ui icons. Karl DeSaulniers Design Drumm http://designdrumm.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/
Re: [css-d] Will the unsemantic HTML elements B and I be soon phased out?
I've always had a problem understanding why em and strong are supposedly more semantic than i and b. Italics don't necessarily indicate emphasis and bold doesn't necessarily indicate importance. Often they're nods to traditional comprehension of things or to the organisation of a text so as to aid understanding. In fact, if you ask me, the instinctive, natural distinction between 'emphasis' and 'strong' is fuzzy, despite html5's attempt to define it. On the other hand, if i plainly means 'italic', and results in an italic font being displayed, then that to me is straightforward and unambiguous and no messing about. When I read it I can understand it however I prefer and according to the context. Same goes for 'bold'. Of course if you style i in the css to produce a different, non-italic style then, yes, that's very unsemantic. But seeing as i and b will be legit for the foreseeable future I'll prefer them over em and strong. They're quicker to key, too. Peter H. __ 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/
Re: [css-d] Will the unsemantic HTML elements B and I be soon phased out?
Peter H. wrote: I've always had a problem understanding why em and strong are supposedly more semantic than i and b. Because em means emphasised and strong means strongly emphasised (semantic, saying nothing about how they will be rendered) whilst i means set in italics and b means set in bold (presentational, focussing solely on presentation and saying nothing whatsoever about semantics). There is nothing supposedly about it; the older tags addressed presentation, the more modern ones address semantics. Philip Taylor __ 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/
Re: [css-d] Will the unsemantic HTML elements B and I be soon phased out?
El 17/02/2014, a las 11:01, Philip Taylor escribió: Peter H. wrote: I've always had a problem understanding why em and strong are supposedly more semantic than i and b. Because em means emphasised and strong means strongly emphasised (semantic, saying nothing about how they will be rendered) whilst i means set in italics and b means set in bold (presentational, focussing solely on presentation and saying nothing whatsoever about semantics). There is nothing supposedly about it; the older tags addressed presentation, the more modern ones address semantics. Philip Taylor What you say is evidently true, but my point is that there are many cases where you want to distinguish words within a text without necessarily implying emphasis. It's also true that the browser by default draws an italic font for 'emphasis' and a bold font for 'strong' so the result is equally presentational. Dunno why they couldn't have left it well alone, stuck with 'i' and 'b' and not created another can of worms. Peter __ 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/
Re: [css-d] Will the unsemantic HTML elements B and I be soon phased out?
While bikeshedding around 'how semantic' people feel any given element to be is a great laugh (although definitely off-topic for this list), I would highly recommend the HTML specification for insight into the purpose of any HTML element, especially when confusion arises over the possibility of using other elements in its stead. The 'Text-level semantics' page would seem to be incredibly pertinent to this conversation. From the section describing the em element: The em element isn't a generic italics element. Sometimes, text is intended to stand out from the rest of the paragraph, as if it was in a different mood or voice. For this, the i element is more appropriate. The em element also isn't intended to convey importance; for that purpose, the strong element is more appropriate. __ 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/
Re: [css-d] Will the unsemantic HTML elements B and I be soon phased out?
El 17/02/2014, a las 11:29, Barney Carroll escribió: While bikeshedding around 'how semantic' people feel any given element to be is a great laugh (although definitely off-topic for this list), I would highly recommend the HTML specification for insight into the purpose of any HTML element, especially when confusion arises over the possibility of using other elements in its stead. The 'Text-level semantics' page would seem to be incredibly pertinent to this conversation. From the section describing the em element: The em element isn't a generic italics element. Sometimes, text is intended to stand out from the rest of the paragraph, as if it was in a different mood or voice. For this, the i element is more appropriate. The em element also isn't intended to convey importance; for that purpose, the strong element is more appropriate. Thanks Barney, that's a useful extract. Because browsers draw em as italic I'd always assumed it was just a new fangled complication. But it seems as though it wouldn't be bad practice at all to restyle em in the css as one thinks appropriate to the concept of emphasis. I had to go to wikipedia for 'bikeshedding'. Must be my age. Peter __ 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/
Re: [css-d] Will the unsemantic HTML elements B and I be soon phased out?
Barney Carroll wrote (probably citing one of the finite-but-unbounded number of HTML 5 draft specifications) : The em element isn't a generic italics element. Correct. It has no connection with italics at all other than a historical one. Sometimes, text isintended to stand out from the rest of the paragraph, as if it was in a different mood or voice. For this, the i element is more appropriate. Yes, if you want it to appear in italics; if you don't, don't use i The em element also isn't intended to convey importance; for that purpose, the strong element is more appropriate. Oh, so I want to emphasise something does not mean that I consider that something important ? What a completely load of tosh. Sometimes I wonder which planet the authors of this nonsense came from. Philip Taylor __ 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/
Re: [css-d] hiding things and bandwidth?
Which is precisely what I suggested as one of the two alternatives: use JS to serve up content based on screen size. On 2/17/14 12:27 AM, MiB digital.disc...@gmail.com wrote: Javascript analysis of screen type ... __ 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/
Re: [css-d] hiding things and bandwidth?
Only this group's mentor and creator can set the rules. Because this group IS a forum for discussing CSS it seems right to limit fine-grained how-to-do-it discussion to CSS only. But the use of CSS in the real world invariably happens in a context that almost always includes a mixture of technologies including databases, server side scripting and javascript. So at higher big picture level some discussion about how CSS fits into the overall scheme of things still seems appropriate. Using Javascript cookies and (initially) a double GET to determine the state of the current user agent makes the most sense to me--so custom CSS, custom image sizes and even custom HTML can be sent back down the pipe. CSS only mobile first approaches violate basic theory of programming rules because mobile first inescapably couples itself to both small mobile displays plus the vastly different requirements of bigger desktop displays. Writing codes with semi-secret two role agendas is seldom a good idea. On Mon, Feb 17, 2014 at 9:48 AM, Chris Williams ch...@clwill.com wrote: Which is precisely what I suggested as one of the two alternatives: use JS to serve up content based on screen size. On 2/17/14 12:27 AM, MiB digital.disc...@gmail.com wrote: Javascript analysis of screen type ... __ 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/ -- /* Colin (Sandy) Pittendrigh --oO0 */ __ 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/
Re: [css-d] hiding things and bandwidth?
17 feb 2014 kl. 17:48 skrev Chris Williams ch...@clwill.com: Which is precisely what I suggested as one of the two alternatives: use JS to serve up content based on screen size. I underscored the importance from my perspective not having a separate ”mobile” web site. Whatever the details, the choices a developer will have to make is about a complete system rather than individual solution. /MiB __ 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/
Re: [css-d] hiding things and bandwidth?
feb 17 2014 18:05 Colin (Sandy) Pittendrigh sandy.pittendr...@gmail.com: So at higher big picture level some discussion about how CSS fits into the overall scheme of things still seems appropriate. Exactly. Using Javascript cookies and (initially) a double GET to determine the state of the current user agent makes the most sense to me--so custom CSS, custom image sizes and even custom HTML can be sent back down the pipe. I like Googles variheader concept. CSS only mobile first approaches violate basic theory of programming rules because mobile first inescapably couples itself to both small mobile displays I disagree for the most part, but obviously this depends on the actual difference in user patterns and user objectives on different devices. I have embraced that the customers of my clients want to do everything on all types of devices. But envy site is different. plus the vastly different requirements of bigger desktop displays. Writing codes with semi-secret two role agendas is seldom a good idea. This does not make sense. Secret two role agendas? It’s different styles for equivalent content. For some content, like audio/video you may have to server different content and consequently different markup. I fail to see the problem with that though. __ 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/
Re: [css-d] hiding things and bandwidth?
MiB digital.disc...@gmail.com: the choices a developer will have to make is about a complete system rather than individual solution. Solutions obviously. Sorry about that. /MiB __ 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/
Re: [css-d] Will the unsemantic HTML elements B and I be soon phased out?
It must be remembered that the presentation layer is optional, and CSS isn't always available. It might be due to a server error or timeout (i experience that on maybe 1% of page loads), or, as HTML rendering capability extends to ever-smaller devices, a physical limitation. span has no default presentation. So I tend to use it only in situations where it doesn't matter if presentation is lost. But if the differentiation of such text matters, it makes sense to use markup that will differentiate it regardless of the availability of CSS. In most cases this is em or strong, often with a class to classify it semantically. But if I want to use a binomial name, where emphasis is not intended but italic rendering is desirable, then there is a case for i class=binomialbeta vulgaris/i. __ 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/
Re: [css-d] Will the unsemantic HTML elements B and I be soon phased out?
Ya'll, I hate to be rude, but isn't markup debates a little OT for CSS-d? http://css-discuss.incutio.com/wiki/Off_Topic __ 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/
Re: [css-d] Will the unsemantic HTML elements B and I be soon phased out?
17 feb 2014 kl. 18:35 skrev Richard Grevers richard.grev...@gmail.com: But if the differentiation of such text matters, it makes sense to use markup that will differentiate it regardless of the availability of CSS. A valid point. In most cases this is em or strong, often with a class to classify it semantically. Widely used classification schemes may have semantical value, but hardly if it’s the developers' classifications only. __ 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/
Re: [css-d] Will the unsemantic HTML elements B and I be soon phased out?
feb 17 2014 18:51 Micky Hulse mickyhulse.li...@gmail.com: Ya'll, I hate to be rude, but isn't markup debates a little OT for CSS-d? Actually it is indeed OT, except for where it ties in directly with CSS. References to external discussions on the topic are not OT, IMHO. So good point. __ 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/
Re: [css-d] Will the unsemantic HTML elements B and I be soon phased out?
2014-02-17 19:35, Richard Grevers wrote:
It must be remembered that the presentation layer is optional, and CSS
isn't always available. It might be due to a server error or timeout (i
experience that on maybe 1% of page loads), or, as HTML rendering
capability extends to ever-smaller devices, a physical limitation.
Or some of the other CSS Caveats may apply, see
http://www.cs.tut.fi/~jkorpela/css-caveats.html
span has no default presentation. So I tend to use it only in situations
where it doesn't matter if presentation is lost.
That's my approach too, but many people disagree.
I hope this mostly quite off-topic discussion ends, but I'd like to
summarize what I see as directly CSS related in the topic discussed:
Most HTML elements that can be used inside the body element have some
default rendering, which is largely (though not completely) describable
in CSS, and is being described in HTML5. We cannot always be sure of the
effect, though; there are browser differences.
When designing the use of CSS, the default rendering needs to be taken
into account. There are many approaches. One of them is extensive use of
span (which has no default impact on rendering) and div (which has
no other default impact than display: block), usually with class or id
attributes. Another approach is to use some of the CSS Resets (which
cannot remove all default rendering). In these approaches, the author
then writes explicit rules for all the rendering he wants. In a sense,
this resembles CSS styling of XML documents: you build up all the rendering.
A third approach uses elements with default rendering and considers the
implications, by overriding what needs to be overridden. You might also
explicitly set what you expect to be default rendering (such as b {
font-weight: bold }) if that's what you want, on the grounds that in
some browsing situations it might not be the browser default.
In all approaches, b is really not different from strong at all, for
example. Theoretically, they could have different default renderings,
but I haven't seen any evidence of such things actually happening. So
whatever you might think of b vs. strong or i vs. em vs. cite
etc., it's really not relevant to CSS.
Yucca
__
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/
[css-d] Change formatting based on browser capability?
Although the subject might immediately have people thinking about
Internet Explorer - and older versions, at that - in this case, it's
FireFox that appears to be the problem child.
The issue here is that even though the spec isn't necessarily clearly
defined, most browsers make a reasonable attempt at supporting
display:run-in. Firefox doesn't. Neither do older versions of IE, nor
very older versions of webkit-based browsers or Opera. OK, fine. Here's
what I'd like to do:
THE HTML
DL
DTJohn Jacob Jingleheimer Schmidt/DT
DDHis name is my name, too. Whenever we go out, we can hear the people
shout Hooray for John Jacob Jingleheimer Schmidt./DD
/DL
DESIRED RENDERING
Stuff bracketed with * should be bold, stuff in [] is generated content.
CASE 1: display: run-in SUPPORTED
*John Jacob Jingleheimer Schmidt[:]* His name is my name, too. Whenever
we go out, we can hear the people shout Hooray for John Jacob
Jingleheimer Schmidt.
CASE 2: display: run-in NOT SUPPORTED
*John Jacob Jingleheimer Schmidt*
His name is my name, too. Whenever we go out, we can hear the people
shout Hooray for John Jacob Jingleheimer Schmidt.
Note that Case 2 is easily managed with the default rendering for a DL
plus
dt { font-weight: bold; }
if I wanted that to be the rendering in all cases. What's not clear to
me is (a) how to handle Case 1, specifically the undenting of the left
margin (most of the rest I can work out), and (b) HOW DO I DETECT
whether display: run-in is supported so as to make the application of
the appropriate CSS conditional on the support?
I have full control over the HTML, so adding classes or IDs to DLs, DTs,
or DDs isn't an issue.
--
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/
Re: [css-d] Change formatting based on browser capability?
Le 18 févr. 2014 à 10:06, Freelance Traveller edi...@freelancetraveller.com a
écrit :
The issue here is that even though the spec isn't necessarily clearly
defined, most browsers make a reasonable attempt at supporting
display:run-in. Firefox doesn't. Neither do older versions of IE, nor
very older versions of webkit-based browsers or Opera.
You may want to reconsider this.
Both Chrome and WebKit (nightly) have removed support for display: run-in
webkit:
https://bugs.webkit.org/show_bug.cgi?id=127874
Chromium:
https://codereview.chromium.org/53373003
And there are so many inconsistencies between browsers with this property
(you'll need to do a search on www-style and check the Gecko bug linked below).
In fact the CSS WG has removed it entirely, from the CSS 2.1 spec. It will
eventually make a come back in a new CSS3 spec.
Ok, the case you outline is pretty basic though…
http://www.w3.org/TR/CSS21/visuren.html#propdef-display
Gecko bug report:
https://bugzilla.mozilla.org/show_bug.cgi?id=2056
– – –
To answer another part of your question, one way to style an element based on
browser capability is using @supports () {}
https://developer.mozilla.org/en-US/docs/Web/CSS/@supports
http://dev.w3.org/csswg/css-conditional/
e.g @supports not (display: run-in) {
dl { background: lime; }
dt { background: red; }
}
Philippe
--
Philippe Wittenbergh
http://l-c-n.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/
Re: [css-d] Change formatting based on browser capability?
On Mon, Feb 17, 2014 at 8:06 PM, Freelance Traveller edi...@freelancetraveller.com wrote: THE HTML DL DTJohn Jacob Jingleheimer Schmidt/DT DDHis name is my name, too. Whenever we go out, we can hear the people shout Hooray for John Jacob Jingleheimer Schmidt./DD /DL DESIRED RENDERING Stuff bracketed with * should be bold, stuff in [] is generated content. CASE 1: display: run-in SUPPORTED *John Jacob Jingleheimer Schmidt[:]* His name is my name, too. Whenever we go out, we can hear the people shout Hooray for John Jacob Jingleheimer Schmidt. [...] What's not clear to me is (a) how to handle Case 1, specifically the undenting of the left margin (most of the rest I can work out), 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 -- Jon Reece jon.re...@gmail.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/
Re: [css-d] Change formatting based on browser capability?
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
