Re: [css-d] Drop Menu failing on most Mobile Phones
At 20:02 -0600 on 11/28/2014, Karl DeSaulniers wrote about Re: [css-d] Drop Menu failing on most Mobile Phones: Yes. jQuery can make this work. Note that jQuery IS JS (under the covers) so the query of if JS is the only method that will work is answered since use of jQuery implies use of JS. Best, Karl DeSaulniers Design Drumm http://designdrumm.com On Nov 28, 2014, at 2:13 PM, Crest Christopher crestchristop...@gmail.com wrote: Thanks David, the example you provided doesn't have the nice collapse effect ! Do you think jQuery could iron out any quirks that this menu has, or strictly JS will only work ? Christopher David Laakso mailto:laakso.davi...@gmail.com Friday, November 28, 2014 2:20 PM On Fri, Nov 28, 2014 at 10:58 AM, Crest Christopher You may need js [off-topic for this list] for that to collapse in mobile. And even with js transitions can be problematic for Android. This is a CSS only method that may? work for you with transitions and max-height: http://ccstudi.com/site/playpen/nav-1.html Best, David Laakso Crest Christopher mailto:crestchristop...@gmail.com Friday, November 28, 2014 10:58 AM Hi, the following effect http://cssdeck.com/labs/navigation-dropdown-with-flip-effect is not collapsing on iPhone and it's not opening or collapsing on WP8.x. I can't say whether it works on Android as I didn't test on Android ? Christopher __ 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-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-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] Fwd: Re: Web fonts
At 08:02 -0400 on 07/31/2014, Chris Rockwell wrote about [css-d] Fwd:
Re: Web fonts:
-- Forwarded message --
From: Chris Rockwell ch...@chrisrockwell.com
Date: Jul 30, 2014 10:36 PM
Subject: Re: [css-d] Web fonts
To: Stuart King zinlo...@gmail.com
Cc:
Here is the culprit:
.column-content p {
font-family: Whitney A, Whitney B, sans-serif, Helvetica, Arial,
sans-serif;
line-height: 1.6em;
font-weight: 300;
color: #666;
}
I didn't check anything else for other declarations, so there could be more.
Note that with this declaration if Whitney A or Whitney B is not
available, the user's defined sans-serif font will be used. The
fallback to Helvetica or Arial will be short circuited by that first
sans-serif.
__
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] P tag can't be child of label ?
At 14:08 -0400 on 07/09/2014, Tom Livingston wrote about Re: [css-d] P tag can't be child of label ?: If you wrap the input with the label, you can leave off the 'for' attribute (just read that... had no idea about that one!). The use of the for attribute allows the label to not need to wrap the input. It just references the id of the tag that wraps the input (if I remember correctly). __ 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] P tag can't be child of label ?
At 20:01 -0400 on 07/13/2014, Crest Christopher wrote about Re: [css-d] P tag can't be child of label ?: Do you mean form ? No I mean the for parm of label. See http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#h-17.9 and http://www.w3.org/TR/WCAG20-TECHS/H44.html Robert A. Rosenberg wrote: At 14:08 -0400 on 07/09/2014, Tom Livingston wrote about Re: [css-d] P tag can't be child of label ?: If you wrap the input with the label, you can leave off the 'for' attribute (just read that... had no idea about that one!). The use of the for attribute allows the label to not need to wrap the input. It just references the id of the tag that wraps the input (if I remember correctly). __ 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] font-variant:small-caps;
At 14:01 -0500 on 06/16/2014, Richard Wendrock Forum wrote about Re: [css-d] font-variant:small-caps;: I used David's suggestion to solve the problem. Assuming Arial does not have small-caps variants, I switched to font-family: Verdana, Geneva, sans-serif; and that solved the problem. Thank you everyone! One warning - Even if you choose only families that have small-caps, it will not fix the problem UNLESS these families are universal (ie: Are on all your user's machines). Otherwise the selection will end up defaulting to the user's sans-serif default and the problem will still exist for that user. The only fix that will work is to use a downloadable font with small-caps. This, of course, assumes that the user's browser supports downloadable fonts g. __ 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?
At 11:24 +0100 on 02/17/2014, Peter H. wrote about Re: [css-d] Will the unsemantic HTML elements B and I be so: 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. The use of em and strong in lieu of i and b is aimed NOT at the visual presentation (ignoring screwing with the em-i and strong-b mappings via CSS) but at AUDIO (ie: Screen Reader) presentation. This way you can markup the text so the audio indicates the markup to these who listen as opposed to view the text. Of course, the text-to-speech mapping could in theory treat i the same way as it treats em, but that is a separate issue. __ 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?
At 13:59 -0500 on 02/14/2014, Chris Williams wrote about Re: [css-d] hiding things and bandwidth?: AFAIK, there are but two choices: 1) A mobile version of the page/site, users get redirected there based on client and you only load as needed for each client. This has a number of issues: different user experiences, non-portable links, multiple sites to test, etc. but is the easiest way to handle this issue. 2) Have the client determine what is needed and download as necessary. That's lazy loading, that's Javascript, and while a worthwhile topic and a useful method used more and more lately, it's off-topic here. Solves several of the issues with separate sites, but adds another language, testing, and layer of complexity. Chris How about controlling the sending of the optional stuff via Server Side Scripting? So long as the server can tell the difference between a mobile and a non-mobile user the optional page contents can be sent only to the non-mobile user. __ 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] child problems with li?
At 18:18 -0800 on 12/20/2013, John wrote about Re: [css-d] child problems with li?: On Dec 20, 2013, at 6:00 PM, John j...@coffeeonmars.com wrote: at this page: thinkplan.org the footer li nav appears to be being influenced by the header nav li CSS and I can not see whyany clues? think I solved it; put the top nav inside the header, renamed those header nav, header li and that broke the influence, but I still don¹t see why the footer nav and footer nav li would take their marching orders from the top nav am I right thinking this is an inheritance issue? While I have not looked at your page to try to see why you might be getting the results you are, I can point at one other reason aside from inheritance - CSS Sepecifity. This refers to the issue of what happens if more than one CSS rule matches some HTML. In that case the most specific match (or matches if the is more than one - each applying and being cascaded) is used. For example if you have a rule for nav li and one for ul li, both match a ul li enclosed in a nav and thus both will be applied in the order that occur in the CSS. If you do not want this to occur, you have to have some way of telling the difference in the two rules such as what the nav is enclosed in - IOW: Header Nav ... vs Footer Nav ... or something like that. By staring the rule with Header or Footer, you prevent a nav li rule from being applied to a nav ul, or other cases since only a header or footer section would be a match. Also a nav ol will override a nav li if one case is has the li enclosed in ul and the other in ol (the nav li would thus only apply to the ul case but not the ol one). thank you, John __ 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-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] Two classes, two conflicting rules, which wins ?
At 20:17 +0100 on 10/01/2013, Philip Taylor wrote about Re: [css-d]
Two classes, two conflicting rules, which wins :
Chris Rockwell wrote:
That is why it works that way, yes.
The engine sees two widths, both with the same weight, origin and
specificity; the last one to be declared will win.
If instead, you did:
div.c1 {width:20em}
.c2 {width:30em}
The width would be 20em, because div.c1 is more specific.
Yes, the last example is clear; it was only the 'class=c1 c2'
about which I was uncertain.
Philip Taylor
So you are saying that in a 'class=c2 c1' case, it scans the CSS
defs, sees .c1 and applies it, keeps going and sees .c2 which
overrides the c1 width?
IOW: The order that you list the class in the HTML is ignored and
only the order that the classes are defined in the CSS defs counts.
__
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] Where do you cut-off your browser support?
At 10:51 -0400 on 09/22/2013, Tom Livingston wrote about Re: [css-d] Where do you cut-off your browser support?: But we recently had a client ask (tell) us to support IE7 as that's what they use internally still and, according to their own stats, have a significant user base on 7. Of course if they use it internally, they are going to show a significant user base on 7 - or are they talking about only external users and not counting their internal users? __ 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] html email with css
At 14:52 +0100 on 09/06/2013, Philip Taylor wrote about Re: [css-d] html email with css: What I do think is pandering to the manufacturers is using inline styles because they are too lazy to parse styles found in the head region, repeating styles in inner elements because they are too lazy to implement inheritance properly, and so on. There is also the issue that you are forced to send bloated messages (slowing the reception) due to their failure to follow standards. A message that uses header styles is much smaller than the same message with in-line styling. It is also harder to generate the message text itself since you have to locate where each style is needed and add a copy of the style parm there. __ 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] accents on e in Resume
At 23:17 +0100 on 06/20/2013, Philip Taylor wrote about Re: [css-d] accents on e in Resume: Incidentally, as you can type e-acute (é) in your e-mail, why not enter them the same way in your web page ? I assume you are working in UTF-8 and not ASCII/ISO-8859-1. This letter is part of the ISO-8859-1 character set (as shown by its code being between 160 and 255. Codes between 128 and 159 are control codes not glyphs unless your charset is Windows-1252 which replaces these useless/legacy codes with useful glyphs (which in Unicode end up on the 8xxx range). __ 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] Trumping bad proprietary code.
At 19:45 +0100 on 11/06/2012, =?UTF-8?B?U3VzYW5uZSBKw6RnZXI=?= wrote about Re: [css-d] Trumping bad proprietary code.: But all other methods have a real effect (and side effects), that may not fit in a special environment. zoom: 1; is wonderful meaningless, it does nothing (beside fixing a stupid old IE bug). The only real problem I see, is that you might miss an important validation error, when you get used to ignoring some. The fix for that is to update the W3C Validator to just issue a Warning for zoom:1 or even better to have a setting to ignore it totally. Note that in either case, it is ONLY zoom:1 that is special cased - Any other zoom (such as zoom:1.5 or zoom:2) would still get an error. __ 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] Trumping bad proprietary code.
At 15:25 + on 11/06/2012, Philip TAYLOR wrote about [css-d]
Trumping bad proprietary code.:
Wishing (as always) to keep my sites 100% W3C standards compliant,
I am stuck with a bad property in proprietary code. The offending
rule reads :
.qmmc {position:relative;zoom:1;}
Just so you are aware, zoom:1 is a Windows/IE hack/fix to set
HasLayOut so the element displays correctly. Aside from making the
code display correctly in IE, it has no downside/effect with non-IE
browsers so you can ignore it (or consider it W3C compliant since its
purpose it to make IE act W3C compliant).
__
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] on html and css versions
At 16:57 -0400 on 08/01/2012, Tedd Sperling wrote about Re: [css-d] on html and css versions: What is wrong with using? !DOCTYPE html Sure it doesn't have a *real* DTD, but the W3C validator does somehow validate pages that have this DOCTYPE declaration, right? So, there must be some sort of *standards* it validates contents against, right? Where/what is that DTD? I think that would be an interesting thing to know. You are missing two points. First is that while browsers may not actually use the referenced DTD (the http... clause), they do parse the HTML based on the DOCTYPE html PUBLIC... clause and treat the HTML differently based on what you declare. Second is that just because the Validator approves of the supplied HTML5 HTML, that does not mean that a browser will not choke on it or display the code properly. This is not the case with pre-HTML5 DOCTYPES where if the Validator approves of the code, the browser will correctly parse, interpret, and display it. IOW: At the current time, !DOCTYPE html throws the browser into tag soup mode where it tries to figure out what it is being supplied with as opposed to knowing how to parse and handle it. __ 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] non-English characters: omit accents when using text-transform:uppercase
At 14:11 +0300 on 07/22/2012, sweepslate wrote about [css-d] non-English characters: omit accents when using tex: I want to text-transform:uppercase a piece of text writen in Greek. The Greek language requires that: a. in lower case text, some letters need to have accents --and b. in full upper case text, LIKE THIS, have no accents at all My problem is: if I use the uppercase property I will end up with upper case accented text, which is a typographical error. I could write the text, inside the HTML, in lower case and omit the accents - but that would make it a typographical error when viewed without CSS. I could write the text using upper case characters, inside the HTML, and omit the accents - but using upper case in this webpage is a decision of style, not content, so I'd rather do it with CSS. Any ideas? How many blocks of Greek text is this needed for? Are the accented letters a different Unicode codepoint from the same letter unaccented or is it unaccented letter followed by the accent? If so, you can just use find/replace to do the conversion of the text in the HTML. One way that this may work is if you can duplicate the text in both lower and upper case and then just use span with class tags to mark each version. Use style=hide to not display the version you want. I may be misunderstanding your needs so this advice might not be what need. __ 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] font-face declarations
At 11:53 -0400 on 06/29/2012, Tom Livingston wrote about [css-d]
font-face declarations:
I got the following from FontSquirrel:
@font-face {
font-family: 'AlegreyaRegular';
src: url('Alegreya-Regular-webfont.eot');
src: url('Alegreya-Regular-webfont.eot?#iefix')
format('embedded-opentype'),
url('Alegreya-Regular-webfont.woff') format('woff'),
url('Alegreya-Regular-webfont.ttf') format('truetype'),
url('Alegreya-Regular-webfont.svg#AlegreyaRegular') format('svg');
font-weight: normal;
font-style: normal;
[snip]
My question is, shouldn't the declaration for AlegreyaBold use
font-weight: bold; instead of 'normal'? And should AlegreyaItalic use
font-style: italic; - again, instead of 'normal'?
If so, why would FontSquirrel use 'normal' in these cases?
I think it is correct. Saying italic or bold asks the browser to
either select an italic/bold version of the roman font requested or
fake the style if there is no italic/bold of the font. Since you are
supplying a pre-formatted font you want to use it as-is so normal is
the correct setting.
To see what happens if you mix font-weight/style with an italic/bold
font, try asking for one that you have on your machine and the add a
style to it and compare with the same font with no style.
TIA!
--
Tom Livingston | Senior Interactive Developer | Media Logic |
ph: 518.456.3015x231 | fx: 518.456.4279 | mlinc.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] Responsive Design Issue
At 23:41 +0200 on 04/24/2012, Gabriele Romanato wrote about Re: [css-d] Responsive Design Issue: Why should we get rid of a piece of design when you have a CSS3 property for that? Use background-size. It works. Maybe since use of background-size assumes/requires that the device's browser supports the property. Attempting to use it with a non-CSS3 Supporting Browser causes the background image to display. You need to use a solution that works with all browsers. __ 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] question on media queries and full screen browsers
At 17:32 -0600 on 04/14/2012, Debbie Campbell wrote about [css-d] question on media queries and full screen browsers: I'm using media queries for desktop vs. tablet vs. smartphone on my site (and the media query code is taken directly from the developer of the Lynda.com adaptive design course). [snip] I don't know how to fix this, especially since I can't see it happening. Can someone help? I think the value of device-width (ie: The Current Window Width is available to PHP? If so, you might want to add some debugging code to supply it as a readable display on the page. That would show something for the user who is getting the wrong style sheet to report. Also put out a set of debugging comments on the page that report on which style sheet is being selected (in the style sheet have the lines marked as visibility:hidden except for the one that IDs THAT style sheet). You can also insert the two device-width values in each line if available. __ 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] How to make a div fill the height of an iframe
At 08:32 + on 03/23/2012, Luis Cabral wrote about [css-d] How to make a div fill the height of an iframe: Hello, I have the following scenario: - An iframe that has fixed width and height and is absolutely positioned in the middle of the screen (simulating a modal pop up window)- The document inside that iframe contains 2 divs, both 100% width. The top one is variable height, and the bottom one should occupy the space left inside the iframe. If required, scrollbars should display in the bottom div, but not in the iframe itself. I made a diagram to try to make it clearer: +-iframe (fixed width and height)|+-div1||variable height|+---|+-div2||height should occupy the ||remaining space in the div, scrollbars show ||inside the div if required if its contents ||are bigger than the available space|+--+-- Note that this slightly different from the usual requirement, which is to dynamically resize the iframe accordingly to its contents. Is this possible to be done with just CSS? (assume the most recent browsers will be used i.e. Chrome, IE8+ etc) ThanksLuis __ 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/ If you make the 2nd DIV a table would that work (ie: Show the scroll bars as needed but not affect the height of the iframe or add scroll bars to it)? __ 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/
