Re: [css-d] Double space after a period]]
On Sun, 15 Oct 2006 13:15:59 +0100 Designer <[EMAIL PROTECTED]> wrote: > declare: > > i {padding-right : 1em; } > > then use . in the text. Not brilliant, certainly not semantic, > but it seems to work. I wanted to avoid a long 'span' and use a simple > (short) tag. > > I doubt that anyone can spot an italicised period. . :-) ! you could also apply a style to make the period not be italicised too. Maybe I missed the point, but why not use in this case? I thought the idea was that the text was being inserted without formatting, and that the author is looking for a way to apply two spaces to "as typed" text that otherwise is having whitespace compressed. The first 3 thoughts I had would not work. I then went to using unobtrusive javascript to "fix" the markup after it's delivered to the browser, (assuming server-side intervention is not possible) but that is definately not a CSS solution. __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Four that could be two
I think the active state is used if you keyboard navigate the links without activating them. The link that will be followed by pressing the space/enter key can be "active" without sharing the "hover" status. True, many people navigate solely with the mouse. As a general rule, I would suggest being extra explicit about your selectors and rules rather than relying on default behaviors. On Fri, 26 May 2006 15:20:32 -0700 "skye estes" <[EMAIL PROTECTED]> wrote: > On 5/26/06, Scott Haneda <[EMAIL PROTECTED]> wrote: > no problem. also note that if your hover and active states are the same, > only specifying rules for the hover state will be enough, as you have to be > hovering over a link in order for it to be active. > __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] Selector complexity
Is there any known performance impact to possibly overly specific selectors? ex: #CategoryList li.Category ul li.product ul li.ciDsc a:hover {} (vs.) li.ciDsc a:hover {} The first case is extremely specific and clues the reader to the structure of the document Does the second case incur less parse/render overhead? I normally opt for readability, but I have recently executed a styled list of links from what was once a table-based layout. The page display performance is pretty terrible. I would post a url, but this is part of a redesign rollout that is not yet public. __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] menu help
Can someone explain to me why IE removes the background from Menu11 when the browser is resized so the viewport is smaller than the top menu bar? http://www.pgi_products.com/test/cssmenu2.asp?CM=3 (remove the underscore) I know the graphic and color schemes are terrible, and a coworker was complaining about font size and family, etc. This proof of concept is close enough to working to be promising: css only 2 line menu (except for IE .htc) - but if I can't figure out why IE is rendering incorrectly, I will have to find a new solution. (The latest version on our developement server is reliably crashing IE) __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] class vs. id
I think the idea was that the wiki would stay "evergreen" while the past discussion would not be as available to new members (or existing members who don't feel like searching archives) Wiki pages are also more easily referred to in response to new questions than an old discussion thread. On Wed, 14 Dec 2005 11:54:40 -0500 brian <[EMAIL PROTECTED]> wrote: >> Start a blog, add a page to the wiki. This is where I put things like >> that, as it is meant to be remembered, right? > > Go start your own blog. The last time i looked, the d in css-d stood for > 'discuss' __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Help my design team move away from nested tables
If a page is composed entirely of a 'cut up' Photoshop image, what value is CSS? If the page is created and managed as a photoshop document, is there any useful presentation feature offered by CSS? There is no font control (sizing, face, etc.) there is no color control, there is no (real) hope of liquid layout, there is no alternate stylesheet. If marketing decides to 'tweak' the page, you're going back to the original photoshop document. I don't see how a site made of pages like this is much different than an interconnected PDF that pops up in your browser. Our webmaster draws pictures in photoshop and gets approval for pages using those images, then he'll create a FrontPage mockup - which is essentially the photoshop document polluted with Frontpage markup. The multipage mess is then handed over to me to "make functional" by adding infrastructure that should have been built first. Am I wrong to believe this is not a 'best practice' way to go about web design? (sorry for the wandering rant) ...Anyone have a favorite URL for 'best practice' web design? On Tue, 29 Nov 2005 15:58:36 +0300 "Nick Wilsdon" <[EMAIL PROTECTED]> wrote: > Paul wrote: > >> If we want to produce good clean markup using CSS we have the basically > rewrite much of the output from the design team. This seems like double > work, Considering this is more a tool issue than the fault of the designers. > What alternatives are there for this? > > > This tool doesn't exist, sorry Paul. It just sounds like you need a web > designer. You're essentially using Adobe ImageReady to 'make' your web sites > at the moment. Once they finally launch a 'CSS web designer tool' then a lot > of us are out of work! *g > > I have 2 people here (and myself) hand coding up the Photoshop layouts from > the designers - I couldn't imagine doing it any other way. > > There are tools which make working in CSS easier - TopStyle by Nick Bradbury > is one that really helps me. You can also pick up layouts at glish.com and > bluerobot.com which will save your team time. __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Text decoration help
em is a tag that semantically implies emphasis If your CSS does not get applied, the default rendering of the em tag should still provide emphasis, while the p tag with a class does not have the same implicit meaning. font-style controls italics text-decoration controls underline does this work?: em { font-weight: 900; font-style: normal; text-decoration: underline; } On Fri, 25 Nov 2005 13:57:04 -0800 Jim Davis <[EMAIL PROTECTED]> wrote: > Angus, > > Try CSS something like.. > > .shout-it { font-weight: 900; text-decoration: underline; } > > Then html like: > > This is bold underline > > Using em as a class or id name is probably a bad idea. > > Jim > > On 11/25/05, Angus at InfoForce Services <[EMAIL PROTECTED]> > wrote: >> >> In my style sheet, I have: >> >> em { >> font-weight: 900; >> text-decoration: underline; >> } >> >> And the text between the appears as bold italic and not bold >> underline. Anyone now why? >> >> >> > __ > css-discuss [EMAIL PROTECTED] > http://www.css-discuss.org/mailman/listinfo/css-d > List wiki/FAQ -- http://css-discuss.incutio.com/ > Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ > > > > __ > This message was scanned by ATX > 4:57:49 PM ET - 11/25/2005 __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Why add an .img class?
define "uncluttered" Good markup should describe the content. If there is semantically correct information about the tags that is not immediately used by the current stylesheet, that does not mean the information is 'clutter.' I would prefer the content creator add appropriate classes describing the content (though not the layout preferences) so that the presentation layer (css) has more opportunity to specifically style the content. It becomes very difficult to later isolate specific elements in a document if those elements do not have appropriate classes. On Tue, 18 Oct 2005 11:45:53 -0400 "Charles Dort" <[EMAIL PROTECTED]> wrote: MANY thanks to all who have so helpfully replied to my question! As a beginner, perhaps I've focused too much on the value of uncluttered markup. So far as I can see, I was able to complete all of the tasks of that chapter (including changing margins, etc.) without "cluttering" the markup with a class that to this beginner seemed unnecessary. I would have supposed that if in the future I made a change such as adding text to the with an image, then I would need a class and could then add it at that point, and I wondered why do it until/unless it's needed. I gather from the replies that experienced CSS coders would often prefer to "be prepared" for such a possible future need, even though it may mean adding classes to the html markup that aren't actually needed, at least at this time. It's helpful for me to think about these things, and I thank all of you for your help. Charles __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ __ This message was scanned by ATX 12:19:13 PM ET - 10/18/2005 __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Music Files and CSS
By that definition there should be no background: url(anything) I know it's difficult enough to find support for current levels of CSS specs, but the user experience on the Web will likely continue to evolve to a point where audio will be as much a part of a site's "style" as the images or fonts. [perhaps body{background-audio: url(mymusic.mp3);} ] I don't think it was unrealistic for Peggy to ask the question. On Wed, 20 Jul 2005 19:00:35 -0500 Matthew Ohlman <[EMAIL PROTECTED]> wrote: Peggy Bart wrote: Any information on how to add mp3 files to be played by visitors to my web site using CSS would be greatly appreciated. Thank you, Peggy Bart Peggy: I don't think CSS is going to help you there. Here is the definition of CSS straight from the spec: "Cascading Style Sheets (CSS) is a simple mechanism for adding style (e.g. fonts, colors, spacing) to Web documents." CSS is used for styling, not content. I think what might work better is the 'object' tag, or maybe you could create a Flash applet. I think JavaScript might be able to handle sound, but don't quote me on that one. [1] http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-object.html - Object Tag [2] http://www.w3.org/Style/CSS/ - CSS Specs __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Inline links, background images and MSIE
I would suggest for the sake of the future, (where the CSS gets moved to another directory and you have to update the markup to reflect the change) that the only relative paths you use are relative to the root: /images/whatever.gif Otherwise, you may have to update the markup referring to the CSS as well as go through the CSS to change paths to images that haven't even been moved. Also, for security reasons some administrators may uncheck the "allow parent paths" checkbox to disable the ".." directory from working. YMMV If your images were in a images folder (or directory) this would be the correct way: - - - O R - - - a { background: #fff; url(../images/arrow-selected.gif) 0 50% no- repeat; padding-left: 1em; } __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] hiding and displaying table rows FF vs. IE
1. inline styles are less than ideal. 2. if an object is display: none; why bother setting its visibility? how about this instead: #mytable tbody {display: none;} #mytable tbody.show {display: block;} then in javascript: mytbody.className = 'show' ; /* show the tbody */ or mytbody.className = '' ; /* remove the "show" class = return the default style = display: none; */ The idea is to keep the presentation details in CSS (preferrably in an easier-to-maintain external CSS file) and the behaviors for changing the presentation (via obj.className) isolated to the javascript. Note: If you want to use multiple classes on the object, you will need to tweak the javascript - which is beyond the scope of this simple example and completely off-topic for css-d. BTW, Are you doing anything to accommodate browsers with javascript unavailable? On Fri, 17 Jun 2005 09:28:52 -0400 Jason Kohls <[EMAIL PROTECTED]> wrote: Hi all, I'm having issues hiding and displaying table rows contained within a tbody, specifically, Gecko-based browsers. The initial state is to hide the rows. In order to do this in both IE and FF, I used the following: ... ... Using javascript, I'm changing these styles to "visibility:visible" and "display:block" in a function using an onclick event. This works fine in IE; the rendering order is maintained and life is wonderful. In FF, however, the display: none is taking it out of the rendering context (like it's supposed to) so when I change the display/visibility attribute, the now visible tbody/tr's show up last in the rendering order (below the tfoot even). I've tried playing with positioning, etc. is there: a) a better way to do this? If the initial state was to show the rows, this works fine, but thats not what I need. b) a way to force the rendering order using some CSS hack goodness? :) Thanks in advance, J __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ __ This message was scanned by ATX 9:41:47 AM ET - 6/17/2005 __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] layout issue with floats and wide content
the current site: http://pgiproducts.com/pgi.asp my attempt at removing the layout table: http://pgiproducts.com/skins/pgimsd/demo1.htm Resize your viewport small enough that the #content wraps below #nav I "fixed" my design proof in Firefox by #content {overflow: visible} but my proof used long strings of static text, which is not accurately representational of the actual dynamic contents. The markup that goes inside the #content div is out of my control, but I have to make sure the existing content is displayed properly. A small viewport causes the floated #content to wrap under the floated #nav. I tried using absolute positioning, but could not figure out the #footer. Since IE does not allow content to be visible outside the containing box, I set an arbitrarily large width on the #middle div to try to prevent the wrapping when #content got too big. None of this is working the way I think it should. Many of the links I've googled have simple examples of two-column layouts with header & footer. The problem is that they do not expect the #content to scroll right out of the viewport. I know horizontal scrolling isn't fashionable, but I can't enforce a redesign of existing pages which have been allowed the freedom of infinite right extension. What else can I try before admitting I've spent too much time on this already and leave the table-based layout in place? __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/