Re: [css-d] mac vs pc
Is it possible that the fonts that your CSS specifies (especially those classed as !important) exist on PCs but not on Apple Macintoshii ? Philip Taylor S Baily-Gould wrote: Sorry, Theresa from the CSS list pointed out that you have to log in to Hubspot to help. The same page is already live at the client's site at http://www.vernassoc.com/ Same issues I mentioned below, except for the last one, regarding the Painting a Map of Sixteenth-Century Mexico City text because that doesn't exist in original home page. I don't think I am authorized to give you the Hubspot login. But again live site has same problems. Thanks in advance for any help, Sydney __ 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] android blackberry emulators
On 04/07/2012 03:25, David Laakso wrote: I've no idea about that site, but the official Android SDK includes an If accuracy is your bag in the end you'll want to break down and purchase a mobile device and save the receipt for your business accountant. I think in the end you'll want several devices, aside from the different OS versions, the different UI layers from different manufacturers and different form factors can have a significant effect when actually using a device. On 04/07/2012 04:21, Philippe Wittenbergh wrote: probably better Safari release builds, as Chrome has a much faster release cycle, esp compared to the default browser included with Android Staring with 4.1 tablets, Chrome will become the default browser on Android devices. Where Simulators of all kind fail completely is testing interaction design. You could always install the emulator on a Windows 7 tablet... Rob __ 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] Odd behaviour of block elements
Hi everybody, We are used to the width of block elements being 100% by default. HTML5 new 'divs' such as section, article, footer, etc seem to behave like that when declared as 'display: block;' This corresponds with Eric's reset.css. The odd behaviour, in my eyes, is that as soon as you use 'position: ;' on on of those block elements, including the old div, they seem to loose their 100% width. Three questions, is this established normal behaviour that should be expected? What other attributes loose their values? Is the remedy to add a general 'width: 100%;' for example in reset.css, or am I better served by specifically having to write the width attribute on the selected elements? Tia Niels -- Niels Muller Larsen, MSc Programmer, College Professor We really don't have any enemies. It's just that some of our best friends are trying to kill us. __ 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] Odd behaviour of block elements
Hi Behaviour is expected. Floated and absolutely positioned elements lose their 100% width by default. See http://jsfiddle.net/6De85/6/ for example. You should specify the width for selected elements rather than using general width for positioned elements. Ville 2012/7/4 muhle...@gmail.com muhle...@gmail.com Hi everybody, We are used to the width of block elements being 100% by default. HTML5 new 'divs' such as section, article, footer, etc seem to behave like that when declared as 'display: block;' This corresponds with Eric's reset.css. The odd behaviour, in my eyes, is that as soon as you use 'position: ;' on on of those block elements, including the old div, they seem to loose their 100% width. Three questions, is this established normal behaviour that should be expected? What other attributes loose their values? Is the remedy to add a general 'width: 100%;' for example in reset.css, or am I better served by specifically having to write the width attribute on the selected elements? Tia Niels -- Niels Muller Larsen, MSc Programmer, College Professor We really don't have any enemies. It's just that some of our best friends are trying to kill us. __ 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-d] a media rule without a target media type
According to the CSS3 spec http://www.w3.org/TR/css3-mediaqueries/
@media all { … }
@media { … }
should be equivalent.
Current Firefox and Opera agree, and at least Webkit nightly too.
But current Safari, IE9 and IE 10 disagree, only the first one applies.
http://satzansatz.de/w3/media.html
My questions:
- The second rule, a media rule without a target media type, should be
invalid according to CSS 2.1, right?
- According to CSS3 mediaqueries example 7, an empty media query list
evaluates to true.
So @media { … } became valid in CSS3, correct?
Fun: IE 6,7,8 render both rules.
Thanks,
Ingo
__
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 media rule without a target media type
Le 5 juil. 2012 à 04:23, Ingo Chao a écrit :
According to the CSS3 spec http://www.w3.org/TR/css3-mediaqueries/
@media all { … }
@media { … }
should be equivalent.
Current Firefox and Opera agree, and at least Webkit nightly too.
But current Safari, IE9 and IE 10 disagree, only the first one applies.
http://satzansatz.de/w3/media.html
Yeah, those are slightly buggy…
I'm surprised that IE 10 (PR) has this wrong, as the issue was discussed fairly
recently on the www-style mailing list, if memory serves (ok, at least this
year). Can't find the thread though, may it was buried into another thread
My questions:
- The second rule, a media rule without a target media type, should be
invalid according to CSS 2.1, right?
Indeed, and the CSS validator agrees with that assessment.
- According to CSS3 mediaqueries example 7, an empty media query list
evaluates to true.
So @media { … } became valid in CSS3, correct?
Yes.
Fun: IE 6,7,8 render both rules.
We can always rely on old IE to bring some fun to the table…
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/
