[css-d] Role of Pre-processors
Eric: Well, I am just thinking theoretically, but the standards refrain is, everyone should meet the standards. And so css says, the code 'corners: rounded' or 'corners: spiked' is valid. But then the browsers fail to comply. They need it to be, 'mozilla-corners: rounded', and then there are 8 varieations. And I wonder, why does the language not have the ability to internalize that, or can the language itself negotiate a successful result, given this imperfect reality. Pre-processors may well have other value, but is this negotiation a function that should be done by them? We already have a lack of standardization, so I personally am not thrilled with this extra layer of complication on an already difficult process, but given the potential I would assume they are here to stay. Rgrds, Andrew Andrew, I'm not following what you mean by this - Why can't there be a code for all browsers, to do something like transparency or rounded corners. Are you talking about something outside of CSS? Something else maybe? Eric __ 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] Pre-processor discussion
Nice to see some thoughtful replies. Under the circumstances, I don't want to be the one to push this issue and start a holy war. I do wonder if CSS itself could at least potentially come to make the pre-processors obsolete. Why can't there be a code for all browsers, to do something like transparency or rounded corners. But I don't know if that is possible. Anyway, nice discussion, thanks! Andrew __ 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] Ready for Pre-processors?
Hello All: I have been a bit busy and haven't been keeping up, how does the list feel about discussions involving LESS, SASS and SCSS? I have a Sass project where I have to make some changes and feel a little lost. Not sure if I would have any specific question to ask here, but is the list open to these technologies as well? Cheers! __ 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] IE 7 still doesn't play nice!~
Hi All: I am sorry to bring a IE 7 problem to you all. I am sick of IE 7, so I know some of you are as well. The 3 bullet points for the 3 sections each have one bullet point that prints going down, destroying the layout about as effectively as possible. Wonderful efficiency, Microsoft! Pls have a look: www.rayxi.com I have fiddled and read up on the various IE 7 problems such as hazlayout, but to no avail. Could anyone point me in the right direction pls? Deepest Advanced Gratitude! Andrew __ 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] IE 7 still doesn't play nice!~
Hi Chris: Thanks for taking a look. The pic you linked to is what it *should* look like, in fact it looks fine on all browsers except for IE7. If the lines just wrap like they do in a couple places in that pic, then I would be ok. Here is a pic of what it looks like in IE7: http://tinypic.com/r/e6w009/6 I made green marks to show where the problems are. There seems no rhyme or reason for it. It doesn't wrap at all, but prints basically up and down, pushing the next line down by quite a bit. I thought maybe margins and so on were the problem, but my tinkering didn't seem to help. I wonder what I should do next... Thanks again, Andrew From: Chris F.A. Johnson ch...@cfajohnson.com To: Andrew C. Johnston attyjohns...@yahoo.com Cc: css-d@lists.css-discuss.org css-d@lists.css-discuss.org Sent: Friday, November 2, 2012 2:42 PM Subject: Re: [css-d] IE 7 still doesn't play nice!~ On Thu, 1 Nov 2012, Andrew C. Johnston wrote: Hi All: I am sorry to bring a IE 7 problem to you all. I am sick of IE 7, so I know some of you are as well. The 3 bullet points for the 3 sections each have one bullet point that prints going down, destroying the layout about as effectively as possible. Wonderful efficiency, Microsoft! What do you mean by prints going down? Do you mean the line wraps? If so, that's perfectly normal; if there's not room for the line, that's what happens. Would you want it to overwrite the next column? Pls have a look: www.rayxi.com This is how it looks in my browser (Firefox): http://b.cfaj.ca/rayxi.jpg -- Chris F.A. Johnson, http://cfajohnson.com/ Author: Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress) Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) __ 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] IE 7 still doesn't play nice!~
Apparently IE7 heard your snide little comment about its brain, Phillippe.
Because the result after adding the code is even worse! Haha unbelieveable but
true, have a look:
http://tinypic.com/view.php?pic=20tnwows=6
Now, each of the li's are printed up and down after the first one, except for
the first section.
Sigh. Its tough to admit defeat to a zombie drone like IE7...
Help?
Rgrds,
Andrew
From: Philippe Wittenbergh e...@l-c-n.com
To: Andrew C. Johnston attyjohns...@yahoo.com
Cc: CSS-D css-d@lists.css-discuss.org
Sent: Friday, November 2, 2012 3:50 PM
Subject: Re: [css-d] IE 7 still doesn't play nice!~
Le 2 nov. 2012 à 16:43, Andrew C. Johnston attyjohns...@yahoo.com a écrit :
Here is a pic of what it looks like in IE7: http://tinypic.com/r/e6w009/6
I made green marks to show where the problems are. There seems no rhyme or
reason for it. It doesn't wrap at all, but prints basically up and down,
pushing the next line down by quite a bit.
Apparently IE 7 doesn't stack the li's correctly due to the fact that they are
floated.
add
ul.pList3 li { clear: left; }
and they should behave (should… who knows what IE7's little mind is up to next)
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/
[css-d] Text positioning in FF and Chrome - They go opposite ways
Hi All, wonder if I can tap into the wetware database with a question. I have a lot of teaser boxes that entice users to click on them, with text in the boxes. Nothing shaking or flashing or anything (yet). Due to my design's limitations (or my own) I need to keep this box fairly short, I guess not anything over 100 px. The problem is that FF and Chrome seem to handle the spacing I am doing in completely opposite ways, which makes the text in the box never quite centered. Check it out, newest Chrome and FF (Linux version): http://www.rayxi.com/lsat-exam-information-rayxi In FF the text is a little too low, almost to the bottom border. In Chrome, a little too high. Any workaround for this? Smaller box or bigger? Bigger box and smaller text? Maybe my margins and spacing are working at odds? Any help would be appreciated. Thanks in advance, Andrew __ 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] A question about 2-color borders (grooved, ridge etc.)
While I am tempted to get some popcorn and watch you two bludgeon each other with fancy tech/design words, I think its better to re-focus, and try to explain my point more clearly. With inset, outset, groove and so on, you choose one color *for each side of the border*, but then the final result is two colors for each side of the border. A darker or lighter color is chosen for me based on the color I choose. So if I made different color sides of the border, including top, bottom, and so on, each using groove for instance, then I would finally have 8 colors in the complete border. What I am saying, and I apologize for being unclear, is that I would like to be able to choose the relationship between those two colors in one side of the border, or at least have more options than I do now. Now, I can choose one color for one side of the border, and using groove or ridge will tell the browser to calculate the other color (again, just for one side of the border) based on some formula. I don't see why another formula can't be substituted, or indeed why I can't just specify 2 colors for the one side of the border. But just to be serious for a second, I do enjoy the discussion. HTH, Andrew From: Barney Carroll barney.carr...@gmail.com To: Alan Gresley a...@css-class.com Cc: Andrew C. Johnston attyjohns...@yahoo.com; css-d@lists.css-discuss.org css-d@lists.css-discuss.org Sent: Monday, June 6, 2011 11:17 PM Subject: Re: [css-d] A question about 2-color borders (grooved, ridge etc.) On programmatically achieving abstract optical effects with an eye to beauty and design standards (warning: huge philosophical digression)… On 6 June 2011 07:48, Alan Gresley a...@css-class.com wrote: I guess you're learning. Not to start qualitative debates on CSS lists? Vry slowly. People giving me the time of day certainly isn't helping ;) I thought inset and outset borders were in CSS2. Why are you cynical of CSS3? Inset and outset borders are a great example of an abstract optical effect getting a programmatic definition in CSS2. CSS3 offers many more opportunities (border-image, double border, gradients, box shadow, etc). I was basically being a design snob, inferring that these were a slightly less dramatic analogy of giving Comic Sans and Papyrus fonts to somebody making a business presentation. The properties described can be created using long-established alternative means by someone sufficiently dedicated to use graphics software and experiment with the desired visual outcome regardless of what can quickly be written in CSS. With specific regards to plain old CSS2 borders, I would test and adjust each combination of colours individually. So if you haven't tested, how is it that you can express such an opinion? I've done plenty of testing, but mostly with the purpose of achieving designs to a certain standard for extensive public-facing sites, as opposed to arbitrary quantitative feature-detection (ie does the inset border style exist? check; can we use a variety of colours? check; problem solved). Basically it comes down to your ambition of vision and extensible replication with regards to artistic control. This is not to say I won't use purely ornamental CSS3 extensions at all, but they are abused by programmers too lazy to create the same effects to a better standard without said extensions. Can you prove that absolutely? This is the crux of the matter: there's no automated unit test for aesthetic value and optical illusion effectiveness. In short, when you're talking about optical illusions and a certain level of detail with coherent aesthetics, I don't believe it's possible to algorithmically generate the lot based on small input values. I don't follow what you are saying here. Basically, while the CSS your provided effectively achieves an optical illusion that suggests an embossed panel by virtue of consistent lighter and darker geometric shapes suggesting a light source over a 3 dimensional object, I don't believe the 21st century man on the street would ever consider this worth representing as a standalone 'feature'. In the early 90s it might've invoked a sense of cool because it implied the upper limits of popular emerging computer graphics interfaces of the time. I'd struggle to find a client who would take me seriously if I proposed this as a design. Yes, I have. See the example above and the example in my reply to Andrew. I'm still working on the maths but I believe I have hit the most aesthetic values. Again, I'm very intrigued in the notion of 'working on the maths' to get the 'most aesthetic values', especially seeing as you believe that target has already been achieved by a 4-tone blue box whose inset panel has a higher hue saturation than the outer surface. But it is all relative — it *is* possible to achieve a certain standard of raised box effect based on procedurally
[css-d] A question about 2-color borders (grooved, ridge etc.)
Hi All: In working on a new template, I noticed something about borders that I find to be very limiting, and wonder if anyone thinks there will be improvement in the future. I do not play a real designer on tv or in real life, but I have come to like ridged, grooved, inset/outset borders, which have two colors to them. Don't laugh at me, they are cool! I don't care what anyone else says. Anyways I was trying to get the look I wanted recently and found that the darker part of the border was too dark. For all of these types of borders, I can select the color I want, and the computer uses some sort of function or algorithm to determine the color of the darker part (maybe this process can be reversed in some cases, where the user determines the darker color and the function chooses the lighter color, but its the same basic process). When I was learning about CSS, I saw many examples of techniques that utilized very large borders to show some effect or other, and the contrast between these lighter and darker colors is nice. But when I try to make 2-5 px borders for instance I find that no matter what color I choose, the other part is very, very dark. And if I then choose a still lighter color, the other part...is still just dark. It seems I should be able to have at least some influence on both the colors, and this seems to me to be not a very big issue technically. Right now, as I said (and I am no expert, so correct me if I am wrong. I know you will anyway), it seems that one function or whatever is used each time to render the border. Best case scenario would be that I could choose precisely what color I wanted for both parts, but it would be an improvement if there were a couple different functions to choose from, (extra light, regular, darker, whatever) so that I could allow my darker part to lighten up a little and not be so serious. Am I wrong about this? Am I missing something? Or can I dream of the day when my control of webpages is just a little more complete? Kind Rgrds, Andrew __ 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] Side-Header Image...Minor Followup
Just a minor followup, sorry to burden the list, but perhaps it will benefit someone. Upon closer inspection the comment code surrounding the javascript must remain, otherwise it throws up a lot of errors when validating. The rest of the comment code can / should be removed. __ 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] Side-Header Image Problem in IE 6, 7
Hello:
I hope someone can steer me in the right direction on this issue. As this is
ie
6 and 7, I don't expect too much ;-) But I need these browsers to work because
my client base uses them.
I have a site converted from a dreamweaver site, and still retains a javascript
header navigation bar, to swap out images on hover. I am too
lazy/unskilled/frightened to re-write it all into css. I had the code cut into
chunks to put in a management system (modx).
When the site was converted, I hacked out one piece of code, which served to
allow the header image to effectively span the entire width of the browser,
improving the look tremendously in my view, but causing errors in ie:
!--
body {
margin-top: 0px;
background-color: #EAEAEA;
background-image: url(http://www.rayxi.com/assets/images/bg2.gif);
background-repeat: repeat-x;
}
--
The site now validates, and I went back to this issue recently, it turns out
this css comes first, right before the javascript starts, and before the css
stylesheet is called. It doesn't work at all if put in the stylesheet, for me
at least.
So when I try to put in back in, it looks fine except ie 6 and 7 both have
trouble, in ie 6 it seems to prevent any images to be displayed in the page.
Test page is here: http://www.rayxi.com/index.php?id=63
I tried researching ie bugs, but its a wide sea of information and I almost
drowned. Can someone point me in the right direction?
Kind Regards.
__
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] Side-Header Image Problem in IE 6, 7
Andrew C. Johnston wrote:
When the site was converted, I hacked out one piece of code, which served to
allow the header image to effectively span the entire width of the browser,
improving the look tremendously in my view, but causing errors in ie:
!--
body {
margin-top: 0px;
background-color: #EAEAEA;
background-image: url(http://www.rayxi.com/assets/images/bg2.gif);
background-repeat: repeat-x;
}
--
The site now validates, and I went back to this issue recently, it turns out
this css comes first, right before the javascript starts, and before the css
stylesheet is called. It doesn't work at all if put in the stylesheet, for me
at least.
Is it /possible/ that, when trying to transfer it to the stylesheet,
you left in the HTML comments markers :
!--
and
--
If so, these should be omitted when inserting the remainder
in a valid CSS file.
Philip Taylor
_
Hmm, I left those in on the javascript not knowing they were not needed. Not
sure how well I follow you but let me report that:
The link I sent before *had*
script
body element (with comment code)
/script
script
java (with comment code)
/script
stylesheet.
Now I have stripped out all comments, and it still seems to work but also still
seems to have the same problem in ie.
Plus, I have a new page to test your line of thinking, with all comment code
out
and it successfully puts the body element in the stylesheet instead of before
the java, which didn't work before. So you pointed me in the right direction
for sure, must have been the comments that messed that up. I don't think I
would have taken the comments into the css, I know a bit about what css code
looks like, so maybe the comment code in the java did something.
New link here: http://www.rayxi.com/index.php?id=197
But, it still seems to have the same problem is ie.
Maybe I have made a mistake, I will need to go over this again. In ie, its
almost like my stylesheet isn't being accessed, because every aspect of the
stylesheet isn't showing up, only html stuff is appearing.
__
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] Side-Header Image Problem in IE 6, 7
Are these, in combination, not likely to be the source of the problem ? base href=Rayxi Consulting/base link href=assets/templates/andrew/css/cncss.css rel=stylesheet type=text/css/ which together give you (approximately speaking) link href=/Rayxi Consulting/assets/templates/andrew/css/cncss.css rel=stylesheet type=text/css/ Philip Taylor ___ Thanks Philip for your assistance. I will pull that out and test, but I have that code in all templates on the site, and no other pages have trouble, just the addition of the body element causes the problem. In other words, no body element, no problem. Add in the body element into the css file, then the problem appears. __ 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] Side-Header Image Problem in IE 6, 7 - Solved
Are these, in combination, not likely to be the source of the problem ? base href=Rayxi Consulting/base link href=assets/templates/andrew/css/cncss.css rel=stylesheet type=text/css/ which together give you (approximately speaking) link href=/Rayxi Consulting/assets/templates/andrew/css/cncss.css rel=stylesheet type=text/css/ Philip Taylor ___ Thanks Philip once again, pulling out the base href=[(site_name)]/base solved the problem, in combination with your earlier advice about the comment code. Really appreciate your assistance, I could never have figured it out by myself. Best Wishes, Andrew __ 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] browser check (Matthew P. Johnson)
Site looks good, other than the misspelling in the header image... Message: 16 Date: Fri, 11 Feb 2011 14:58:24 -0800 From: Matthew P. Johnson i...@ecoitsf.com To: css-d@lists.css-discuss.org Subject: [css-d] browser check Message-ID: 009d01cbca3f$31014bb0$9303e310$@ecoitsf.com Content-Type: text/plain;charset=us-ascii Hi Ya'll I am almost finished with our house site. Can you let me know if it displays correctly in your browser/os? Tanks :0) http://applegateelements.com/ Matthew P. Johnson | Eco I.T. 708 Bay Road Mill Valley CA 94941 | 415.254.1563 | http://ecoitsf.com ecoitsf.com P Please consider the environment before printing this email. __ 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/
